Extract UK Completion Statements to Excel

A UK completion statement is the conveyancer's financial summary of the money coming into and out of a property transaction, usually issued shortly before completion. A practical completion statement to Excel UK workflow starts by separating buyer-side and seller-side line items, then capturing each row's amount, tax or VAT treatment, and any leasehold apportionment or mortgage-redemption detail in consistent columns. If that structure is missing, the spreadsheet may still look tidy, but it will be hard to review, reconcile, or reuse.

For a practitioner, the problem is not understanding what the document is. The problem is that each solicitor PDF mixes professional fees, property taxes, disbursement-style charges, leasehold adjustments, and balancing figures in a layout designed for client communication rather than row-level finance data. The cleanest approach is to treat the statement as a transaction dataset: convert each meaningful line into its own row, preserve whether it belongs to the buyer or seller side, and keep enough context for a reviewer to trace the figure back to the source document.

That matters because completion statements are not rare edge-case documents. HMRC's monthly UK property transaction statistics say the provisional seasonally adjusted estimate of the number of UK residential property transactions in February 2026 was 102,410. With that volume, a repeatable extraction method is far more useful than a generic consumer explanation, especially when the same finance team may need to review buyer statements, seller statements, and leasehold-heavy matters in the same reporting cycle.

Separate buyer and seller statements before you design the spreadsheet

The first spreadsheet decision is to preserve the side of the transaction on every row. Buyer and seller statements may share a few labels, but they do not describe the same cash movements. If those rows are collapsed into one undifferentiated table, later review becomes harder because identical-looking amounts can mean opposite things depending on whether the statement is funding a purchase or distributing sale proceeds.

On the buyer side, the extracted rows usually include purchase price, deposit, mortgage advance, SDLT, LBTT, or LTT, Land Registry fees, search fees, solicitor fees, VAT-bearing admin fees, leasehold notice fees, deed-of-covenant fees, and the balance to complete. On the seller side, the table usually needs sale proceeds, estate-agent commission, redemption of the existing mortgage, any early repayment charge, legal fees, VAT-bearing admin fees, and the net balance due to the client. That split is what turns buyer completion statement line items and seller completion statement extraction into something reviewable instead of a loose list of charges. If the same team also has to turn supplier-side matter costs into ledger-ready rows, a separate workflow for conveyancing disbursement invoice extraction and Excel posting fits naturally alongside completion statement capture.

A workable schema for UK property completion statement data normally needs these columns:

• line description
• side of transaction
• gross amount
• VAT amount or VAT flag
• tax type
• accounting category
• sign or direction of funds
• source page or reference

The sign or direction field matters because balancing figures are easy to misread when they are lifted out of context. A balance to complete is not the same kind of row as a balance due to client, even if both are visually prominent on the PDF. Keeping a source-reference column on each row also makes reconciliation faster, especially when a reviewer needs to confirm whether a fee was shown as a separate line or rolled into a broader total. If your team already needs to extract financial documents into Excel or CSV, this same row-based structure is what makes completion statements usable downstream rather than just searchable.

Tools such as Invoice Data Extraction are most useful here when they can return one row per line item, preserve the custom columns you care about, and attach source-file or page references for review. That is a better fit for completion statements than a summary-only capture, because the operational value is in the row structure, not in reproducing the solicitor's narrative layout.

Keep tax, VAT, and leasehold adjustments as explicit rows

The rows that usually break a completion-statement spreadsheet are the ones people try to flatten for convenience. Property tax is the clearest example. England and Northern Ireland use SDLT, Scotland uses LBTT, and Wales uses LTT. Those are not just regional labels for the same spreadsheet field. The extracted output should keep tax type explicit so the reviewer can see exactly which regime the row belongs to instead of inheriting a generic "stamp duty" category that loses useful context.

VAT needs the same discipline. Completion statements often combine charges that sit in very different VAT positions. Solicitor fees and some admin fees may carry VAT, while many taxes, Land Registry charges, and other disbursement-style property costs do not. Preserving VAT line by line is safer than assigning one document-level treatment after the fact, which is why the review logic in UK VAT invoice requirements for mixed-fee and VAT-coded lines is a useful reference point when fee descriptions are mixed.

Leasehold matters need their own extraction rules rather than a catch-all "other fees" bucket. Ground-rent apportionments, service-charge apportionments, LPE1-related fees, notice-of-transfer fees, notice-of-charge fees, and deed-of-covenant fees should usually stay as separate rows with clear descriptions and categories. That is the only reliable way to preserve the accounting meaning of each charge and to keep completion statement apportionment Excel work from turning into manual cleanup later. If you also deal with landlord and managing-agent paperwork, the logic behind commercial service charge reconciliation and apportionment schedules shows why these adjustments need explicit treatment rather than being merged into a total.

The buyer-versus-seller split still matters here. Leasehold adjustments and notice fees tend to appear on the buyer side, while redemption figures and related lender charges belong on the seller side. The aim is not to give legal or tax advice. It is to preserve enough row-level detail that the extracted table still reflects the real structure of the statement when someone reviews it before posting or reconciliation.

---

Prompt for one row per line item and tell the model what to flag

Once the schema is clear, the prompt should describe the output table, not just the document type. Tell the model to create one row per line item, preserve whether the row is buyer side or seller side, standardize dates and currency formatting, and capture tax type plus VAT treatment wherever those fields apply. That is what makes a conveyancing completion statement CSV usable after extraction instead of leaving the reviewer to interpret a loosely structured export. The same principle also helps when turning a dilapidations Scott Schedule into an Excel working file, where each repair item, quantified demand entry, and adjustment needs its own structured row.

The prompt should also name the output columns explicitly. For this document type, that usually means description, side of transaction, gross amount, VAT amount or VAT flag, tax type, accounting category, sign or direction of funds, and source reference. The next instruction should be just as explicit: if a row is ambiguous, flag it instead of guessing. That matters most for blended fee descriptions, leasehold adjustments, and redemption-related figures, where a confident but wrong categorisation creates more work than an exception queue.

You do not need the model to preserve every solicitor's wording exactly as written. You need it to map varying source phrases into a stable set of output labels. A fee described as "telegraphic transfer", "bank transfer fee", or "CHAPS fee" may need one standard category in the output, while still retaining the original description in a reference field if your review process needs it. The same principle applies across buyer-side, seller-side, and leasehold-heavy samples: standardize the output labels, then test the workflow on representative statements before you rely on it at scale.

That is also the practical value of a prompt-based tool such as Invoice Data Extraction for specialized financial documents. Users can upload PDFs or larger batches, describe the columns and handling rules they need, download Excel, CSV, or JSON output, and save reusable prompts for recurring work. The important limitation is just as important as the feature set: completion statements should be tested on representative samples from the firms and matter types you actually handle, not treated as a built-in conveyancing template that will always work without review.

Review balances, redemption figures, and import-ready rows before posting anything downstream

The first QA pass should focus on the controlling numbers. Check the balance to complete, the net balance due to client, and any total funds-in or funds-out figure that determines whether the extracted table still ties back to the original statement. If those rows are wrong, the rest of the spreadsheet may still look plausible while the overall posting is wrong.

Seller-side statements deserve extra attention around redemption amounts, early repayment charges, and estate-agent commission because those rows directly change net proceeds. Buyer-side statements usually need closer review of leasehold apportionments, notice fees, deed-of-covenant fees, and tax rows. In both cases, the safest rule is the same: do not import the data into bookkeeping or matter-accounting workflows until the row structure, signs, and totals reconcile to the PDF.

This is also where a source-reference column earns its keep. A reviewer should be able to jump from a spreadsheet row straight back to the originating file and page, confirm the wording, and decide whether the category is right. If you work in a legal-finance environment, the controls described in law firm accounts payable and matter-level expense workflows are a useful reminder that clean extraction is only part of the job. The downstream process still needs evidence, review, and posting discipline.

Invoice Data Extraction can help at this stage because extracted rows can carry source-file and page references that speed up manual checking before the data is used anywhere else. That is the real gain from a good completion-statement workflow: less rekeying, faster review, and a cleaner path into downstream systems, without pretending the QA step can be skipped.