Touchless GR auto-posting

An invoice is a claim for payment, not evidence that pallets hit the dock.

Post a goods receipt automatically on two paths only. First, the purchase order, receipt evidence, and invoice already match: the matcher has the PO, a dock artifact, and the invoice, and they agree inside the written band. Then the agent posts the GR in the ERP so inventory and AP finally line up. Second, a confirmed ASN plus quantity tolerance: the supplier sent an advanced shipping notice, receiving confirmed it at the dock, and the counted quantity sits inside the band. The invoice may not have arrived yet. The GR can still post because the dock event exists.

Do not post from an invoice alone. That creates stock that was never there and releases payment for a truck that never came. Invoice data extraction can make that failure look finished: a high-confidence PDF with a PO number and a total, and no one at the dock ever scanned a label.

Receipt evidence is a warehouse fact: a confirmed ASN, a packing-slip scan tied to the inbound delivery, or a receiving scan. A PO number printed on supplier stationery does not.

Three-way match automation is the comparison. This page is the ERP write. Matching can propose. Posting a GR changes on-hand quantity, GR/IR clearing, and what AP is allowed to pay. Keep those jobs separate.

SAP, Coupa, Oracle, and Jaggaer sit in the same class: they hold a PO, a receiving transaction, and an invoice, and they can post a receipt into the system of record. None of them invents a dock event. If receiving is a receive-all click from invoice quantity, the suite will post what you told it arrived.

Auto-post is a narrow band, not a plant-wide switch. Write the band before anyone enables the interface.

Category. Catalog and MRO lines with a material number, a unit of measure you already receive against, and a supplier you have received from before. Keep capital equipment, first receipts from a new vendor, and free-text descriptions that never became a clean PO with a human at the dock.

Quantity tolerance. A written over/under band by category, signed by finance and the warehouse. Do not copy a percentage from another company code to raise the touchless rate. Tight bands belong on counted piece items.

No discrepancy flag. If receiving already marked short, over, wrong item, or damage, auto-post is off for that delivery. Delivery discrepancy classification is that flag. A classified short is a claim, not a rounding error to absorb so the invoice can post.

Spend that already passed low-risk auto-approval on the requisition is a candidate only if the receiving band is also true. A cheap MRO line can still arrive short. Approval of the request is not confirmation of the pallet.

If the PO itself was created by PO auto-generation from requisition, keep GR auto-post off until those orders survive receiving without constant line splits and unit-of-measure fights. Two automated ERP writes on a messy order bury the mess in inventory.

The following is a made-up but realistic design, not a case study and not reported results.

Westfield runs a regional DC for a process manufacturer. MRO catalog spend (filters, seals, electrical) arrives daily against blanket POs. AP parks invoices that wait on a goods receipt. The warehouse posts GRs when the dock has time, often after the invoice is already aging. The AP lead asked IT to auto-receive against the invoice for catalog suppliers so parked invoices would clear.

IT pointed receiving at the invoice quantity whenever the PO matched and no GR had been posted. For a stretch the AP queue looked healthy.

What actually happened on a seals shipment: the dock counted 80 boxes against a PO of 100. A warehouse clerk started a receipt, got pulled to another door, and never posted. The invoice arrived for 100. The auto-receive job posted a GR for 100 because the PO and invoice agreed and there was no posted GR to conflict with. The short never became a discrepancy record. A later count found a hole in that bin. The supplier had been paid in full.

What they changed:

1. Auto-post only on catalog and MRO, for named suppliers, with quantity inside the band finance wrote, and only if receiving had a confirmed ASN or a dock scan for that inbound delivery.
2. If a discrepancy flag existed, or counted quantity sat outside the band, the job skipped. Warehouse owned the short.
3. Invoice quantity could confirm a match. It could not create the receipt.
4. Posting used a dedicated identity, not the integration user that also wrote purchase orders.
5. Every auto-post stored PO, inbound delivery or ASN, dock-scan id, invoice reference if present, quantities, the rule that fired, timestamp, and posting identity, in a log finance could replay without a vendor ticket.

They left packaging off the band (pallet rounding and catch-weight) and kept a human on any vendor whose first receipt of the quarter still needed eyes at the dock.

A goods receipt in the ERP is an accounting document. Someone has to own it.

If every auto-posted GR lands as a shared interface user that also creates POs and parks invoices, you have erased segregation of duties. Audit will ask who received the goods. "The integration" is not an answer. That is the no-named-identity failure: a posting with no person or dedicated account to reconstruct.

Create a named posting identity used only for this band, for example a catalog/MRO auto-receive account that cannot create purchase orders and cannot release payment. Document it. Run SOD review before go-live, not after the first finding.

Keep a replayable trail:

• PO line and inbound delivery
• Dock artifact (ASN confirmation, scan, or packing slip)
• Invoice document number if the three-way path fired
• Ordered, counted, invoiced, and posted quantities
• The rule that allowed the post (band, supplier, no discrepancy flag)
• Timestamp and posting identity
• The ERP material document number that came back

If you cannot reconstruct those fields a year later, you cannot defend the post. Sampling posted receipts against physical stock still belongs to the warehouse. A document match is not a cycle count.

SAP, Oracle, Coupa, and Jaggaer each stamp a user on the receiving document. Configure that stamp. Do not accept the default interface user because it was easier to copy from the PO interface.

Once a GR is posted short, do not finish it from the invoice so AP can close.

That overwrite erases the shortage. The vendor claim, the carrier claim, and the inventory adjustment disappear into a clean three-way match. If the clerk later wants the books to show 80 received, the books already say 100.

Payment workflow starts after a legitimate GR, not instead of one. On the three-way path, the match passing is what lets you post the GR and then release the invoice. On the ASN path, the GR posts from confirmed quantity; the invoice still has to match later. Either way, AP does not get a dummy receipt to stop dunning.

Leave these off auto-post on purpose:

• Any line with a discrepancy flag
• Quantity outside the written band
• No ASN confirmation and no dock scan
• Service lines mixed onto a goods PO
• Invoices that arrived before any inbound delivery exists in the warehouse system

The speed you are buying is parked invoices and late GRs on boring catalog lines. If parked AP is the pain, fix receiving timeliness and match routing first. Auto-posting a GR you cannot defend is how inventory and cash both go wrong at once.