Food EDI Isn't Retail EDI

Most of what is written about EDI assumes you are selling to a big-box retailer. Purchase order, ship notice, invoice. Three documents and you are done.

Food is a different animal. If you supply grocery chains, foodservice distributors, or anyone provisioning kitchens at scale, three things quietly break the assumptions in that advice. None of them are edge cases.

Why grocery uses different EDI documents

The purchase order and invoice everyone writes about are the general-purpose ones. The grocery trade built its own.

Uniform Communication Standard, usually shortened to UCS, is a set of EDI conventions developed specifically for the grocery industry. It has its own purchase order and its own invoice, the 875 and the 880. They do the same job as the retail pair, but they are not interchangeable with it. The 875 pairs with the 880, not with the general invoice everyone else talks about.

The grocery versions carry things the general ones were not built around. Packaging hierarchies. UPC and GTIN identifiers. Allowances and promotions, which in grocery are constant rather than occasional.

Not every food partner uses them. Plenty of food companies trade on the standard retail pair and always have. But some do, and if whoever handles your mapping has only ever touched the retail documents, that is a spec they have not seen before. Worth asking before you sign, rather than during testing.

What catch weight does to an invoice

If you ship meat, seafood or cheese, you are already living with this one.

Catch weight means tracking a product in two units at the same time. A count unit, usually cases, and a weight unit, usually pounds or kilos. The case is what gets ordered and picked. The weight is what gets priced.

So a line might read one case of salmon at 50.2 pounds, billed as 50.2 multiplied by the price per pound. Ten cases go out and 502 pounds get invoiced.

Now read that again in the context of a three-way match. The quantity on the purchase order and the quantity on the invoice are different numbers, and both of them are correct. That is not an error. That is the product being what it is.

Whether the line passes depends on whether the billed weight, the unit basis and the extended amount are all supported by the purchase order, the receiving record and the paperwork that travelled with the shipment. If any of those disagree about which unit they are counting in, the line fails. And it fails in a way that looks exactly like overbilling.

What is a substitution overcharge deduction

Substitutions are ordinary in food. You are short on an item, you ship the nearest equivalent, and everyone on the warehouse floor knows precisely what happened.

The paperwork often does not.

A substitution overcharge is a deduction applied when the item number on your invoice does not match the item number the buyer's receiving system recorded. They charge you the difference in price between what you billed and what they say arrived.

There are two ordinary routes to it, and neither involves anyone behaving badly. Either the purchase order never gets adjusted, so the invoice and the shipping documents still name the original item. Or the invoice is generated from what was ordered rather than what was actually picked and loaded, so a late substitution never reaches the billing record at all.

The fields that resolve it are unglamorous. Supplier SKU, product description, pack size, unit of measure, and the line reference back to the original purchase order. When those travel with the substitution, the deduction does not happen. When they do not, it does.

The pattern underneath all three

In retail, a gap between the purchase order and the invoice means something went wrong. That is the entire premise of matching, and it is a reasonable premise when every case holds twelve identical units.

In food, a gap is frequently what correct looks like. The weight was always going to differ from the case count. The substitution was the right operational call. The grocery documents carry fields the retail ones do not.

The system checking your invoice at the other end cannot tell those apart. It sees a mismatch and applies a rule.

So the work is not making everything match. It is making the legitimate differences legible, so that the ones which genuinely are errors have somewhere to stand out.

Most EDI advice will not tell you any of this, because most EDI advice was written for somebody selling to Walmart.