Matching fails because the goods receipt has not been posted yet

If the same exception disappears when nobody touches it, the process is generating work rather than finding problems. Goods arrive on Monday, the invoice arrives by email 3 hours later, and the receipt is keyed on Wednesday when the warehouse supervisor does the week's paperwork. Between Monday and Wednesday the match fails for a reason that is about clocks, not about goods.

The distinction that matters is between a receipt that is late and a receipt that is never coming. The first needs patience the system can supply on its own. The second needs a named person at a specific site, and no amount of waiting will produce it. Everything below is about telling them apart on arrival rather than after a week in a queue.

Compare the exception's age with your own receipting lag

There is no industry number for this and there does not need to be one: your own history contains it. Receipting lag is the elapsed time from delivery date to receipt posting date, and it varies enormously between a distribution centre that scans at the dock and a small branch where a manager keys receipts on Friday afternoons.

1. Take 6 months of posted receipts and compute lag as posting timestamp minus delivery date, in working hours rather than calendar days.
2. Report the 50th and 90th percentiles per site, per receiver and per supplier, and keep 12 months of history so seasonal sites are visible. One receiver at one site usually accounts for most of the long tail.
3. Overlay the age of your current unmatched invoices on the same scale. Anything younger than the site's 90th percentile is presumed timing.
4. Count how many of last quarter's receipt exceptions were closed with no action beyond a recheck. That number is the size of the prize.
5. Split the residue by whether a receiving event was ever possible: stock delivered to a site, goods drop-shipped to a customer, or a service with nothing to receive.
6. Recompute quarterly. Lag moves when a site changes process, and thresholds set once and forgotten become the reason exceptions escalate too early.

Four reasons the receipt is absent, only one of which is timing

They present identically — an invoice with no matching receipt — and they need 4 different responses. The confirming signal for each is available at the moment the exception is raised, which is what makes automatic routing possible.

The hold-and-recheck loop, and the numbers that set it

A timing exception should be a state on the invoice, not an item in anyone's work list. The invoice is held, rechecked on a schedule, and only becomes visible to a human when the schedule runs out. Three parameters define the loop, and all 3 come from the lag measurement rather than from a vendor default.

1. Recheck frequency. Every 4 hours for the first working day, then once a day. More often just re-reads the same tables; less often wastes a day of terms.
2. Hold window, per site, set at that site's 90th percentile lag rounded up to the next working day. Most timing cases resolve inside it without anyone knowing they existed.
3. Escalation target: the named receiver for that site, with the delivery reference and the supplier's dispatch advice attached, because the person who can post the receipt is never in AP.
4. Hard stop at close. Whatever the window says, stop holding 3 working days before period cut-off and force a decision, because an unmatched invoice at close is an accrual question.
5. A visible countdown on the invoice. Anyone who opens it should see how long it has been held and when it escalates, or the hold looks like the invoice being lost.

Holding is not free, which is why the window has a cap. If your terms run from invoice date, every day held is a day of the payment period consumed, and an early-payment discount can be lost while the invoice sits in a state nobody is watching — the reason the choice of clock matters, argued in which invoice date starts the payment clock.

Deliveries nobody was ever going to receive

Two categories break the 3-way match by design rather than by delay, and treating them as slow receipts guarantees they age out to a human every single time. Drop-shipped goods go directly to a customer, so no company site ever handles them. Services produce nothing to count: the work happened, and there is no dock, no scan and no receiving line.

• Flag these lines at PO creation, not at invoice time. A matching engine cannot infer that a delivery address is a customer's warehouse.
• Substitute an evidence source. Carrier proof of delivery, or the supplier's dispatch advice arriving over EDI or a portal, for drop-ship; a confirmation from the requisitioner or contract owner for services.
• Make the substitute a first-class object with a timestamp and an owner, so the audit trail shows what the match ran against instead of a receipt.
• Route milestone and retention billing to the contract rather than to a receipt. What is being verified is a contractual event, and it is closer to a non-PO approval than to a match.
• Keep the coding consistent with whatever the substitute implies, since a service confirmation often carries the cost centre — the ground covered in automatic GL and cost-centre coding a controller will accept.

Why period close ends the argument

An invoice held past cut-off stops being an AP workflow item and becomes a reporting problem. Goods received not invoiced (GRNI) and invoiced not received are the 2 halves of a clearing balance the controller has to explain, and a growing hold queue quietly inflates one of them. This is where holding invoices out of the ledger and posting them provisionally diverge sharply, and the answer depends on where your books live — the trade-off in a hosted ledger against an in-house ledger.

What escalation should look like when the window runs out

The failure mode here is routing an expired hold into the AP exception queue, where a clerk who cannot post a goods receipt looks at it, emails a site, and marks it pending. That is a hop with no decision in it, and repeated a few hundred times a month it is a large part of why an AP exception queue grows faster than it clears.

• Escalate to the person who can act: the named receiver at that site, with the supplier, delivery reference and quantity in the message.
• Give them 1 action. Post the receipt, or state that nothing was delivered — a binary answer that changes the invoice's state without a conversation.
• Escalate on a clock, not on a queue position. Silence for 2 working days goes to the site manager, and the invoice's state records both hops.
• Feed the outcome back into the lag data. A site whose escalations always resolve as "already posted, wrong line" has a matching problem rather than a receipting one.
• Keep it out of approval routing. An invoice waiting for a receipt is not waiting for an approver, and mixing the 2 is how invoices stall in approval with nobody able to say what they are waiting for.

The whole fix is small: a state machine, a scheduler, per-site thresholds derived from your own data, and 1 escalation path to a named human. It is the sort of thing we scope as an MVP and product build around an existing ERP for finance teams across fintech and financial operations, and the rest of the invoice-to-pay and AP automation cluster covers the matching and queue design it plugs into.

• three-way match
• goods receipt
• accounts payable
• exception handling