Payroll automation that survives an audit, not a demo
Payroll folds your scheduling, your compliance and your money into one calculation. Get any part of it wrong and the mistake turns up as a number an employee can point at.
What payroll engineering actually demands
4 things that decide this
- 01Your gross-to-net has to run on integers or fixed-precision decimals. A float rounds every value it touches, and one pay run touches thousands of them.
- 02Overtime rules belong in your record rather than in a spreadsheet formula somebody edits by hand. Federal thresholds, shift differentials and state rules each change the sum.
- 03Eligibility and pay share one record. When your scheduling data and your payroll data live apart, the two drift and somebody squares them up by hand every cycle.
- 04A payroll break needs an owner and a reason before your next run rather than a note for month end.
Payroll fails quietly, then all at once
Most payroll systems get built as a report sitting on a spreadsheet. Your hours come from one place, your rates from another, and somebody stitches them together before every run. That works until a rate changes mid-period or a shift crosses a cutoff. Then it makes a wrong number, and nobody spots it until an employee asks about their check.
Your fix isn't a better spreadsheet. It's treating pay as a calculation off one input record rather than an export somebody massages afterwards. Hours worked, rate, overtime status and deductions all want to come from the system that scheduled the shift in the first place.
- 01Gross-to-net calculated from stored rules, not a formula copied across a spreadsheet each period.
- 02Overtime and shift differentials applied at the hour, so a late clock-out changes the right line.
- 03Scheduling and pay share one record.
- ClockHours captured at the shift.
- RateBase, differential, overtime rule.
- GrossComputed from stored rules.
- DeductTax, benefits, garnishment.
- NetOne number, one record.
- ReconcileMatched against the bank file before payday.
Move your reconciliation before payday and a break gets caught with hours left to fix it. Leave it after and you're writing a correction check.
The problems every payroll build hits
These show up whatever payroll frequency or jurisdiction you run.
Money stored as a float rounds itself wrong
Binary floating point can't hold 0.10 exactly. Add up a few thousand rows across your pay period and that drift becomes a number your payroll team explains by hand.
Overtime is a rule, not a lookup
Federal overtime, state daily rules and shift differentials all interact. Hardcode a multiplier and it works in one place, then breaks the moment you add a second.
A pay run needs a version, not an edit
Fix a processed run by changing the old numbers and you've destroyed the record your audit or your dispute needs. Post a correcting entry instead, and keep the original where anyone can see it.
The exceptions still need a person
A disputed clock time or an odd leave case isn't something to settle automatically. Route it to somebody with the context, then log what they decided and why.
Reconcile every run, not every month
Reconciliation proves your payroll ledger and your bank file agree, and it explains every difference between them. Run it monthly and a break from week two is buried in thirty days of transactions by the time anyone looks.
Reconcile against every pay cycle instead and a break sits inside one run. That's the difference between a five-minute fix before payday and a correction check after it, plus an employee who now doubts the whole system.
- Match your bank file to the ledger before funds leave the account rather than after.
- Give every unmatched line an owner and an age rather than a note in a spreadsheet.
- Post your corrections as new entries, and never edit a run that has already gone through.
The professional signs, the model reads but never does the arithmetic, and the compliance gate blocks. We write that down first.
A firm's work is a regulated act: the CPA signs the return, the producer binds the policy, the adjuster determines the claim, the recruiter decides the placement, and the regulator expects to see how a model was used and governed. So every build starts with a one-page map of what the software reads, what it proposes, and where a professional signs.
What follows is simple to state, and we put it in writing. Documents are read and extracted by the model; numbers are computed by code and reviewed by a person. Compliance checks are gates that stop the next step, not dashboards that mention it later. Client data is scoped to the engagement, never firm-wide, with written no-training terms you can produce. And every automated touch is logged so a reviewer, an auditor or a regulator can read what happened, and when.
- 01Returns, binds, determinations and placements signed by the professional; the software prepares.
- 02Extraction by the model, arithmetic by code, review by a person; compliance gates that block.
- 03Money handled as money: integer minor units or fixed-precision decimals, with corrections posted as new entries rather than edits.
Some of the systems we have shipped
“They will treat your vision like their own and build it that way.”
Ron Klabunde · Founder, SmartREI ↗
A payroll spreadsheet against a payroll system
Both of them give you a number. Only one can show its work.
Where hours come from
Spreadsheet and export
Copied in from a separate scheduling tool.
What production requires
One shared record between scheduling and pay.
Overtime rules
Spreadsheet and export
A formula someone updates by hand.
What production requires
Stored rules applied at the hour.
Money handling
Spreadsheet and export
Often a float or a display-rounded number.
What production requires
Integer minor units or fixed-precision decimals.
Correcting an error
Spreadsheet and export
The old cell gets overwritten.
What production requires
A new entry points at the original.
Reconciliation
Spreadsheet and export
Monthly, against thirty days of activity.
What production requires
Every run, before funds move.
The stack this work runs on
Platform
- Next.js
- Supabase
- PostgreSQL
- Vercel
- CI/CD pipelines
Money handling
- Postgres NUMERIC
- Integer minor units
- Stripe Connect
- Webhook idempotency
Controls
- Row-Level Security
- Role-based access
- Audit logging
- Attributed corrections
What HR and finance leaders ask us
01Can payroll calculations be fully automated?+
Your gross-to-net and your standard overtime rules can be, once they run on stored rules rather than a spreadsheet formula. Disputed hours and odd leave cases still need a person with the context, so we route those rather than settling them automatically.
02Why does the money data type matter?+
Binary floating point can't hold 0.10 exactly, so a pay run built on floats drifts by a small amount that piles up across your pay periods. Store pay as integer minor units or a fixed-precision decimal and the drift never starts.
03How do you handle a correction after a pay run is processed?+
It posts as a new entry rather than an edit. Your original numbers stay visible and the correction points back at them, so anyone asking about that pay period a year later can see what changed and why.
04Does this replace our existing payroll provider?+
Not usually, no. Most of our work builds the layer that feeds your existing provider or bank file with clean, reconciled data. ADP, Gusto or whatever you run already carries statutory filing and tax remittance that took years to get right.
05What about multi-state or multi-jurisdiction overtime rules?+
Those rules live as data rather than as code paths. A new state or a rate change is a configuration update your team makes rather than a release you wait for, and the system stays right as you grow.
Go deeper
- AI, automation and custom software for firms →The whole chain, for accounting, insurance, staffing and HR.
- HR and payroll teams →The segment this capability sits inside.
- Workforce compliance →How eligibility gating feeds the hours that become pay.
- Workflow automation for firms →Onboarding, the recurring chase and the work that repeats.
- Shift Link case study →Onboarding, validation, scheduling, payroll and margin on one record.
- Custom software for firms →Dashboards and the integration layer your stack won't build.
