EDI 876 Grocery PO Change: Segments and Example

The EDI 876 is the grocery version of the purchase order change. When a grocery buyer moves a delivery date, raises a promoted item, or cuts a line from an order it sent on an 875 Grocery Products Purchase Order, the 876 is how that change reaches the supplier. It does the job the 860 Purchase Order Change does for an 850, but it works differently, and the difference trips up suppliers who map it like an 860.

This guide covers what the 876 carries, the restatement rule that governs every change, the G92 change type codes, every segment you will map, two live examples (a restated order and a cancellation), how it compares to the 860, and the errors that ship the wrong quantity.

What Is an EDI 876?

An EDI 876 is the Grocery Products Purchase Order Change transaction set defined by the ASC X12 standards body, sent by a retailer or wholesaler to request a change to a grocery purchase order it previously submitted. It belongs to the grocery family of X12 documents that grew out of the Uniform Communication Standard (UCS), which is why its segments carry the "G" prefix and why many grocery guides label the version 004010UCS.

Authoritative references for 876 work:

• The X12 transaction set catalog defines the 876 structure, its segment order, and the G92 change type codes
• GS1 US governs the UPC and GTIN identifiers carried on every 876 line, including the case code in G6804
• Each grocery buyer publishes its own 876 implementation guide, which narrows the change types it sends and says how its changes should be applied

Who sends it? The buyer: a grocery retailer, a wholesaler, or a distributor ordering from a manufacturer.

Who receives it? The supplier that received the original 875.

When is it sent? Any time after the 875 and before the order ships. Late changes, sent after the supplier has picked the order, are where most disputes start.

Why does it matter? An 876 that is missed or applied wrongly means the supplier ships the old order. In grocery that turns into refused product at the dock, short-pays on the 880 invoice, and perishables that cannot be resold.

How the 876 Restates an Order

The X12 standard sets one rule for the 876 that shapes everything else: changes are made by sending the new value of each field, not the difference. To take a line from 5 cases to 8, the 876 says 8, not "plus 3". To delete an item, the buyer restates its quantity as zero.

Three practical consequences follow:

1. There is no line-level change code. The 860 marks each changed line with a POC segment and a code such as "quantity increase". The 876's line segment, G68, has no element for that. The change type lives once, in the header G92, and the lines carry the new values.
2. There is no line number. G68 has no assigned line number element. You match each restated line to the original order by its item identifiers (the case UPC in G6804, or the product IDs in G6805 to G6808), never by position.
3. You have to compare against the original. To know what actually changed, your system diffs the 876 against the 875 it already holds. A supplier that overwrites the order without that comparison cannot tell its warehouse which lines moved.

Some grocery buyers send every 876 as a full restatement of the order (change type RZ, replace all values). In that case the 876 carries the whole order again, including lines that did not change. Others send only the lines that changed. The buyer's guide says which, and it is the first thing to confirm, because it decides what a line missing from the 876 means: unchanged, or removed.

G92 Change Type Codes

G9201 holds one code for the whole transaction. The X12 code list (element 670) is long, and a grocery buyer uses only a few of them. Some grocery buyers' published 876 guides list just two: RZ and CF.

Treat the buyer's guide as the source of truth. A code your map does not recognize should stop the change for review, not fall through as a no-op.

Interactive Example: Restated Grocery Order (876, Change Type RZ)

This 876 changes PO GRO-456789, the wholesaler order in our 875 guide. The original asked for 5 cases of whole wheat bread and 40 lb of sharp cheddar for delivery on May 16. Three days later the buyer sends this change:

• G92*RZ says the values replace the original order, and repeats the original PO number and PO date so the supplier can find it
• G62*02 moves the requested delivery date to May 18
• The bread line is restated at 8 cases
• The cheddar line is restated at 0 lb, which deletes it
• NTE spells out the change for the people reading it, which buyers often include and suppliers should not rely on

Use the Plain English tab for a readable summary, or click any segment to break it down element by element.

Notice that neither line says what it was before. The only way to report "bread up 3 cases, cheddar removed" to your warehouse is to compare against the stored 875.

Interactive Example: Grocery Order Cancellation (876, Change Type CF)

A cancellation is the shortest 876. G92*CF names the order and the date the buyer gave it, and no line items follow. The ship-to N1 stays because the standard requires at least one party loop.

If the order is already picked or on a truck when a CF arrives, call the buyer. The 876 does not tell you whether a load in transit will be refused or received.

876 Structure at a Glance

The 876 mirrors the 875. The header identifies the change and the order, the detail loop restates items, and an optional summary closes it. In the version 4010 standard:

In the GS envelope, the functional group code in GS01 is OG, the same group code the 875 uses. Buyers' guides tighten these rules, so read "optional" as "optional unless the guide says otherwise".

Key Segments Explained

G92: Purchase Order Change Type

G92*RZ*20260509*GRO-456789~

G92 replaces the 875's G50 header. The most common mapping mistake is reading G9202 as the change date. It is the PO date, and it helps you find the right order when a buyer reuses PO numbers across years. The date and time the change was sent sit in the GS envelope.

G62: Date/Time

G62*02*20260518~

G6201 qualifies the date: 02 is the requested delivery date and 10 the requested ship or pick-up date, among others. G6202 is the date. On an RZ change, a G62 that differs from the original is the new date. A grocery buyer that runs delivery appointments may treat a changed date as a new appointment request, so check that your scheduling side sees it, not just order entry.

N1 Loop: Parties

N1*ST*ACME GROCERY DC #001*92*001~

The 876 restates the parties so the supplier can confirm the order. N101 names the role (ST ship-to, BT bill-to, VN vendor), N102 the name, and N103/N104 the ID qualifier and code. A changed ship-to on an 876 is a real change. Treat it as one, not as a formatting difference.

G68: Line Item Detail (Product)

G68 is the restated line. Every value on it is the new value.

G68*8*CA*14.99*001234567895*VN*BREAD-WW-24*UP*012345678905~

Later elements carry price brackets, a cost in a different unit (G6810/G6811), price list references and a retail pre-price. Most buyers leave them empty.

Two rules matter more than the rest. Match lines on the identifiers, since G68 has no line number, and confirm with the buyer which identifier it treats as the key: some grocery buyers use the case code, others their own item code in G6805/G6806. And read the cost with its unit: a catch-weight line in LB carries a cost per pound, so a change from CA to LB on the same item changes what the cost means.

G69 and G70: Description and Pack

G69*WHOLE WHEAT BREAD 24OZ~
G70*12*24*OZ~

G6901 is a free-text description. G70 carries the pack (G7001, consumer units per case) and size (G7002 and G7003, here 24 ounces). A pack change on an 876 means the buyer expects a different case configuration. If your item file disagrees, resolve it before you ship.

G72 and G73: Allowances and Charges

G72 carries an allowance or charge at order level (in the header) or line level (in the detail). It holds an allowance or charge code, a handling method (for example off-invoice or bill-back), and a rate, quantity or total amount. G73 adds a free-text description. The codes a buyer uses are listed in its guide and must match the deal agreed with the category buyer. When an 876 changes a deal, the 880 that follows has to bill the changed deal, not the original.

G76: Total Purchase Order

G76*8*CA~

G76 gives the order's total quantity and unit, with optional weight, volume and total amount (G7608, with two implied decimals). It is optional on the 876, and some buyers' guides leave it out of the change entirely. If it is present, recompute it from the restated lines and compare.

EDI 876 vs EDI 860

Both change a purchase order that was already sent. They do it differently.

If your map treats the 876 as "an 860 with different segment names", it will miss deletions (a zero quantity looks like a valid line) and apply changes to the wrong lines (because there is no line number to anchor on).

Where the 876 Sits in the Grocery Order Flow

1. 875 Grocery Products Purchase Order. The buyer orders.
2. 997 Functional Acknowledgment. The supplier confirms receipt of the 875.
3. 855 PO Acknowledgment, if the buyer requires one.
4. 876 Grocery Products Purchase Order Change. The buyer changes or cancels the order. The supplier answers with a 997 to confirm receipt.
5. Change response, if the buyer requires one. The general X12 answer to a PO change is the 865 Purchase Order Change Acknowledgment. Many grocery buyers ask for none, so check the guide.
6. 856 Ship Notice. The ASN must reflect the changed order, not the original.
7. 880 Grocery Products Invoice. Bills the changed quantities and costs.
8. 820 Payment Order/Remittance Advice. The buyer pays, and deducts for anything that did not match.

For direct store delivery, the order (where there is one) often goes straight to the route, and the record of what arrived is the 894 Delivery/Return Base Record, not an ASN. An 876 against a DSD store order still has to reach the route before the truck loads. For the wider picture, see our guide to grocery EDI requirements.

Common 876 Errors and How to Prevent Them

Run any 876 you are unsure about through the free EDI inspector to see each restated line with its quantity, unit, cost and identifiers side by side.

876 Implementation Checklist

Before your first live 876 with a grocery buyer:

• Get the buyer's 876 guide and list the G9201 codes it sends
• Confirm whether it restates the full order or only changed lines
• Confirm which identifier it uses to match lines (case UPC, consumer UPC or its own item code)
• Map G6801 = 0 to a line delete, and test it
• Store every 875 so the 876 can be compared against it
• Agree a change cut-off, and what happens to changes received after the order is picked
• Confirm whether the buyer expects an 865, an updated 855, or no response
• Make sure the 856 and 880 are built from the changed order
• Test with a quantity change, a date change, a deleted line, an added line and a cancellation
• Monitor 997s for structural rejections in the first weeks of production

If you are mapping the grocery family for the first time, the EDI document types reference shows how the 875, 876, 880 and the DSD documents fit together, and our page on EDI for grocery suppliers covers the wider requirements.

Handling Grocery Orders and Changes With OrderSync

Grocery buyers change orders constantly: a delivery date moves, a promotion lifts a quantity, a line gets cut. EDI partners send those changes as 876s and 860s. Everyone else sends a revised PDF, an email that says "make it 8 cases", or a phone call to the sales desk.

OrderSync reads inbound orders in any format, including EDI 850s and 875s, PDFs, emails and spreadsheets, matches customers, items and units to your catalog, and outputs valid X12 or clean data to your ERP. When a customer sends a revised order document, OrderSync handles the change as part of order intake, so the order in your ERP reflects the latest version. Paste any 876 into the free EDI inspector to see it parsed with a plain-English summary, read more about purchase order automation, or book a 15-minute walkthrough to see your own orders processed.

Frequently Asked Questions