Ask a payroll specialist in any single country to list what changed in their jurisdiction last year. You will get contribution rates, a threshold that moved, a slab that was re-cut, a new levy with an awkward effective date, and a revised filing format that broke everyone’s export in the same week. That is one country, one year, told by somebody who does nothing else.
Now hold that list next to a product page claiming accurate statutory payroll in twenty countries. Either that vendor employs twenty of those specialists and keeps them, which some very large companies genuinely do, or the claim is quietly untrue somewhere, and neither you nor they know where until a filing deadline finds it.
The surface area nobody prices correctly
Statutory payroll looks like arithmetic and is really a compliance subscription. The arithmetic is trivial: multiply, subtract, round. The hard part is that every input to that arithmetic is a fact about a jurisdiction on a date, and jurisdictions revise those facts on their own schedule, with retrospective effect more often than anyone would like.
The surface multiplies badly. It is not the number of countries, it is countries times sub-jurisdictions times employment categories times effective-date versions, because a payroll run for March must use March’s rules even if you are running it in June. Our India orientation guide is a useful sense of one country’s shape: several distinct contributions, some applying from the first employee and some only above thresholds, several varying by state, each with its own filing. Multiply that by a launch map and you have a permanent engineering commitment that has nothing to do with HR software and everything to do with tax administration.
There is a second, quieter problem. Statutory rules encoded in software are invisible until they are wrong. A misfiled return does not throw an exception. It sits there being wrong for two quarters until an authority notices, and by then you have paid the wrong amount for a lot of people.
The system of record and the system of computation are different systems
The architectural move is to stop treating payroll as one thing. There are two jobs inside it, and they want opposite properties.
The system of record holds the facts about people over time: who was employed, on what terms, from when, on which pay group, with which absences, and what they were eventually paid. It should be stable, auditable, append-only in spirit, and it should still answer questions correctly in five years when someone asks for a payslip from a job they left.
The system of computation holds the rules of a country in a given year. It should change constantly, because the rules do. It is maintained by people whose entire job is watching a legislature and a tax authority, and its value is precisely that it is never stable.
Putting both in one product forces one of them to compromise. Usually it is the record, because computation changes are urgent and record changes are not, and you end up with a system whose historical answers shift because a rules update was applied more broadly than intended. Which of the two a vendor built first tells you most of what you need to know about where payroll sits in the product, and about which of the two will be asked to bend when they conflict.
What the split buys
Correctness first. The people maintaining a country’s rules are specialists who carry professional responsibility for getting them right, and they are watching a jurisdiction you visit once a year.
Coverage second. Country reach becomes a commercial question rather than an engineering roadmap. Adding a country means finding a partner who already operates there, not waiting for a release that adds it to a rules engine.
Third, and least discussed, is separability. If your record system holds no statutory logic, changing payroll partner is a change of one integration and one export format. If your HRIS computes payroll, the two are welded, and switching payroll means switching your system of record for everyone, including the people who left three years ago. That is exactly the lock-in described in our writing on switching costs, arriving through a door most buyers never inspect.
What the split costs
Be honest about this, because vendors selling the model rarely are.
You have an integration. Data leaves one system in a defined format and results come back, and that seam needs a format, a version, and somebody who notices when the partner changes their template.
You have a reconciliation step. Results arriving from outside cannot simply be trusted onto people’s records: the member set has to match what was sent, the line items have to sum to the totals they claim, and a mismatch has to stop the import rather than partially apply it. That is real work every pay cycle, and it is the price of the seam.
And you have two vendors, which means two support relationships and the possibility of each pointing at the other. The mitigation is unromantic: the export format is documented and versioned, so when something disagrees there is an artefact both parties can read.
For most companies below a few hundred people this is a good trade. You were already paying an accountant or a payroll bureau to do the computation. What changes is that the inputs stop being a monthly email attachment assembled by hand and become a compiled, provenance-stamped set that came out of the system where the facts already live.
Where Capstan stands
Capstan runs in partner-integration mode, and the load-bearing property is what it does not do. It computes no statutory payroll, anywhere, ever. It holds no rate, no slab, no bracket, no threshold and no formula. That absence is structural rather than a gap awaiting a release: there is no table and no column in the payroll module permitted to carry a statutory rate or bracket, and a test asserts it rather than a policy asking politely.
What it does is compile. For a pay period it snapshots every input it already owns, with the source of each recorded: payable days and unpaid leave from finalised attendance, approved overtime, current compensation components, approved unpaid expense reimbursements, and joiners and leavers as dates rather than as computed amounts, because proration arithmetic belongs to the partner too. That set goes out as a documented, versioned export in CSV and JSON, partner-neutral by design, with no partner named anywhere in the code.
The partner computes and files. Their results come back, are reconciled against what was sent, and are filed onto the record: statutory lines stored as labelled amounts that Capstan stores and does not interpret, and payslip documents attached to each person, so an employee, and a former employee where alumni access is switched on, can still find their own payslip years later. Money never moves through Capstan; payment is recorded as a date and a reference. The module catalogue lays out the boundary, and the pricing page is where any number lives.
If you want a system that promises to compute Indian or German or Nigerian payroll for you, we are not it, and the honest version of that sentence is that almost nobody at our size is.