Construction procurement
Three-way matching in construction procurement: order, receipt, bill
Three-way matching is the discipline of paying only for what was ordered, at the price that was agreed, once it has actually arrived. On a construction site, where materials are delivered in parts and bills arrive late, it is the control that keeps a supplier bill from becoming a project cost nobody authorised.
Last revised
What three-way matching is
Three documents describe one purchase from three points of view. The purchase order says what was ordered, in what quantity, at what price. The receipt — a goods receipt note for materials, a service receipt for work — says what actually arrived or was performed. The vendor bill says what the supplier wants to be paid. Three-way matching is the rule that a bill is accepted only where all three agree: the quantity billed was received, the quantity received was ordered, and the price billed is the price on the order.
On a construction project the three rarely arrive together. Steel comes in four deliveries against one order; the supplier bills the first two together; a site engineer confirms the third a week after it landed. Without a systematic match, the bill is approved on its own face, and a project pays for a delivery that never came, or twice for one that did.
The chain, as BuilderOne enforces it
In BuilderOne’s Procurement module the match is not a check run on a finished bill; it is built into what each document is allowed to reference. Each link can only be created against an approved predecessor, and it copies its facts from that predecessor rather than accepting them from the person typing.
| Document | Created only against | What it copies | The hard rule |
|---|---|---|---|
| Purchase request | A project and cost category | — | The request states the need; it commits nothing. |
| RFQ and supplier quotations | An approved request | The requested lines | One quotation is selected and awarded. |
| Purchase order | The awarded quotation | Item, quantity, unit price and provenance from the quotation | At most one live order per awarded quotation; totals are derived, never typed. |
| Goods / service receipt | An issued purchase order | The supplier, from the order | Cumulative received quantity per order line can never exceed the ordered quantity. No tolerance. |
| Vendor bill | An approved receipt | Supplier and order from the receipt; unit price from the order line | Cumulative billed quantity per receipt line can never exceed the received quantity. Price is never user-supplied. |
Read the last two rows together and the three-way match falls out of the structure. A bill line must name a receipt line; that receipt line must name an order line; the price is the order’s; the quantity cannot exceed what was received, which cannot exceed what was ordered. There is no separate “matching step” to skip, because a bill that does not match cannot be constructed.
Quantity, price and receipt — the three tests
- Quantity. A receipt may be partial — three deliveries against one order line are three receipts — but the running total can never pass the ordered quantity. A bill may cover part of a receipt, but its running total can never pass the received quantity. Both limits are strict: there is no percentage tolerance, because a tolerance is a quantity nobody approved.
- Price. The vendor bill does not carry a price of its own. Its unit price is copied from the awarded purchase-order line, so a supplier who bills at a higher rate has to be dealt with as a commercial matter — a revised order or a credit — not absorbed silently into an approved bill.
- Receipt. Nothing can be billed that has not been received and approved as received. A service receipt does the same job for work as a goods receipt does for materials, so a consultant’s bill is matched to a confirmed service receipt exactly as a steel bill is matched to a delivery.
What happens to an exception
A system with no tolerance needs a clear answer for the cases that do not fit. In BuilderOne the answer is that the exception is resolved on the document that owns it, never on the bill:
| Exception | What the system does | Where it is resolved |
|---|---|---|
| Supplier delivers more than ordered | The receipt cannot record the excess against that order line. | A further order (or an amended quotation and order) for the excess, then a receipt against it. |
| Supplier bills at a different price | The bill cannot carry it; the line prices from the order. | Commercially, with the supplier — a revised order or a credit note outside the bill. |
| Bill arrives before the goods | No approved receipt exists to bill against, so the bill cannot be created. | Receive and approve first; the bill follows. |
| Partial delivery | A partial receipt; the order line stays open for the remainder. | Further receipts until the ordered quantity is reached, or the order is closed. |
| Wrong project on the request | Project and cost category flow from the request through every document. | Correct at the request or order stage before receipt, not by re-keying the bill. |
Project attribution and the ledger
Because the supplier, project and cost category are the same records the Construction module uses, a matched vendor bill lands on the project it was bought for without anyone re-typing it — and appears in that project’s cost position beside the contractor bills. Approving the bill in Procurement records that the business accepts it; it writes no ledger entry itself.
The general ledger then takes over through two governed posting adapters: the vendor bill accrual (the cost, attributed to the project, against a payable) and the vendor payment (the payable settled from a cash or bank account). Payment readiness is therefore a property of the chain: a bill is ready to pay when it is matched, approved and accrued — and not before.
Questions to ask of any procurement system
- Can a vendor bill be created with no receipt behind it? It should not be possible.
- Where does the bill’s unit price come from — the order, or the keyboard?
- Can received quantity exceed ordered quantity, or billed exceed received? By how much, and who approved the tolerance?
- Does the project attribution travel from the request to the bill, or is it re-entered at each step?
- Is “approved in procurement” the same as “posted to the ledger”? It should be two separate, traceable events.
Where this lives in BuilderOne
See it on your own numbers
The fastest way to judge whether this is how your software should work is to put a real project through it. Tell us what you run and we will set your company up.