The most common payroll question an employee asks is not "why is my salary this much" but "why is my tax different from last month when my salary did not change". The answer is that salaried income tax in most progressive systems is not a monthly tax at all. It is an annual liability, collected monthly, and the monthly amount is a forecast that gets corrected as the year unfolds.
The tax is annual; the deduction is a forecast
A progressive slab table defines tax on annual taxable income: nothing up to the first threshold, a low rate on the band above it, a higher rate on the next band, and so on. An employer withholding tax each month therefore has to guess what the year’s total income will be, work out the tax on that guess, subtract what has already been deducted, and spread the rest over the months that remain. When the guess changes, so does the monthly figure.
Written out, the rule that most payroll teams follow is short:
- Projected annual income = gross paid so far this tax year + current monthly gross × months remaining.
- Annual liability = the slab table applied to that projection (fixed amount for the band, plus the band rate on the excess).
- This month’s deduction = (annual liability − tax already deducted this year) ÷ months remaining.
Everything that makes the number move follows from those three lines.
Why it changes after an increment
Suppose the tax year runs July to June and an employee on 250,000 a month gets a raise to 275,000 in October. From October the projection is three months at the old salary plus nine at the new one, so the annual figure rises, the liability rises, and the shortfall between what should have been deducted so far and what actually was is recovered over the remaining nine months. The October payslip shows a jump that is bigger than the raise alone would suggest, then settles. That is correct behaviour, not an error.
Why it changes for a mid-year joiner
Someone who joins in March has only four months of income in that tax year. If payroll treats them like a full-year earner, it projects twelve months of salary and over-deducts heavily. If it uses only the months they will actually be paid, the projection is right but the slab still applies to the whole tax year, so a joiner on a high monthly salary can pay very little tax in year one and a lot in year two. Both outcomes are legitimate; the important thing is that the system knows the joining date and that finance can see which assumption it used.
Why the first month on a new system matters most
Moving payroll to new software mid-year is the moment this goes wrong most often. If the system knows nothing about the months already paid, September looks like the first month of the year: the projection is twelve months of current salary, and the deduction is computed as if nothing had been withheld yet. The result is an under- or over-deduction that only surfaces when the annual certificate is produced.
The fix is an opening balance per employee for the current tax year: gross paid to date, tax deducted to date and the number of periods already paid. With those three numbers the projection picks up exactly where the previous sheet left off. In Ledgr they sit on the pay profile’s tax card, next to the tax id and the regime, and they are the one thing a payroll migration cannot infer from anywhere else.
What a payroll system needs to get this right
- The slab table as data, with the year it applies to, editable when the budget changes the rates, and kept per country so one product serves more than one tax authority.
- A tax ledger per employee and tax year: one entry per pay period with taxable pay and tax deducted, written when the sheet is disbursed and never recomputed afterwards.
- Exemptions and credits as rules, such as a medical allowance exempt up to a percentage, applied before the slab rather than by hand.
- A visible explanation on every line: projected annual income, liability, deducted to date and months remaining, so a reviewer can check the arithmetic without a calculator.
- An override with a note, because the tax office occasionally issues a certificate that changes an individual’s deduction and the system must record why the number differs from the engine.
From ledger to certificate
The same ledger that drives the monthly forecast is what the year end needs. Each deposit to the treasury is recorded against the periods it covers, so reconciliation is a comparison of two columns rather than a hunt through bank statements. The annual salary certificate an employee hands to the tax office is a report over the ledger, and the withholding statement the employer files is another. None of it is a separate workbook, which is the point of holding the fact once — the theme of moving payroll off spreadsheets.
This matters most to software companies with salaries spread across several slabs and frequent increments, and to professional services firms whose staff expect a clean certificate every year. The employee-facing side is simple: their own payslip shows the projection, so the "why did it change" question answers itself.
Built for your industry
