Electronic Data Interchange (EDI) integration connects Adobe Commerce or Magento to a trading partner’s system so purchase orders, shipment notices, and invoices move as structured documents instead of email and manual entry. For most B2B merchants the EDI documents flow through the ERP that sits behind the store, while Adobe Commerce owns catalog, pricing, and self-service ordering.
That division of labor is the single most important decision in an EDI project, and it is the one most guides skip. Below is how the documents actually move, where each one belongs in an Adobe Commerce stack, and how to keep large retailers from clawing back margin through compliance chargebacks.
What EDI Actually Does for a B2B Store
If you sell to distributors, big-box retailers, grocery chains, or government buyers, those partners rarely place orders on your website. They transmit an EDI 850 purchase order from their procurement system and expect a machine-readable acknowledgment, shipment notice, and invoice in return, on their timeline and in their exact format. A missed or malformed document is not a support ticket. It is a fine.
EDI replaces the fax, PDF, and rekeying loop with a defined sequence of X12 (North America) or EDIFACT (international) transaction sets. Each partner publishes a specification that dictates which documents are required, which segments and qualifiers they use, and how fast you must respond. Two retailers both asking for an “850” will still demand different data in different places.
For a Magento or Adobe Commerce development team, the job is less about the storefront and more about making the commerce platform and the ERP speak the partner’s dialect without drift.
The Core Documents, in Order
An order-to-cash cycle usually runs through four documents, with two acknowledgments keeping everyone honest. The table below maps the transaction sets a B2B merchant meets first.
| X12 set | Name | Direction | Purpose |
|---|---|---|---|
| 850 | Purchase Order | Inbound (buyer to you) | Line items, quantities, pricing, ship-to DC, and the Must Arrive By Date |
| 855 | PO Acknowledgment | Outbound | Confirms receipt; accepts, rejects, or proposes changes per line |
| 856 | Advance Ship Notice (ASN) | Outbound | Pack hierarchy (pallet, carton, item) with SSCC carton labels, sent before delivery |
| 810 | Invoice | Outbound | Bills for shipped goods, referencing the PO and ASN |
| 846 | Inventory Advice | Outbound | Communicates available stock to partners |
| 997 | Functional Acknowledgment | Both | Confirms a document was received and passed structural validation |
The sequence matters. A retailer sends the 850. You return a 997 to confirm receipt, then an 855 to accept the lines. You ship, transmit the 856 before the truck reaches the dock, and follow with the 810 to get paid.
The 850 sets the rules
The purchase order carries more than SKUs and counts. It includes the ship-to distribution center, vendor and UPC/GTIN item numbers, pack sizes, routing instructions, and the Must Arrive By Date (MABD), a hard delivery deadline. In an Adobe Commerce context, the 850 typically lands in the ERP, which validates it against the catalog and pricing that Adobe Commerce also serves, then creates a sales order.
The 856 is where money is won or lost
The Advance Ship Notice transmits the pack hierarchy: how cartons sit on pallets and what is inside each carton. Every carton carries an SSCC-18 (Serial Shipping Container Code) on a GS1-128 label, so the receiving dock can scan a carton and see its full contents against the ASN. The rule that trips up new vendors: the 856 must arrive before the physical shipment does. According to 3PLGuys’ breakdown of the 850, 856, and 810, a late ASN commonly draws a chargeback of around 3% of invoice value, and inaccurate carton counts or missing SSCC labels draw more.
The 810 has to reconcile
The invoice references the PO and the shipment, and its quantities must match the ASN exactly. When the 810 disagrees with what was shipped, retailers short-pay or delay payment. Getting the 810 right depends entirely on the 856 being right first.
Where EDI Belongs in an Adobe Commerce Stack
Most Magento B2B installations run an ERP such as NetSuite, SAP, Sage, or Microsoft Dynamics behind the storefront, and the cleanest architecture keeps EDI at that layer. Adobe Commerce stays focused on catalog, customer-specific pricing, and self-service reordering, while the ERP handles inbound POs and outbound ASNs and invoices. This mirrors the ERP, CRM, and POS integration patterns that hold up as B2B operations scale.
There are three integration models, and the right one depends on how many partners you serve and how much of the flow the ERP already owns.
| Model | How it works | Best for | Tradeoff |
|---|---|---|---|
| ERP-layer EDI | Partner documents map to and from the ERP; Adobe Commerce syncs orders and inventory with the ERP | Merchants whose ERP is the system of record for fulfillment | Adobe Commerce needs a clean ERP integration first |
| Middleware / managed network | A provider (SPS Commerce, TrueCommerce, Cleo, MuleSoft) translates and routes documents | Many diverse partners, frequent onboarding, limited in-house EDI staff | Per-document fees and a dependency on the network |
| Direct connection | You build and maintain AS2/SFTP links and maps to each partner yourself | A handful of high-volume, stable partners | Full control, but you own every map, protocol, and change |
A hybrid is common: a managed network for the long tail of retailers plus direct AS2 links to your two or three largest accounts. Documents move over AS2, SFTP, or a legacy Value-Added Network (VAN), and the choice is usually the partner’s, not yours.
For teams that also route procurement through buyer platforms, EDI often sits alongside B2B PunchOut with Ariba, Coupa, and Oracle. PunchOut handles the catalog-and-requisition side inside the buyer’s procurement tool; EDI handles the resulting order, shipment, and invoice documents. Serious B2B sellers usually need both.
Adobe Commerce B2B and EDI Are Complementary
Adobe Commerce B2B (company accounts, shared catalogs, negotiable quotes, and requisition lists) covers buyers who log in and order themselves. EDI covers buyers whose systems order on their behalf. The same customer can do both: a distributor’s buyers might use your self-service portal for small replenishment while their procurement system fires 850s for scheduled bulk orders.
Because Adobe Commerce already models company accounts and customer-specific pricing, it is a strong system of record for who a partner is and what they pay, even when the transactional documents route through the ERP. Adobe’s own overview of Adobe Commerce B2B features and use cases describes approval rules and hierarchies that pair naturally with an EDI back end, where the storefront governs identity and terms and the ERP governs documents.
If your storefront runs on Hyva, none of this changes the frontend. EDI is a back-office data flow, so Hyva theme development and an EDI program proceed on separate tracks. The frontend team ships a faster storefront while the integration team wires the documents, and the two only meet at order status and inventory display.
A Realistic Implementation Path
A first EDI partner, done properly, is a multi-week project, not a plugin install. The work breaks into predictable phases.
- Read the partner spec, twice. The retailer’s implementation guide defines every required segment, qualifier, and SLA. Map it against your ERP and Adobe Commerce data before writing anything.
- Fix the data first. EDI is unforgiving about UPC/GTIN accuracy, unit-of-measure conversions, and ship-to identifiers. Clean catalog and pricing data in Adobe Commerce and the ERP is a prerequisite, not a nice-to-have.
- Map inbound, then outbound. Get the 850 landing as a clean order and the 997/855 responding correctly before you attempt the 856 and 810.
- Nail the ASN. Model your real pack hierarchy and SSCC label generation against the partner’s carton rules. This is where chargebacks concentrate.
- Test in the partner’s certification environment. Large retailers require you to pass their test cycle before going live.
- Monitor after launch. Track functional acknowledgments, failed maps, and SLA timers. A silent EDI failure becomes a chargeback days later.
Onboarding partner two is faster than partner one, but never free: each retailer has its own map and its own rules.
Common Failure Points to Design Around
- Treating EDI as a Magento problem. The storefront is rarely the right home for document translation. Push it to the ERP or middleware and keep Adobe Commerce focused on commerce.
- Ignoring the acknowledgment layer. Missing 997s and 855s look harmless until a retailer says an order was never confirmed.
- Underestimating the 856. Late or inaccurate ASNs are the most expensive recurring error in retail EDI.
- No error visibility. Without monitoring, the first sign of a broken map is a deduction on a remittance.
- One-off custom maps with no ownership. When the engineer who built a direct connection leaves, an unmaintained map is a liability.
Bemeir builds the Adobe Commerce and Hyva side of these programs and integrates them with the ERP and EDI layer, drawing on a deep bench of technology partners across integration, fulfillment, and compliance. The goal is an architecture where documents flow predictably and the storefront stays fast and focused. You can read more about Bemeir and the way the team works as an extension of a merchant’s own staff at bemeir.com.
While EDI dominates North American retail and distribution, merchants expanding onto other platforms often ask how document exchange looks there. Bemeir also delivers on Shopify and Shopify Plus, BigCommerce, and Shopware, where the same trading-partner requirements usually route through an ERP or a managed EDI network rather than the storefront itself.
FAQ
Does EDI run inside Magento or Adobe Commerce, or somewhere else?
For most B2B merchants it runs at the ERP or in dedicated middleware, not inside the storefront. Adobe Commerce owns catalog, pricing, and self-service ordering, then syncs orders and inventory with the ERP that handles the actual EDI documents. Putting document translation in Magento itself is possible but rarely the cleanest design.
What EDI documents does a B2B seller need first?
Start with the 850 purchase order (inbound), the 997 functional acknowledgment and 855 PO acknowledgment (outbound responses), the 856 advance ship notice, and the 810 invoice. The 846 inventory advice follows once the core order-to-cash loop is stable.
Why are 856 ASN errors so costly?
The advance ship notice must reach the retailer before the shipment does, and its carton-level SSCC labels must match what is physically in each box. Late ASNs commonly incur chargebacks around 3% of invoice value, and inaccurate carton data or missing labels add more, so the ASN is the highest-risk document in the flow.
Should we build direct EDI connections or use a managed network?
Direct connections give you control and avoid per-document fees, but you maintain every map and protocol. A managed network such as SPS Commerce or TrueCommerce onboards many partners quickly with built-in compliance. Many merchants run a hybrid: direct links for their largest partners and a network for the long tail.
How does EDI relate to Adobe Commerce B2B and PunchOut?
They cover different buyers. Adobe Commerce B2B and PunchOut serve buyers who order through a portal or their procurement tool, while EDI serves buyers whose systems transmit orders automatically. Larger sellers typically need all three working together.
Can we add EDI without touching our Hyva storefront?
Yes. EDI is a back-office data flow between your ERP, middleware, and trading partners. A Hyva frontend project and an EDI program run on separate tracks and only intersect at order status and inventory display.
