Receive goods and three-way match

The shipment that was 20% lighter than the invoice

A manufacturing client ordered 500 components from a long-standing supplier. The PO went out at the agreed price. Two weeks later a pallet arrived, the warehouse signed for it, and the invoice landed in AP for the full PO amount. The bookkeeper coded it, the payment run picked it up, and £18,400 went out on the next BACS cycle.

Three months later, during a stock count, the operations manager realised the pallet had only ever held 400 units. The supplier had short-shipped by 20% — and invoiced for the full order. Nobody had checked. The signed delivery note said "1 pallet received", which was technically true; what it didn't say was how many units that pallet contained.

The supplier credited the difference once it was raised, but the cash had been gone for a quarter. Nothing in the books would have flagged it. The bill matched the PO; the PO had been approved; the bank statement matched the payment. From the audit trail's point of view, everything was perfect. The system never asked the only question that mattered: did we actually get the thing we paid for?

A Goods Received Note is the answer to that question. The GRN is the entry in the AP record that says "this much, of this PO line, arrived on this date". It's the second leg of the three-way match — and the only stage in the cycle where someone with eyes on the goods (or the inbox, or the contract) signs off that the thing was delivered.

What a GRN is

A GRN is a per-line receipt against a Purchase Order. It records, for each line item on the PO:

• How many units the supplier ordered (from the PO)
• How many units actually arrived (from the receiver)
• The date the goods landed
• Who received them
• Optional condition notes (damaged box, serial numbers, batch IDs)

It produces a PDF — the formal Goods Received Note — that you can hand to a supplier driver, file alongside the warranty paperwork, or attach to an insurance claim. More importantly, it produces structured data the three-way matcher uses to decide whether the supplier's bill should be paid.

Without a GRN, there's no record that what arrived matched what was ordered. The bill is unanchored. With a GRN, every paid invoice traces back to a confirmed receipt — and any discrepancy between order, receipt, and bill surfaces before the money leaves.

Per-line, not per-PO

This is the bit teams new to GRNs tend to get wrong: a GRN is per line, not per PO. If a PO has three lines and the supplier ships line 1 today, line 2 next week, and line 3 the week after, you raise three GRNs — one per delivery. Each GRN can cover one line, two lines, or all three; whatever actually arrived in that consignment.

The PO line carries an outstanding column: quantity_ordered − sum(quantity_received_to_date). When you open the Receive modal, that's what defaults into the input. You can accept it, reduce it (the supplier only shipped some), or set it to zero (this delivery didn't include this line at all).

The PO status flips automatically:

• All lines fully received → PO status = received
• Some lines received, others outstanding → PO status = partial
• Nothing received yet → PO status = sent (unchanged)

For service POs — a six-month consulting engagement, an annual software licence — the same model applies. You raise GRNs on the dates the service was rendered, even if no physical box arrived. Monthly retainers typically get one GRN per month for the value of that month's service.

How to raise a GRN

1. Open the PO from Purchase Orders (must be status sent or partial).
2. Click Receive goods in the action bar. The modal lists every PO line with three columns: ordered, received-to-date, outstanding.
3. For each line, enter the quantity received for this delivery. Defaults to the outstanding amount. Reduce it if the supplier shipped less; leave at 0 if this line wasn't in this delivery.
4. Optionally add condition notes per line — "2 boxes dented, accepted with discount", "serial numbers logged on shelf 4", "delivered direct to client site". These print on the GRN PDF and stay on the audit trail.
5. Optionally adjust the received date. Defaults to today; set it to the actual delivery date if you're logging after the fact.
6. Save. The system inserts a grn header + grn_lines rows, increments each PO line's quantity_received, recomputes PO status, and runs the matcher against any bills already on file.
7. Click PDF on the GRN row in the Goods received card to download the formal document.

The three-way match

The matcher runs on three documents and applies three rules. All three must hold for the bill to auto-clear.

Rule 1: PR.amount ≤ PO.amount. What you committed to externally can't exceed what was internally approved. If the PO was raised at a higher value than the approved PR, the matcher flags it — usually means a price change was negotiated after approval and wasn't routed back through the policy.

Rule 2: PO.lines ≥ GRN.received_qty. You can't receive more than was ordered. Over-supply is blocked at GRN save (you can't enter a quantity above outstanding) — but if the supplier ships extra and you accept it, you have to raise a PO amendment first, not just record the larger quantity.

Rule 3: Bill.amount ≤ PO.amount × (GRN.received_qty / PO.qty). The bill can claim no more than the pro-rata value of what was actually received. If you've received 80% of the PO, the supplier can only bill 80% of the PO value before the matcher complains.

When all three hold, the bill flips to approved and joins the normal payment flow. When one breaks, the bill lands in manual_review with a match_warning flag and a list of which rule failed and by how much.

What the engine flags

Over-supply. Supplier shipped more than ordered. Caught at GRN save, not at the bill. You either reject the excess, raise a PO amendment to absorb it, or split the surplus into a separate PO. Don't just receive the larger quantity and hope — that breaks the audit chain.

Over-billed. Supplier invoiced for more than the pro-rata GRN supports. Could be a price escalation they didn't communicate, could be a unit conversion error (they billed in dozens when the PO was in singles), could be a duplicate line. The bill stays in manual review until you either accept it (with a justification on the audit log) or push back to the supplier for a credit note.

PO closed too early. The bill arrives after PO.status = 'closed'. The match fails because there's no open PO to reference. Finance can reopen the PO temporarily, accept the late bill, and re-close — or, if the bill is genuinely for a different procurement, raise a new PO retrospectively to anchor it.

Bill without PO. The supplier invoiced something you never raised a PO for. Catches expense-style spend that should have gone through the PR/PO gate. The bill can still be paid, but the operator has to override the match with a flagged justification, and the spend shows up on the "unauthorised" report.

What it doesn't catch

The matcher only checks quantity and value alignment. It can't tell you whether what was delivered was the right thing — only that the right number of something arrived. The receiver is the source of truth for quality and identity:

• Wrong goods. Correct quantity, wrong item. Matcher passes; reality is broken. The receiver has to spot this and either reject the delivery or raise a discrepancy note before signing off the GRN.
• Defective goods. Box arrives, units inside are damaged or non-functional. Matcher passes (you got 100 units); the units are useless. Condition notes on the GRN are the place to record this, and you typically raise a credit note request separately.
• Late delivery. The matcher has no SLA awareness — no concept of "should have arrived by X". If on-time delivery matters, that lives in the supplier scorecard, not the AP cycle.
• Wrong supplier. Goods arrive from a supplier you didn't order from (cross-shipment, drop-ship error). Don't receive it. Refuse the delivery and let the courier sort the misroute.

The audit trail

Each GRN writes a fixed bundle of evidence:

• GRN.received_at — the date goods landed (operator-set, not system-set).
• GRN.receiver_user_id — who clicked Save.
• grn_lines[] — one row per PO line, with ordered + received quantities and optional condition notes.
• GRN.pdf_url — the formal PDF, regenerated on demand from current data.

The PO updates as a side effect: each line's quantity_received increments; status recomputes; received_at lands on the PO header when the last line completes.

When a bill later matches against this PO, the match log links it to every GRN that contributed. The full chain — PR → PO → multiple GRNs → bill → payment — is queryable from any one of those records.

Common workflow patterns

Service POs (consulting, software licences, retainers). Receive on the contract milestone or invoice date. For a six-month consulting engagement billed monthly, raise a monthly GRN for the value of that month. The PO closes when the engagement ends.

Physical goods, single delivery. Receive in full on arrival. One PO, one GRN, PO flips to received. Quickest path.

Physical goods, multiple deliveries. Receive per consignment. Each pallet or courier drop gets its own GRN. PO sits at partial until the last unit lands.

Subscription renewals. Receive monthly as the service ticks. Useful when the supplier bills monthly against a single annual PO — each GRN anchors that month's invoice without you having to raise twelve separate POs.

Drop-shipped to customers. You buy from the supplier; the supplier ships direct to your customer. Receive when the customer confirms delivery, not when the supplier confirms dispatch. The customer's confirmation (email, signed POD) goes in the condition notes.

When the supplier delivers but you haven't raised a PO

It happens — emergency replacement parts, an urgent contractor extension, a renewal nobody flagged. Two ways to handle it cleanly:

Reverse-engineer the PO. Raise a PR + PO retrospectively, back-date the PO to the day the order was placed, then raise the GRN against it. The whole chain reads correctly in the audit log; the approver who signs the PR is signing off on a commitment that's already been made, with full disclosure that it has. Use this when you want to preserve the discipline of the cycle.

Accept the bill direct. Skip the PO; receive against an "ad-hoc" cost code with no match required. Faster, but the spend won't show on the commitments register, and the match warnings will list it forever. Reserve for genuinely one-off events where reverse-engineering would be theatre.

Most teams default to the first option and reserve the second for the genuinely emergency cases. The PR/PO record is what your auditors and your future-self need to reconstruct what happened — the cost of raising one after the fact is small compared to the cost of not having it.

Tips

• Receive what's actually in the box, not what's on the delivery note. The delivery note is the supplier's record of what they think they shipped. The GRN is your record of what you got. Where they disagree, your record wins.
• Date the GRN as the date goods arrived, not the date you got around to logging it. The received-date drives the three-way match and the GRN-to-bill timing analysis. Logging it accurately matters even if the click happens days later.
• Per-line GRN PDFs are useful for warranty disputes and insurance claims. Six months from now, when you need to prove a unit was delivered, the GRN PDF is the document the supplier can't argue with.
• Don't accept "1 pallet received" as a receipt. Count the units. Condition-note the count if you can't physically count on the dock. The whole point of the GRN is to anchor the bill to a number; "1 pallet" gives the bill nothing to match against.
• Run the matcher again after a late GRN. Bills already in manual review don't re-evaluate automatically — open the bill detail page and click Re-run match after receipting.

Next chapter: how the bill itself lands in the system, what OCR gets right, what you have to fix by hand, and how the bill ties back to the PO and GRN you just covered.