Client Requirements and Audits
Clients increasingly specify how the workforce is tracked, and audit whether it was. What they ask for, and what is worth agreeing at tender rather than discovering later.
Commercial · Analysis
On commercial and public work the client frequently specifies the workforce arrangements, and the specification arrives as a contract requirement rather than a suggestion.
For teams turning client requirements and audits into a repeatable record, online timesheets for site teams provides a useful operational reference for time, attendance and reporting workflows. It should be assessed alongside ISO standards catalogue so the software choice remains grounded in site practice and applicable guidance.
What clients typically require
A named access system, or a category of one.
Competence standards above the statutory minimum: a specific scheme, a card level, additional training.
Reporting: headcount, hours, demographics, local employment, apprentice numbers.
Right-to-work verification evidenced rather than asserted.
And on public work, certified payroll or prevailing wage returns.
The reporting that surprises contractors
Social value commitments — local labour percentages, apprentice hours, training weeks — which are increasingly contractual and are measured from the workforce records.
Which means the register has to capture the attributes those commitments are counted in: postcode of residence, apprentice status, trainee hours.
Captured at enrolment, because it cannot be reconstructed, and captured with a stated purpose because it is personal data collected for a commercial commitment rather than for safety.
A contractor who agreed a local labour percentage and did not capture postcodes has agreed to report something it cannot measure.
Auditing
Clients audit these things, and the audit looks at records rather than at intentions.
Typical questions: show me who was on site on this date; show me their competence evidence; show me the induction record; show me the returns for this week.
Which are the same questions an incident investigation asks, and preparing for one prepares for the other.
The audit that catches people is the one asking for a date eight months ago, because that is when the records were being kept casually.
What to agree at tender
Exactly which attributes are to be reported and how they are defined — "local" varies by client and by scheme, and agreeing the definition later is a dispute.
The reporting frequency and format.
Who bears the cost of a client-specified system, which on a small project can be disproportionate and is legitimately priced.
And the retention and handover of records at completion, because the client will want them and the format should be agreed before the data exists.
Where the requirement is disproportionate
A client standard written for a major project applied to a small one.
Which happens routinely and is usually the result of a single framework document rather than a considered decision.
Ask. Most clients will accept an equivalent arrangement if one is proposed with reasons, and the conversation is far easier at tender than at mobilisation.
The audit trail that survives
Records assembled continuously rather than reconstructed for the audit.
Which means the reporting fields are captured at enrolment and the returns are produced weekly rather than at the point of request.
A contractor producing a year of returns in the week before an audit is producing a document, not a record, and it usually shows.
The measure
Reporting produced on time, as a proportion of periods.
Audit findings, by category.
Attributes captured at enrolment against attributes required by contract, which is a comparison worth running at mobilisation rather than at the first report.
Preparing for an audit properly
Assemble the pack for a randomly chosen past date, before the auditor picks one.
Time it, and note what was missing.
Do it twice a year and the audit becomes a routine rather than an event.
The sites that struggle are the ones whose first attempt at this is the audit itself.
Where client requirements conflict with each other
A client standard requiring biometrics and a data protection position that cannot justify them.
A reporting field the client wants and the workforce has no obligation to provide.
Raise it rather than complying quietly, because the obligation to justify the processing remains with you regardless of who asked for it.
"Our client required it" is a reason and not an assessment, and an auditor of the other kind will say so.
Preparing for the audit you will get
Pick a date eight months ago and assemble everything for it.
Who was on site, their engaging company, their competence status on that date, the induction version, the returns for that week.
Time it.
The gaps are what the audit will find, and finding them yourself costs an afternoon rather than a finding.
When the client's system is the record
Some clients require their own system, and the records then live with them.
Which is convenient until the contract ends and you need them for a dispute.
Agree an export at completion, in a usable format, as a contract term — because after handover the data belongs to somebody with no reason to help.
More in this section