Payroll has a second half.
The first half is: did we count the hours right? That's what our Portuguese payslip test and restaurant stress test cover.
The second half is: now that we have gross pay, what gets added, what gets taken off, and can someone change a paid run after the fact?
We built a test for the second half too. Here's what we verified.
What we tested
We set up individual employee additions and deductions through the engine's JSON-driven earnings components — the same mechanism the real payroll flow uses:
- Bonuses and allowances — configurable as taxable or non-taxable, subject to Social Security or not.
- Salary advance recovery — a deduction tied to a prior advance.
- Insurance deductions — fixed monthly amounts.
We also tested the engine's locking behavior: once a payroll run is approved, it should refuse further recalculation.
What we found
2 out of 2 tests passed, 0 failures.
- Individual additions and deductions — bonuses, allowances, advance recovery, and insurance all applied cleanly per employee, with the right taxable/non-taxable and Social Security treatment. No double-counting.
- Payroll locking — calculations attached to an approved payroll run correctly threw an exception when we tried to recalculate them without going through the proper correction path.
None of the existing tests regressed. The isolation we proved in the stress tests still held: employee A's bonus didn't leak into employee B's calculation.
Why this matters
If you run payroll for real people, three things need to be true:
- Additions and deductions are configurable, not hard-coded. You don't want a dev to touch the engine every time you add a new allowance type.
- Locking is real. A paid or approved run can't be silently overwritten by a stray recalculation.
- Isolation holds under additions too. A bonus for one employee doesn't inflate another's pay.
We verified all three. The engine is configurable through the same JSON component mechanism the rest of the payroll flow uses, and approved runs are locked.
What we're honest about
We didn't build a full multi-step adjustment approval workflow UI in this phase. The core calculation and locking are solid; the richer approval transition experience is an extension on top. We say so in our own audit.
We also didn't certify the tax tables with an accountant. The math is correct and configurable. Statutory specifics need a local review before you run real payroll — that's true for any payroll product, and we say so openly.
Where this fits
- We stress-tested Chegatta's payroll against a real Portuguese payslip — the hours-and-rate half of payroll.
- Restaurant payroll is harder than office payroll — here's what we tested — the real-world shift scenarios.
- We proved there's zero cross-employee leakage in payroll calculations — the isolation guarantee.
- What "production-ready payroll" actually means — our Phase 4 checklist — the full production readiness picture, including PDF, SEPA, and locking.
- Why we publish our payroll test results instead of pretending everything is perfect — the honest summary of all of the above.