Walmart
Primary-source verifiedUL/GLN qualifier, X12 4010. Every chargeback rule and envelope quirk verified against Walmart’s own published spec, line by line.
Coverage
Every retailer. Every document. Built from the spec.
Direct-connect retailers and the full X12 order-to-cash document set — each one built from the retailer’s own published EDI spec and verified against the source line. A new retailer is config, not a rebuild.
5
Direct-connect retailers
10
X12 document types
1
Config-driven pipeline
The roster
Hand-built per retailer — not a directory entry.
Most platforms add a retailer to a dropdown. We treat each one as its own engineering project, built from its published spec and verified against the source.
Best Buy
Live & wiredDUNS qualifier, X12 4030. Traditional core-vendor flow, triple-verified from the DTS / RDC / vendor-onboarding guidelines.
Meijer
Live & wiredX12 4010 VICS, 6-digit POs, SOIP carton hierarchy (BSN05 = 0002), SSCC18 + GS1-128 labels.
Sam's Club
Live & wiredWalmart-family rules plus 820 Payment and 846 Inventory. SSCC18 cartons, GS1-128 labels.
Burlington
Config-ready from specMerchandise EDI, built entirely from Burlington’s published spec — zero new code. The living proof that your retailer is just config.
Your retailer
Target, Home Depot, Lowe’s, Kohl’s… config-ready from their published spec. No integration project, no statement of work.
Send us the specThe document set
The full order-to-cash cycle — every document wired.
Order in; acknowledgment, ship notice, and invoice out; payment, inventory, and every functional ack in between — parsed, validated, and generated from config.
850
inbound
Purchase Order
Retailer to vendor — the order that starts the cycle.
855
outbound
PO Acknowledgment
Vendor to retailer — “I will fulfill, with these line decisions.”
856
outbound
Advance Ship Notice
Vendor to retailer — carton-level shipment with SSCC18 + GS1-128.
810
outbound
Invoice
Vendor to retailer — the bill for the shipped goods.
997
both
Functional Ack
Protocol-level “I got your file” handshake. Both directions.
824
inbound
Application Advice
Retailer to vendor — business-level errors after a 997 OK.
860
inbound
PO Change
Retailer to vendor — amends an existing 850 (qty / date / cancel).
820
inbound
Remittance
Retailer to vendor — payment of an invoice with deductions.
846
both
Inventory Advice
Inventory inquiry / advice, wired to each retailer’s workflow.
865
outbound
PO Change Ack
Vendor to retailer — accept or reject an inbound 860 change.
How any retailer gets added
Your retailer next — from its published spec.
We read each retailer’s published EDI spec — every chargeback rule, envelope ID convention, and SLA window — and translate it into reviewed configuration. That config is the parsing, validation, and generation logic, so adding a retailer is config authoring, not a code rebuild.
Read the published spec
The retailer’s own EDI guidelines — the PDF, the tables, the sample files — are the source of truth. Every rule is verified against the source line.
Translate into reviewed config
That spec becomes reviewed configuration — the same config that drives parsing, validation, and document generation. No bespoke code branch per retailer.
It ships — not rebuilt
A new retailer or doc type is added as config and ships on the next release. That’s exactly how Burlington went live from spec alone.
Your retailer next
Don’t see your retailer? Send the spec.
Point us at your retailer’s published EDI guidelines and we’ll add it as config — no rebuild, no statement of work.