EDI for Food Brokers: A Practical Guide to 850s, 875s, and 997s

Why This Comes Up

Sooner or later a retailer or distributor tells you they'll only send purchase orders through EDI—no more emailed PDFs or phoned-in orders. For a lot of brokers, that's the first time the acronym stops being a buzzword and becomes a Monday-morning problem. The good news: a broker's EDI footprint is much smaller than the alphabet soup vendors like to quote. You receive orders and confirm them—that's most of the job. You don't need to implement everything; you need the two or three documents that actually apply to your role.

EDI—Electronic Data Interchange—is just a standardized way for trading partners to exchange business documents computer-to-computer, using numbered transaction sets in the X12 standard. The numbers are the vocabulary. Here's the short list that matters for a broker.

The Documents a Broker Actually Touches

850 — Purchase Order (inbound)

The 850 is the retailer's purchase order. This is the document you receive. When a retailer places an order electronically, it arrives as an 850 that has to be parsed and turned into an order in your system, then routed to the right principal. This is the workhorse of broker EDI.

875 — Grocery Purchase Order (inbound)

The 875 is the grocery-specific cousin of the 850, used by some grocery and foodservice trading partners. Functionally, for a broker, it plays the same role: an inbound order you receive and process.

997 — Functional Acknowledgement (outbound)

The 997 is the receipt. When you receive an 850 or 875, EDI etiquette—and usually the retailer's mandate—requires you to send back a 997 confirming the transmission arrived and was syntactically valid. It's automatic and technical; it says "I got your file," not "I accept your order." A good system sends it for you.

That's the core of it. Receive the order, acknowledge the transmission. For most broker accounts, that's the whole job.

The Documents You Don't Need (and Why)

Vendors will happily quote you a system that does 810 invoices, 856 advance ship notices, and 855 order acknowledgements. For a broker, those generally belong to someone else in the chain:

• 810 (Invoice) and 856 (Advance Ship Notice) are the manufacturer's and shipper's responsibility. The party that owns the inventory and ships the goods invoices and notifies. As a broker, you don't own inventory, so you don't send these.
• 855 (PO Acknowledgement) is a business-level accept/reject/change of the order, handled by the party fulfilling it.

These aren't gaps in your setup—they're someone else's job, on purpose. Invoicing, shipping notices, and order acknowledgements are core manufacturer systems, and they're absolutely necessary at that level. They're tightly wired into how your principal gets paid by their retailer or wholesaler. You don't help your manufacturer by inserting yourself into that conversation—you add a point of failure to a process that's working.

And the failure isn't hypothetical. Transmit an 856 late, or an 810 with data that doesn't match, and the retailer assesses a compliance fine—deducted straight from your manufacturer's receivables. That's the same short-pay bleed a good broker is supposed to help prevent, except this time you caused it. A broker has no place sending these documents. Receive the order, acknowledge it, and leave the manufacturer's EDI to the manufacturer.

Paying to implement documents outside your role is also a common way to overspend on EDI. If a vendor is pushing a full manufacturer-grade EDI package at a brokerage, that's a sign they don't understand the broker model. Match the scope to your actual place in the transaction: you receive orders and acknowledge them.

How Trading-Partner Setup Actually Works

The part nobody warns you about: EDI isn't a switch you flip. Each retailer is a separate trading-partner setup. You exchange technical details—identifiers, communication method, document versions—and usually run test transactions before you go live. A network like SPS Commerce sits in the middle for many retailers, translating and routing so you're not building point-to-point connections to each one.

Two implications for planning:

1. Budget lead time per retailer. Getting connected to a new trading partner takes coordination, not minutes. Onboard the retailers that mandate EDI first.
2. You don't need EDI for everyone. Plenty of accounts are fine with manual entry or file upload. EDI earns its keep on high-volume, EDI-mandated retailers—not on the account that sends you three orders a month.

Where TradePath HQ Fits

TradePath HQ handles the broker side of EDI without the manufacturer-grade overhead: inbound X12 850 and 875 purchase orders are received at a dedicated endpoint and parsed into orders automatically, with 997 functional acknowledgements sent back. If your partners route EDI through a network like SPS Commerce or edict, they simply forward a copy of the order to your endpoint—there's no separate integration to buy. Trading-partner setup is handled as part of onboarding, so you're not wiring up connections yourself. EDI is available on Professional and Velocity plans; Core is built for agencies that manage orders manually or by upload. Start with a 14-day free trial and no implementation fee.