Paying the Premium on the Premium
The order of operations in a premium calculation, why including the premium in its own base compounds it, and the three ways systems get the sequence wrong.
One hour's components, in the order they have to be applied
The multiplier applies to £14.74 — not to £12.40, and not to £15.64. The order of operations is the whole of it. How the premium is computed differs by jurisdiction and is a question for somebody qualified in the place concerned.
Build the rate first, then apply the multiplier. Everything earned for working goes into the rate; the premium itself does not, because multiplying a figure that already contains a premium pays a premium on a premium. The whole of this page is that order of operations, and almost every error in premium arithmetic is a departure from it.
The pay calculation in “Paying the Premium on the Premium” depends on a complete record before any rate is applied. For organisations researching remote workforce management software, a practical approach to remote workforce management software can connect hours with projects and review steps, provided payroll keeps the governing formula, contract terms and disputed-entry process outside any single dashboard.
Systems get it wrong in three ways: by multiplying the base rate and ignoring the components, by including the premium in the rate, or by applying a percentage differential after the multiplier rather than before.
For an independent reference relevant to “Paying the Premium on the Premium”, consult the ICO employment-practices guidance. Use it to test record quality, working-time definitions, access, retention and exception handling against the organisation’s real payroll process.
The sequence
- Total everything paid for working in the period: base, differentials, bonuses, commission.
- Exclude reimbursements, genuine gifts and the premium itself.
- Divide by the hours actually worked to get the rate.
- Identify the hours that qualify for a premium.
- Multiply the rate by the multiplier for those hours.
- Check that nothing has been counted twice.
Step six is not padding. In systems where several components are configured independently, double counting happens through two settings that each look correct in isolation.
Multiplying the base only
The most common error and the least visible. The system holds a base rate, the premium configuration multiplies it, and the differentials and bonuses sit in separate lines that never enter the calculation.
Every payslip balances. Every figure is explicable. The answer is wrong by the proportion that the components bear to the base, which in an operation with night work and bonuses can be twenty per cent or more.
Including the premium in the base
Rarer, and it runs the other way: the rate is computed by dividing total pay by total hours, and total pay already includes premium amounts paid earlier in the period.
This happens most often where a rate is derived weekly from a pay total rather than built from components. It produces an inflated rate, which is an overpayment, which is still an error and is still worth finding — partly because it tends to be corrected abruptly when somebody notices, which creates a different problem.
Percentage differentials after the multiplier
Where a differential is expressed as a percentage, the sequence matters even more. A twenty per cent night differential applied after a one-and-a-half multiplier gives a different answer from the same differential applied before it.
The correct order is the one above: the differential is part of what the hour is worth, so it goes into the rate, and the multiplier applies to the result.
Testing it by hand
Take one employee with a night differential, a bonus and premium hours in the same week. Compute the rate and the premium on paper, then compare with what the system produced.
A single discrepancy here applies to everybody with the same combination of components, which is why one employee is enough to start with and why the finding is never about that employee.
Where more than one premium applies
Some weeks attract two: a daily threshold and a weekly one, or a premium for the seventh consecutive day on top of an hours-based one.
The rule for combining them has to be configured and is usually that an hour attracts the higher rather than both. Assuming it is configured correctly without testing is how an organisation pays two premiums on the same hour for a year, or none.
Where the components are paid separately
Some organisations pay a differential as a separate line rather than building it into the rate, and then compute the premium on the base. The employee sees both lines, the arithmetic looks complete, and the premium is understated.
Paying a component separately is a presentation choice. Whether it goes into the rate is a different question with a different answer, and conflating the two is the specific mechanism by which this error survives review — everybody can see the component is being paid, so nobody asks whether it is in the rate.
Checking after a payroll upgrade
The order of operations is implemented in configuration, and configuration moves. An upgrade that changes how components are grouped can change what the multiplier applies to, silently.
Keep the hand-calculated test case from this page and rerun it after every upgrade. It takes ten minutes, it is the single most likely thing to break, and nothing in a release note will tell you it has.
What to document
The sequence, as six lines, with an example worked through. One page.
That page is what new payroll staff need and what nobody writes, which means the knowledge lives with whoever configured the system. When they leave, the configuration continues to run and nobody can explain why it produces what it produces — which is where most of the problems described on this site come from in the first place.