Why flat matching goes wrong
Two public records can look similar while still referring to different things. One may identify a unit within a building, while another may refer only to the building name or number. That is especially risky in blocks converted into flats, mixed-use buildings or addresses that have changed format over time.
HM Land Registry explains that Price Paid Data contains separate address components rather than one single free-text address. It says PAON means Primary Addressable Object Name and is typically the house number or name. It says SAON means Secondary Addressable Object Name and is used where a property has been divided into separate units, for example flats, so the building may sit in PAON and the unit in SAON.
That means a missing flat number in one source is not a minor spelling issue. It may be the difference between a building-level reference and a unit-level reference.
- Treat unit identity as a separate question from building identity.
- Do not merge records just because the street and postcode look right.
- Record which source names a flat explicitly and which does not.
What the source definitions tell you
The HM Land Registry guidance gives a practical starting point for interpreting sold-price records. Besides PAON and SAON, it lists Street, Locality, Town or City, District and County as separate fields. It also says the postcode in Price Paid Data is the postcode used at the time of the original transaction, and notes that later postcode changes are not reflected in the dataset.
That detail matters for property address matching. If a current certificate search returns a slightly different postcode pattern, that does not automatically mean the records are different properties. Equally, if two records share a postcode, that does not prove they are the same unit.
The GOV.UK energy certificate service gives different search routes: postcode, street name and town, or certificate number. It also says the service covers properties in England, Wales and Northern Ireland, including homes, business properties and public buildings, while Scotland has a different service. In practice, that means you should note both the jurisdiction and the search route you used when saving evidence.
- Read Price Paid Data address fields as structured components, not one perfect mailing address.
- Keep historic postcode wording separate from current search results.
- Log whether a certificate was found by postcode search or by a more specific reference.
A simple confidence log for ambiguous unit matches
When records are messy, a confidence log is often more useful than a yes-or-no match column. The idea is to record what is directly supported by the source and what still needs checking.
A simple log can use four confidence levels: confirmed, probable, possible and unresolved. Confirmed should be reserved for cases where the unit and building both align clearly across the sources you checked. Probable may fit a case where the building matches and the flat identifier is very close, but one source uses a variant such as Flat 2 and 2A. Possible is for building-level matches without solid unit evidence. Unresolved is for conflicts or missing unit detail.
This is your internal research method, not an official government standard. Its value is that it stops weak matches being treated as facts.
- Source checked
- Jurisdiction
- Search method used
- Building identifier from each source
- Unit identifier from each source
- Postcode comparison note
- Confidence level
- Reason for confidence level
- Next check needed
Fictional worked example: three records for one building, but which flat?
Fictional example. Imagine you are reviewing three records for Rose Court on the same street. Record A in sold-price data shows SAON: Flat 3, PAON: Rose Court, plus the street and postcode. Record B from an energy certificate search result appears as 3 Rose Court with the same street and postcode. Record C appears only as Rose Court, same street, same postcode, with no visible flat reference in your notes.
A cautious property address matching workflow would not treat all three as one property. Record A and Record B may be a probable or even confirmed unit match if the rest of the address components align and you can see that the unit wording is simply formatted differently. But Record C is weaker. Because it lacks a flat reference, it may refer to the building generally, to a communal certificate context, or simply to an incomplete note in your own file. The shared postcode does not solve that ambiguity.
In your confidence log, you might record A plus B as probable pending one more check of the exact address display, and C as possible building-only match. You would avoid combining C into the flat record until stronger unit evidence appears.
- Flat 3 versus 3 Rose Court can be a formatting issue, but it still needs checking.
- Rose Court on its own is not enough to prove Flat 3.
- The same postcode across all three records supports proximity, not identity.
Checklist before you combine records
Use this short checklist before you merge flat and building records in your own dataset or research file.
First, confirm jurisdiction. Price Paid Data is for England and Wales. The energy certificate search covers England, Wales and Northern Ireland, and Scotland is separate.
Second, break each address into parts. Pull out SAON, PAON, street, town or city, district and postcode where available.
Third, compare building identity before unit identity. Make sure the main building name or number is consistent.
Fourth, compare unit wording carefully. Flat 2, Apartment 2, Unit 2 and 2A should not be treated as interchangeable without evidence.
Fifth, note postcode limitations. HM Land Registry says the postcode in Price Paid Data is the one used at the time of the original transaction.
Sixth, record how you found the energy certificate result. The GOV.UK service allows different search methods, and broad postcode searching can surface nearby or similarly named entries.
Seventh, assign a confidence level and keep unresolved cases separate rather than forcing a match.
- Check jurisdiction first.
- Split addresses into fields.
- Match building before unit.
- Do not rely on postcode alone.
- Keep an evidence note for every merged record.
Limitations and next checks
Public records are useful starting points, but they do not guarantee a clean one-to-one address match. HM Land Registry says it tries to keep public data accurate but cannot guarantee it is free from errors. It also explains that administrative areas and postcodes can change over time, so older records may not mirror current address conventions.
The energy certificate search page explains how to find existing certificates, but the search result you capture is still only one source. If your project depends on exact unit identity, treat unresolved cases as research gaps rather than filling them with assumptions.
A sensible next step is to revisit the original record displays, keep a dated note of what each source actually showed, and only combine records where the building and unit evidence are strong enough for your purpose. Planning Data Hub can help businesses organise property research, but readers should still check the original source and whether the match is good enough for their own project.
- Some records may remain unresolved after first review.
- Historic and current address formats can differ.
- Your confidence threshold should depend on the task you are doing next.
Sources & further reading
- How to access HM Land Registry Price Paid Data - GOV.UK Accessed 22 October 2026
- Find an energy certificate - GOV.UK Accessed 22 October 2026

