Once a month, many suppliers send their customers a statement of account. It lists the invoices the supplier believes are still open, the credits it has issued, the payments it has received and applied, and a balance at the bottom. Accounts payable holds its own version of the same account: the vendor’s open items in the subledger, with their own balance. The two balances almost never agree on the first read, and the difference is rarely one thing.
Vendor statement reconciliation is the work of explaining that difference line by line. It is not glamorous and it is often done by eye: the statement arrives as a PDF, someone prints the vendor’s open items from the ERP, and the two lists are ticked against each other with a pen. The point of the exercise is not the balance. It is the handful of lines that appear on one side only, because each of them is a missing invoice, an unapplied payment, a credit nobody posted, a fee nobody agreed to, or an invoice that is about to be paid twice.
This piece describes what a statement says, how to match it against the payables ledger, which kinds of unmatched line come up and what each one asks for, and what an extraction has to deliver so the matching can run as data rather than as a pen exercise. It works at the level of the vendor account. Checking a single invoice against its order and goods receipt is covered in our article on three-way matching, and tying a credit note to the invoice it reduces is covered in the credit memo article. A statement is where the results of both show up, or fail to.
A statement of account is not a summary invoice
The OASIS Universal Business Language 2.1 standard defines the Statement as a document “used to report the status of orders, billing, and payment,” and adds a sentence that matters for anyone automating it: “This document is a statement of account, not a summary invoice.” A statement asks for nothing new. Every amount on it should already exist as an invoice, a credit note or a payment. If a line on a statement has no underlying document, that is a finding in itself.
The UBL data model also shows what a statement is made of, which is a useful checklist even when the statement arrives as a scanned PDF rather than XML. At the document level there is a statement period, a total debit amount, a total credit amount, a total balance amount and a count of lines. Each statement line can carry a debit amount, a credit amount, a running balance, a reference to the billing document it concerns, payment terms, collected payments, and a flag saying whether the line is a balance brought forward from a previous statement.
That last flag points to the first decision a reconciliation has to make. Statements come in two broad shapes, and they are reconciled differently:
- Open-item statements — list only the documents still open at the statement date, each with its remaining amount. They are compared directly with the vendor’s open items in the subledger.
- Balance-forward statements — start from the previous closing balance and list the period’s invoices, credits and payments. The opening balance has to agree with last month’s closing balance before the period activity is worth comparing.
- Mixed statements — an open-item list followed by recent activity, or an aging summary on top of either. The aging buckets are printed totals and should be checked against the lines before anything else uses them.
Match on the reference, compare on the amount
The join between a statement and a ledger is the supplier’s document number. The statement prints the invoice and credit note numbers the supplier issued. The payables ledger usually stores the same numbers as the supplier reference on each posted document, next to an internal document number the supplier has never seen. Matching on anything else, such as amount and date alone, will pair two invoices for the same recurring amount and miss a split payment.
Supplier references are not always typed the same way on both sides. One side carries a prefix and the other does not, leading zeros are dropped, a letter O is keyed instead of a zero. Normalising references before matching is necessary, and every normalisation should be recorded, because a reference that only matches after aggressive cleaning is weaker evidence than one that matched as printed. A reasonable order of keys:
- Exact supplier reference and amount — the strongest match; close it.
- Normalised reference and amount — close it, and keep the normalisation that was applied.
- Reference matches, amount differs — a matched pair with a difference to explain, not two unmatched lines.
- Amount and date match, no reference — a candidate for review, never an automatic close.
Account identity matters as much as document identity. UBL carries the customer-assigned account identifier for the supplier party, which is the vendor number in the buyer’s system. A supplier that sells to several of a group’s entities, or that invoices from more than one legal entity of its own, may send statements that mix accounts. Lines from a different bill-to entity are not differences; they belong to another reconciliation.
Every unmatched line has a short list of causes
After matching, what remains is two short lists: lines on the statement with no partner in the ledger, and open items in the ledger with no partner on the statement. Each kind of unmatched line has a small set of usual causes and a different owner. The table below is a starting set for routing, not an accounting policy.
| Unmatched line | Usual cause | Evidence to look for | Action |
|---|---|---|---|
| Invoice on the statement, not in the ledger | Invoice never received, or received and not yet posted | No document with that reference in the inbox, the scan queue or the hold list | Request a copy; post it through the normal approval path, never from the statement |
| Invoice open on the statement, paid in the ledger | Payment in transit, or applied by the supplier to another invoice | Payment date close to the statement date; remittance advice naming the invoice | Send the remittance details; follow up if still open next month |
| Small residual open on the statement | Deduction taken on payment and not accepted by the supplier | A debit memo or short payment in the ledger for the same invoice | Route to whoever owns the dispute, with the debit memo attached |
| Credit on the statement, not in the ledger | Credit note issued and not received or not posted | Credit note number on the statement with no matching document | Request the credit note and post it; do not net it from the statement alone |
| Fee or interest line on the statement | Late payment charge, freight or service fee raised by the supplier | Contract or terms that allow the charge; dates of the late payments | Check the terms before accepting; route disputed fees to the vendor owner |
| Invoice open in the ledger, absent from the statement | Cut-off: invoice dated at or after the statement date | Invoice date against the statement date | Close as timing; expect it on the next statement |
| Two ledger items, one statement line | Same invoice posted twice | Same supplier reference and amount on two internal documents | Block payment of the second item before the next run |
| Ledger item the supplier shows as never issued | Posted to the wrong vendor, or a document from another supplier | Supplier name and tax identifier on the original document | Move it to the right vendor account after review |
Two rows deserve attention before the rest. The duplicate posting is the most valuable finding a statement reconciliation produces, because the supplier’s own record is independent evidence that the invoice exists once. And the invoice on the statement that is not in the ledger must not be posted from the statement. The statement is not the invoice; posting from it skips the approval and the match the real invoice would have gone through.
A worked example
An industrial supplies vendor sends a balance of $27,195.00 as of September 30. The buyer’s subledger shows $17,600.00 open for the same vendor on the same date. The values below are invented for illustration.
| Reference | Statement | Ledger | Result |
|---|---|---|---|
| Invoice 70412, Aug 18 | $6,200.00 | $6,200.00 | Matched |
| Invoice 70455, Aug 29 | $9,850.00 open | Paid by transfer on Sep 28 | Payment in transit; send remittance details |
| Invoice 70488, Sep 9 | $4,320.00 | $4,320.00 on two internal documents | Duplicate posting; block the second item |
| Invoice 70501, Sep 15 | $7,480.00 | Not found | Not received; request a copy |
| Invoice 70388, Aug 4 | $400.00 residual | Closed: $5,000.00 paid plus $400.00 debit memo | Deduction not accepted; route the dispute |
| Late payment fee | $185.00 | Not found | Check the terms before accepting |
| Credit note CM-2207 | −$1,240.00 | Not found | Request and post the credit note |
| Invoice 70540, Sep 30 | Not listed | $2,760.00 | Cut-off; expect it next month |
| Balance | $27,195.00 | $17,600.00 | $9,595.00, fully explained by the rows above |
The arithmetic closes: the statement-only lines add up to $16,675.00, the ledger-only lines to $7,080.00, and the difference between them is the $9,595.00 gap between the balances. The balances, compared on their own, would have suggested the buyer owes almost ten thousand dollars more than it has recorded. Compared line by line, the account holds seven separate findings with four different owners.
The example also shows why the balance is the wrong thing to chase. The duplicate posting of invoice 70488 makes the ledger balance larger, the missing invoice 70501 makes it smaller, and they partly cancel. A reconciliation that stops when the balances are close enough would have missed both, and the duplicate would have been paid on the next run.
Timing differences are not errors
A statement is the supplier’s ledger at one moment, and the payables ledger is the buyer’s at another. Some differences are only the two clocks: payments sent but not yet applied, invoices issued but not yet received, credits raised on the last day of the month. They still need to be identified, because a timing difference that does not clear on the next statement is no longer timing.
Dates are where timing becomes rules. The US federal Prompt Payment regulation, which governs how federal agencies pay their vendors, is a clear example of how much the date of receipt matters. Under 5 CFR 1315.4(b), the payment due date and the start of interest on a late payment are computed from the date a proper invoice is deemed received: normally the date the agency office actually receives it, and the date printed on the invoice only when the agency failed to record receipt. Under 1315.4(c)(2), an invoice found to be improper is returned to the vendor within seven days with every defect identified. Most private buyers are not bound by that regulation, but its logic is the one a reconciliation needs: an invoice the supplier lists as open may never have been received, or may have been returned as improper, and the record of that has to be findable.
For that reason, a reconciliation should keep three dates for every invoice it can: the date on the invoice, the date it was received and the date it was posted. A statement line older than the oldest received invoice in the ledger is a strong sign of an invoice that went to the wrong mailbox. A fee line dated soon after a late payment is worth checking against the payment terms before anyone argues about it.
What the extraction should deliver
For each statement, a useful extraction returns the statement as a table with its own header and its own printed totals, not as a balance:
- Header fields — supplier name and tax identifier, the account number the supplier uses for the buyer, the bill-to entity, statement date, statement period, currency and page count.
- Statement type — open-item or balance-forward, and for balance-forward statements the opening balance as printed.
- Every line as a row — document date, document type, supplier reference, any customer reference such as a purchase order number, debit or credit amount, remaining open amount, due date and running balance where printed.
- Printed totals as their own fields — total debits, total credits, closing balance and aging buckets, so the extraction can be checked against its own arithmetic before it is compared with the ledger.
- Page and position evidence — for every line and total, where on which page it was read, so the reviewer of an unmatched line sees the original in one step.
The ledger side is an export of the vendor’s open items, with supplier reference, internal document number, amount, invoice, receipt and posting dates, and any payment block. The reconciliation then runs as its own step: normalise references, match by key in order of strength, check the statement’s arithmetic, classify what is left, and turn each unmatched line into an exception that names both sides, the key that failed and the evidence page. Nothing in that step posts an invoice or accepts a fee. Those stay with the people who own them.
The invoice extraction page describes how Cogneris recognises a statement as a document variant distinct from an invoice and splits bundled statements into the invoices they contain. Nothing here describes a product feature for statement reconciliation; the argument of this article is about the fields a statement has to become before any reconciliation can run.
Where this sits next to matching and credits
Statement reconciliation sits at the end of the payables cycle and inherits everything before it. An invoice that failed its three-way match and was put on hold shows up on the statement as open and overdue. A credit memo that was received but not tied to the invoice it reduces, the problem described in the credit memo article, shows up as a credit on both sides that never nets. And an invoice matched against an outdated purchase order, the case in the change order article, can leave a short payment that reappears as a residual.
Structured invoicing does not remove the statement either. As the e-invoicing exceptions article notes, the invoice is rarely the only document in the decision, and a vendor statement is one of the documents that stays outside the network format for most suppliers. The reconciliation described here works the same whether the invoices arrived as PDFs or as XML; only the statement itself usually remains a PDF.
Reconcile the open items, not the balance
A vendor statement is the supplier’s view of what the buyer owes, built from the same documents the buyer should hold. Matching it against the payables ledger by supplier reference, in order of evidence strength, turns a single balance difference into a short list of unmatched lines, each with a usual cause and an owner: a missing invoice, an unapplied payment, a disputed deduction, an unposted credit, an unagreed fee, a cut-off or a duplicate. The extraction’s job is to make that possible: every statement line, every printed total and every date as data, with the page it came from.