Why your payroll software should never need an update when tax changes

In January 2026 every Nigerian employer had to move to the new PAYE bands under the Nigeria Tax Act 2025. Teams whose payroll software held the bands in code waited for a vendor release, then hoped it arrived before the first run of the year. Teams whose bands were data changed a table, checked a test payslip and moved on. The difference is not cosmetic. It decides who controls your compliance.

What goes wrong when rules live in code

• You wait for a release, and the release may bring other changes you did not ask for
• Nobody outside the vendor can see the rule that was applied
• Back-dated corrections are taxed on today's rules, because the old ones no longer exist
• A rerun of an old period gives a different answer from the one you filed

The last point is the dangerous one. If last year's payslip cannot be reproduced, you cannot defend it.

Four properties of a rule held as data

Effective-dated. Every table carries the date it starts to apply. When the law changes, you add a new version from the new date instead of editing the old one. Each run picks the version in force for its own period, so January uses the new bands and a correction to December still uses the old ones.

Versioned and audited. Each change records who made it, when, and the old and new values. When an auditor asks why PAYE moved in a given month, the answer is in the log, not in someone's memory.

Protected on closed periods. Once a period is approved, its figures are frozen. A later change to a rule never reaches back into a locked month. If a correction is needed, the period is reopened through a governed step and the corrected run replaces the old one, with both kept.

Visible. The people who run payroll can read the rule the engine applied: the bands, the rates, and the base each rate is charged on.

A change in the law should be a new row with a date on it, not a release you wait for.

How Vintage People holds them

In Vintage People the PAYE bands sit in an effective-dated tax table, and you can hold separate tables per state where you need them. Rent relief has its own effective-dated rate and cap. Pension and NHF rates live on their pay elements, each with a defined formula for its base, so Pension is 8% of Basic + Housing + Transport and NHF is 2.5% of Basic, and you can see both.

The payroll policy is versioned too. Pay frequency, proration basis, rounding, the PAYE method and the minimum-wage exemption all sit in it. A change applies from the period you choose, and it can never start inside an approved or locked period.

After your first rollover the tax bands lock. That is deliberate. From then on, a change in the law is a new version with its own effective date, not an edit of history. Every change to these settings is recorded with its old and new values.

When a run is approved, each employee's result is kept as a snapshot, and payslips are built from that snapshot. Reprinting a March payslip in October gives March's figures, whatever has changed since.

Where the limits are

Rules held as data cover changes of rate, band, cap and base. They do not cover a change of concept. If a future Finance Act introduces a relief that works in a new way, the engine has to learn it, and that is a software change. The honest promise is narrower than "never update": routine changes to rates and thresholds are yours to make on the day, and structural changes arrive as a tested release that leaves your past periods untouched.

What to check in your current system

• Can you see the bands and rates the engine used for a given month?
• Can you add a new version with a future effective date and leave the old one in place?
• Does a rerun of a closed period reproduce what you filed?
• Is every change to a statutory setting logged with its old and new values?
• Are the pension and NHF bases shown, or only their rates?

If the answer to any of these is no, your compliance depends on someone else's release calendar. That is worth fixing before the next Finance Act, not after it.