The Identifier Beneath the Address: A One-Sitting UPRN Audit for UK Customer Files

Most UK customer tables contain an address field. Far fewer contain an address entity. That distinction matters because customer matching is routinely framed as a master data management programme, with all the cost, sponsorship and governance weight that implies, before anyone has tested whether the underlying addresses can be matched at all. A UPRN audit is a smaller and more revealing question: can this file be anchored to a stable property identifier, and what does the failure rate tell us about the next move?

The Unique Property Reference Number, or UPRN, is the identifier most UK organisations already have access to through Ordnance Survey AddressBase products and the GeoPlace address infrastructure. It is not a customer number, a household number or a postal product. It identifies a property or premises. For customer records, that is often exactly the missing anchor: a way to say that these four differently typed lines refer to one front door, and that this flat above a shop is not the shop.

Why the address problem precedes the matching problem

Customer matching projects tend to begin with algorithms, fuzzy logic and survivorship rules. They should begin with the raw material. In many UK customer files, the address is a concatenation of lines captured at different times by different processes. One record has a flat number in line one. Another has it in line two. A third omits it and relies on a postcode that covers twelve premises. A fourth has a valid postcode but the wrong street number because a sales agent corrected it from memory.

None of these failures is solved by buying a better matching engine first. They are data capture and data structure problems wearing the costume of a technology problem. A UPRN test exposes them quickly because it asks a property-level question rather than a string-similarity question.

What the identifier does and does not do

A UPRN gives a persistent reference to a property. It helps distinguish a building from a unit within a building, and it allows an organisation to join its customer records to authoritative address data without relying on postal formatting. It does not tell you that two customers are the same person, that a household has moved, or that a business has changed hands. It is an anchor, not a customer identity.

That limitation is useful. It keeps the test honest. The question is not whether the customer record is correct in every respect. The question is whether the address in the record can be resolved to a property that actually exists in the national address base, and whether multiple customer rows resolve to the same property when they should.

The one-afternoon test

Scope the exercise to one customer table and one afternoon. Do not attempt every system. The aim is a diagnostic, not a migration.

1. Take a defensible sample

Extract a random sample of 500 to 1,000 active customer rows from the table. Include the address lines, postcode, customer identifier and any premise-type field such as residential, commercial or billing address. If the table contains multiple address types, pick one for the first pass. Mixing service addresses and billing addresses will confuse the read.

2. Standardise only what is cheap to standardise

Do not build a bespoke address parser. Use the address matching capability available through your AddressBase licence, a commercial address lookup service, or a geocoding tool that returns UPRNs. The test is whether the existing address text can be resolved, not whether a data engineer can hand-clean it into submission.

3. Classify the matches

For each row, record one of four outcomes: exact property match with a UPRN; probable match requiring review; street or postcode match only; no match. This four-way classification is more useful than a single percentage because it separates formatting noise from genuine ambiguity.

4. Count duplicates by UPRN

Group the matched rows by UPRN and count customer identifiers per property. A small number of shared UPRNs is expected in households, flats and multi-occupancy buildings. A large number on a single UPRN often indicates a default address, a shared registered office or a capture failure. Look at the distribution rather than the average.

5. Inspect the mismatches manually

Take twenty unmatched or ambiguous rows and read them. This is the step most teams skip. The pattern in those twenty rows usually explains the result better than the aggregate score.

Reading the result

The numbers are not a grade. They are a triage signal.

If more than 95 per cent of the sample resolves to a property-level UPRN and duplicate rates sit at a level your business can explain, the problem is likely to be fixed at source. Tighten address capture at the point of entry, validate postcodes against AddressBase, and stop new records from arriving unanchored. A matching service may still help at the margins, but a full MDM programme would be premature.

If property-level resolution sits between roughly 80 and 95 per cent, or if duplicates cluster in a way that cannot be explained by households and multi-occupancy, a matching service is usually the pragmatic next step. The organisation needs ongoing resolution, not a one-off cleanse. The service should return UPRNs and a confidence indicator, and it should be tested against the same sample before purchase.

If resolution falls below 80 per cent, or if several systems disagree about the same customers, the case for a fuller master data effort strengthens. But even then, the UPRN audit should shape the business case. It tells you whether the programme is fixing identity, address structure, capture discipline or all three. Those are different budgets.

A governance note before starting

Address data is personal data when it relates to an identifiable individual. A UPRN audit should be scoped accordingly. Use a controlled sample, document the lawful basis for processing, and avoid exporting full customer records to third-party tools where a postcode and address fragment will do. The audit is a data quality exercise, but it is still a processing activity.

It also helps to agree in advance who owns the outcome. If the test shows a capture problem, the remedy sits with the teams that create customer records, not only with the data office. If it shows a systems problem, the remedy sits with architecture. A UPRN audit that produces a number but no owner is an interesting afternoon with no institutional effect.

The decision after the afternoon

The appeal of the UPRN test is that it replaces an abstract debate about master data with a concrete read on the customer file. It does not settle the whole customer matching question. It does tell UK organisations whether they are dealing with a formatting nuisance, a resolution service requirement or a genuine master data problem. That is enough to choose the next spend with a little more confidence and a little less ceremony.