The Company Behind the Number: An Entity-Resolution Audit for UK Systems

A UK group can appear in the same operational estate as a legal entity, a trading brand, a supplier account, a billing address and a legacy finance code. Each representation may be correct in its own system. The difficulty begins when those representations are treated as interchangeable. Entity identity is not a naming problem to be cleaned up at the end of a programme; it is an operational control that determines whether payments, reporting, procurement and customer records refer to the same organisation.

Why entity identity fails quietly

Most failures are not dramatic. A CRM record uses a trading name that has no legal standing. An ERP company code reflects an old divisional structure. A procurement supplier record carries a VAT number that belongs to a group registration rather than the contracting entity. A reporting layer then joins these records on name similarity and produces a consolidated view that looks plausible but cannot be defended.

The UK context adds particular complications. Companies House numbers identify legal entities, but a group may operate through dormant companies, special purpose vehicles, franchise arrangements or entities that have changed name. VAT registration may be group-wide or held by a different entity from the one named on the contract. Trading names are not legal identifiers. Legacy account codes often encode historic sales territories or finance hierarchies rather than current corporate structure.

For data architecture teams, the issue is not simply master data quality. It is the absence of a governed relationship between identifiers across systems. Without that relationship, every reconciliation becomes a local judgement, and every local judgement becomes a future exception.

Begin with a register, not a matching exercise

An entity-resolution audit should start with an inventory of the identifiers already in use. For each operational system, record the legal name, company number, VAT registration, registered address, trading names, parent entity, legacy account codes, source system, status and effective dates. Include the system owner and the purpose for which the identifier is used.

The register should distinguish between different kinds of identity. A legal entity is not the same as a trading location, a contract, a customer account or a supplier record. A single company may have several sites, brands and accounts. A single account may, incorrectly, contain several legal entities. The audit should make those distinctions explicit before any merge logic is proposed.

This is also the point to assign stewardship. Companies House should be treated as authoritative for legal existence and company numbers. HMRC should be treated as authoritative for VAT registration. Internal finance should own the chart of accounts and company codes. CRM should own commercial relationships and trading names, but not legal identity. Procurement should own supplier onboarding evidence. No single system should be allowed to overwrite another system's authoritative identifier without a controlled process.

The three numbers that rarely agree

The company number, the VAT registration and the legacy account code are the three identifiers most likely to disagree in UK operational estates. Each has a different purpose. The company number confirms legal existence. The VAT registration confirms a taxable registration, which may be group-wide. The legacy account code reflects an internal finance or sales structure that may no longer match either.

A practical audit tests each identifier against its authoritative source and records the result. Does the company number exist and is it active? Does the VAT number belong to the same legal entity, or to a group registration? Is the account code still in use, and which reporting hierarchy does it serve? Where a discrepancy exists, the audit should record whether it is expected, tolerated or unresolved.

The important discipline is to avoid inferring one identifier from another. A matching address does not prove a matching entity. A similar name does not prove a shared company number. A shared VAT number does not prove that two supplier records should be merged. These inferences are common because they are convenient, but they are not evidence.

Merge-and-survivor rules that can be defended

Where duplicate records are confirmed, merge rules should operate at attribute level rather than record level. The surviving legal name should come from the statutory source. The trading name may come from CRM where it reflects commercial practice. The billing address should come from finance or the contract. The VAT registration should come from the tax record. The legacy account code should survive only where it still has an operational purpose.

Each attribute should carry a source, a timestamp and a reason for survivorship. The audit trail should show what changed, who approved it and which evidence supported the decision. Where an entity has changed name or number, the previous identifiers should remain linked rather than deleted. Historic reporting depends on being able to reconstruct the identity that applied at the time.

Merge rules should also define what happens to related records. Contacts, contracts, invoices, purchase orders and support tickets may need to be re-pointed. If those relationships are not considered, a clean entity record can still leave a fragmented operational picture.

Exceptions that should never be auto-matched

Some cases should always go to human review. Similar names, shared registered addresses, group VAT registrations, franchise arrangements, dissolved companies, dormant entities, special purpose vehicles and supplier aliases are common sources of false matches. Sole traders and partnerships may trade under names that differ from the legal entity. A company that has changed name may still appear under its former name in older systems.

These cases should be placed on a negative match list or an exception queue with clear ownership. Automated matching can propose candidates, but it should not confirm them. The cost of a false merge is often higher than the cost of a manual review: duplicate payments, misstated consolidation, incorrect supplier due diligence and reporting that cannot be reconciled to statutory accounts.

Running the audit as a standing control

The first audit will be substantial, but the value comes from making it repeatable. A quarterly reconciliation of new and changed records against the entity register is more useful than an annual clean-up. Procurement onboarding, CRM account creation and ERP supplier maintenance should all check against the register before a new record is created.

Metrics should reflect operational risk rather than record counts alone. Track unresolved exceptions, records without a verified company number, VAT registrations that do not match the contracting entity and merges reversed after review. Report these to the same governance forum that oversees reporting quality and procurement controls.

Entity identity is a data architecture concern because it determines how systems relate to one another. It is also a digital operations concern because it determines what the organisation can safely pay, procure, report and defend. The company behind the number should be a governed record, not an assumption embedded in a join.