ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

B2B vs EDI

Every EDI exchange is a B2B exchange. The reverse is not true. This page draws the exact boundary between the two scopes, and gives practical rules to decide whether your integration project counts as strict EDI — or just plain B2B.

B2B — a broad scope

By economic convention, B2B (Business-to-Business) covers any commercial relationship where both ends are organisations — as opposed to B2C (Business-to-Consumer), which addresses an individual, and B2G (Business-to-Government), which addresses a public administration. In that sense the B2B perimeter is deliberately broad: it includes both sending an email with an attachment and calling a REST API between two partner information systems.

The topic of this page is more technical: inside the B2B perimeter, which exchanges actually qualify as EDI, and which do not? Answering that requires categorising exchange modalities.

Three families of B2B exchanges

The overwhelming majority of modern technical B2B flows fall into three big families. Each corresponds to a different integration mode, a different degree of standardisation, and a different level of automation.

1. File exchange (file-share)

The oldest and simplest modality: a file is dropped by the sender into a shared directory (SFTP, FTPS, S3, OneDrive, SMB) and pulled or pushed to the recipient. Format may be CSV, XLSX, free XML, PDF — the content is not bound by a public standard and machine reading depends on a bilateral convention documented out of band. Usually no formal acknowledgment: if something goes wrong, you find out at the next on-call. This mode is still very common for internal flows, reporting flows, and asynchronous reconciliations.

Is it EDI? Not in the strict sense. None of the three EDI characteristics — normalised structure, mutual identification, two-way acknowledgment — is mechanically guaranteed by an SFTP drop. It may tend towards EDI when the conventions are rigorous, but it remains a private convention.

2. APIs (REST, GraphQL, SOAP)

Since the early 2010s, the REST API has colonised the B2B perimeter. One partner exposes a URL, the other calls it with POST/GET and a JSON or XML payload, receives a synchronous response, and the chain continues. The modality is application-to-application by design, hence machine-readable; it usually includes a synchronous acknowledgment (the HTTP 200/4xx/5xx code) and often strong mutual authentication (OAuth 2.0, mTLS, JWT). It is the default option for every recent marketplace, every payment provider, every real-time catalogue flow, and most SaaS-to-SaaS integrations.

Is it EDI? Not automatically, but it can be. The cXML case is precisely that: an HTTPS API carrying XML documents standardised by Ariba, with mutual identification through a Network Identity and a cXMLResponse acknowledgment. PEPPOL, on its eDelivery side, is also an API in architectural terms (SOAP over AS4), and it is EDI. Conversely, a marketplace's custom REST API is generally not EDI because the payload structure belongs to the publisher.

3. EDI in the strict sense

EDI is the sub-family where all three properties are reunited:

  1. The content is structured by a public standard — EDIFACT, X12, cXML, UBL — versioned and maintained by a standards body independent of any publisher (UN/CEFACT, ANSI ASC X12, OASIS, OpenPEPPOL).
  2. Parties are identified by a stable international scheme — GLN, DUNS, SIRET, PEPPOL identifier — that survives changes of publisher or infrastructure.
  3. Every message yields a formalised two-way acknowledgment: CONTRL in EDIFACT, 997/999 in X12, cXMLResponse in cXML, ApplicationResponse in UBL — doubled by a cryptographic MDN at the transport layer for AS2.

The transport channel may vary widely — SFTP, AS2, AS4, OFTP2, HTTPS API — but the payload, identification and acknowledgment remain standardised.

EDI as a subset of B2B

Visually, you can picture EDI as the hard core of technical B2B: a sub-area where formalisation is maximal, automation is total, and portability across publishers is guaranteed. The further you move from the centre, the more you meet B2B exchanges that are legitimate but do not qualify as EDI in this industry's jargon métier.

When to choose what?

Use case Recommendation Why
Order/delivery/invoice between a major retailer and a supplier EDI (EDIFACT D.96A + AS2 or OFTP2) High volume, audit requirement, known partners, sector already standardised via EANCOM.
Interactive product catalogue between a buyer and a marketplace cXML punchout The SAP Ariba/Coupa ecosystem mandates cXML; no benefit to inventing a protocol.
B2B/B2G invoice in Europe PEPPOL BIS Billing 3.0 (UBL + AS4) EN 16931 framework, converging national mandates: France 2026/2027, Belgium Jan 1, 2026, Germany 2025.
Recent SaaS-to-SaaS integration (CRM, payment, marketing) REST/GraphQL API No established business standard, many partnerships, responsiveness needed: API beats EDI.
Internal reporting or ad-hoc exchange with a single partner SFTP file Minimum setup cost, freely negotiated format, low volume. No value in mandating an EDI standard.

Common mistakes

  • "We do EDI" — when actually doing SFTP CSV drops. The vocabulary shortcut is fine internally, but becomes toxic when a buyer requires real EDI: they expect CONTRL acknowledgments, EDIFACT or X12 messages, and a qualified secure protocol.
  • "Our REST API replaces EDI". True in some cases (cXML, PEPPOL AS4), false in most: a custom REST API is not an industry standard. If your major retailer partner requires an X12 850, your POST /orders JSON does not replace it.
  • "We have a mapping, so we have a standard". An integration mapping has value only for the sender-recipient pair; a standard is what can be reused with a third partner without renegotiating the format.

Further reading