GR
A Goods Receipt (GR) is a buyer-side document posted in the buyer's ERP after the receiving team verifies that physical goods (or completed services) arrived as ordered. For AR teams, GR is the silent gate between shipment and payment: without it, the supplier's invoice cannot pass three-way match and stays unpaid.
A Goods Receipt is a document created inside the buyer's ERP or procurement system once their receiving team confirms that goods arrived from a supplier or that a service was completed. It is the buyer's internal acknowledgement: the Purchase Order has been fulfilled, in part or in full, and the inventory or service value can now be recognised on their books.
Mechanically, the GR sits between two functions inside the buyer's organisation. Receiving (the dock, warehouse, or business owner) verifies what physically showed up. AP (Accounts Payable) cannot move the supplier's invoice toward payment until that verification is recorded as a GR posting against the original PO. The GR is therefore the handoff document that turns a physical event into an accounting event.
For the supplier's AR team, this matters enormously. You can ship perfectly, invoice perfectly, and still wait 60+ days for payment because someone on the buyer's receiving team never clicked post GR in their ERP. Your invoice is not late because of cash issues. It is late because of a missing internal document inside someone else's system.
A typical Goods Receipt captures a defined set of fields against the originating PO. These fields are what AP later compares the supplier's invoice against.
Variances are where AR pain typically starts. A partial receipt means only some lines or quantities were posted, so any invoice covering the full PO will fail to match. An over-receipt records more units than the PO authorised, and most ERPs will block that GR until someone approves a tolerance override. A short receipt records fewer units than were shipped, which typically kicks off an OS&D (Over, Short and Damaged) investigation between the carrier, the receiving team, and the supplier. A damaged receipt may be rejected outright, sending the supplier into a returns and credit cycle before any payment can occur.
Three-Way Match is the AP control that ties everything together. Before AP approves a supplier invoice for payment, it must align on three documents:
All three must agree on item, quantity, price, and (in most ERPs) date tolerance. If PO and invoice match but no GR exists, the invoice goes into a GR pending queue. If GR quantity is lower than invoice quantity, the invoice goes into a price/quantity variance queue. Either way, the supplier does not get paid and often does not get notified. The invoice simply ages.
Most AR teams instinctively chase late payments by calling AP. But in three-way-match environments, AP is rarely the blocker. The blocker is whoever was supposed to post the GR and did not. Common scenarios include:
None of these are credit issues. None are dispute issues. They are buyer-side workflow issues that the supplier is left to untangle, often with no visibility into the buyer's ERP.
Goods Receipts assume there is a physical receipt event. For services (consulting, implementation, maintenance, software subscriptions, professional services), there is no pallet to scan, so most ERPs use a separate construct. In SAP and similar systems this is the Service Entry Sheet (SES). The business owner who consumed the service must create the SES and have it approved before the supplier's invoice can be three-way matched.
Service GRs and SES are notoriously prone to delay. The buyer's project sponsor often does not realise that approving the SES is what releases payment, so they treat it as low-priority admin. For AR teams selling services, a large share of aged invoices can usually be traced to missing or unapproved SES rather than genuine disputes.
Traditional AR systems treat GR as a black box because it lives inside the buyer's ERP. AI-native and agentic O2C platforms close that gap by treating GR status as a tracked, customer-specific signal.
The shift is from chasing payment after the invoice is overdue to managing the GR step that determines whether the invoice can be paid in the first place. For AR teams selling into large corporate buyers with strict three-way match, that shift is one of the highest-leverage changes available.
The buyer creates the Goods Receipt inside their own ERP or procurement system. The supplier never posts a GR. This is why GR delays are so frustrating for AR teams: the document that unlocks payment is created by someone outside the supplier's control, usually a receiving clerk or business owner on the buyer's side.
GR pending means the buyer's AP system received your invoice but cannot find a matching Goods Receipt against the PO. Either the receiving team has not posted the GR yet, posted it for a different quantity, or posted it against the wrong PO line. Until a matching GR exists, three-way match will fail and the invoice will not move forward to payment.
Proof of Delivery is the supplier-side evidence that goods physically arrived, typically a signed delivery note from the carrier. Goods Receipt is the buyer-side record that confirms acceptance and triggers AP processing. POD is the input that justifies the GR, but only the GR (posted inside the buyer's ERP) unlocks invoice payment in a three-way match environment.
A Service Entry Sheet (SES) is the equivalent of a Goods Receipt for services rather than physical goods. Because there is no pallet to scan or dock to verify, the buyer's business owner must manually create and approve the SES to confirm the service was completed. For service-heavy AR portfolios, missing or unapproved SES is one of the biggest sources of aged invoices.
Yes. Sending a clean PO reference and a signed POD with the invoice gives the buyer's team everything they need to post the GR in one step. Tracking GR status per customer (via portal or API) lets AR escalate proactively when a GR is overdue rather than waiting for the invoice to age. Predicting GR timing per customer also helps cash forecasting stay realistic.
Agentic O2C platforms pull GR status from customer AP portals and supplier networks, learn each customer's typical GR-to-payment pattern, and flag invoices where the GR is not posted within the expected window. They also attach the supporting documentation (POD, BOL, completion sign-off) that buyers need to post the GR, turning a passive wait into a proactive workflow that shortens the cash conversion cycle.
