Flat 2, Flat B and the Second Floor Flat
A property manager searches your product for a flat and finds three records: Flat 2, 14 Elm Road; Flat B, 14 Elm Road; and Second Floor Flat, 14 Elm Rd. One has the current tenancy, one has last year's gas certificate, and one has the inventory from when it was first let. They are the same flat. The negotiator who created the third one could not find the first two, so made a new one.
Multiply that across an agency with thousands of properties, and then across every agency using your product. Reports double count. History is split. When your product sends data back to the agency's CRM, it may create more duplicates there too.
Why text matching fails on UK addresses
UK addresses are messier than they look. Flats are numbered, lettered or described. Buildings have names that some people use and others leave out. Streets are abbreviated. New builds get plot numbers before they get postal addresses. Properties are split into flats or knocked back into houses.
- Each source system stores addresses in its own format, one field or five.
- Your product creates a new record when an exact text match fails.
- There is no stable property identifier stored alongside the address.
- Negotiators under time pressure create a new record rather than search harder.
- Nobody owns the job of merging duplicates, so they accumulate.
What duplicates cost the product and the agency
Duplicate property records break the thing your product is supposed to provide: a reliable history. Compliance documents sit on the wrong record, previous tenancies do not show, and reports disagree with the agency's own figures. Support tickets about missing information are often duplicates in disguise. Any analytics or AI feature you build on top inherits the same errors.
Duplicates also make integrations fragile. When your product pushes an update to the agency's CRM or a portal, it has to decide which of three records is the real one, and a wrong guess can overwrite good data with stale data. Developers end up writing special cases for individual agencies, which is the sort of code that nobody wants to touch a year later.
How we build address matching you can trust
What we build treats the property as an entity with an identifier, not a line of text.
- Address normalisation on the way in, so abbreviations, case, punctuation and flat descriptions are handled consistently before any comparison.
- Lookup against an address dataset, such as Ordnance Survey AddressBase or a postcode address service you license, to attach the UPRN (the unique property reference) where one can be found.
- Matching that uses the UPRN first, then postcode, building number or name, and sub-building details, producing a confidence score for each candidate.
- At the point of entry, the negotiator sees likely existing properties before a new one is created.
- Confident matches merge under your written rules, keeping every document and history item, with a record of the merge that can be reversed.
- Doubtful matches go to a review queue for the agency or your team, with both records side by side.
| Case | Handled by |
|---|---|
| Same UPRN, different spelling | Merged automatically, logged |
| Same postcode and number, flat described differently | Suggested merge, reviewed |
| New build with a plot number only | Kept separate, linked when the address is issued |
| House later split into flats | Parent and child records, not a merge |
| No UPRN found | Matched on address parts, reviewed if uncertain |
Licensing for address data is a commercial choice for you. We tell you what each option provides and build to the one you choose.
Searching for 14 Elm Road again
A negotiator starts typing a new property. Before they save, the product shows a likely match with the same UPRN and the history attached. They open it instead. The existing duplicates at that agency were worked through in a one-off review: most merged automatically, a few checked by the lettings manager, and two kept separate because the building really had been split. The property manager now finds one record with the tenancy, the certificate and the inventory in one place.
Checklist: duplicate properties
- Searching for an address in your product often returns more than one record.
- Documents are attached to a record that turns out to be a duplicate.
- Your product has no stored property identifier beyond the address text.
- Syncing with agency CRMs creates new records instead of matching existing ones.
- Merging duplicates is done by hand, occasionally, when someone complains.