23 June 2026
Written by Sajid Fense, Founder
What employment documents has each of your staff actually been issued?
Whatever the person hiring had open at the time, unless you keep an issue log recording what each person was sent and when.
Employment paperwork drifts faster than any other document type in a business, and the reason is structural. It is issued by whoever happens to be hiring, at a moment when they are focused on the candidate rather than the document, from whatever file they used last time.
Nobody is careless. The process simply has no single owner, because hiring is distributed and document control is not.
What the drift looks like
Start from one employment contract. Someone hires a second person in a slightly different role and edits a copy. Someone else hires for a third role and edits a copy of the copy. A year later, a clause is updated: in the version the person doing the updating happens to have.
After three years and fifteen hires, a business typically has somewhere between four and nine distinct employment documents in issue, differing in ways nobody chose. Notice periods vary by a week for no reason. Some contracts contain a confidentiality clause and some do not. Two people in the same role are on materially different documents because they were hired eight months apart by different managers.
None of this is visible from the shared drive, because the drive holds templates and the drift lives in what was sent.
Organise by role, not by person
The structural fix is to stop treating employment documents as per-person artefacts and start treating them as per-role ones.
A role-based set means: for each role type in the business, there is one current document, and hiring into that role means issuing that document. Personalisation is confined to a schedule at the front (name, start date, remuneration, reporting line) while the body stays identical across everyone in that role.
This does two things. It makes the question "what are our engineers on" answerable, and it makes updating a term a single edit rather than an archaeology project.
Most businesses need fewer role types than they expect. Full-time salaried, part-time, casual, and fixed-term covers a large proportion; adding a couple for genuinely different arrangements usually completes it. If the count climbs past eight, the roles are probably being defined by seniority when they should be defined by engagement type.
The issue log
The register that makes the whole thing usable is a log of what each person was actually issued.
Four columns: person, document and version identifier, date issued, date signed and returned. Optionally a fifth for any variation agreed.
The last column matters more than it looks, because employment terms get varied by letter (a promotion, a change of hours, a new reporting line) and those letters end up in personnel files rather than with the contract. A person's actual terms are the contract plus every variation letter, and that set is not reconstructable unless somebody records it as it happens.
The log answers the question that is otherwise unanswerable: for this person, what do they hold, and what is the complete set of documents that make up their terms.
Sequence the onboarding
Alongside the set and the log, write down what gets issued, by whom, in what order, for a new hire. Not a policy: a sequence.
A workable one names the document, the person responsible by role, and the point in the process it happens. Offer, then contract, then policies acknowledged on day one, then any role-specific documents within the first week. The value is not in the specific order; it is that the order exists, so that a manager hiring for the first time does not assemble their own.
This is also where the drift gets stopped at source. If the sequence names where documents come from (the current set, not a colleague's copy) then hiring stops generating new versions.
Review triggers
Employment documents need reviewing when things change, and the changes that matter are rarely on a calendar.
Useful triggers: the business takes on its first employee in a new state, a role changes enough to need a different arrangement, remuneration structure changes, the business crosses an employee headcount threshold, or an award or industrial instrument that applies to your workforce is updated.
Attach the trigger to the role type, so that a change fires a review of one document rather than all of them.
Catching up
If this has never been done, the recovery is an audit rather than a rebuild. Take each current employee, find what they were issued, record it, and note any variation letters. This is tedious and it is finite: a few hours for most businesses.
The output is the issue log, populated with reality rather than intention. It will show clusters: groups of people hired in the same period on the same document. Those clusters are the natural unit for anything that needs to change.
The boundary
Organising documents by role, logging what was issued, and sequencing onboarding is filing work, and it is the part a business can do for itself.
Whether any term complies with an award, an enterprise agreement or the Fair Work Act, and what any clause does, are questions for your own external adviser. The audit is what makes that a bounded question. They can look at four current documents and a list of who holds what, rather than fifteen personnel files.