Running payroll for a distributed team

Running payroll for a team spread across countries is not one big payroll. It is several local payrolls, each computed and filed under its own country’s rules, held together by one clear record of who works where and on what terms. The single most useful thing to understand before you start is that no credible vendor runs one global payroll engine that computes gross to net everywhere. The statutory calculation is local, and it stays local. What you can centralise is everything around it.

This guide is about the operational reality, not the tax arithmetic. The rules, rates and filing mechanics differ by country and change over time, so confirm the specifics for each place with a local payroll provider or an employer of record. What carries across every country is the shape of the work, and that is what this guide maps.

There is no single global payroll

It is tempting to imagine one button that pays everyone. In practice, each country’s payroll is performed by someone who tracks that country’s tax tables, social contributions, filing formats and deadlines: a local payroll provider, an accountant, or an employer of record that employs the person for you. A company with people in three countries runs three payrolls, on three calendars, with three sets of rules.

That is not a failure to consolidate; it is the correct structure. The reforms and rate changes in any one country would otherwise force a software release everywhere. Keeping the computation local means a change in one country stays in one country. Your job is not to compute payroll. It is to feed each of those local runs clean, complete, on-time inputs, and to keep one record that agrees with what they all produced.

Inputs are the actual work

Ask anyone who has run distributed payroll what hurts, and it is almost never the maths. It is the monthly assembly of inputs. A payroll run needs to know, for each person and each period: who is employed and on what compensation, who joined or left and on exactly which dates, how many days are payable, what leave was approved and what was unpaid, any overtime, and any one-off payments, deductions or corrections.

When those facts live in a spreadsheet, an email thread, a chat message and someone’s memory, assembling them for even one country is a scramble, and doing it for several at once, on staggered cut-off dates, is where errors and late runs come from. The discipline that fixes it is boring and decisive: one source of truth for the facts, captured as they happen rather than reconstructed at month end. Attendance and approved leave feed the payable-day count directly, and a mid-month joiner or leaver is a date, not a guessed proration. The payable days calculator shows the arithmetic for a single case; a system of record does it for everyone without anyone opening a spreadsheet.

Cut-offs, approvals and the calendar

Each local payroll has a cut-off date, after which changes land in the next cycle. Distributed teams need those cut-offs written down per country and honoured, because a compensation change approved after cut-off is not this month’s problem to the provider even if it is to the employee. Build a simple monthly rhythm: a window for changes, an approval step so that pay changes are authorised rather than assumed, a hand-off to each provider, and a reconciliation when their results come back.

The approval step matters more as the team grows. A pay rise, a bonus or a correction should be a recorded, approved change with a date attached, not a line someone typed into a payroll file. That record is also what makes the run auditable later, and what lets a promotion in April still read as history two years on.

Currency, funding and contractors

People are generally paid in their local currency through the local run, and you fund each payroll accordingly. Exchange rates move, so a headcount cost that looks fixed in your home currency is not; treat the rate as a budgeting variable and keep each person’s contracted amount and pay currency explicit. Model the fully loaded cost rather than the gross, because employer contributions differ enormously by country; the employee cost estimator builds a loaded cost per hire from the lines you name.

Contractors are paid on a different track from employees, and mixing the two is a common source of mess. Contractors invoice and are paid against those invoices, without the statutory withholdings and contributions of employment, and treating a contractor like an employee, or the reverse, creates both payment errors and classification risk. Keep the two engagement types structurally distinct, and read hiring global contractors for the compliance side.

One record, many providers

The workable architecture is one directory that holds everyone across every country and entity, and a set of local providers that each compute and file their own country’s payroll. When some of your people are employed by a subsidiary rather than the parent, you are also running HR across more than one legal entity, and each record has to carry which entity employs it, because that decides which payroll partner and which obligations attach to that person.

The reconciliation at the end of each cycle is what keeps the record honest: the provider’s computed payslips and totals come back onto each person, so your record and their filings agree, and a former employee writing in two years for a payslip lands somewhere it can be found. Exits deserve their own attention, because a final pay run has to settle everything owed and owing; the full and final settlement guide covers that process.

Where Capstan fits

Capstan does not run payroll. It holds no rate, slab, bracket, threshold or formula for any country, computes no gross to net, and files nothing with any authority, and it never will. What it does is be the system of inputs around each local run: it compiles the attendance, approved leave, overtime, compensation changes, joiners, leavers and adjustments it already holds into a documented export for your payroll partner or EOR in each country, then files their computed payslips and results back onto each person.

That export is deliberately the same shape everywhere. It carries day counts, the compensation components in force at period end, and joiner or exit prorations recorded as dates and payable days rather than prorated amounts. There is no country logic in it at all, because the country is supplied by your provider, not by Capstan. The one country pack authored so far is for India, and it covers contractor invoice withholding and tax lines rather than employee payroll. If you want a single vendor to compute and file payroll in every country, that is a different product, and it is worth knowing that now rather than three months in. The reasoning behind keeping payroll a partner rather than an in-house engine is set out on the blog.

Where to go next

For the India-specific statutory picture as a worked example of what a local run involves, see statutory payroll in India. For the wider HR side of running people across borders, leave, documents and residency, read managing a distributed team. And confirm each country’s payroll mechanics, cut-offs and filing obligations with a local provider before you rely on them; the rhythm is portable, the rules are not.