Feeding Payroll

Every other integration in this category can fail quietly for a day. This one cannot.

What crosses the boundary

Hours by pay code, not raw entries. The timesheet system classifies; payroll applies rates.

Absence, where the timesheet system records it.

Premiums and allowances triggered by the shift pattern.

The pay period identifier, so a late entry can be attributed correctly.

Not: project codes, narratives, client attribution. Payroll does not need them and sending them widens the data flow for no purpose.

Who applies which rule

The boundary that causes most trouble, and it should be decided once and written down.

Option one: the timesheet system classifies into pay codes, and payroll applies money. Clean, and it means overtime rules live in the timesheet system.

Option two: the timesheet system sends raw hours, and payroll classifies. Also clean, and it means the timesheet system does not need a rule engine.

Option three: both do some, which is what most organisations end up with and where the double-counted overtime lives.

Pick one. Write down which system owns each rule. The audit question "why was this person paid this" must have one answer.

The reconciliation nobody runs

What the timesheet system sent, what payroll received, what was paid.

Three figures, per period, compared.

Differences investigated rather than absorbed.

A recurring difference on one rule is a configuration finding; a scattered one is usually manual intervention in payroll.

Most organisations do not run this, and discover the gap when a worker does.

Late entries and corrections

An entry made after the cut-off has to go somewhere.

Options: hold for next period, force a re-run, or an off-cycle payment. Each has a cost and the choice is a policy.

Corrections after payment need a defined route with a deadline, visible to the worker, and a record.

Ask the product what happens to an approved, exported entry that is then edited. The answer ranges from blocking it to silently changing it, and the second is a defect you want to know about before go-live.

Testing before trusting

Run three parallel periods, not one. The first finds gross errors, the second finds rule errors, the third finds the edge cases.

Compare line by line, per person, not totals. Two errors in opposite directions produce a matching total.

Include the awkward people deliberately: the one with a split contract, the one on nights, the one who changed pay group mid-period.

Sign off in writing, by payroll, before the old process stops.

Who owns which rule

The boundary that causes most trouble, written down once.

A table: each rule, and which system applies it.

Overtime classification. Break deduction. Premium triggers. Minimum call-out. Rest period checks.

One system per rule, with no shared ones.

Reviewed when either system changes.

The audit question "why was this person paid this" must have a single answer, and this table is it.

Three parallel periods, not one

The number is the point.

The first finds gross errors: missing people, wrong pay codes, dropped records.

The second finds rule errors, once the noise is gone.

The third finds edge cases: the month with a public holiday, the person who changed contract, the shift crossing the boundary.

Organisations that run one go live with the rule errors intact, and find them in production where correction costs a re-run and an apology.

Inspect the source before payroll

The approved record must remain traceable before it reaches payroll. Compare the required fields with a working example of online timesheets, then test corrections and exports with a complete sample period.