Why UPRN Matching Matters in Property Searches (and What Gets It Wrong)

If you run a personal search company, the address is where every order begins. A solicitor sends you a property. You turn it into a search.

The bit in between — turning their version of the address into a confirmed, specific property — is UPRN matching. Most of the time it's invisible. When it goes wrong, it's the most expensive mistake in the whole process.

What is a UPRN, and why does the whole search hang off it?

A UPRN is a Unique Property Reference Number: the unique geocode for every addressable location in Great Britain, defined by the UPRN (GeoPlace). There are over 42.8 million of them. It's the anchor every part of your search hangs off.

Local authorities and Ordnance Survey allocate UPRNs from ranges that GeoPlace manages, and the data flows out through OS AddressBase. The plain identifier is published openly as OS Open UPRN (Ordnance Survey).

Here's why it matters to you. The UPRN doesn't just say "this property exists." It pins the property to a precise point, and through that point to the authority whose records you need. Get the right UPRN and everything downstream — which council, which area, which boundary — falls into place. The address is the question. The UPRN is the answer your whole search depends on.

What goes wrong when you match to the wrong UPRN?

Match the solicitor's address to the wrong UPRN and you've built the search on the wrong property. That can mean the wrong council, the wrong area, and a result that's either useless to the buyer or rejected outright. It's the single error that contaminates everything after it.

Think about what flows from the UPRN. It tells you which authority to request the CON29 and LLC1 from. It tells you which boundary to plot. It tells you what the property actually is — house, flat, plot. Get it wrong at the start and you don't get a slightly-off search. You get a search for the wrong place.

The dangerous part is that a wrong UPRN doesn't announce itself. The order processes normally. The council answers. A report builds. Nobody notices until the solicitor does, and by then it's gone out under your firm's name. A near-miss address — the flat next door, the plot two along — is far worse than no match at all, because no match makes someone stop and look.

Why don't all addresses match automatically?

Around 90% of addresses auto-match cleanly to a UPRN, in our experience. The other ~10% don't — and that minority is where the real work, and the real risk, sits. Solicitors send addresses as free text, and free text doesn't line up neatly with structured address data.

The reasons are familiar to anyone who's done this. New builds that aren't in the dataset yet, sent as plot numbers off a developer's plan. Flats and HMOs described one way by the solicitor and another way in AddressBase. Transposed postcodes, missing flat numbers, a house name where the data expects a number. None of it is the solicitor being careless. It's just what addresses look like in the wild.

The ~90% figure is Valio's own operational experience across the searches we process, not a published statistic. Your own rate will move with your mix of work — heavy new-build volume pushes the unmatched share up, because new builds are exactly the addresses the dataset is slowest to catch.

The bottleneck hiding in that 10%

Here's the part most firms underestimate. The 90% that auto-match cost you nothing. The 10% that don't get routed to one person — usually the person who "just knows" the awkward addresses. And that's a bottleneck waiting to happen.

I've watched firms where every tricky address waited for one experienced hand to come free. It works fine, until that person is on holiday, or off sick, or finally leaves. Then the unmatched pile grows, turnaround slips, and nobody else feels confident resolving an address they might get wrong. The knowledge never got written down because it lived in one head.

What does good UPRN matching software actually look like?

Good UPRN matching software does two jobs: it auto-matches the easy 90% with no human touch, and it gives the awkward 10% a clear, shared exception process. Not a pile in one person's inbox — a visible queue anyone trained can work, with the address data in front of them to confirm the right property.

Most firms judge matching tooling on its auto-match rate. That's the wrong test. The auto-matched addresses were never your problem. The real test is what happens to the ones that don't match — whether the tool turns the hard 10% into a structured task anyone can pick up, or quietly hands them back to the one person who's always done them.

So what should you look for? A high auto-match rate, yes. But more than that: a confirm step that shows whoever's resolving an address exactly which property they're picking, and an exception queue that doesn't depend on a single name. The councils each property maps to should already be known — that's the council data in Valio doing its job once the UPRN is confirmed.

"The worst search mistakes I've seen didn't start with the council. They started with the address. A flat matched to the wrong flat, a plot matched to the house next door. Everything after that was perfect — and perfectly wrong. Get the UPRN right and the rest of the search has a chance. Get it wrong and you've automated a mistake."

— Valerie Bennett, Personal Search Veteran · June 2026

UPRN matching isn't the glamorous part of the job. It's the foundation. And like any foundation, you only notice it when it's been laid wrong. If you're building out the rest of your operation, it's worth seeing how matching connects to everything downstream — covered in running a personal search business.

See how Valio handles council data → · The full order-to-invoice workflow → · Valio features →