"Production-ready" is an overused phrase. In payroll it should mean something specific.
For Chegatta's payroll engine, we defined production readiness as: the engine does the same thing in the UI, the database, and the PDF; it can't be silently changed after locking; it keeps tenants and agencies isolated; it leaves an audit trail; and it links payment data back to approved salary records.
We ran a Phase 4 readiness check against the engine. 3 tests, all green. Here's what was on the checklist and what we found.
1. One source of truth across UI, database, and PDF
A payroll system fails in a specific, expensive way when the UI shows one number, the database holds another, and the PDF prints a third.
We verified that the engine's calculated result, the salary slip service output, and the PDF template all consumed the same source of truth — without independent recalculation in the PDF layer.
That matters because payroll disputes usually start with "your system says one thing, our records say another." If the PDF is generated from the same numbers as the UI, you remove one entire class of dispute.
2. Payroll run reconciliation
A payroll run is more than the sum of its employees. If you run payroll for 20 people, the run total should equal the sum of the individual gross amounts.
We verified that individual employee gross totals aggregate accurately to payroll run totals. That's the check that catches "the engine is right per employee but wrong in aggregate" — a real failure mode when summaries are calculated independently.
3. SEPA and payment linkage
Chegatta produces SEPA payment files and payment details. We verified that payment details, IBAN, and net pay figures link directly back to approved salary records.
This is the difference between "we exported a payroll file" and "this payroll file ties back to the approved calculation." The latter is what an accountant or auditor actually wants.
4. Payroll locking and immutability
Once a payroll run is approved or locked, it should not be silently recalculated.
We verified that calculations associated with approved/locked payroll runs throw an exception on attempted unauthorized recalculation. In other words: the engine refuses to quietly redo a payroll you've already locked.
Corrections still happen — through the intended audit path, not by silently overwriting the locked run. Historical calculations remain immutable once locked or associated with an approved run.
5. Audit trail
Payroll needs an audit trail by default, not as an afterthought.
We verified that the audit trail is maintained via relational tracking on salary calculations, payroll runs, and approval states. You can trace what was calculated, when, and in what state.
6. Multi-tenant and agency isolation
Payroll data is sensitive. A staffing agency running payroll for its own employees and its clients' employees needs to know that one client's payroll data is not visible to another client, and not visible to the agency unless the agency is entitled to see it.
We verified that tenant and agency isolation policies successfully prevent cross-company data access.
7. Performance and failure recovery
We ran the Phase 4 test suite alongside the existing regression and slip tests. The suite stayed fast — under 2 seconds per suite — and all existing tests remained green.
We also verified failure/recovery behavior: locking mechanisms prevent partial corruption and preserve transactional integrity when something goes wrong mid-run.
The one thing that still needs an accountant
We're honest about this: the calculation engine is mathematically correct and configurable with the right Social Security rates, IRS table brackets, meal allowance caps, and overtime multipliers. But statutory table specifics, IRS withholding coefficient edge cases, and sectoral collective agreement rules should be reviewed by a local accountant before you run real payroll.
That's not a weakness of the engine — it's the responsible thing to say. No payroll product should claim that its configurable tax tables replace local legal and accounting review before a first real run.
What this checklist is for
If you're buying payroll software, this is the kind of checklist you should ask a vendor to walk you through:
- Does the PDF come from the same numbers as the UI?
- Do employee totals reconcile to the run total?
- Do payment files link back to approved records?
- Can a locked run be silently changed?
- Is there an audit trail by default?
- Are tenants and agencies isolated?
- What's the performance under normal load?
- What needs local accountant review before first real run?
We published our answers because we'd rather show you the checklist than show you a clean screenshot and ask you to trust us.
Where the other pieces fit
- The full Portuguese payslip example is here: We stress-tested Chegatta's payroll against a real Portuguese payslip.
- The restaurant scenario is here: Restaurant payroll is harder than office payroll — here's what we tested.
- The isolation proof is here: We proved there's zero cross-employee leakage in payroll calculations.
- The honest summary that ties it all together is here: Why we publish our payroll test results instead of pretending everything is perfect.