What EDI taught us about retailer rules

The project

We built an EDI system for a parts manufacturer selling through a retailer's drop ship program. Purchase orders come in, acknowledgments go both ways, and ship notices and invoices go out, all as X12 documents over AS2. It has been running in production since September 2026.

Lesson 1: the spec is the product

Every retailer publishes its own implementation guide on top of the X12 standard. Which segments are required, which codes are allowed, how fast each document must be sent. Two retailers can both "use the 856" and expect very different files. Building to the generic standard isn't enough. You build to their guide.

Lesson 2: acknowledgments are not optional

The functional acknowledgment (997) tells the retailer you received their document. The purchase order acknowledgment (855) tells them what you'll actually ship. Both are easy to treat as paperwork. They're how the retailer decides whether you're reliable.

Lesson 3: guard the money before it leaves

Two checks earn their keep immediately:

• Price checks: compare the price on the purchase order to the expected price before accepting it.
• Short ship guard: if the warehouse can't fill a line, say so in the acknowledgment and the ship notice, instead of discovering it at invoice time.

Lesson 4: watch it like a system, not a file

EDI isn't a file you send once. It's a pipeline. We poll for new purchase orders every two minutes, keep a dashboard of every document's status and alert on anything stuck. Problems are cheap when you see them in minutes and expensive when the retailer finds them first.

That pipeline is what became WhiteLabelEDI.