X12 transaction guide · Finance
EDI 880 Grocery Products Invoice
The X12 invoice grocery suppliers and brokers send to retailers and wholesalers, following grocery-industry (UCS) conventions.
- Sent by
- Supplier, manufacturer or broker
- Received by
- Grocery retailer or wholesaler
- Standard
- ANSI ASC X12
- EDIFACT equivalent
- INVOIC
What is an EDI 880?
The EDI 880 Grocery Products Invoice is the ANSI X12 transaction set a supplier or broker uses to bill a grocery retailer or wholesaler for finished goods. It is a standalone, line-detail invoice built on grocery-industry practice, with its own G-segments for the invoice header, item detail and totals, in place of the segments of the general 810 invoice.
Each 880 identifies the invoice, the purchase order it bills, the ship-to party, the items and quantities invoiced, and the totals. It is not used for statements or for credit and debit adjustments, which have their own transaction sets. Accurate case codes, quantities and allowances are essential, because grocery buyers match invoices against orders and receipts before paying.
How to read this diagram: the top row shows who sends the 880, to whom, and which documents usually come before and after it. The lower part shows what X12 release 004010 itself requires: the envelopes around the 880 and the segments and loops the standard marks as required, area by area. Optional loops are listed by the segment that starts them rather than drawn in full. This is the standard's minimum, not a trading partner's requirement: each partner's implementation guide usually makes some optional loops mandatory, restricts the codes and may use a different release.
When it is used
- Billing grocery retailers and wholesale distributors
- Invoices with U.P.C. case codes and case quantities
- Invoices that carry allowances and charges at header or line level
Where it fits in the document flow
Structure
Key segments in the 880
The segments most implementations use, described in plain language. The last column shows what X12 release 004010 itself requires: "Required" marks a segment the standard requires in every 880; "Optional, common" marks a segment the standard leaves optional, or that sits in an optional loop, but that implementations often use. This is the standard's requirement, not your trading partner's: each partner's implementation guide names the release it uses, makes some optional segments mandatory and restricts the values, and requirements can differ between releases. The requirement status comes from one published X12 reference listing and has not been checked against a second source.
| Segment | Name | What it carries | In X12 004010 |
|---|---|---|---|
| G01 | Invoice Identification | Invoice date and number, with the purchase order date and number being billed. | Required |
| N1 loop | Name | Parties to the invoice, including the party the goods were shipped to. | Required |
| G17 | Item Detail - Invoice | Quantity invoiced and unit, item cost and the U.P.C. case code or other product identifier. | Optional, common |
| G31 | Total Invoice Quantity | Total units shipped, with optional weight and volume. | Required |
| G33 | Total Dollars Summary | Total invoice amount, including charges less allowances, before any terms discount. | Required |
Example
Sample EDI 880
Invoice INV88123 billing order GPO77812 for 50 and 30 cases. G31 totals 80 cases. G33 carries the 1,583.00 total with two implied decimal places (50 × 18.40 + 30 × 22.10).
Illustrative data only, not tied to one X12 release or trading partner. The interchange (ISA/IEA) and functional group (GS/GE) envelopes are omitted for readability.
ST*880*0001~
G01*20261024*INV88123*20261020*GPO77812~
N1*ST*Example Grocers DC 12~
G17*50*CA*18.40*001234567890~
G17*30*CA*22.10*001234567906~
G31*80*CA~
G33*158300~
SE*8*0001~The sample is the same one shown above, with a note beside each segment the first time it appears. Segment IDs are highlighted at the start of each line; the fields after them are separated by asterisks, and each segment ends with a tilde.
Avoid problems
Common 880 errors and how to prevent them
Totals that do not add up
Grocery buyers check G33 against the line detail, allowances and charges. Calculate totals from the same lines you send, with the correct implied decimals.
Billing quantities not received
Invoices are matched to receipts. Bill what was shipped and confirmed in the ship notice, or expect deductions.
Using the 880 for adjustments
Credits and debits for shortages or pricing errors travel in separate transaction sets. Sending them as 880s causes duplicate or rejected invoices.
Trading partners
Integration guides that include the 880
How ECOM helps
Automate the 880 with ECOM
Industry
Food and Beverage
Grocery and foodservice EDI for food and beverage manufacturers, with lot, date and inventory data.
Solution
Order-to-Cash Automation
Automate the flow from purchase order to payment across every customer channel.
Solution
Financial Document Automation
Automate invoices, remittances, payment files and bank statements from capture to posting.
EDI 880 FAQs
What is the difference between an 810 and an 880?
Both are invoices. The 880 is the grocery-industry version, built from G-segments and grocery conventions, while the 810 is used across most other industries.
How are amounts formatted in the 880 totals?
The G33 total amount uses a numeric format with two implied decimal places, so 158300 means 1,583.00. Partners' guides confirm the format they expect.
Do grocery retailers still require the 880?
Some do, while many now accept or require the 810. Suppliers selling into grocery often support both, depending on each partner's requirements.
More general questions about EDI are answered in the EDI FAQ.
Related transactions
Related finance documents
Need help with the EDI 880?
ECOM maps, tests and monitors X12 documents for your trading partners and integrates them with your ERP.