Property counts and transaction counts are different measures

What HM Land Registry says the dataset contains

According to HM Land Registry’s guidance on how to access Price Paid Data, the dataset tracks property sales in England and Wales that are submitted for registration. The collection page also states that Price Paid Data contains sale prices of properties in England and Wales submitted for registration.

The same guidance explains several fields that matter for counting. It describes the transaction unique identifier as a reference generated for each published sale. It also explains PAON as the primary addressable object name, typically the house number or name, and SAON as the secondary addressable object name used where a property has been divided into separate units, such as flats.

That definition is the key to the counting difference. The unique identifier identifies a published sale record. The address fields help describe the property or unit involved. Those are different jobs, so they should not be used interchangeably.

• Transaction unique identifier: identifies a published sale record.
• PAON: usually the building number or building name.
• SAON: helps identify a separate unit within a building, such as a flat.
• Date of Transfer: the completion date stated on the transfer deed.

Why property counts and transaction counts diverge

If a freehold house sells in 2021 and sells again in 2025, that is two transactions involving one property. A row count would give you 2. A distinct-property count would give you 1.

The same logic applies to flats. HM Land Registry says SAON is used where separate units exist within one building. So Flat 1 and Flat 2 in the same building are different properties for counting purposes, even if they share the same PAON, street and postcode.

HM Land Registry also warns that the dataset is based on registrations and that timing varies. Its guidance says the period between sale and registration typically ranges from 2 weeks to 2 months, and the two most recent months are incomplete. That means counts depend not only on your method, but also on which extract or refresh point you use.

• Same property, multiple sales over time: property count 1, transaction count more than 1.
• Same building, multiple flats: property count depends on the unit level, not just the building name.
• Recent periods can be incomplete because registration timing varies.

A labelled synthetic dataset

The example below is fictional and is included only to show a counting method. It is not real market evidence.

Suppose you filter a small working table to one street and keep these fields: transaction ID, transfer date, postcode, PAON, SAON and street.

• TX1001 | 2022-03-15 | AB1 2CD | 10 | blank | Market Street
• TX1044 | 2024-07-01 | AB1 2CD | 10 | blank | Market Street
• TX2003 | 2023-01-20 | AB1 2CD | 20 | Flat 1 | Market Street
• TX2088 | 2025-02-11 | AB1 2CD | 20 | Flat 1 | Market Street
• TX2004 | 2023-06-30 | AB1 2CD | 20 | Flat 2 | Market Street
• TX3001 | 2024-09-05 | AB1 2CD | The Old Bakery | blank | Market Street

How to count that dataset correctly

Using the fictional records above, the transaction count is 6 because there are 6 sale records.

A simple distinct-property method is to create a property key from the address parts that identify the unit. In this example, one workable key is postcode + PAON + SAON + street, with blanks standardised consistently. On that basis, the distinct property keys are: AB1 2CD|10|blank|Market Street, AB1 2CD|20|Flat 1|Market Street, AB1 2CD|20|Flat 2|Market Street, and AB1 2CD|The Old Bakery|blank|Market Street.

That produces 4 properties and 6 transactions. The difference exists because number 10 sold twice and Flat 1 at number 20 sold twice.

This is consistent with HM Land Registry’s field definitions. The transaction unique identifier is for the sale record, while PAON and SAON help describe which property or unit the record relates to.

• Transaction count = count of rows after your chosen exclusions and cleaning.
• Property count = count of distinct property keys built from address fields.
• In the fictional example: 6 transactions, 4 properties.

A reproducible counting workflow

If you want colleagues to reproduce your numbers, write down the method before you count. HM Land Registry’s guidance explains that file types behave differently. Monthly files can include additions, changes and deletions through the record status field, while the single and yearly downloads incorporate amendments differently.

A practical workflow is: first, state the source extract you used. Second, decide whether you are counting transactions or distinct properties. Third, clean the address fields consistently, including blank SAON values. Fourth, build the same property key every time. Fifth, if you use monthly files, apply record-status handling so that deleted or changed records do not remain in your stored data.

HM Land Registry specifically says that in monthly files A means addition, C means change and D means delete. It also says that when a transaction changes category type due to misallocation, it will be deleted from the original category and added to the correct category with a new transaction unique identifier. That is another reason not to treat raw row counts from mixed monthly files as a stable property count without processing.

• 1. Record the exact HM Land Registry file or refresh point used.
• 2. Decide whether your headline measure is transactions or properties.
• 3. Standardise postcode, PAON, SAON and street values.
• 4. Build one consistent property key.
• 5. For monthly files, process A, C and D record statuses before final counting.
• 6. Keep transaction totals and property totals in separate output columns.

Limitations and next checks

This method is useful, but it has limits. HM Land Registry says postcodes are those used at the time of the original transaction and later postcode reallocations are not reflected in the dataset. The guidance also notes that administrative areas can change over time. That means address-based matching can need careful review if you are combining long time periods or comparing to other datasets.

The method here is also only about HM Land Registry Price Paid Data coverage. HM Land Registry says the dataset excludes sales not lodged for registration, sales not for value and several other excluded transaction types listed in its guidance. So neither a property count nor a transaction count from this dataset should be described as a full count of every possible property transfer.

Your next check should be to test your property key on a small sample before scaling up. Review repeated addresses, flats and named buildings. If your business output needs both demand and stock-style measures, publish both numbers together: one column for transactions and one for distinct properties represented in the filtered dataset.

• Scope: England and Wales only.
• Coverage: only sales submitted for registration and included by HM Land Registry’s rules.
• Address fields may need careful handling over long time spans.
• Check a sample manually before relying on automated counts.