Do You Need EDI 857 Alongside 856 and 810?
EDI 857 merges the ASN and invoice into one document. Learn what it replaces, who uses it, and when to skip it and keep 856/810 separate.
No. The EDI 857 Shipment and Billing Notice isn't something you add on top of your existing 856 and 810 transactions. It doesn't replace EDI 856 or EDI 810 individually; instead, it is used in place of sending them as a pair. If a trading partner asks for the 857, they're asking you to stop sending two separate documents and start sending one combined one. It's also a niche requirement, mostly confined to grocery direct store delivery (DSD) and U.S. federal government contracts, not something you'll see from a typical retail or automotive partner.
What exactly does the EDI 857 combine into one document?
The 857 merges the shipment data from an 856 (Ship Notice/Manifest) with the line-item pricing and payment data from an 810 (Invoice) into a single X12 transaction set. It provides the recipient of a shipment with data for both receipt planning and payment generation. The underlying logic, as X12 itself frames it, is that the sender of a shipment may send the recipient's receiving function a Ship Notice/Manifest (856), and the payables function an Invoice (810), even though the contents of these two documents may be largely redundant. In certain business environments, the Shipment and Billing Notice permits the consolidation of these two documents into one.
Structurally, that means a single 857 carries shipment header data, carrier and routing details, bill-of-lading references, item-level costing and allowance information, and invoice totals, all in one hierarchical loop structure (shipment level, order level, item level). SPS Commerce describes it plainly: this document combines the contents of an EDI 856 (Advance Ship Notice) and an EDI 810 (Invoice). One important caveat buried in the spec: the exact prices for the items shipped may not be known in advance by both parties in this environment, and this transaction set is not appropriate in so-called Evaluated Receipts Settlement (ERS) environments, in which the exact prices for the items shipped have been agreed upon by, and are known to, both parties in advance. If you're already running ERS with a partner, the 857 doesn't fit that model at all.
Why did grocery DSD distribution create the 857 in the first place?
The EDI 857 is used primarily in the grocery industry to electronically exchange shipment details and invoice information, and it's part of the shipping process only supported by the UCS guidelines. Kroger's own documentation explains the operational reason clearly: a delivery driver shows up at a store's backdoor, and receiving staff need to check in product and hand over an invoice in the same motion, without waiting for a separate paper or EDI invoice to arrive later.
The mechanism relies on barcode scanning at the pallet level. The benefit for Kroger and vendors using this method is that DSD backdoor store receiving can quickly check in a delivery by scanning the SSCC-18 bar code on each pallet. What makes the 857 different from a plain ASN is the pricing data riding along with it. The primary difference between the ASN 856 and the 857 for Kroger is that the 857 contains line item costing and allowance information similar to the 894 and can be used for checking in the product and generating vendor payment, which is critical for Kroger's DSD backdoor receiving system, since it lets Kroger provide a copy of the invoice to the delivery person immediately upon completion of the check-in process. Kroger closes the loop with the EDI 895 Vendor Acknowledgement document, which communicates back to the vendor the acceptance of the delivery and any item-level discrepancies found during check-in, including cost, allowance, pack, or quantity issues. Timing matters too: all electronic invoices must be transmitted at least four hours in advance of the physical delivery to the store, or check-in gets delayed.
Does the 857 replace 856 and 810 individually, or only as a pair?
Only as a pair. You cannot use the 857 to replace just the ASN while still invoicing separately, and you cannot use it as an invoice replacement while continuing to send shipment notices on their own. Commport is direct about this: it acts as a combination of both, but only to replace both together, and one would not use this transaction set in place of a Ship Notice/Manifest while continuing to send either paper or electronic invoices.
For mapping and testing, this is the detail people miss. A partner can't ask you to "add" 857 support while keeping your existing 810 flow running in parallel for the same order. It's an either/or switch. Commonly used in the grocery industry, the 857 replaces multiple transactions, reducing redundancy rather than adding a new one to your existing set.
Where else does EDI 857 show up outside grocery?
The other major place you'll encounter it is U.S. Department of Defense procurement. The transaction set may be used to send Wide Area Workflow (WAWF) Shipment and Billing Notice documents, also known as COMBOs, per the DLA's implementation guide. Under WAWF's successor system iRAPT, the 857 is a combination shipment and billing notice prepared by a vendor for transmission to iRAPT, and after processing, iRAPT separates the content as appropriate to provide separate outgoing transactions formatted using the applicable 810 invoice or 856 shipment notice. Worth knowing before you commit engineering time: per DFARS 232.252-7006 the government may not require the use of a COMBO, and the vendor may choose to use a COMBO or a standalone invoice and receiving report, since the 2n1 combines the invoice and receiving report into a single document. It's a convenience option for the supplier, not a mandate.
Outside grocery DSD and federal contracting, general retail, automotive, and manufacturing partners almost never ask for this. As a combined document, EDI 857 saves time and cost by replacing the need to send two individual documents, though it's rare to see this use case in practice. Both SPS Commerce and TrueCommerce document 857 support for the trading partners who do require it, which tells you it's a supported-but-uncommon transaction, not a rising standard.
What breaks when teams try to force the 857 into a standard workflow?
The most common failure is timing mismatch. Your ERP's invoice approval workflow is almost certainly built around 810 timing, meaning invoice data arrives after goods ship and gets reconciled against a receipt later. The 857 collapses that sequence into a single pre-arrival message, which means your AP automation has to trust shipment-level pricing before the product is physically counted. Freight audit and payment systems built around the standard 856/214/210 trio also don't have a natural home for the 857's combined carrier and billing fields, so you'll likely need custom mapping rather than a drop-in template.
Because the 857 carries carrier, routing, BOL, weight, and volume data alongside pricing, the quality of your carrier master data becomes an invoice-accuracy problem, not just a shipment-visibility one. A transport management platform with clean carrier connectivity, whether that's Cargoson, MercuryGate, Descartes, or SAP TM, matters more here than with a standalone ASN, since bad carrier data flowing into a combined document turns into a payment dispute instead of just a late tracking update.
| Factor | 856 + 810 (separate) | 857 (combined) |
|---|---|---|
| Typical use case | General retail, automotive, most manufacturing | Grocery DSD, DoD/WAWF contracts |
| Timing | ASN at ship, invoice separately (often post-ship) | Single document, sent pre-arrival |
| ERS compatibility | Works with ERS | Not appropriate for ERS, per X12 guidance |
| Error handling | Errors isolated to one transaction | A single error can block both receipt and payment |
| Partner mandate | Default expectation for most partners | Only where explicitly required (Kroger UCS, WAWF COMBO) |
Should you build 857 support, or keep 856 and 810 separate?
Build it only if a grocery DSD partner or a government contract explicitly requires it in writing. For everyone else, keep 856, 810, and 997 as your default pair. Combining shipment and billing data into one message means your receiving and billing systems have to be synchronized at the moment of transmission, which is harder to test and, when something's wrong, harder to fix. A single bad segment can simultaneously stall a store receipt and a payment run, whereas an error in a standalone 810 only delays the invoice.
- Check whether the mandate is for a specific banner or division, since not every Kroger division or DoD activity requires the 857.
- Confirm you're not in an ERS pricing arrangement with that partner, since the 857 is explicitly not designed for it.
- Map out whether your invoice approval workflow can handle pre-arrival, combined pricing and shipment data before committing engineering time.
- Verify carrier and routing data feeding the transaction is clean, since errors here become invoice disputes, not just tracking gaps.
Before you scope this as "just another ASN variant," pull the actual trading partner guide, whether that's Kroger's UCS documentation or the WAWF implementation guide, and confirm the requirement is real and not just a line item on a generic compliance checklist.
