Your largest retail customer just sent a 40-page integration spec: AS2, EDIFACT ORDERS/ORDRSP/DESADV, go-live within 90 days. At the same time, your new e-commerce partner wants a REST API with webhooks, OAuth 2.0, and an OpenAPI spec. Both deals close the same quarter.
The CIO mediating this has a real architectural question: keep investing in legacy EDI infrastructure, migrate to modern APIs, or run both protocols through a mediation layer? That choice shapes three-to-five-year budgets, partner onboarding timelines, and your ability to meet European regulatory requirements such as mandatory e-invoicing.
This guide compares both worlds using real data, details the cases where each protocol is non-negotiable, and offers a decision matrix you can apply today.
Why B2B Data Flows Remain an Open Question in 2026
The Fragmentation of Standards: EDIFACT, ANSI X12, Peppol, cXML, JSON/REST
The market never converged on a single protocol. Standards coexist — and are incompatible with each other — depending on sector and geography:
- EDIFACT: the UN standard for international trade, dominant in Europe, Asia, and Latin America. Structured into segments (UNH, BGM, DTM…), it covers dozens of normalised message types.
- ANSI X12: the US standard, mandated by Walmart, Amazon Vendor Central, and most major North American retailers. Not natively interoperable with EDIFACT.
- Peppol (Pan-European Public Procurement On-Line): a European routing infrastructure using the AS4 protocol. The network now counts 4.4 million registered participants in over 100 countries (e-invoice.be, OpenPeppol statistics, June 2026).
- cXML: the e-commerce standard used by SAP Ariba and Coupa purchasing platforms, widely embedded in large-enterprise P2P processes.
- JSON/REST and OpenAPI: the modern API layer used by SaaS platforms, e-commerce marketplaces, and fintechs.
The 2026 paradox: Peppol, which was supposed to unify B2B exchanges through e-invoicing mandates, itself uses a transport layer (AS4) distinct from standard REST APIs — even though it exposes REST endpoints for technical access.
The Core Business Flows at Stake
B2B inter-ERP exchanges follow a well-defined document lifecycle. In EDIFACT, the corresponding messages have been normalised since the 1990s:
| Business flow | EDIFACT message | ANSI X12 |
|---|---|---|
| Purchase order | ORDERS | 850 |
| Order acknowledgement | ORDRSP | 855 |
| Advance Ship Notice (ASN) | DESADV | 856 |
| Invoice | INVOIC | 810 |
| Functional acknowledgement | CONTRL | 997 |
| Product catalogue | PRICAT | 832 |
These are the flows the CIO must route between their ERP and trading partners — regardless of the transport protocol chosen.
Classic EDI: Strengths, Limitations and When It Still Wins
How a VAN and an AS2 Flow Work
Classic EDI infrastructure relies on two transport models:
VAN (Value Added Network): a private network managed by a third-party operator (OpenText Business Network, SPS Commerce, Axway…). Each partner has an electronic mailbox on the VAN. The ERP deposits a message; the operator routes and notifies the recipient. Benefit: one contract gives access to thousands of pre-connected partners. Drawback: per-transaction and per-mailbox pricing.
AS2 (Applicability Statement 2): a point-to-point transport protocol over HTTPS, with no intermediary. The sending ERP pushes directly to the partner’s AS2 endpoint, with digital signatures and a Message Disposition Notification (MDN). Walmart, Amazon Vendor Central, Tesco, and most major global retailers mandate AS2 for their direct EDIFACT exchanges.
Strengths: Proven Reliability and Sector-Mandated Standards
EDI survives because it solves constraints REST APIs don’t natively address:
- Mandatory sector standards: in grocery/retail (GS1/EANCOM), automotive (ODETTE, based on EDIFACT), aerospace (ATA Spec 2000), pharma (HL7/EDIFACT), and maritime logistics, EDI is the standard imposed by major customers. Refusing EDI means refusing the customer.
- Transactional robustness: AS2 flows include non-repudiation mechanisms (digital signatures, signed MDNs) with recognised legal standing in commercial disputes.
- Existing partner network: VANs operate directories of tens of thousands of pre-connected partners. A new supplier found in the directory can be onboarded without any special infrastructure on their side.
Limitations: Costs, Timelines and Rigidity
The drawbacks of classic EDI are well-documented and real:
Onboarding timelines: connecting a new EDI partner through a traditional VAN takes 4 to 12 weeks, depending on mapping complexity and test cycles (Orderful, EDI Partner Onboarding Guide, 2026). Modern cloud-native platforms get that down to an average of 9 days — still longer than a REST API integration.
Cost per transaction: VANs charge per document, with typical rates of $0.01 to $1.00 per transaction depending on volume and message type (BOLD VAN, EDI Cost per Transaction Guide), plus per-partner setup fees in the range of $750 to $2,500 for mapping and testing (Orderful, EDI Pricing Guide 2026).
Mapping rigidity: every partner has their own variant of the EDIFACT standard (mandatory optional segments, proprietary qualifiers, specific business rules). Maintaining mappings is a configuration burden that must be revisited with each version update or partner change.
Batch processing: classic EDI operates asynchronously, with scheduled exchanges (every hour, every four hours, or day+1 for invoices). It provides no real-time visibility into flow status.
Modern REST APIs: Flexibility, Real-Time, and Lower Costs
Webhooks, REST, and Event-Driven: How It Works at the ERP Level
Modern ERPs expose REST APIs natively. A few concrete examples:
- SAP S/4HANA: Business Partner API, Sales Order API, Invoice API, all documented via SAP API Business Hub. Uses OData v4 by default.
- Microsoft Dynamics 365: OData endpoints across all Finance & Operations entities, with webhooks via Azure Event Grid.
- NetSuite: SuiteQL + REST Record API, with OpenAPI documentation available.
- Sage Intacct / Sage X3: REST APIs for transactions, projects, and intercompany flows, with OAuth 2.0 support.
The event-driven model (webhooks) fundamentally changes integration logic: instead of polling every hour, the sending ERP notifies the receiving system in real time on each event (order confirmed, shipment created, invoice issued). Latency drops from H+1 or day+1 to a matter of seconds.
Peppol: The Bridge Between EDI and Modern APIs in Europe
Peppol deserves special treatment because it is simultaneously a routing standard (AS4, close to EDI) and a network that connects to ERPs through modern APIs.
The Peppol network works like an “electronic postal network”: each participant has a Peppol ID (based on VAT number or national identifier), and messages transit between certified Access Points using the AS4 protocol. For an ERP, integration happens via the Access Point’s API (REST/SOAP) — not directly via AS4.
Growth has been remarkable: 4.4 million participants as of June 2026 across more than 100 countries. Belgium’s B2B mandate, which came into force in January 2026, doubled registrations in six months — demonstrating how national mandates can drive mass adoption in a matter of months. Several EU member states are following with their own B2B e-invoicing requirements under the EU’s ViDA directive.
For organisations operating in the EU, Peppol connectivity is increasingly non-negotiable for tax compliance, regardless of whether they come from an EDI or API background.
REST API Limitations in B2B Contexts
REST APIs are not without constraints for inter-enterprise ERP flows:
- Governance and versioning: mandating a REST API to your partners requires maintainable documentation, a versioning policy (v1, v2, deprecation), and support for breaking changes. This governance burden is beyond the technical capacity of many SME partners.
- Heterogeneous implementations: unlike EDIFACT where messages are strictly normalised, each ERP exposes its REST APIs differently. An Odoo integration is not reusable for NetSuite or Dynamics 365.
- Weaker SLAs without an intermediary: EDI VANs offer availability SLAs (99.9%) and contractual penalties. Direct REST integrations shift error handling and retry management onto the integrator.
Comparison Table: Classic EDI vs REST API vs Hybrid Architecture
| Criterion | Classic EDI (VAN/AS2) | REST API | Hybrid Architecture |
|---|---|---|---|
| Partner onboarding time | 4–12 weeks | 1–4 weeks | 2–8 weeks |
| Setup cost per partner | $750–$2,500 | Near zero if ERP-native | $1,000–$5,000 |
| Cost per transaction | $0.01–$1.00 | Near zero | $0.01–$0.30 |
| Sector standards | EDIFACT, ANSI X12 | OpenAPI 3.x | Mixed |
| Real-time capability | No (batch H+1 to D+1) | Yes (webhooks) | Depends on config |
| Legal non-repudiation | Yes (signed MDN) | Partial (API logs) | Yes (via AS2/AS4) |
| Suitable for SME partners | Yes (VAN directory) | Partial (technical capacity) | Yes |
| Maintenance burden | High (mappings) | Moderate (versioning) | Complex |
| EU e-invoice compliance | Via Peppol/AS4 | Via Access Point API | Natively |
Sector Decision Matrix
Grocery and retail: EDI wins. GS1 mandates EANCOM for orders and invoices. Retailers like Walmart, Tesco, and Carrefour onboard suppliers via VAN or direct AS2. Convincing them to switch to REST API is not realistic — their procurement infrastructure has been consolidated on EDI platforms for two decades.
Automotive industry: EDI mandatory (ODETTE, based on EDIFACT). The automotive supply chain is historically one of the largest EDI ecosystems in the world. Stellantis, BMW, Volkswagen, and Toyota impose their EDI standards on all tier-1 and tier-2 suppliers.
Pharma and medical devices: EDIFACT + HL7 for documentary flows, Peppol for e-invoicing. Regulatory compliance demands strict traceability that EDI with signed MDNs delivers better than a REST integration without centralised logs.
E-commerce, marketplaces, and SaaS: REST API dominates. Shopify, WooCommerce, Amazon MWS, Stripe, and cloud ERP platforms like Xero, QuickBooks Online, or Pennylane expose documented REST APIs. Their partners are developers, not EDI operators.
Financial services and fintech: REST API + FAPI (Financial-grade API). PSD2 and Open Banking APIs are natively REST.
Multi-sector mid-market businesses: hybrid architecture. A mid-market industrial business with grocery retail customers (EDI), e-commerce partners (REST API), and EU e-invoicing obligations (Peppol) cannot choose one single protocol.
Hybrid Architecture: The Growing Choice for Mid-Market
iPaaS: The EDI/API Mediation Layer
iPaaS (Integration Platform as a Service) platforms enable managing both protocols from a unified interface with centralised monitoring. The main players in the European market:
- Dell Boomi: historically strong on B2B EDI, widely used in retail and manufacturing. Natively integrates EDIFACT, ANSI X12, Peppol, and connectors for major ERPs.
- MuleSoft (Salesforce): more API-management oriented, but EDI connectors exist. Well suited for organisations already in the Salesforce ecosystem.
- Celigo: cloud-native, SME/mid-market focused, good functionality-to-cost ratio for businesses wanting to unify e-commerce (Shopify) and ERP (NetSuite, SAP) without a dedicated integration team.
- Axway B2Bi (Business Integration): B2B specialist, supporting AS2, AS4, SFTP, EDIFACT, ANSI X12, and REST. Historically used in banking, telecoms, and heavy industry.
iPaaS acts as a universal translator: it receives an EDIFACT message from a legacy partner, transforms it into a JSON object, and injects it via REST API into the internal ERP — or the reverse.
Real-World Hybrid Architecture Examples
Mid-market manufacturer with 200 partners: AS2/EDIFACT flows for 30 major customers (grocery, automotive); REST API for 40 e-commerce and SaaS partners; Peppol for all supplier and customer invoices. A single iPaaS platform centralises monitoring, alerts, and error recovery.
Pharmaceutical distributor: DESADV EDIFACT for deliveries to pharmacies (standard mandated by purchasing groups); REST API for orders from hospital procurement platforms; Peppol for e-invoicing since mandatory compliance kicked in.
Peppol: The Standard Progressively Unifying Both Worlds
Peppol’s ambition is precisely to solve the fragmentation problem. The network routes structured documents (UBL, PEPPOL BIS Billing 3.0) via AS4, but Access Points expose REST APIs to ERPs. An ERP integrating with its Peppol Access Point speaks REST, even though inter-Access-Point transmission uses AS4.
It’s an elegant abstraction model: the ERP is unaware of the transport protocol (AS4); it sees only a documented REST API. The Access Point manages network compliance.
This model is becoming structurally important as EU mandatory e-invoicing requirements expand — France, Belgium, Germany, and several other member states are rolling out B2B obligations over 2026–2028. Organisations that have not yet established Peppol connectivity need to factor this into their B2B integration architecture planning, whether they come from the EDI world or the API world.
5 Decisive Questions Before Choosing
1. What protocols do your most important partners impose?
If your 10 largest customers or suppliers mandate EDI, the question is settled: you must maintain EDI infrastructure. REST APIs will be complementary, not a replacement.
2. What is your primary sector?
Grocery, automotive, aerospace, pharma: EDI non-negotiable. E-commerce, SaaS, fintech: native REST API. Mixed industrial or multi-sector distribution: hybrid mandatory.
3. What is your monthly B2B transaction volume?
Below 1,000 transactions per month, EDI per-transaction costs are marginal. Above 50,000 transactions per month, the three-year cost gap between EDI via VAN and REST API becomes significant.
4. Do you have the in-house capacity to maintain both protocols?
Maintaining EDI infrastructure (mappings, message versions, partner onboarding) requires specialised skills that many mid-market organisations no longer have internally. If the team is aligned on modern APIs, outsourcing EDI to a managed operator (EDI-as-a-service) is often more cost-effective than rebuilding in-house.
5. Where do you stand on Peppol/e-invoicing compliance?
If your ERP is not yet connected to a Peppol Access Point and you operate in a market with an active or incoming e-invoicing mandate, compliance becomes your primary constraint. It should be driving your B2B integration architecture decisions — not the other way around.
For further reading on ERP integration architecture, see our ERP API integration testing playbook from J-90 to go-live and our complete CRM-ERP integration architecture guide. If you’re also looking at the EDI-to-Peppol migration path specifically, our operational guide to ERP API governance covers the governance framework in depth.
