Payroll inputs, compiled from your HRIS and handed to your payroll partner

Companies that already have a payroll partner, bureau or accountant computing their statutory pay, and are re-keying the inputs into a spreadsheet every month to get them there. The buyer is the person who assembles that spreadsheet: attendance, approved leave, overtime, one-off bonuses, expense reimbursements, joiners, leavers and prorations, collected from four places and typed into a fifth. It is not for a company that wants one vendor to compute and file its payroll. Capstan will never be that vendor, so if that is what you are shopping for, this module is the wrong shape and you should know now.

No. Capstan compiles the inputs and holds the records; your payroll partner computes gross-to-net and statutory deductions. Capstan holds no statutory rate, slab, bracket or formula anywhere in the product, and that absence is asserted by a structural test rather than left to discipline. It is a permanent product decision under the partner-integration model, not a gap waiting to be filled, so no future release turns Capstan into a payroll engine.

A documented export, CSV and JSON on a versioned schema, of every input it already knows: attendance, leave, overtime, compensation changes, expenses and prorations, so nothing is re-keyed. Every input line carries its source provenance, meaning the module and record it came from, and variance flags against the previous period are surfaced for a human to read before the export is frozen. Prorations travel as date facts rather than computed amounts, because computing them would be doing the partner’s job. The partner returns the computed numbers, and Capstan files the payslips, letters and settlement documents against each person.

A paid plan first, because paid modules cannot be enabled on the free plan. Then the real setup: pay groups, meaning a name, a pay frequency, a pay-day rule and the org scope of who is in each one, and the membership of each group, which is end-dated rather than overwritten so a mid-year move is history rather than a correction. After that you agree the export format with your partner, because the export is a documented schema rather than a certified integration with a named vendor. The inputs themselves need no setup, since the module reads what the core and your other modules already hold. Expect the pay-group modelling to be the work, and expect to run one period in parallel with your existing spreadsheet before you trust it.

It does not calculate gross-to-net, tax or statutory deductions, and it holds no rate, slab, bracket or formula anywhere. It does not file statutory returns, challans or forms. It is not a payroll engine you configure with tax rules: the compliance arithmetic lives with your partner, the inputs and the system of record live here. It does not disburse salary and it generates no bank file, because money never moves through Capstan; a payment is recorded as a date and a reference. And it does not pay contractors: contractor invoices and payouts belong to Contractor Management, permanently.

It reads and never writes. Compilation snapshots the attendance fold, the leave ledger, compensation records under their existing encryption and clearance rules, expense settlement, and overtime outcomes from the advanced Time and Attendance module where that is enabled, and the source modules are never modified by the act of compiling from them. That read-only relationship is asserted structurally rather than left as an intention. The modules it reads from are optional: without them it compiles fewer input types, and none of them becomes a prerequisite. Payslips and letters land in the same document store as everything else, which is how a former employee reaches their own payslips through Alumni Access after their work address is switched off. Contractor payments are deliberately outside its reach.

A distinct person in one of your pay groups during the billing month. The unit is per active payroll member per month, so someone who was in no pay run that month is not billed for by this module, whatever the roster says, and a workspace that runs payroll for forty of its hundred people is billed on forty here. That is a different count from the per-employee seat count your plan bills on, and a different count again from the free plan’s twenty-employee limit, which counts concurrently active employees.

Pay groups, pay runs, compilation, exports and the payroll reports stop being reachable, and billing stops at the end of the current period rather than on the day. Payroll records are not deleted: they are retained on a schedule with a long floor, because payslips and settlement documents are statutory-adjacent records rather than operational data you can throw away when a subscription ends. Re-enabling within the retention window brings the module’s data back as it was, and a full workspace export includes payroll data whether or not the module is currently enabled. Payslips and settlement letters are filed as documents in the core document store, under the same category and visibility machinery as every other document, rather than living only inside the module.