HMRC Error: 15 Years Overcharging Pensioners

The HMRC error that overcharged 1.4 million British pensioners was not a hacker attack or a clever fraud: it was a silent bug, hidden in the UK tax authority's code since 2010. For fifteen years, the system overcharged tax on the state pension — and nobody noticed. For those who build and maintain software, this is an expensive lesson in what happens when legacy code is never audited.

TL;DR

The HMRC error originated from a change to the PAYE system made in 2010 and went unnoticed for fifteen years.

Around 1.4 million pensioners were overcharged in the 2024-25 tax year alone — and another ~1.7 million via self-assessment and simple assessment.

The technical cause: the system applied 52 weeks of pension at the full rate, when the correct calculation was 51 weeks at the new rate plus 1 at the old rate.

John-Paul Marks, HMRC's Chief Executive, apologised in a letter to Parliament and promised to correct calculations by summer 2026.

The engineering lesson: legacy systems without business rule tests and reconciliation hide costly faults for years.

The HMRC error explained: 52 weeks where 51 were due

The UK state pension is paid weekly, and the new rate set each April only applies from the first Monday of the tax year. Therefore, HMRC's own guidance states that the year's tax should reflect 51 weeks at the current year's rate plus 1 week at the previous year's lower rate. Simple to write in a spreadsheet, easy to get wrong in code.

That is exactly what happened. Since a change to the PAYE system in 2010, the calculation applied 52 full weeks at the higher rate. The difference seems trivial line by line. For 2025-26, the correct figure would be £11,962.95 (51 × £230.25 + £221.20), but the system recorded £11,973.00 (52 × £230.25). Just over £10 of phantom taxable income per person — multiplied by millions of pensioners.

This is the classic picture of an HMRC error that does not crash any server, does not raise an exception, does not trigger an alert. It simply delivers the wrong number with total confidence, year after year.

How many pensioners were affected and how much extra tax was collected

The volume grew along with the number of pensioners pulled into the taxable bracket — an effect of frozen tax thresholds combined with pension increases. The data HMRC reported to Parliament shows the escalation:

Tax year	Overcharged pensioners (PAYE)
2022-23	762,000
2023-24	1,170,000
2024-25	1,400,000

In addition to the PAYE channel, around 955,000 people on self-assessment and another 760,000 on simple assessment may have been incorrectly charged — totalling approximately 1.7 million additional taxpayers.

In 2024-25 alone, the tax authority collected over £2 million in tax that was not due. Individually, the loss is tiny: the average was around £1.76 per year for basic-rate taxpayers, and £2.30 for those receiving the full new state pension. It is precisely this smallness that explains why the HMRC error survived so long: nobody challenges £2.

Why a 2010 bug went unnoticed for 15 years

No pensioner files a lawsuit over a couple of pounds extra. No product manager prioritises a discrepancy of pennies. And the system, of course, did not complain about itself. The bug stayed under everyone's radar precisely because the unit damage was negligible — but the aggregate damage, summed over millions of cases and fifteen years, became a national scandal.

What broke the story was journalism, not technology: an investigation by The Telegraph Money exposed the inconsistency in May 2026, forcing the tax authority to admit the fault. In software, the lesson is harsh — when the press finds your bug before you do, the problem has stopped being technical and has become reputational.

The triple lock and the technical root of the miscalculation

The structural trigger is the triple lock, the rule that increases the state pension each April by the highest of inflation, earnings growth, or 2.5%. Every year there is a step change in value mid-tax-year, and it is this step that requires the "51 + 1 weeks" calculation.

The technical root lies in a mismatch between two government systems. The Department for Work and Pensions (DWP) reports pension income on a linear 52-week basis, while HMRC's rules require the split-week method. When two services speak different languages about the same data and nobody reconciles them, the result is predictable: one side takes the other's number without translating, and the HMRC error propagates silently across the entire database.

The official response: an apology to Parliament

John-Paul Marks, HMRC's Chief Executive, was forced to write to the Chair of the Public Accounts Committee in the House of Commons admitting the fault. "I apologise for this error, especially to the pensioners who have been affected," he wrote in the letter. He stated that the correction for the 2025-26 calculation would be issued by summer 2026.

What the letter did not promise is as important as what it did: there was no commitment to automatic refunds for previous years. In other words, the responsibility to check and claim remains with each taxpayer — the same silent pattern that created the problem also shapes its solution.

The lesson for those who build and maintain software

Replace "United Kingdom" with "your billing system" and the story becomes uncomfortably familiar. Every product that handles money — payroll, recurring billing, commission, tax — carries edge cases like this. And every poorly coded edge case is a low-intensity time bomb.

Legacy systems are technical debt that compounds

A piece of code written in 2010 and never revisited is not "stable" — it is merely unobserved. Legacy code that handles values needs periodic auditing, not faith. The same reasoning applies to dependencies: silent faults in software supply chains have already proven the damage they can cause unnoticed, as we showed in the case of NPM packages infected by Shai-Hulud.

Business rules need tests that describe them

The HMRC bug survived because, apparently, there was no automated test stating "the year should sum 51 weeks at the new rate and 1 at the old rate." A single rule test, written in business language, would have failed in 2010 and saved fifteen years of embarrassment. Rule tests do not just protect against regression — they document intent.

System migration is the most dangerous moment

It is no coincidence that the fault was born precisely during a change to PAYE in 2010. Migrations, refactorings, and calculation engine swaps are exactly where subtle rules get lost, because the team focuses on "it works the same in the common case" and forgets the edges. Every system change that touches values should run in parallel with the old system for a few cycles, comparing output by output — a shadow run. If the new engine had been compared line by line with the old one, the one-week divergence would have appeared in the first close, not the first news report. This same HMRC error would have been trivial to catch with a reconciliation diary between the new and old calculation versions.

How to detect silent errors before they become scandals

Faults that do not crash require an observability discipline that goes beyond "is it up?" In practice, what prevents a case like this:

Automatic reconciliation between sources: if the DWP says X and HMRC calculates Y, a daily job should compare the aggregates and scream when they diverge.
Business rule tests: every tax rule, every rounding, every "51 + 1" deserves an explicit, named test.
Anomaly monitoring on aggregates: do not just look at individual cases — sum everything and observe the trend. A jump from 762,000 to 1.4 million affected is a signal, not a coincidence.
Legacy code auditing: schedule cycles to revisit old financial modules that "nobody has touched in years."
Log trails and replay: storing the calculation for each period allows you to redo the maths and prove where the logic went wrong.

Silent errors also haunt security, not just accounting — a compromise that goes unnoticed can cost dearly, as in the case of GitHub invaded by a malicious VS Code extension. The pattern is the same: what is not monitored is not trustworthy.

The hidden cost of systems nobody audits

Two pounds per person does not break anyone. Multiplied by 1.4 million taxpayers and fifteen years, it breaks trust in an entire institution. Small, constant leaks are the most insidious form of loss in software, because they do not trigger alarms — they just drain.

It is the same mechanism we analysed when exposing the hidden cost of markup in WhatsApp messages: a tiny fee per unit, invisible on an individual statement, that becomes a fortune at scale. Whether it is an overcharged tax or a penny extra per message, the antidote is the same — transparency in calculation and independent auditing of code that handles money.

What affected pensioners in the UK should do

For those living in the UK who suspect they have been affected, the path is straightforward. The deadline to claim overpaid tax is four years from the end of the relevant tax year — for 2025-26, that means until April 2030, but claiming earlier returns the money sooner.

Check your calculation to see if the pension income appears as 52 weeks at the full rate instead of 51 + 1.
Gather your coding notices and statements from the years in question.
Use the official channels at gov.uk/claim-tax-refund and consult the pension rules at gov.uk/state-pension.

This text is an editorial and technology analysis, not tax advice — individual cases should be confirmed with HMRC or an accountant.

Conclusion: every line of code that handles money counts

The HMRC error was not malicious genius; it was an absence of auditing. One number changed in 2010, without a test to challenge it and without a reconciliation to catch it, cost fifteen years of credibility and millions in incorrect charges. It is the kind of fault that any billing, invoicing, or compliance system could be harbouring right now, waiting for someone to add up the pennies.

At Agathas Web, we treat financial software for what it is: code where the detail costs money. If you maintain legacy systems that calculate values and have never undergone a serious audit, now is the time to look — before the press, or your customer, looks first.