The EDI 861 · Receiving Advice / Acceptance Certificate is the buyer's confirmation of what was actually received — not what was ordered, not what the seller said shipped, but what arrived at the dock, in what quantity, in what condition, and whether it was accepted. It closes the loop that the 856 · Ship Notice / ASN opened: the ASN says "this is coming," the 861 says "this is what we got."
If you sell into retail or distribution, the 861 is where a shipment stops being your version of events and becomes the shared record both sides bill, dispute, and reconcile against.
What is the EDI 861 · Receiving Advice / Acceptance Certificate?
The 861 is an X12 transaction set sent by the receiving party — a retailer, distributor, or warehouse — back to the seller after goods arrive. It reports, line by line, the quantity received, the quantity accepted, any quantity rejected or damaged, and the reason for any exception.
Think of it as the receiving-side counterpart to the seller's documents:
- The 850 · Purchase Order says what the buyer wanted.
- The 855 · Purchase Order Acknowledgment says what the seller promised.
- The 856 · Ship Notice / ASN says what the seller shipped.
- The 861 · Receiving Advice says what the buyer actually received and accepted.
- The 810 · Invoice should then bill only for what was accepted.
When those five documents agree, payment is boring. When the 861 disagrees with the 856 or the 810, that disagreement is the earliest, most precise evidence either side will ever have about what went wrong.
What does an 861 actually contain?
At the header, the 861 identifies the shipment, the original purchase order, the receiving location, and the date and time receiving was completed. That linkage matters: an 861 that cannot be matched to its ASN and purchase order is just a complaint with no address.
At the line level, each item carries the product identifier, the quantity shipped per the ASN, the quantity received, and a disposition for the difference — accepted, rejected, or accepted with exception. Reason codes do the heavy lifting: short shipment, overage, damage, wrong item, or quality hold. A line that simply shows a smaller number, with no reason, forces a phone call. A line with the right reason code lets the seller fix the right thing — reship, credit, or correct the invoice — without one.
Some implementations also carry lot, serial, or pallet-level detail, tying acceptance back to the same shipment hierarchy the ASN described. That traceability is what makes an 861 useful months later, when a chargeback arrives and someone asks what the dock actually saw.
Why does the 861 matter if there is already an ASN?
Because the ASN is the seller's statement, and statements can be wrong. Cartons get left on the outbound dock. A pallet is loaded onto the wrong truck. Goods arrive damaged in ways that were invisible at packing. The ASN faithfully reported what was supposed to happen; the 861 reports what did happen.
That makes the 861 the control point for three separate jobs. For the seller, it is the trigger to invoice accurately — bill the accepted quantity, not the shipped quantity, and the most common class of invoice deduction never happens. For the buyer, it is proof of receipt that receiving, accounts payable, and inventory can all share instead of each keeping a private count. For both sides, it is dated, structured evidence: if a retailer later deducts for a shortage, the 861 either supports the deduction or refutes it, and there is very little arguing with a document the buyer sent at the time of receipt.
Where do 861 flows usually break?
The first break is delay. An 861 sent a week after receipt arrives after the invoice has already been cut from the ASN quantity, so a correct receiving record still produces a short-pay, a deduction, and a dispute. The value of receiving advice decays fast — its job is to reach the seller before billing, not after.
The second break is the silent exception. Quantities are adjusted in the buyer's warehouse system, but the 861 is never sent, or is sent without reason codes. The seller learns about the shortage from the remittance — the 820 · Payment Order / Remittance Advice or, in healthcare-style flows, its equivalent — weeks later, with less evidence and less goodwill than the 861 would have provided on day one.
The third break is treating the 861 as a warehouse formality instead of an integration input. If the accepted quantities in the 861 do not flow into invoicing, inventory reconciliation, and reshipment decisions, the document exists but does no work. The receiving advice has to change what the seller does next, or it is just paperwork about a problem that will repeat on the next shipment.
Frequently asked questions
Is the 861 · Receiving Advice the same as a goods receipt in an ERP?
They describe the same event, but they are not the same artifact. The ERP goods receipt is the buyer's internal record; the 861 is the structured message that shares that record with the seller, in a form the seller's system can act on automatically.
Who sends the 861 — the buyer or the warehouse?
Whoever performs receiving sends it. That is often the buyer's distribution center, and for drop-ship or third-party arrangements it can be a 3PL receiving on the buyer's behalf. Either way, it flows to the seller whose ASN it answers.
Does every retailer require an 861?
No. Some buyers rely on the ASN plus invoice matching and surface exceptions only through deductions. Where an 861 is in the trading-partner guide, though, it is usually because the buyer wants exceptions resolved by document, not by deduction — which is better for the seller, provided the 861 is actually read and acted on.
What should a seller do with a rejected line on an 861?
Treat the reason code as the work order: reship a shortage, credit damage, and correct the invoice before it is disputed. The worst response is to invoice the original quantity anyway and let the remittance deliver the news.
Receiving is the moment two companies' records either converge or quietly diverge, and the 861 is the document that forces the convergence. At SignalEDI, we treat the 861 as a first-class input to invoicing and exception handling rather than an FYI — because the cheapest dispute is the one the receiving advice prevents.
— Chris, founder of SignalEDI
Top comments (1)
The point about the 861 closing the loop between the 856 and the 810 is a useful way to frame it. One detail worth planning for on the seller side: a single ASN does not always map to a single receiving advice. When a load is received in stages, or part of it is held for a quality check, several 861s can reference the same shipment, so a reconciliation job should probably aggregate received quantities per ASN line instead of assuming a one-to-one match.
It also helps to treat arrival order as unreliable. An 861 can reach the seller after the invoice has already been posted, and storing both the receiving timestamp inside the document and the time the message was received makes those late cases much easier to explain. As far as I know, trading-partner guides differ on whether a corrected 861 replaces the first one or supplements it, so that is worth confirming per partner before building the matching rules.