Payroll
Payroll is the one process where being nearly right is worse than being late.
Every other system in a business tolerates a correction. This one pays people, reports to a regulator, and does both on a date somebody else chose — which is why the interesting part is not the calculation, it is the gates around it.
The run
Each gate exists because of a specific way this goes wrong.
A run belongs to one legal entity and one period. It does not move forward because somebody is ready; it moves because the thing before it finished.
Inputs lock before anything computes. Approval sits between the calculation and the money, and can send it back rather than forcing a wrong run through to record a rejection. Paying and publishing payslips are separate acts, because deciding to pay and deciding what people can see are different decisions with different timing.
- Inputs are lockedsomebody changing an input while the run is calculating
- It computesa spreadsheet being the thing that decided the number
- It goes for approvala run reaching a bank file because one person pressed go
- Approval can send it backa wrong run being the only way to record a rejection
- Paying is its own actan approved run being assumed paid
- Publishing payslips is anotheremployees seeing a payslip before the money moves — or after
What a run is made of
Structures and components, not a spreadsheet of columns.
Salary structures define the shape of a package; components define what each line is and how it behaves — fixed, computed, a reimbursement, a recovery. A person on a structure gets a package that is legible six months later, rather than a set of amounts somebody typed once.
Arrears and reimbursements attach to the run that should carry them. Payslips come out per employee, and a bank file comes out ready to upload.
- It picks the right people, by date —
Everybody employed by that entity for that period — including somebody who joined mid-month and somebody serving notice, excluding somebody who left before it started. Nobody is on a run because a filter was left set from last month.
- And prices them on the structure that applied then —
The one effective at the start of the period, falling back to a structure that began mid-period so a mid-month joiner still prices correctly rather than landing at zero.
- Two people cannot lock the same run —
Transitions serialise, so two administrators pressing the same button do not drain the same arrears twice.
- A period cannot be run twice, or overlapped —
Not the same month, and not a period that straddles one you have already run. Which is what stops two versions of a paid month existing.
- The payslip is a frozen artefact, not a report —
At approval each payslip is serialised and fingerprinted, and the PDF is rendered from that snapshot every time — never from a fresh query. A payslip re-opened in three years shows what was paid then, and its fingerprint proves it.
- Every line says how it got there —
The base it was computed from, the rate applied, and a note in plain words — "prorated 21 of 30 days", "capped at the wage ceiling". Somebody querying their payslip is querying a line, and the line answers.
- Approval refuses before it starts —
If no approver can be resolved, the run says so up front rather than parking in a queue nobody owns — and it will not go for approval with nothing computed.
- Locking tells you what it locked —
How many attendance rows froze, how many pending arrears drained onto the run and what they came to — returned as a receipt rather than something you go and check.
- Per legal entity —
Multiple entities under one roof, each running its own payroll on its own period, without one file per company.
- Nobody is silently left out —
An employee without a salary structure is flagged when the run is drafted — before anything computes — rather than discovered missing from a bank file.
- Recoveries and reimbursements come through the run —
A loan repayment, an approved expense claim and a vested incentive all arrive as their own named line on the payslip rather than folded into a generic adjustment — and an expense claim only reports itself reimbursed once the run carrying it is marked paid.
- The structure is minted from the offer, at hire —
Built from the same breakup the candidate saw on their offer appendix, to the rupee — so the first payslip matches the letter they signed instead of being close.
- Rates are versioned by date —
A back-dated correction uses the rates that applied then, not the ones that apply now. That is the difference between a correction and a second error.
The scope limit, stated
One statutory regime, and a refusal for the rest.
The calculation of statutory amounts is separate from the run. One regime is complete today: India — provident fund, state insurance, professional tax in the states that levy it, income tax on both regimes, gratuity and statutory bonus.
Ask the product to run payroll for a country it has not been built for and it refuses. It does not approximate. A payroll engine that produces a plausible number for an unsupported regime is worse than one that declines, because the plausible number is discovered by a regulator.
What a payroll manager asks
Mostly about the month it went wrong.
›Can we run payroll outside India?
Not today. One statutory regime is built, and an unsupported country is refused rather than estimated. The rest of the people module is locale-neutral, and some teams run that here with payroll elsewhere.
›How do we correct a month that has already been paid?
As arrears on the next run, carrying the difference — not by re-opening a period that has already been paid. A period cannot be run twice, which is what stops two versions of a paid month existing.
›Can somebody change an input while the run is calculating?
No. Inputs lock first, and locking freezes the attendance for that period at the same moment.
›Can a payslip be proved authentic later?
Yes. It is rendered from a frozen snapshot and carries its own fingerprint, so the copy somebody downloaded is checkably the copy you issued.
›Can one person run and approve payroll?
Approval is its own gate, and it can reject back rather than only pass. Whether one person holds both is your permission model to set — the product makes the separation possible, which is the part software can do.
›Do employees see the payslip as soon as we pay?
Only if you publish it. Paying and publishing are separate actions on purpose, so a bank file going out on the 28th and payslips appearing on the 1st is a choice rather than a workaround.
›Does it handle more than one company?
Yes — a run is per legal entity and per period, so multiple entities sit under one workspace rather than one installation each. The payslip carries that entity's own registered details, because it is that company paying them.
›Can we run payroll weekly, or off-cycle?
No. One run covers one calendar month for one entity. A weekly payroll or an off-cycle correction run are both genuinely absent, and if either is how you operate this is the first thing to raise.
›Can a published payslip be corrected?
Not in place. A correction to a paid month arrives as arrears on the next run — the issued payslip stays true to the data it was built from, which is the point of fingerprinting it.
›What does the payslip actually show?
The employing company's own details, earnings and deductions as separate tables with the base and rate behind each line, the paid and unpaid day count, the net in its own band, employer cost kept visually apart, and any warnings the run raised printed on it rather than hidden.
›What happens to somebody who joined mid-month?
They are on the run with what they are owed, or skipped with a recorded reason. There is no silent omission, which is the failure mode that costs you the most goodwill.
Book a demo
Bring a month that went wrong.
The correction is the one worth watching. Anyone can demo a clean month.
- Run it, then send it back at approval
- Post a back-dated correction and check which rates it used
- Pay without publishing, then publish
- Skip an employee and find the reason on the run