EDI 880 Grocery Products Invoice: The Complete Guide (2026)

Billing a grocer is not quite like billing anyone else. The order came in as an 875 grocery purchase order, the delivery may have gone to a single store this morning, and the invoice that follows has its own dedicated document: the EDI 880 Grocery Products Invoice. It belongs to the same UCS grocery family as the 875, and the two are designed to travel as a pair — order out, invoice back, at the pace grocery moves.

The 880's place in the chain

A useful rule from the grocery world: the invoice follows the order's dialect. Programs that order on the 875 expect billing on the 880; programs that order on the standard 850 expect the 810. Albertsons makes the split explicit — its DSD programs order daily on the 875, and the 880 invoice pairs with the 875, not the 810. Suppliers serving both a grocer's warehouse and DSD programs often run both invoice types side by side, mapped from the same billing records.

Downstream, payment and deductions flow back the way they do everywhere else in EDI — remittance detail on an 820, with adjustments itemized.

What's inside

The 880 opens with a G01 segment carrying the invoice number and date plus the reference back to the 875's order number. N1 loops identify the store or DC billed, G17 detail lines carry item, quantity, and price, G72 segments itemize allowances and charges, and totals close the document. Two conventions deserve special care:

• Bill the delivery, not the order. Grocery receiving reconciles invoices against what physically arrived. If the store cut two cases at the door, the 880 must reflect it — an invoice for the ordered quantity will short-pay, and at daily DSD volume those small variances compound into a permanent deductions backlog.
• Keep promotional money visible. Off-invoice allowances, promotions, and charges belong in their own segments with codes, not silently netted into unit price. Grocers audit invoice pricing against agreed deal sheets; transparent allowances reconcile, invisible ones get disputed.

Volume changes the failure math

An invoice error rate that would be tolerable in general retail is a crisis in grocery, simply because of document count. A supplier delivering to hundreds of stores daily generates invoices at the same rate — so a small percentage of mismatches becomes a daily stream of short-pays, each one requiring research that costs more than the variance itself. This is why grocery billing rewards automation at the source: generate every 880 from the delivery confirmation, with prices from the current agreed list, and the mismatch stream mostly dries up.

Timing plays a role as well. Grocery payment cycles are short, and an invoice that arrives days after the delivery competes with the store's own receiving memory — the older the claim, the harder the reconciliation. Generating the 880 at delivery confirmation keeps billing inside the window where the grocer's records and yours still agree, which is the cheapest dispute prevention available.

EDISQ generates 880s automatically from delivery data in your ERP, maintains the 875-to-880 references, and keeps store-level billing running at whatever cadence your grocers order — part of the broader grocery flow covered in our food and beverage solution.

Priced for daily billing

High-frequency invoicing is exactly where per-document economics get interesting. On EDISQ's pricing, your first 25 documents in any month are free; beyond them, each 880 starts at $0.50, and as monthly volume climbs the marginal rate falls tier by tier to $0.10. Nothing else is metered — no mapping or setup costs, and the network connectivity is included. Daily store billing stays a rounding error in your cost of doing business, which is what it should be.

FAQ