← systeric.com Interwise / Docs
Open App →

The Payroll Cycle

Payroll is a process, not a calculation. The arithmetic is the easy part and it is the part software already does. What separates a payroll team that gets it right every month from one that does not is a sequence of stages, each with an owner, a deadline, and something specific it is meant to catch.

This is the best-codified part of the whole discipline. The professional bodies, PayrollOrg in the US and CIPP in the UK, build their certifications around it, and the sequence is the same everywhere because the constraint is the same everywhere: at some point money leaves the business and cannot be recalled.

The stages#

1. Inputs. Everything that could change someone’s pay is collected: attendance, approved overtime, leave taken, new joiners, leavers, salary changes, one-off payments, and any deductions. This is the messiest stage and the one most often done over WhatsApp.

2. Cut-off and input freeze. A published date after which no further changes enter this month’s run. The freeze is not administrative fussiness. Without it the calculation is being recomputed under its own feet and nobody can ever say what the final number is. A change that arrives after cut-off does not delay the run. It goes into next month as a retro adjustment.

3. Calculation. The draft run. Gross to net for every employee. See Gross to Net for what happens inside this step.

4. Review: variance analysis. This month’s numbers against last month’s, employee by employee, with every difference explained. Someone’s pay moved by 2 million rupiah: is that the promotion, the unpaid leave, or a data entry error? This is the stage that actually catches mistakes, and it is the most under-built feature in the category.

5. Approval. A named person who is accountable signs off. Not the person who prepared it.

6. Disbursement. The bank file is generated and submitted, and the money moves. This is the point of no return.

7. Close. Statutory filing (PPh 21, BPJS), posting the journal to the general ledger, archiving the register, and reconciling what the bank actually paid against what was instructed.

cut-off review pay inputs calculate approve close free to change expensive to change gone
Two moments matter more than the rest. At cut-off the inputs stop moving, which is the only thing that makes a final number possible. At disbursement the money is irrecoverable, which is why every check has to happen before it.

Think of it as a departure#

Check-in closes before the flight leaves. That is the cut-off, and it exists for exactly the same reason: you cannot load a plane whose passenger list is still changing. A traveller who arrives after check-in closes is not an emergency, they go on the next flight. That is a retro adjustment.

The pre-flight checks are read out and confirmed by two people, because the whole point is that the person who prepared it is not the only one who looked. That is variance review and approval.

Then the doors close and the aircraft pushes back, and at that moment the cost of a mistake changes completely. Everything in payroll is arranged around getting the checks done before pushback, because there is no version of this where you bring the money back.

The two checks that actually catch things#

Variance analysis is the one that finds real errors. Comparing this run to the last one, every employee whose pay moved should have a reason attached, and the reasons should be boring: a promotion, unpaid leave, a bonus, a new joiner’s part month. What you are hunting is the one difference nobody can explain, because that is the error, and it is invisible if you only look at this month in isolation. A number can be wrong and perfectly plausible. It cannot usually be wrong and unexplained.

The parallel run is the migration check. When a company moves payroll systems, or when a calculation changes materially, the old and the new are run over the same period and the outputs compared line by line. It is expensive and slow and it is the only thing that will tell you whether the new system agrees with reality. Every serious payroll migration includes at least one, usually two.

last month this month why? one row
The same people, two consecutive runs. Four rows match and one does not, and the only question worth asking about that row is whether anybody can say why. An unexplained difference is the error; a plausible number tells you nothing.

The runs that are not the monthly run#

  • Off-cycle. A payment outside the normal schedule: a correction, a termination settlement, an early release. Same controls, compressed.
  • Retro. A change that should have applied to an earlier period, paid in this one. Retros are where errors hide, because the amount is correct for a month nobody is looking at any more.
  • Final settlement. A leaver’s last run, which triggers the December-style tax settlement early. See Gross to Net.
  • THR. A statutory religious holiday allowance, paid on its own schedule, taxed differently from monthly salary.

Why this matters to our strategy#

Our north star is payroll periods paid end to end through Interwise with zero manual intervention. That sentence only means something against this cycle, because “manual intervention” is not a vague quality. It is a specific stage where somebody stepped out of the product: fixing an input by hand after cut-off, editing the bank file, or rebuilding the variance check in a spreadsheet because ours did not answer their question.

That gives us a way to read the roadmap. Every stage above is either fully inside the product or it is a leak, and a leak is worth more than a feature, because a period with one manual step does not count toward the number even if everything else was perfect.

The review stage is where our bet is won or lost. A customer who has to build their own month-over-month comparison in Excel has not been given a payroll system, they have been given a calculator plus homework, and they will keep the spreadsheet forever. Doing the variance analysis for them, with a reason attached to every movement, is what makes the spreadsheet unnecessary rather than merely unwelcome.

What this means for what we build#

  • Cut-off must be a real state in the product, not a date in someone’s head. Before it, inputs are open. After it, changes are captured as retro for next period rather than silently altering this one.
  • Never let the calculation change under an approval. If an input moves after someone signed, the approval is void and must be visibly re-taken.
  • Variance is a first-class screen, not a report someone exports. It should open on the exceptions, with the explainable movements already explained and only the unexplained ones demanding attention.
  • Approval has to be separable from preparation. In a company of forty that may be the owner rather than a second HR person, but it cannot default to the same click by the same user.
  • The point of no return needs to feel like one. Everything before disbursement should be freely revisable and everything after it should be a correction with a trail, never an edit.