UK Builders' Merchant Statement Reconciliation Guide

Builders merchant statement reconciliation is the month-end process of proving that a supplier statement from Travis Perkins, Jewson, Howdens, Selco, or a similar trade merchant agrees to the invoices, credit notes, and payment activity already posted in Xero, QuickBooks, or Sage. The statement is a control document, not a substitute for the underlying invoices. Each line on the statement 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?

What it does not do is replace the original invoices and credit notes. The statement may show invoice numbers, dates, and gross values, but it is not the document you rely on for line-level checking, VAT evidence, or correcting a pricing dispute. If you also need to evidence eligible self-build purchases for HMRC, keeping a VAT431NB invoice schedule as you go helps separate reclaim-ready invoice records from the month-end supplier statement. 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 and correctly coded.

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.

The safest way to read the statement is as an index of what needs to exist elsewhere in your records. It tells you which invoices, credits, and payments should be present, whether old items are still being carried, and whether the closing balance looks plausible. It does not remove the need to verify the individual documents behind the balance.

---

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 a Jewson monthly statement to Xero, a Travis Perkins account to QuickBooks, or a Howdens balance to 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. 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 more false differences than many other supplier accounts because the buying pattern is messy by design. A building firm may have several people purchasing against the same trade account, across different branches, for different jobs, with returns and shortages being resolved later. That creates a constant lag between what happened on site and what is visible in the month-end statement.

A Travis Perkins statement reconciliation often gets stuck on returns that were agreed with the branch but credited later, so the original invoice is already in the ledger while the credit note lands on the next statement. A Howdens monthly statement reconciliation can be complicated by kitchen orders, replacements, and pricing adjustments that do not all clear in one cycle. A Selco statement of account reconcile exercise may show mixed cash and credit activity, where card purchases by a site manager never belonged on the credit statement in the first place. Those are not edge cases. They are normal trade-account behaviour.

Multi-site and multi-branch buying adds another layer. The statement may be 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 sitting unresolved. Short deliveries and agreed price corrections can produce the same effect. The apparent mismatch is real, but it does not always mean the closing balance itself is wrong. Sometimes it means one part of the three-check process is still incomplete.

The fastest way to work these cases is to identify which type of difference you are looking at. If the problem is a missing or late document, go back to the completeness check. If the documents exist but the supplier ledger is wrong, fix the bookkeeping entry. If both are right and the payment still differs, you are now dealing with a timing or settlement issue. That diagnosis is far more useful than a generic instruction to "investigate discrepancies."

---

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.

That is where structured document workflows earn their place. 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.

Used well, that does not turn the monthly statement into a booking document and it does not remove the need to review credits, disputes, or timing differences. What it does is shorten the slowest part of the workflow: rebuilding a complete, reviewable supplier record when the month-end statement tells you the ledger is missing something.