You cannot fine-tune your way out of bad records

In the twelve months from 4 March 2024, Companies House queried and removed false or misleading information affecting 100,400 companies. It rejected over 10,200 suspicious applications. On a longer count, running from March 2024 to the point of writing in October 2025, false entries had been removed from 82,600 registered office addresses, 66,900 officer addresses and 55,100 addresses for people with significant control.

Those figures come from the registrar’s own Integrity and Enforcement Team, writing on 8 October 2025. In one investigation into company cloning during 2024 the team flagged 786 suspicious incorporations, removed 965 companies and struck out 2,895 fraudulent appointments.

Now consider what that register is used for. It is the dataset against which British firms verify who they are contracting with, who owns a counterparty, and whether a director is who they claim to be. It underpins onboarding checks in banks, credit decisions in trade finance, supplier due diligence in procurement, and a great deal of automated screening that runs without a human ever looking.

The register was never designed to be true

The reason is not incompetence, and understanding it is the whole point of this piece.

For most of its history Companies House operated as a filing repository. It received what companies told it and made that available. It had limited power to question the content, so an address you had never visited could be recorded as your registered office, and a person who did not exist could be recorded as a director, and the register would faithfully reproduce both.

That changed with the Economic Crime and Corporate Transparency Act 2023. From 18 November 2025, identity verification became compulsory for new directors and people with significant control, with a twelve month transition for those already on the register. More than 1.5 million individuals had verified by that date, having started voluntarily in April.

The general rule underneath is worth stating plainly because it applies to every internal system in every organisation reading this. A dataset’s accuracy is decided at intake, not at cleaning. The 100,400 figure is not evidence that Companies House is now doing a good job of quality control. It is the measured cost of two decades of accepting whatever was submitted. Cleaning is always remediation of an intake design, it always costs more than the check would have, and it never gets you back to where verification at the door would have left you.

Ask of your own systems which fields are checked at entry and which are merely stored. In most organisations the honest answer is that almost nothing is checked, because every check is a point of friction that somebody once removed to improve a conversion rate.

Almost nobody measures their own error rate

Here is the thing that separates organisations which improve from organisations which discuss improving.

The Department for Work and Pensions publishes, annually, a measured estimate of how often it pays the wrong amount. In the year ending 2026, published on 14 May 2026 and revised on 19 May, 3.2% of benefit expenditure was overpaid, worth £9.9 billion. Of that, official error, meaning error by the department, a local authority or HMRC rather than by the claimant, accounted for 0.4%, or £1.1 billion. Separately, 0.4% of expenditure was underpaid, £1.2 billion, and underpayment is attributed entirely to official error.

So roughly £2.3 billion a year moves incorrectly because a record or a process was wrong rather than because anybody lied. The estimate comes from a sample of claims reviewed for accuracy by a specialist team, drawn between September 2024 and October 2025.

Set aside the politics of the number and look at the method. A large organisation takes a sample of its own transactions, has trained people adjudicate each one against the underlying truth, and publishes the resulting error rate with a confidence interval and a breakdown by cause. Then it does it again the following year, so the direction of travel is knowable.

Now name a private company that publishes anything comparable about its own master data. There are very few, and the reason is not that the exercise is expensive. Sampling a few hundred records and adjudicating them is a fortnight of work for two people. The reason is that the resulting number is embarrassing and unowned, and no executive has to produce it.

This is the actual bottleneck, and it is upstream of every technology decision. An organisation that does not know its error rate cannot tell whether a data quality investment worked, cannot tell a supplier what accuracy it needs, and cannot answer the only question that matters about an automated decision, which is how often it is wrong.

Why models make this worse rather than better

There is a persistent hope in enterprise AI that a sufficiently capable model will smooth over messy inputs, in the way that a good analyst does. It is worth being precise about why that hope is misplaced, because the reasoning is not simply that rubbish in produces rubbish out.

Three mechanisms make model deployment a quality amplifier.

The first is throughput. A defect that reached a hundred decisions a week when a person was reading each file reaches a hundred thousand when the process is automated, and it reaches them before anybody has noticed the pattern.

The second is plausibility. When a human analyst hits a record that is internally contradictory, the contradiction stops them. A language model interpolates. It produces an answer of exactly the same fluency and confidence as it produces for clean records, which means the output carries no signal that anything was wrong. Bad inputs used to announce themselves through friction. Now they do not.

The third is the removal of the incidental audit. In most organisations, data quality is silently maintained by people who notice things while doing something else. The clerk who spots that an address looks wrong, the account manager who knows this customer merged two years ago. Automating their task removes the check without removing it from anyone’s mental model of the process, because it was never in anyone’s job description in the first place.

Four defects that specifically break automation

Not all bad data is equally dangerous. Four classes cause most automation failures in large British organisations, and they are worth naming because they are diagnosable in an afternoon.

Identifier collision. Two different real world entities sharing a key, or one entity holding several. Every merger produces both, and the join that looked correct in testing silently combines two customers into one, or splits one across two. This is the defect that produces the wrong answer rather than no answer, which is why it survives testing.

Silent schema drift. A field’s meaning changes while its name and type stay the same. A status code repurposed, a currency column that quietly switched from gross to net, a date that used to be the order date and is now the despatch date. Nothing breaks. Everything downstream is wrong from that day onward, and the discontinuity is invisible unless somebody plots the series.

Deprecated codes that are still emitted. A reference list is retired, the documentation is updated, and the system carries on producing the old values because a legacy integration was never changed. Anything validating against current documentation rejects perfectly real records, and anything not validating accepts them and mislabels them.

Meaning hiding in free text. The most consequential fact about a case is very often in a notes field, entered by someone working around a form that had no box for it. Structured extraction from those notes is now technically easy, which is exactly why it is dangerous: the conventions in that field were never standardised, they vary by team and by decade, and a model reading them will impose consistency that was never there.

None of the four is exotic and none is expensive to look for. What they have in common is that they are invisible to any monitoring built around uptime, latency or record counts, which is what most organisations actually monitor.

Fine-tuning does not fix facts

The specific technical belief worth killing is that further training will resolve this.

Fine-tuning adjusts how a model behaves: its tone, its format, its willingness to follow a particular pattern of reasoning. It does not install a corrected fact about your customer’s ownership structure, and it cannot, because the corrected fact is not in the training signal. If your records say a dissolved subsidiary is active, a fine-tuned model tells you so more fluently.

Retrieval is a better answer and it has the same limit. Retrieving the authoritative record helps enormously when there is an authoritative record. Where the difficulty is that four systems hold four versions and no rule says which governs, retrieval simply moves the choice into a similarity score, which is a worse adjudicator than a person and considerably harder to appeal.

The uncomfortable corollary is that the parts of the estate least ready for automation are exactly the parts where automation is most attractive, because processes accumulate manual workarounds in proportion to how bad their data is. The team doing the most tedious reconciliation is doing it for a reason.

What to do first, and what it costs

Measure. Draw a sample of the master dataset that matters most, a few hundred records, and have two knowledgeable people independently adjudicate each one against reality: the contract, the system of record, the customer. Record disagreement between the adjudicators too, because that tells you whether your definition of correct is itself contested. Publish the number internally. Repeat it quarterly.

That exercise costs a fortnight and produces the thing no dashboard can, which is a defensible statement about how wrong you are and in which direction. Every subsequent argument about investment becomes tractable once it exists, and almost none of them are tractable before.

Then move the check upstream. Every defect found in the sample has an intake point, and fixing it there is cheaper than any downstream reconciliation, permanently. That is the lesson the register learned at a cost of 100,400 companies.

The infrastructure this discipline has to sit on, and the order in which to build it, is set out at most AI projects fail one layer below the model. For the bill that arrives in year two of an automated process, see what automation costs to run. The rest of this desk’s reporting sits at data and analytics.