Gross Pay Is Not One Number

Payroll looks, from the outside, like the easiest thing in the whole system. Take the salary, take off tax, pay the difference. It is arithmetic that a competent bookkeeper does by hand every month, and has done for decades.

It is also the only module where a small mistake has a name, a bank account, and a reasonable expectation of being told the truth. That changes what “good enough” means.

Three bases, not one total

Here is the thing most people outside payroll have never had to think about. When you add something to someone’s pay — a bonus, a travel allowance, a standby payment, a one-off gift — you are not adding it to one total. You are deciding, separately, whether it counts toward:

• the income tax base
• the national insurance and health base
• the pension and severance base

Those three answers are genuinely independent. A payment can be fully liable for income tax and sit outside the pension base entirely. Another can be pensionable but treated differently for national insurance. There is no general rule you can apply once and reuse — the answer belongs to the kind of payment, which is why it has to be a property of each pay component rather than a setting on the employee or a rule in someone’s head.

So a payroll engine that computes one gross figure and applies three percentages to it is not simplifying. It is wrong, in a way that produces a plausible payslip.

Three charges, three separate bases. Anything that collapses them into one number has already lost the argument.

The rule that keeps it honest

There is one design decision underneath all of this that is worth stating plainly, because getting it backwards is the classic error.

An exemption narrows a statutory base. It never reduces gross pay.

If a component is not pensionable, that fact must not touch what the employee earned. Gross is what they were paid — full stop. It appears on the payslip, it feeds the statutory reporting, and it is the number the employee will compare against their contract. A flag that leaked into gross would understate earnings and take the statutory filings down with it, which is a much more expensive kind of wrong than a miscalculated deduction.

Where the amount itself comes from

Before anything can be classified, the amount has to exist. In practice a pay line arrives in one of three shapes, and each carries its own way of being wrong.

Fixed. The amount is the amount. Simple, and the right default.

Hourly. Quantity times rate. The failure mode here is a missing or zero rate: the naive behaviour is to compute zero and carry on, which pays somebody nothing for a month of work and looks, on a report, like they simply did not work. A rate that is not there should stop the calculation, not produce a confident zero.

A percentage of something else. This is the interesting one, because “five percent” is meaningless until you say five percent of what. Two things follow. First, percentages have to resolve after every fixed and hourly amount is final, or the answer depends on the order the lines happened to arrive in — put the percentage line first and you get five percent of nothing. Second, a percentage of a percentage has to be refused rather than resolved, because chains reintroduce exactly that order-dependence.

And there must be no default for “of what”. Quietly assuming base pay would change somebody’s salary without anyone deciding to.

What should happen when the system doesn’t recognise something

This is the question that separates payroll software you can trust from payroll software that merely runs.

Somebody adds a new pay component and does not finish configuring it. The engine now has an amount it cannot classify. There are two ways to behave, and only one of them is defensible.

The comfortable option is to leave it out of the bases. Nothing errors, the payslip looks normal, and the consequence is that the payment is silently untaxed and silently not pensioned. Nobody finds out until a year-end reconciliation or an audit — and by then it has happened twelve times.

The correct option is the opposite: count it toward every base and record a warning. That may over-collect slightly for one month, which is visible, correctable and comparatively harmless. A missing configuration is a problem to fix loudly, not a tax exemption to grant quietly.

Every rate has a date

Tax brackets change. National insurance percentages, the reduced band, the ceilings, the value of a tax credit point, the minimum pension and severance percentages — all of them move, most of them in January, and none of them announce themselves in your software.

Which means a rate cannot be a constant in code. It has to be a row with an effective-from date, so that recalculating March’s payroll in November uses March’s tables rather than November’s. This is the same principle that governs a tax document’s VAT rate, and it matters for the same reason: history must not be quietly rewritten by a maintenance update.

It also changes who can respond to a regulatory change. When a rate is data, the new figures are entered with a date and the engine is untouched. When a rate is code, every January is a release.

A payroll run is a sequence, not a button

The last piece is process rather than arithmetic. A month’s payroll moves through distinct states — drafted, approved, posted to the books, marked paid — and each transition means something different to a different person. The payroll clerk cares about the calculation. The manager cares about approval. The accountant cares that it reached the ledger exactly once, with the employer’s own costs on the right side.

Collapsing that into a single “run payroll” action feels efficient right up to the first month somebody needs to answer “who approved this, and had it been paid when the report was produced?” A run that carries its own state, and a link to the journal entry it produced, answers that without anybody reconstructing it from memory.

Where Capitán fits

Capitán’s payroll is built on the model above, and deliberately so. Taxability is a property of each pay component, resolved into three separate statutory bases. Amounts derive as fixed, hourly or a percentage of a nominated component, in two passes so the result cannot depend on input order — and the engine refuses to guess rather than inventing a base. Income tax brackets, national insurance rates and ceilings, tax credit point values and pension and severance minimums are all date-effective tables, so a rate change is data entry rather than a deployment.

Because it is part of one system rather than a separate service, the employees are the same HR employees, and an approved run posts into the same books as everything else — which is the difference between payroll being reconciled and payroll being reconcilable.

What it will not do is pretend a policy decision is a feature. Statutory overtime multipliers, for instance, are not hidden inside the engine: an overtime hour is its own component at its own rate, because deciding how many of an employee’s hours are overtime — or vacation, or sick leave, each with its own pay rule and its own accrual — is a policy question, and a payroll engine that answers it on your behalf is guessing about somebody’s wages.

If you are evaluating payroll, the useful conversation is about the awkward components rather than the standard ones. Bring us your strangest pay component — the one nobody can quite explain — and we will tell you honestly how it would be configured.

The short version

Payroll is not arithmetic with a compliance wrapper. It is three bases that disagree with each other, rate tables with dates on them, and a long list of places where the wrong default is silence. Judge a payroll system by what it does when something is missing.