Standards & protocols.

Business documents move between companies in formats and over protocols that rarely surface outside an integration team. The vocabulary is dense, applied inconsistently, and full of near-identical names that mean different things. This guide states what each standard and protocol is, what it does, and what adopting it commits you to.

It is written for the people who own those decisions: platform and engineering leaders establishing what their systems have to support, and the teams who run the connections once they are live. It covers the document standards your trading partners send, the transport protocols that carry them, the European e-invoicing rules now in force, and the interfaces used to reach document exchange programmatically. Version tables with their sources follow at the end.

A document standard defines what the content means: which fields exist, what order they appear in, and how a purchase order is distinguished from an invoice. Two companies agree on one before they can trade electronically, and in most relationships the larger partner decides which.

X12

Published by ANSI ASC X12 and dominant in North America. Each document type carries a number rather than a name: an 850 is a purchase order, an 810 an invoice, an 856 a shipping notice. Those numbers are how the documents are referred to in practice, including in partner requirements. X12 versions are written as six digits, explained in the reference section below.

EDIFACT

The United Nations standard, and what most international and European trade runs on. It does the same job as X12 with different naming: document types carry short alphabetic names such as ORDERS and INVOIC. Organizations trading across both regions routinely support both, on opposite sides of the same supply chain.

Tradacoms

An older UK retail standard, largely superseded by EDIFACT. Retail relationships outlast the standards they started on, so it persists in established grocery and general merchandise connections.

VDA

The standard set by the German automotive industry association for its own supply chain. Automotive is the sector most likely to require a specific regional standard rather than accept a general one. A supplier into German manufacturing can expect to support VDA alongside whatever it already runs.

cXML and ebXML

Both are XML-based. cXML came out of electronic procurement and appears most often around purchasing and catalog workflows. ebXML is a broader framework for business messaging, and its messaging specification is also the foundation of the AS4 transport protocol described below.

Non-EDI formats

A substantial share of business data moves as XML, JSON, CSV, fixed-width flat files, or a format a trading partner defined and never documented. These have no governing body and no version to cite, but they arrive through the same connections and carry the same commercial consequences when they fail. The format a partner sends is rarely negotiable, which is why translation between formats is a standing requirement rather than a migration task.

The document standard says what is in the file. The transport protocol determines how it reaches the other company and whether the sender can prove it arrived. The two are independent: the same X12 purchase order travels over any of the methods below.

AS2

The most widely deployed protocol for direct EDI exchange, and the one large retailers most often mandate. It moves documents over HTTP with encryption and digital signatures, and returns a signed receipt, the MDN, which gives the sender cryptographic proof of delivery. That receipt is why AS2 displaced earlier methods: it settles disputes about whether a document was sent. AS2 is defined in RFC 4130, and a revision is active at the IETF.

AS4

The newer relative of AS2, built on a web services messaging framework rather than plain HTTP, and published as a profile of the ebXML messaging specification. It is the transport behind Peppol, so adoption follows European e-invoicing obligations rather than independent protocol selection.

oFTP

The Odette File Transfer Protocol, created for the European automotive industry and still standard within it. Like VDA on the format side, it is a sector requirement rather than a general-purpose choice.

X.400

A messaging standard predating the modern web, still in service across banking, aerospace and parts of government. It is rarely selected for new connections, but the systems that depend on it are expensive to replace and continue to work, so support for it remains a real procurement criterion in those sectors.

SFTP, FTP and HTTP/HTTPS

General-purpose file transfer and web protocols, used constantly in B2B because they are universally available. They move a file reliably but carry no concept of a business document and no signed receipt, so delivery assurance and audit have to be built around them rather than assumed from them.

Value-added networks

A VAN is a delivery model rather than a protocol: a network that accepts a document and takes responsibility for reaching the recipient, whatever protocol that recipient uses. It is the oldest approach in EDI and remains the practical answer to a trading partner whose technical requirements you cannot influence.

Managed file transfer

A category rather than a standard, covering files that are not EDI documents at all, such as artwork, engineering drawings, reports and bulk data, handled with the same controls and audit trail as the EDI traffic beside them.

Invoicing is where B2B document exchange stops being a private arrangement between two companies and becomes a matter of law. Europe is where most of that change is happening, and the obligations arrive on fixed dates rather than on your roadmap.

Peppol

Peppol is a network, not a document standard. Participants connect through accredited access points, and any participant can reach any other without negotiating a separate connection per relationship. That is the structural difference from point-to-point EDI, where every partner is its own onboarding project. OpenPeppol governs the network and publishes the specifications an access point must implement; those are listed with their versions and effective dates in the reference section.

Peppol's transport is a profile of AS4, which is itself a profile of the ebXML messaging specification. Anything claiming Peppol capability inherits both layers.

EN 16931 and its legal anchor

The European standard on electronic invoicing is EN 16931, identified in Commission Implementing Decision (EU) 2017/1870, which fulfilled the request made under Article 3(1) of Directive 2014/55/EU. That is the authoritative legal path to it, and the citation to use in preference to a vendor summary. No dated edition is given here, because that detail could not be confirmed at the publishing body.

ViDA

ViDA is Council Directive (EU) 2025/516 of 11 March 2025 amending Directive 2006/112/EC as regards VAT rules for the digital age. It is in force and it is staged. Provisions take effect on entry into force, then on 1 January 2027, then on 1 July 2028. A further article carries the heading "Amendments to Directive 2006/112/EC with effect from 1 July 2030." Scope compliance work against the article text, which the directive citation below leads to directly.

Two provisions in the directive shape system requirements. Electronic invoicing becomes the default system for issuing invoices, with Member States still able to authorize other invoices for domestic supplies. And the definition of an electronic invoice aligns with Directive 2014/55/EU: issued, transmitted and received in a structured electronic format allowing automated and electronic processing, with hybrid invoices qualifying where all reportable data is carried in the structured part.

The sections above describe how documents move between companies. The separate question for anyone building on top of that exchange is whether setting up a trading partner, checking whether a document arrived, or pulling an audit trail is something a person does in a portal or something your software does directly. That distinction determines whether onboarding scales with headcount or with code.

SOAP and REST

The two API styles in common use. SOAP is older, strongly typed and described by a formal contract, which is why it persists where an interface has to stay unambiguous and stable for years. REST is lighter, uses ordinary web verbs, and is what most current integrations expect. The evaluation question is not which style a platform wraps its operations in, but which operations it exposes at all.

Webhooks

A webhook reverses the direction of the question: instead of polling to ask whether something has happened, your system is notified when it does. For document exchange that is the difference between discovering a failed acknowledgement on a schedule and learning about it as it happens.

Model Context Protocol

MCP is an open protocol for connecting AI assistants and agents to external systems and data. It changes who the consumer of an interface is: an agent can be given the same view of network state a person would get from a dashboard. Current B2B implementations are typically read-only, answering questions about traffic and partner status rather than changing configuration, which is the appropriate starting posture for infrastructure carrying other companies' commercial documents.

Each table names its source and the date it was read, so any figure here can be checked against the body that publishes it.

X12 version numbers

X12 versions are six digits, and the digit positions carry specific meaning. In 007050 the release is 05, the fourth and fifth digits. Read 005010 the same way: version 005, release 01.

Peppol specification register

The specifications an access point must implement, with the version and the date each became valid.

Verified 18 September 2026. The X12 release schedule, the IETF Datatracker entry for draft-ietf-ediint-rfc4130bis, the OASIS AS4 Profile of ebMS 3.0, the OpenPeppol eDEC specification register, and Council Directive (EU) 2025/516 were each read at the publishing body's own site on that date. Standards move: check any version number or date against the source named beside it before relying on it for a compliance decision.