Price Paid Data: apply monthly changes before counting sales

You combine three monthly property-data files and count their rows. The total looks like a sales figure, but some rows may correct or remove earlier entries. In HM Land Registry’s Price Paid Data for England and Wales, a monthly update is not simply a list of homes sold during that month.

Decide which output you need: a current view of transaction records, a history of changes, or transactions selected by transfer date. Those are three different tables. Keeping them separate prevents a correction from becoming an extra sale in your analysis.

Read the two status columns separately

The official field and record-status guide distinguishes transaction category A/B from monthly record status A/C/D. In the latter, A adds a record, C changes an existing record and D removes one. Apply changes using the transaction identifier. A category correction can remove an old identifier and introduce a new one.

Give the columns unambiguous names in your working copy, such as ppd_category and record_action. Seeing “A” twice does not mean the fields do the same job. Preserve the source fields and their order before renaming anything; the CSV import exercise helps check that identifiers survive the import.

Four update rows, one record left

The following teaching example is invented. Its short identifiers are deliberately fictional, its prices are not observations, and no real address or transaction is being examined. We start with an empty current view and process three imagined releases in sequence.

In this constructed history, release two corrects the price and release three corrects the category. Appending every row produces four rows. Counting only additions produces two. Applying the complete changes leaves one current transaction record. Our local replay of these invented actions checked that final state; it was not an audit of a Land Registry download.

We know the old and new identifiers refer to a category correction because the example defines that history. Do not infer the same relationship in real data merely because two prices or addresses match. Where the connection is unresolved, retain the uncertainty instead of inventing a merge rule.

Keep an archive and a current view

Store each downloaded release unchanged, with its source, retrieval time, stated coverage and hash. Maintain a separate log of which releases have been applied. A second run should recognize an already processed release rather than append it again.

In the working current view, require a unique transaction key. An addition should introduce a key; a change should update a known key; a deletion should remove that key from the current view while leaving the archived evidence intact. Treat an unexpected duplicate addition or a change for an unknown key as an exception to investigate. It may reveal a missing release or an incorrectly chosen starting dataset.

For a new project that only needs the current picture, begin with a fresh complete dataset or a suitable official report rather than reconstructing years of changes. Record its version and avoid applying updates it already contains. If you maintain incremental data, test the release on a copy, inspect exceptions, and commit the resulting view only after the checks pass.

Then choose the date and the denominator

The official downloads page, checked on 4 November 2026, listed September 2026 as its current monthly release. It includes records received in that month and revisions to earlier releases. The publisher cautions against treating the latest month alone as a complete picture of activity.

For a question about when transactions occurred, use the documented transfer-date field after reconciliation. For a question about changes received in a release, count update actions and label them as actions. Neither count is automatically a count of distinct properties. The field guide defines the identifier as transaction-specific rather than a lasting property identifier.

Before sharing a total, write one sentence specifying the dataset version, date field, geographic and category filters, treatment of changes, and unit counted. For example: “Current transaction records matching these filters and transfer dates, using the dataset retrieved on [date].” Fill the brackets from your evidence. A tidy row count becomes useful only when a reader can reconstruct what you counted.