UK Builders' Merchant Statement Reconciliation Guide

Builders' merchant statement reconciliation is the month-end check that a Travis Perkins, Jewson, Howdens, Selco, or similar supplier statement agrees to the invoices, credit notes, supplier ledger, and payment activity in Xero, QuickBooks, or Sage. The statement is a control document, not a substitute for the underlying invoices. Each line should either match a posted bill or credit note, explain a timing difference, or trigger follow-up before the supplier payment is treated as correct.

In practice, that means separating three checks that many teams blur together. First, compare the statement to the underlying invoices and credit notes so the document set is complete. Second, compare those documents to the supplier ledger so the accounting entries are right. Third, once the supplier balance is proven, match the bank payment that settles it. If those steps are collapsed into one month-end task, missing invoices, duplicated bills, and late credits are easy to miss.

That distinction matters in UK construction because builders' merchants run exactly the sort of busy trade accounts that create reconciliation noise. BMF's 2024 building materials sector research said the Builders Merchants Federation's membership stood at 1,000 merchant and supplier companies as of 1 September 2024, with combined sales of 50.2 billion pounds and more than 6,500 branches across the UK and Ireland. For a small building firm or construction bookkeeper, that scale shows up as dozens of monthly purchases, returns, and credits compressed into one month-end builders' merchant statement.

The practical goal is simple: prove the closing balance before the payment is matched. If the statement shows a 7,240-pound balance due, the bookkeeper should be able to point to the invoices and credits behind that number, show that the supplier account in the ledger agrees, and explain any gap between the statement date and the eventual payment date. That is a different job from ordinary bank reconciliation, and it starts with understanding what the statement is actually telling you.

What the monthly statement shows, and what still has to come from invoices

A UK builders' merchant statement normally gives you the account-level picture for the period: the account reference, opening balance, dated invoice lines, credit notes, payments received, and the carried-forward closing balance. On some statements you will also see branch references, transaction descriptions, or short narrative labels that help identify whether a line relates to timber, kitchens, civils, or another purchase stream. That makes the statement useful as a control document because it tells you what activity hit the account and what balance the merchant says is outstanding.

On a live statement, the first fields worth checking are usually the statement date, account reference, opening balance, each invoice or credit note number, payment lines, and the closing balance carried forward. Those are the checkpoints that let you answer practical questions quickly: has this line already been posted, is this an old balance still rolling forward, did a return become a credit note yet, and does the amount due reflect payments already made after cut-off?

The statement may show invoice numbers, dates, and gross values, but VAT evidence, line-level checking, and pricing disputes still depend on the original invoices and credit notes. If a Jewson or Travis Perkins statement lists an invoice you have never captured, you still need the underlying PDF or portal copy before you can be confident the bill in Xero, QuickBooks, or Sage is complete, correctly coded, and tied to the right job. For wider job-cost controls, the same discipline shows up in construction invoice coding for supplier bills.

This is where construction bookkeepers can get tripped up. A month-end statement is designed to help you agree the account balance, not to stand in for the whole purchase record. The difference between an open item vs balance forward statement matters because many builders' merchants carry older unpaid items into the current period rather than isolating only this month's activity. If the statement is balance-forward, the closing balance can be right even when the current-month transaction list is incomplete on its own.

---

Match the statement to invoices and credit notes before touching the payment

Start with the statement and work line by line against the underlying paperwork. Pull the monthly statement, gather every invoice and credit note for that merchant, and compare the statement lines to what is already posted as bills or credits in your bookkeeping system. At this stage you are not deciding whether the supplier balance is right in accounting terms. You are proving that the document set is complete.

In a real building firm, the document trail is rarely in one place. Some invoices may already have come through Hubdoc or another capture process. Others may be sitting in branch emails, a merchant portal, or a site manager's inbox. Credit notes for returns can appear days after the original materials were booked, which means the statement may show a legitimate credit that your ledger does not yet reflect. If a statement line has no matching source document, treat that as a missing-evidence issue first, not as a reason to force the ledger to the statement total.

The source path changes the work. If invoices are already captured in Hubdoc, Dext, or manual bill entry, use the statement as a completeness checklist against what is already posted. If the statement shows document numbers that never reached the ledger, the next step is usually portal or branch retrieval. If the ledger is thin and the statement is the only complete list you have at cut-off, statement-table extraction can help build the chase list before the missing PDFs are backfilled and reviewed.

This is also the point where duplicate capture shows up. A merchant invoice might have been posted from an emailed PDF and then posted again when the statement prompted a second round of chasing. The opposite problem is just as common: the statement shows an invoice number, but the only record in the ledger is a manually keyed total with no source file behind it. If the reconciliation depends on invoice detail, quantities, or branch-specific purchases, it often helps to extract line items from UK builders' merchant invoices before you start clearing differences by hand.

By the end of this step, every line on the statement should sit in one of three buckets: matched to a captured invoice or credit note, missing and still to be pulled, or duplicated and needing correction. Only then does it make sense to ask whether the supplier ledger in Xero, QuickBooks, or Sage agrees to the statement balance.

Agree the supplier ledger in Xero, QuickBooks, or Sage

Once the invoices and credit notes are complete, compare the statement closing balance with the supplier account in Xero, QuickBooks, or Sage. This is the stage where the Jewson, Travis Perkins, or Howdens balance in Xero, QuickBooks, or Sage should start to reconcile cleanly because the document gaps have already been dealt with. If the ledger still differs from the statement, the problem is now in the accounting entries or the timing of those entries, not in missing paperwork.

Typical causes of a remaining difference are straightforward once the document set is complete. An invoice may have been posted twice, coded to the wrong supplier account, or left as a draft instead of a live bill. A payment may have been entered against the wrong merchant account. A credit note may exist in the portal but not yet be applied in the ledger. A partial settlement may also mean the statement balance is correct on the statement date while the ledger reflects a later payment position.

The logic is the same as any broader vendor statement reconciliation process, but the construction context adds more noise because one merchant account can carry many small site purchases across the month. That is why the accounting question here is specific: does the supplier account show the same balance, for the same reason, as the merchant statement? If not, the difference needs an explanation tied to a real invoice, credit, or payment.

Only after the supplier account is proven should you match the bank transaction. Supplier-statement reconciliation proves the liability. Bank reconciliation proves that the cash movement was recorded and cleared correctly. Property firms handling protected client money face a similar separation in letting-agent rent and landlord statement reconciliation, where receipts, deductions, and landlord balances need to be proven before the bank match is treated as complete. Those are connected tasks, but they are not the same task, and mixing them together is how unresolved supplier-account errors get hidden inside a "paid" status.

The exception patterns that trip up builders' merchant accounts

Builders' merchant accounts generate false differences because several people may buy against the same trade account, across different branches and jobs, while returns and shortages are resolved later. Adjacent supplier types behave differently again: a plant-hire account, for example, needs its own verification routine for on-hire and off-hire dates under CPA Model Conditions before its invoices can be reconciled cleanly at month end.

The common patterns are easy to name once the paperwork is grouped. A Travis Perkins return may be agreed with the branch but credited on the next statement. A Howdens order may include replacements or pricing adjustments that do not clear in one cycle. A Selco statement-of-account review may show card purchases by a site manager that never belonged on the credit account. Multi-site buying can also make the statement right at account level while individual jobs look wrong because invoices were posted to the wrong project, branch references were ignored, or a disputed line is still unresolved. Identify the difference type first: missing document, ledger error, or payment-timing issue.

---

When structured extraction saves time at month end

Manual reconciliation usually breaks down when the statement is not the only problem. The real drag on month end is the combination of a long statement table, scattered invoice PDFs, late credit notes, and several people buying against the same account. At that point, the value is not in replacing the reconciliation judgment. It is in turning the evidence into something that can be filtered, matched, and reviewed quickly.

If missing PDFs and fragmented merchant data are slowing down close, construction invoice processing automation is useful when it helps rebuild the supplier evidence pack rather than just reading one page at a time. The practical aim is to turn statement lines, invoice headers, or invoice line items into rows you can sort by invoice number, date, credit value, branch reference, or total before you decide what needs posting or correcting.

Invoice Data Extraction is built for that sort of work. The product converts invoices and financial documents into structured XLSX, CSV, or JSON output, supports vendor statements as well as invoices, and can produce one row per invoice or one row per line item depending on the prompt. Each output row also includes a reference to the source file and page number, which is useful when a bookkeeper needs to trace a statement difference back to the original document. That still does not turn the monthly statement into a booking document or remove the need to review credits, disputes, and timing differences; it simply shortens the evidence-gathering step when the ledger is missing something.