Forward-Deployed Engineering · Staffing · Payroll, billing and workforce compliance
Case study: contractor timesheets and compliance files, from three kinds of paper to an approved payroll batch
Illustrative engagement — not a client record. The company, people, volumes and results below are a representative composite, written to show how a forward-deployed engagement runs end to end. The workflow, the architecture, the controls and the method are real and technically valid.
Offering usedIntegration & Data OnboardingYour systems of record connected, your data modelled and governed.
Illustrative results, first three payroll cycles after cut-over, in-scope sites only:
71%
Timesheet lines validated with no re-keying
Before 0%
2.5 working days
Days from timesheet cut-off to an approved payroll batch
Before 6.0 working days
0.8%
Workers with a correction in the following cycle
Before 3.1%
99.5%
Billable hours invoiced in the cycle they were worked
Before 96.4%
Explainer09 scenes
The whole story in about a minute
Nine short scenes, from the pay-cycle crunch to the results. Press play, or pick a scene.
Every fortnight and monthhours in three shapes
1 / 5Missing or expired
11 in payroll, 5 in billing
Scene 01Before
Every pay cycle, hours arrived in three shapes.
3 in 100workers needed a correction in the following cycle
About 3,800 workers' hours came as portal exports, photos of paper sheets and emails. About three workers in a hundred needed a correction the next cycle.
- About 3,800 workers at 140 sites
- Portal exports, photos and emails
- 11 in payroll, 5 in billing
At a glance
- Client
- A staffing firm with about 3,800 contract workers placed at 140 client sites — warehouses, factories, facilities and back offices — across several states
- Workflow
- Timesheets from client portals, photographs of signed paper sheets and supervisor emails, validated against assignments, rates, overtime rules and client approvals, into payroll and billing batches; and a standing check that each worker's statutory and client-required documents are present and unexpired
- Engagement
- Integration & Data Onboarding, scoped per system across five systems, then Managed Operations from the month after handover
- Team
- One named senior forward-deployed engineer, full time, with a data engineer for the modelling weeks. Client side: the Head of Operations (owner), the payroll manager, the billing lead, the compliance officer, a platform engineer
- Where it runs
- The client's own cloud account and region. No data retained outside it
- Handover
- Runbook executed by the client's team in the last two weeks; our access re-scoped to the operations rota the same day
| Measure | Before | After |
|---|---|---|
| Timesheet lines validated with no re-keying | 0% | 71% |
| Days from timesheet cut-off to an approved payroll batch | 6.0 working days | 2.5 working days |
| Workers with a correction in the following cycle | 3.1% | 0.8% |
| Billable hours invoiced in the cycle they were worked | 96.4% | 99.5% |
| Batches paid or billed without a named person approving | not applicable | 0, by design |
FDE / 01Case study
01 / 12
In shortEvery pay cycle, thousands of workers' hours arrived in three shapes and were keyed in by hand, with mistakes.
Every fortnight and every month, the same crisis. Around 3,800 workers' hours had to become a payroll batch and an invoice batch, and the hours arrived in three incompatible shapes:
Client portal exports, a little under half. Each client's system produced its own spreadsheet or comma-separated file, with its own column names, its own date format and its own idea of what a shift is.
Photographs of signed paper sheets, about a third. Supervisors photographed the muster sheet on a phone. Some were crisp; some were taken at night, at an angle, with a thumb across one column.
Emails from supervisors, the rest. "Ramesh and four others did 12 hours Saturday, approved."
Eleven people in payroll and five in billing turned that into batches. The work was arithmetic under time pressure, and it leaked in both directions:
Underbilling. Hours worked but not invoiced in the cycle they belonged to, usually because a sheet arrived late and nobody went back for it.
Overpayment. Overtime at the wrong multiple, allowances applied to the wrong shift, or hours keyed for a worker whose assignment had ended.
Corrections. About three workers in a hundred needed an adjustment in the following cycle. Each one costs twice: the correction, and the worker's trust.
Compliance drift. Every worker needs a file: identity, tax and social security registrations, a bank account, and whatever the client's contract requires — safety induction, a trade certificate, a medical fitness certificate, a police verification. Certificates expire. The register lived in a spreadsheet, and an audit by one large client found a fifth of the workers on its sites had at least one missing or expired document.
FDE / 02Case study
02 / 12
In shortAn attendance app made a fourth shape of data, and clients could not see it.
Eighteen months earlier the firm had rolled out a mobile attendance app for workers. It is still in use at eleven sites. It stalled everywhere else, for reasons that were nobody's fault:
The client's approval is the thing that matters. Clients pay against their own record of hours, whether that is their portal, their gate system or a signature on a sheet. A separate app the client does not see does not settle an invoice dispute.
Site conditions. Shared phones, no data coverage in some warehouses, and workers who change sites weekly.
It moved the problem. The app produced a fourth data shape, so payroll had four to reconcile instead of three.
Nothing was measured. There was no figure for how many lines needed a person, so there was no way to show whether the app helped.
The lesson, written into the scope, was that the work is not to change how hours are captured. It is to read what clients already produce and check it against what was agreed.
FDE / 03Case study
03 / 12
In shortThe work was to read what clients already send, checked against what was agreed.
Integration & Data Onboarding is scoped per system, so scoping was a survey of systems and of the data inside them. Five connectors were scoped and priced on their own: the intake channels, the staffing platform that holds workers and assignments, the payroll system, the billing side of the ERP, and the document store. The engineer spent a live cycle with the payroll team, two days at three client sites watching sheets being signed, and the rest reading records.
What was found:
The rate cards in the staffing platform were not the truth. For 18% of active assignments, a rate change had been agreed by email with the client and never entered. Payroll knew; they kept a side sheet. Any automation that trusted the platform blindly would have paid and billed the wrong amounts faster than before.
Three identifiers for one worker. The staffing platform, the payroll system and the document store each had their own key, and none was primary. Matching on name and phone number produced duplicates for common names.
Overtime meant three different things. The statutory position, the client contract's position on billable overtime, and what a particular supervisor had always approved.
Client approval evidence existed in every channel, in different forms: an approved flag in an export, a signature on a sheet, a sentence in an email.
Document expiry dates were readable but unreliable. Around a tenth of stored files were re-uploads of an older certificate under a newer name.
Photographs were about a fifth of intake by line count and would carry most of the residual manual work whatever was built.
The one-page scope, signed by the Head of Operations:
- WorkflowTimesheet intake from three channels, validation against assignment, rate, overtime rules and client approval, into a proposed payroll batch and a proposed billing batch; and a compliance check on each worker's statutory and client-required documents
- Out of scopeCandidate sourcing, screening, selection and any hiring or deployment decision; disciplinary matters; statutory filings and returns; client contract negotiation; the mobile attendance app
- MetricShare of timesheet lines validated with no re-keying, at or above 99.5% line-level accuracy on the golden set, with zero batches released without a named approver
- OwnerHead of Operations
- GuardrailsNothing is paid or billed without a person approving the batch. A missing or unreadable document holds the worker's compliance status and raises a task; it never marks a document present and never holds wages for hours already worked. The system makes no judgement about any worker's suitability
- Exit gateTwo cycles run in shadow against the team's own output, one cycle live with rollback armed, runbook executed by the client's own engineer
The clearest decision of the two weeks was the smallest: payroll's side sheet of agreed rate changes became a real record in the staffing platform, owned by the account managers, before any validation was built on top of it.
Timeline09 lanes
The engagement, stage by stage
Nine stages on one clock, from the old pay-cycle crunch to three cycles after cut-over. Press play, or pick a stage.
Lane 01 / 09 · Before
Pay cycle
Every pay cycle, hours arrived in three shapes.
About 3,800 workers' hours came as portal exports, photos of paper sheets and emails. About three workers in a hundred needed a correction the next cycle.
3 in 100
workers needed a correction in the following cycle
- Sub-shifts
- About 3,800 workers at 140 sites
- Portal exports, photos and emails
- 11 in payroll, 5 in billing
FDE / 04Case study
04 / 12
In shortTen weeks: connect the systems, model the data, build, run in shadow, cut over, hand over.
Ten weeks of build and handover, then Managed Operations from the following month.
the paused clock in week three
W0Scope
What happened
Scope page signed; access requested for the three intake channels, the staffing platform, payroll, billing and the document store
What existed at the end
The signed scope, the access register and a per-system scope for five connectors
What happened
Scope page signed; access requested for the three intake channels, the staffing platform, payroll, billing and the document store
What existed at the end
The signed scope, the access register and a per-system scope for five connectors
What happened
Repository created in the client's source control; engineer joined the payroll stand-up
What existed at the end
First pull request merged on day seven: intake from the shared mailbox and messaging export, hashed and threaded
What happened
Connectors for the staffing platform, payroll and the document store; portal exports for the eight largest clients. One client's export needed written consent under the services contract; the clock paused for three days, as agreed at scoping
What existed at the end
Connectors with tests against the live systems, and a data quality register
What happened
Worker, assignment, rate, shift and approval resolved across the three systems, with provenance on every field. Golden set agreed with payroll and billing
What existed at the end
One worker record across systems, and a golden set of 4,000 timesheet lines with known answers
What happened
Reading for all three channels, the validation rules, the flag set, the batch builder, the compliance check, the queues, the audit log and the dashboards
What existed at the end
A system producing proposed batches in parallel with the team
What happened
Two cycles run in shadow; every difference between the system's batch and the team's investigated
What existed at the end
A written difference log, and rules changed where the team was right
What happened
One cycle live at the 40 largest sites, then all in scope, with rollback armed
What existed at the end
Real batches approved by named people and paid
What happened
Client's platform engineer performed a release, a rollback, a new client's export mapping and a re-score without us at the keyboard
What existed at the end
Signed runbook, decision record, and the operations rota agreed
the paused clock in week three
Calendar time was ten weeks and three days. The three days were the paused clock in week three, recorded on the day.
FDE / 05Case study
05 / 12
In shortA model reads the sheets, rules check every line, and people approve every batch.
Try a timesheet
Pick a timesheet line. Watch where it goes.
The same checks run on every line. What the line says decides whether it joins the batch or waits for a person.
The timesheet line
A line from a client's portal export, marked approved
Line log
- 01IntakeStored in the client's storage with a hash, the sender and the thread
- 02ReadParsed as data, with this client's column and date mapping
- 03Worker recordMatched to one worker record by the worker code
- 04RulesActive assignment, hours inside the shift, rate from the rate record, approved flag present
- 05FlagsNo pattern found
- 06Proposed batchAdded to the proposed payroll and billing batches
- 07Named approverThe payroll manager and the billing lead approve by name
- 08Paid and billedWritten to payroll and billing only after approval
Paid and billed
Nothing reaches payroll or billing until a named person approves the batch.
Intake. Every file — export, photograph or email — lands in the client's storage with a content hash, the sender and the thread. The hash catches the same sheet sent twice; a perceptual hash catches the same sheet photographed twice from slightly different angles, which is more often carelessness than fraud and was previously caught only by someone with a good memory.
Read. Portal exports are parsed as data, with a mapping per client that names the columns and the date format. Photographs go through a layout-aware document model, then a language model in a private endpoint in the client's region, which fills a strict schema: site, date, worker name and code, in and out times, shift, hours, overtime hours, and whether a signature is present in the approval box. Emails go to the same schema. Every value carries the region of the page it came from, so a reviewer sees the evidence, not just a number.
Resolve. The worker on the sheet is matched to one worker record built across the staffing platform, payroll and the document store, with provenance on every field, using the worker code where present and the site's assignment roster where not. A name matching two active workers at the same site is never picked; the line is held.
Validate. Deterministic rules, not a model:
the worker has an active assignment at that site on that date;
hours fall inside the shift pattern and the daily and weekly limits, with overtime identified and paid at the statutory multiple, calculated daily or weekly, whichever is more favourable to the worker;
overtime is billable only where the client contract allows it and a client approval is present for it;
pay rate and bill rate come from the current rate record for that assignment, never from the sheet, and allowances apply to the shift actually worked;
approval evidence exists: an approved flag in the export, a signature in the approval box whose signer is on the client's list of authorised signatories, or an email from an address on that list;
arithmetic: the line sums to the stated total.
Flag. A second set of checks looks for the patterns that leak money. They never decide anything; they attach a reason and evidence to a line and send it to a person:
the same worker with hours at two sites on the same day;
hours after an assignment's end date or before its start;
a sheet whose totals do not equal the sum of its lines, or a photograph that is a near-duplicate of one already processed;
a run of identical round-number shifts unlike the site's own history, or overtime far outside the site's distribution for that week;
a bank account shared by more than one worker.
Batch. Clean lines are assembled into a proposed payroll batch and a proposed billing batch, each with a summary: totals, headcount, held lines and their reasons, and the difference from the previous cycle. The payroll manager and the billing lead each review and approve their own batch, by name. Nothing is written to the payroll system or the billing side of the ERP until that happens. There is no automatic release path, and none is configurable.
Wages are not held for the system's questions. A held line means a person looks at it, not that a worker waits. The queue is ordered by the payroll cut-off, and anything unresolved at cut-off goes to the payroll manager, who decides — usually to pay the undisputed hours now and settle the rest next cycle.
Compliance files. For every worker the system reads the document store, extracts document type and expiry date, and sets a status: present and unexpired, expiring within 30 days, expired, missing, or unreadable. Identity documents are stored with the identifier masked as the regulator requires. The status is set by rule from the extracted date; the model never infers a date, never carries one over from a similar document and never marks a document present because another looks like it. Missing, expired and unreadable all raise a task to the compliance officer, and each client's pack lists its workers' status honestly, gaps included. Whether a worker may continue on site is a decision for the compliance officer and the account manager with the client. The system does not make it.
- Model
A model reads documents and photographs and fills a schema.
- POS
Rules validate.
- Caller
People approve.
- Person
No model decides pay, a bill, a compliance status or anything about a worker's standing.
The system holds no opinion about any worker's suitability, does not read CVs, does not score workers and takes no part in hiring, selection or deployment.
Audit and monitoring. Every line, with its source region, rule results, flags, model versions and the approver's name, goes to the client's log store. Dashboards show intake by channel, validated share, held lines by reason, cycle progress against cut-off and accuracy from the weekly sample. Thresholds page whoever is on the rota.
System map20 objects
How the pieces connect
Every part of the system and of the story, lit one scene at a time. Press play, or pick an event.
Graph · 20 objects2 selected
- Client sites140Site
- Payroll team11 + 5 billingTeam
OntologyTimesheets and compliancePay cycle
Payroll team
Team11 + 5 billing
Every pay cycle, hours arrived in three shapes.
3 in 100 · workers needed a correction in the following cycle
About 3,800 workers' hours came as portal exports, photos of paper sheets and emails. About three workers in a hundred needed a correction the next cycle.
Properties
- Type
- Team
- Links
- 2
- State
- In this scene
Linked objects01
- Client sitesSite
FDE / 06Case study
06 / 12
In shortA test of 4,000 known timesheet lines, where holding a line counts as a correct answer.
The golden set was agreed with payroll and billing in week five.
4,000 timesheet lines from three prior cycles, across all three channels, the 40 largest sites and a tail of small ones, day and night shifts, weeks containing public holidays and weeks containing a rate change.
Answers taken from what was finally paid and invoiced, after corrections, not from what the sheet appeared to say.
A red-team slice: a sheet submitted twice, once as a portal line and once as a photograph; a worker with hours at two sites on one day; hours after an assignment ended; a total altered on a paper sheet; an approval signed by somebody not on the authorised list; a certificate re-uploaded with a new name and an old expiry; a night-shift sheet photographed badly enough to be genuinely ambiguous, whose correct answer is "hold".
- RT-01a sheet submitted twice, once as a portal line and once as a photograph
- RT-02a worker with hours at two sites on one day
- RT-03hours after an assignment ended
- RT-04a total altered on a paper sheet
- RT-05an approval signed by somebody not on the authorised list
- RT-06a certificate re-uploaded with a new name and an old expiry
- RT-07a night-shift sheet photographed badly enough to be genuinely ambiguous, whose correct answer is "hold"
Field-level scoring on worker, date, hours, overtime hours, rate and approval, so a line with the right hours and the wrong overtime split counts as wrong.
A hold is a correct answer. The suite scores refusals as well as readings, because a system that guesses a night-shift photograph is worse than one that asks.
- worker
- date
- hours
- overtime hours
- rate
- approval
WHOLE ORDER · ALL 6 FIELDS
TAP A FIELD
The suite runs in the client's CI. In week seven it failed a candidate. A change to the photograph pipeline improved reading of printed muster sheets and degraded handwritten "7.5" into "75" on two sites' forms often enough to move the hours field below threshold. It never reached a batch. Two changes followed: a plausibility rule that no line may exceed the spread-over limit without a flag, and a rule that a reading whose digits imply more hours than the shift pattern allows is always held.
FDE / 07Case study
07 / 12
In shortEverything stays in the client's own cloud, and no batch is released without a named approver.
Perimeter. Everything runs in the client's cloud account and region. Egress is limited to the private model endpoint, which retains nothing. Worker documents never leave the client's storage.
Identity. Connectors hold the narrowest scope that works: read on the staffing platform and the document store, write only to the batch tables in payroll and billing, and only after an approval is recorded. Our engineer's access ran through the client's identity provider and was re-scoped to the operations rota at handover.
Personal data. Identity numbers are masked at rest as the regulator requires, bank details are visible only to payroll, and the pack a client receives lists statuses, not documents. Access to worker records follows the walls that already exist in the source systems.
Autonomy is bounded. No batch is released without a named approver. Held lines cannot be released in bulk without a reason recorded. Rate records cannot be changed by the system at all. Text in an email or on a sheet — including "urgent, approve and pay" — cannot change a rule or clear a flag.
Fraud flags are not accusations. They go to the payroll manager and the account manager, never to the client and never onto a worker's record as a mark. What happens next is a human process that existed before.
Review. The security team reviewed the design in week five and the deployment in week nine. Findings and their closure are in the decision record.
FDE / 08Case study
08 / 12
In shortTwo cycles in shadow, then live at the largest sites first, with a rollback flag that was not needed.
Two full cycles ran in shadow, and the two sets of batches were compared line by line. The differences fell into three piles. In the first the system was wrong, usually on a badly photographed sheet. In the second the team was wrong: allowances on the wrong shift, and one site whose overtime had been billed at the wrong multiple for two cycles. The third pile was policy nobody had written down — how to treat a worker who signs in at one site and is moved to another mid-shift — and went back to the Head of Operations as decisions.
Two full cycles ran in shadow
the system was wrong
the team was wrong
policy nobody had written down
went back to the Head of Operations as decisions
The live cycle covered the 40 largest sites, then all in scope. Rollback was one flag that returned every line to the manual queue with its reading intact. It was tested in week nine and not needed.
FDE / 09Case study
09 / 12
In shortThe client's engineer proved they could run it, and we stayed on for day-to-day operations.
The build ended on the manifest, not on the calendar.
In the dry run, the client's platform engineer added a new client's export mapping, scored it, released it and rolled it back, with our engineer in the room but not at the keyboard.
From the following month the engagement moved to Managed Operations: our rota carries the pager first, with a named first responder, and the client's platform engineer is second. The system is re-scored on fresh cases each month against the golden set, the golden set is extended when a new kind of case appears, and a written report goes to the Head of Operations with the same six headings every month.
That mattered in the second month. A large client changed its portal export without notice — two new columns and a different date format — the evening before a cut-off. Parse failures crossed the queue-depth threshold and paged the first responder; the mapping was corrected, the cycle re-run and the batch approved on time. The incident, its cause and the change that followed — a schema check that holds an export and pages before any lines are produced, rather than after — are in that month's report. The third month's report recommended that the client's own engineer take first response for two cycles, which is how taking a system in-house usually begins.
Key numbers09 badges
The story in nine numbers
One number for each scene, from three corrections in a hundred to a cycle closed in 2.5 days. Press play, or pick a number.
Badge 01 / 09
Key numbersBadge 01 / 09
Pay cycle
Valid · Before
3 in 100
workers needed a correction in the following cycle
Every pay cycle, hours arrived in three shapes.
About 3,800 workers' hours came as portal exports, photos of paper sheets and emails. About three workers in a hundred needed a correction the next cycle.
- 01
- About 3,800 workers at 140 sites
- 02
- Portal exports, photos and emails
- 03
- 11 in payroll, 5 in billing
FDE / 10Case study
10 / 12
In shortMore lines checked without re-keying, a faster payroll cycle and fewer corrections.
Figures are illustrative, measured on in-scope sites over the first three cycles after cut-over.
71% of timesheet lines validated with no re-keying. Portal exports run much higher; photographs much lower, as the scope predicted.
BEFORE0%AFTER71%The cycle closed in 2.5 working days instead of 6.0, from cut-off to an approved payroll batch, so billing went out in the week the work was done.
Corrections in the following cycle fell from 3.1% of workers to 0.8%. Most of the remainder are late sheets, not arithmetic.
BEFORE3.1%AFTER0.8%0%4%−2.3 pts99.5% of billable hours were invoiced in the cycle they were worked, up from 96.4%. The recovered hours were mostly supervisor-approved overtime that had never reached billing.
BEFORE96.4%AFTER99.5%96%100%+3.1 ptsWorkers with a complete, unexpired document file rose from 81% to 97%, because the gaps became a dated task list instead of a spreadsheet nobody read.
BEFORE81%AFTER97%No batch was paid or billed without a named approver, because the design does not allow it.
Nobody in payroll lost a job. Two people moved to client onboarding, where every new site's export mapping and signatory list now has an owner.
What did not improve, and was never promised:
FIG. 10.2Photographs from two night-shift sites are still read poorly, held and keyed by a person. The honest fix is a printed sheet and better light, which those sites have now scheduled.
Client approval latency did not change. Some clients still approve their portal hours days late, and nothing on our side makes them faster.
Statutory filings and returns were out of scope and are unchanged.
FDE / 11Case study
11 / 12
In shortSix rules for anyone automating timesheets and compliance files.
- Read what the client already produces.
A new capture app the client cannot see does not settle a billing dispute.
- Find the record that is not the record.
Payroll's side sheet of agreed rates was the real rate card. Automating on the official one would have broken faster.
- Score refusals.
"Hold this line" must be a correct answer in the golden set, or the system learns to guess.
- Hold lines, not wages.
Workers are paid for hours worked. The queue must be ordered by the payroll cut-off, and the escalation must be written down before the first cycle.
- Keep flags away from the worker's record.
A pattern is a reason to look, not a finding. Route it to the people whose job it already is.
- Say plainly what the system does not do.
Nothing about screening, selection or deployment. Writing that into the scope made the rest of the conversation easier.
FDE / 12Case study
12 / 12
In shortThe client's engineer now shares first response, and the firm asked for two more connectors.
Managed Operations is in its fourth month, and the client's platform engineer now takes first response in alternate cycles. The firm has asked for two more connectors under Integration & Data Onboarding: a second payroll system acquired with a smaller competitor, and the gate-access data from three large sites, which would give the validation an independent record of attendance to check sheets against.