Skip to main content
Quanta Meridian logo
Reporting Foundations

Purchase Order, Receipt and Invoice Reconciliation

A three-way reconciliation checks whether the purchase order, warehouse receipt and supplier invoice agree before an invoice is cleared for payment.

Executed invoice reconciliationOpen image

Executed DuckDB evidence generated from the retained BPI event log. It is not a screenshot of an Accounts Payable platform.

Before an invoice is paid

Three records must tell the same story.

A buyer confirms what was ordered. The warehouse records what arrived. Accounts Payable records what the supplier billed. This build compares those events for every purchase order item, clears supported cases and holds the rest for the team that can resolve them.

251,734 purchase items=217,055 supported+34,679 held

The equation comes from the complete BPI Challenge 2019 build. Each item has one final class. Consignment items are kept outside the invoice decision rather than forced through a rule that does not apply.

Invoices that still need a decision

The difference stays beside the team that can investigate it.

The queue below is exported from DuckDB. It shows one retained item from several unresolved classes, including a missing invoice, a missing receipt, a reversal and a recorded value difference.

Purchase itemReasonPurchase valueReceipt valueInvoice valueAge at source closeResponsible teamDecision
4507000280_00010Purchase item was cancelled or deleted39700702 daysBuyerpayment hold
4507000473_00001Invoice is missing9276,6750702 daysAccounts Payablepayment hold
4507075965_00020A receipt or invoice was cancelled2650265686 daysFinance reviewerpayment hold
4507000855_00080Recorded values differ8817788672 daysBuyerpayment hold
4507004049_00030Warehouse receipt is missing92092658 daysWarehouse receivingpayment hold

Values are the publisher's translated monetary fields. They preserve comparisons but do not represent disclosed currency amounts.

How the decision is made

The purchase, receipt and invoice meet before payment.

The source states whether a goods receipt is required. Two-way items compare the purchase and invoice. Three-way items also require a warehouse receipt. Ordered rules then deal with timing, repeated events, reversals and missing records.

Purchase order, goods receipt and supplier invoice matchingA purchase order, warehouse goods receipt and supplier invoice converge on ordered matching rules. Supported items continue to payment. Missing, cancelled or different records branch to the responsible team with their event history retained.BUYERPURCHASE ORDER ITEMWAREHOUSEGOODS RECEIPTACCOUNTS PAYABLESUPPLIER INVOICEDOCUMENT DECISIONREQUIRED RECORDS PRESENT?VALUES WITHIN RULE?REVERSAL OR TIMING NOTE?251,734 ITEMS CLASSIFIED ONCESUPPORTEDContinue or clear with retained historyPAYMENT HOLDBuyer, warehouse, AP or finance review
  1. 01
    The buyer raises a purchase item

    The purchase document, supplier and required receipt rule remain attached.

  2. 02
    The warehouse records what arrived

    Receipt, cancellation and repeated receipt events stay in source order.

  3. 03
    Accounts Payable records the invoice

    The build checks whether the required records and translated values agree.

  4. 04
    The item is cleared or held

    A held item keeps its reason, responsible team, age and complete event history.

What the source actually contains

Exact, grouped, timing and exception paths are all retained.

The full event log naturally exercises twelve of the fourteen configured classes. Small-value tolerance and partial-open behaviour are tested with explicit SQL fixtures because the public source does not populate those two paths.

  1. 01
    Warehouse receipt is missing

    A three-way item stays on hold until warehouse receiving records what arrived or corrects the purchase record.

    Purchase items
    296
    Payment state
    payment hold
    Next team
    Warehouse receiving
  2. 02
    A receipt or invoice was cancelled

    A finance reviewer checks the reversal history before the item can be cleared.

    Purchase items
    6,659
    Payment state
    payment hold
    Next team
    Finance reviewer
  3. 03
    Invoice arrived before receipt

    The invoice waited until the warehouse receipt was recorded, then Accounts Payable cleared it with the timing history retained.

    Purchase items
    109,197
    Payment state
    cleared with timing note
    Next team
    Accounts Payable
  4. 04
    Several receipt events

    More than one goods receipt belongs to the purchase item. The events are reviewed together before the invoice is cleared.

    Purchase items
    1,076
    Payment state
    cleared after grouped review
    Next team
    Warehouse receiving
  5. 05
    Purchase, receipt and invoice agree

    The required documents are present and their recorded translated values agree.

    Purchase items
    89,301
    Payment state
    cleared by rule
    Next team
    Accounts Payable
  6. 06
    Recorded values differ

    The buyer reviews the purchase record and supplier bill because the translated values do not agree within the configured rule.

    Purchase items
    1,556
    Payment state
    payment hold
    Next team
    Buyer

One purchase item traced

This invoice waited for the warehouse receipt.

Purchase item 4507000232_00010 carried the same translated value of 564 on the purchase, receipt and invoice events. The invoice was recorded first, so payment stayed blocked until the warehouse event arrived.

Purchase item4507000232 / 00010

2 Jan 2018

Invoice recordedvendor_0112

3 Jan 2018

Goods receivedWarehouse receiving

4 Jan 2018

  1. 01Create Purchase Order Item

    Buyer · 2 Jan 2018

  2. 02Vendor creates invoice

    Accounts Payable · 2 Jan 2018

  3. 03Record Invoice Receipt

    Accounts Payable · 3 Jan 2018

  4. 04Record Goods Receipt

    Warehouse receiving · 4 Jan 2018

  5. 05Remove Payment Block

    Accounts Payable · 4 Jan 2018

  6. 06Clear Invoice

    Accounts Payable · 25 Jan 2018

Accounts Payable removed the block after receipt and cleared the invoice on 25 Jan 2018. The retained decision is “clear with timing note”.

Checks before publication

Twenty-one checks passed on the complete build.

SQL checks the publisher counts, unique keys, classification, responsible teams, summary tie-outs, record trace and rule edge cases. A second verifier reads the exported files without querying DuckDB.

VAL-01

Complete purchase-item source retained

PASS
VAL-02

Complete event source retained

PASS
VAL-10

No purchase item is classified twice

PASS
VAL-12

Every unresolved item has a responsible team

PASS
VAL-14

Summary item counts tie to detail

PASS
VAL-19

Out-of-window timestamps are retained as exceptions

PASS

Data and limits

The complete BPI Challenge event log, matching rules and SQL rebuild together.

The project processes all 1,595,923 events for 251,734 purchase order items in BPI Challenge 2019.

Technical documentationOpen the retained data, rebuild command and detailed limitations

The build retains the publisher DOI, licence, checksum and 320 timestamps outside the main 2018–2019 process window as visible data exceptions.

npm run verify:reconciliation

The command verifies the 728 MB XES file, streams every trace, rebuilds the DuckDB model, exports the decisions and checks those files independently.

Published by 4TU.Centre for Research Data under CC BY 4.0. The historical, anonymised log does not expose physical ordered, received or invoiced quantities. This is not an Accounts Payable product or audit opinion.

Inspect or continueBPI Challenge 2019 sourceReporting SystemsAnalytics EngineeringReporting Foundations

Next step

Review the controls beneath a supplier payment queue.

Start with the files, joins and checks that make the current reporting route difficult to trust or maintain.

Discuss a reconciliation review