What Is an EDI 875 Purchase Order?

What Is an EDI 875 Purchase Order?

The EDI 875 is an ANSI X12 transaction set used as a grocery-specific purchase order. The EDI 875 transaction set is a Grocery Products Purchase Order, the electronic form of a paper PO used specifically by grocery wholesalers and retailers for the placement of orders for finished goods from their suppliers. It runs on the older UCS version of X12 rather than the standard release most retail EDI uses.

If you've mapped an EDI 850 before, the 875 will feel familiar and slightly off at the same time. Like the 850 Purchase Order, the 875 transaction includes all of the information required for the order, such as item description, item quantity to be delivered, price and total cost, and shipping instructions. The data is nearly identical. The segment names, the functional group, and the trading partner population are not.

EDI 875 vs EDI 850: What Actually Differs

The short answer: almost nothing in the payload, almost everything in who sends it. EDI 875 is tailored for grocery products with specific segment usage, while EDI 850 is a general purchase order for various industries. Functionally, you're looking at the same order information wrapped in different segment IDs.

The segment-level differences are where people get tripped up during mapping. The 875 doesn't use BEG for the header or PO1 for line items the way the 850 does. EDI 850's header segment is BEG with a PO1 line item segment, while EDI 875 uses G50 for its header and G68 for line items, and in practice, if you're trading with a grocery retailer or a food distributor, you'll likely be asked for the 875 family. Nearly everyone else stays on the 850 family, per the same comparison.

Don't assume every grocery chain uses the 875, though. Walmart uses the EDI 850 exclusively, even for grocery items, and Kroger's EDI requirements also specify the 850 as their standard purchase order across all divisions, while the 875 is more commonly used by grocery wholesalers, food service distributors, and some regional grocery chains. That's a detail worth confirming before you build a mapping, not after.

Where EDI 875 Sits in the Grocery Order-to-Cash Cycle

An 875 doesn't travel alone. It opens a document chain that runs 875 → 855 → 856 → 880, and the pairing at the end is the part generalist EDI guides routinely get wrong.

Once a buyer transmits the 875, the supplier confirms it rather than ignoring it and hoping the warehouse figures it out. Following receipt of an 875, a supplier should transmit an 855 Purchase Order Acknowledgment to the trading partner to confirm the PO was successfully received. Changes don't go through a revised order. The 875 PO is not to be used for purchase order changes or acknowledgments, and the 860 Purchase Order Change Request is used to submit changes to a previously sent PO. In grocery trading specifically, though, that role is usually filled by a sibling document instead: EDI 876 is an EDI transaction set used specifically in the grocery industry, and after submitting an EDI 875 Grocery Products Purchase Order, retailers and distributors can use EDI 876 to indicate changes to the order, such as the addition or removal of products, or a change in product quantities.

Here's the part that catches people migrating from general retail EDI: the 875 does not close out with an EDI 810. Known as a Grocery Products Invoice, EDI 880 is one of the most commonly used grocery store EDI codes, and suppliers like food and beverage manufacturers send an EDI 880 to grocery stores to bill them for their purchases after product shipments have been delivered. The matching logic happens on the buyer's side. The receiving grocery stores match the EDI 880 to the related EDI 875 to ensure the transaction's details are correct and schedule payment. If your AP automation is only watching for 810s against 875-based trading partners, invoices will sit unmatched.

The broader grocery document family extends beyond these four. Common grocery store EDI transaction codes include EDI 882 (Direct-Store-Delivery Information), EDI 876 (Grocery Products Purchase Order Change), EDI 875 (Grocery PO), and EDI 880 (Grocery Invoice) for seamless trade. A distributor like McLane illustrates how deep the required set can get in practice: its documented EDI transaction support spans 810, 820, 850, 852, 855, 856, 860, 865, 875, and 880, meaning trading partners are expected to handle both the general retail family and the grocery-specific one depending on the order type.

A Worked Example: Order Flow Through a Grocery-Specific Trading Partner

Picture a regional grocery chain's buying desk placing a replenishment order against a packaged goods supplier. The chain transmits an 875 instead of an 850 because the supplier's trading partner setup is grocery-specific, carrying the PO number, order date, buyer and vendor details, requested shipping dates, product identifiers such as SKUs or UPCs, item quantities, unit price and total cost, and shipping terms including preferred carrier in the G50/G68 segment structure rather than BEG/PO1.

The supplier's EDI system processes the inbound 875 and fires back an 855 confirming receipt and quantities. Warehouse pick and pack execute against that confirmed order, and once the trucks are loaded, the supplier transmits an 856 Advance Ship Notice carrying carton and pallet detail. This is also the point where EDI usually stops doing the heavy lifting. Carrier tendering, load visibility, and exception tracking move into a transport management layer, whether that's a heavyweight TMS or a lighter carrier-connectivity tool like Cargoson, MercuryGate, or Transporeon, since none of those functions live inside the 856 payload itself.

Billing closes the loop. After delivery, the supplier sends an 880 Grocery Products Invoice referencing the original PO number, and the buyer's AP system reconciles it against the 875 rather than waiting on an 810 that will never arrive for this trading partner.

Segment-Level Structure of the EDI 875

Inside the envelope, the 875 is marked at the functional group level before you even get to the transaction set itself. The GS Functional Group Header identifies the transaction type as OG (Grocery Products Purchase Order) and uses 004010UCS, the grocery-specific UCS version. That functional group ID alone tells a translator this isn't a standard 850 interchange.

From there, the structure runs through a predictable set of segments:

• ST – Transaction Set Header, identifying the document as an 875
• G50 – Purchase Order Identification, the header equivalent of BEG, carrying the PO date and number
• N9, G61, G62 – extended reference, contact, and date/time segments for order and delivery dates
• G68 loop – Line Item Detail, the grocery equivalent of PO1, carrying quantity, unit of measure, and product/service ID
• G72/G73 – Allowance or Charge segments, used for trade discounts, freight, and promotional allowances
• G76 – Total Purchase Order, providing summary totals for reconciliation

Most major EDI platforms, including SPS Commerce, TrueCommerce, Cleo, and IBM Sterling, carry native maps for the 875/880 pair alongside the standard 850/810 family, so onboarding a grocery trading partner shouldn't require a custom build from scratch. What it does require is someone on your side who knows to ask for the grocery map rather than assuming the retailer's default 850 template applies.

Implementation Notes for EDI Managers

Confirm with every grocery trading partner, before onboarding starts, whether they run 850/810 or 875/880. Mixing the two inside one partner relationship is how invoices end up rejected for referencing a PO number the AP system has never seen in its 810 queue.

Test files need closer scrutiny on product identifiers than a standard 850 test cycle. Grocery UPC and case-pack data tends to carry stricter GTIN-14 formatting expectations than general retail, and a malformed product ID in the G68 loop will fail further downstream than a generic retail 850 error would, often at the warehouse pick stage rather than at validation.

If you've already built onboarding playbooks for retailer-specific EDI setups, the grocery family slots into the same process: trading partner questionnaire, test ISA/GS envelopes, a round of 997 functional acknowledgments, then production cutover. The difference is simply which transaction set numbers appear in the compliance document.

FAQ

Is EDI 875 the same as EDI 850?
No, though the data they carry is close. The EDI 875 transaction set is an electronic Grocery Products Purchase Order used by grocery wholesalers and retailers to place orders for finished goods from a supplier, and the EDI 875 and EDI 850 Purchase Order are similar in nature, but EDI 875 was specifically designated for grocery EDI transactions by X12.

What response does a supplier send after receiving an EDI 875?
An EDI 855 Purchase Order Acknowledgment, confirming the order was received and flagging any quantity or availability changes.

Does EDI 875 pair with EDI 810?
No. It pairs with the EDI 880 Grocery Products Invoice, which the buyer matches back against the original 875 for payment.

Who sends an EDI 875?
The grocery retailer or wholesaler sends EDI 875 to the supplier when placing an order for grocery products. Suppliers, manufacturers, and distributors are the receiving side.

How do order changes get communicated after an 875 is sent?
Through an EDI 876 Grocery Products Purchase Order Change in grocery-specific trading relationships, or an EDI 860 Purchase Order Change Request where the partner follows the general X12 change process instead.

Is EDI 875 going away in favor of APIs?
Not soon. Grocery trading partners that standardized on UCS-based transaction sets decades ago have little incentive to re-platform a working compliance program, and most EDI providers still maintain native 875/880 support alongside their API offerings rather than retiring the format.