Understanding the Components of EDI
Electronic Data Interchange enables companies to exchange structured business documents directly between systems. While the concept of EDI is widely known, the technical components behind it are often unclear. We’re here to sort that for you.
EDI is composed of several interconnected elements that work together to exchange data between trading partners reliably. These components include the methods used to transmit messages, the technical structure of the data, the standards that define message content, and the networks that connect businesses.
This guide explains the key components involved in EDI implementations, including:
- How EDI messages are transmitted between systems
- How business data is structured and formatted
- How standards define message structure and meaning
- How trading partner networks support large-scale integrations
Together, these elements enable businesses to automate the exchange of documents such as purchase orders, shipping notices, and invoices across supply chains.
How an EDI Transaction Moves Between Companies
An EDI transaction typically passes through several stages before it reaches the receiving business.
For example, when a retailer sends a purchase order to a supplier, the process might follow these steps:
- The business system generates the document
The retailer’s ERP or purchasing system generates a purchase order that includes product details, quantities, and delivery requirements.
- Data is mapped to an EDI format
Internal system data is translated into a structured format that external systems can interpret.
- The message follows a defined EDI standard
The message format aligns with an EDI standard, such as EDIFACT or ANSI X12, so that both companies can interpret the document consistently.
- The message is transmitted through an EDI connection
Transmission protocols such as AS2 or secure networks transfer the message between partners.
- The receiving system processes the document automatically
The supplier’s EDI system converts the message into its internal format and delivers it to the appropriate application.
The automated exchange eliminates manual data entry and ensures that business documents move quickly and accurately between systems.
What technical aspects are included in EDI?
EDI is not a single system or a single standard. Rather, EDI consists of several layers that interact:
- EDI connections: How data is transferred
- EDI formats: How data is technically structured
- EDI standards: What rules and meanings do the data have?
- Networks & Ecosystems: How partners are connected and organised
Only when these layers work together does EDI function reliably, scalably, and automatically.
EDI connections: How EDI messages are transmitted
EDI connections describe the transport path of data between business partners. They regulate security, encryption, delivery and acknowledgments of receipt but not the content of the data.
AS2
AS2 (Applicability Statement 2) is one of the most widely used EDI transmission protocols.
- Direct point-to-point connection via the Internet
- Encrypted transmission
- Acknowledgement (MDN)
- Commonly used in retail and the consumer goods industry
AS2 offers a high level of control, but requires technical expertise on both sides.
AS4
AS4 is the more modern successor to AS2.
- Service- oriented
- More scalable
- Common in regulated environments (e.g., public sector)
AS4 is used in various sectors, including the energy industry.
SFTP (Secure File Transfer Protocol)
SFTP is a file-based approach.
- Simple implementation
- Widespread
- No native delivery confirmation
SFTP is suitable for simple scenarios, but is less close to the process.
HTTP
HTTP-based transfers are primarily used for simple integrations.
- Flexible
- Often part of individual solutions
- Less standardised than AS protocols
Web services (REST / SOAP)
Web services enable system-level, event-based communication.
- REST: lightweight, modern
- SOAP: highly standardised
- Ideal for real-time scenarios
VAN (Value Added Network)
A VAN is a mediating network between business partners.
- Headquarters Connection
- Monitoring & Support
- Less direct effort for companies
PEPPOL (as a network)
PEPPOL is not a format or a protocol, but a standardised network .
- Clear governance
- Secure participant identification
- Particularly relevant for e- invoicing
TrueCommerce has a PEPPOL access point and can provide expert assistance with any questions you may have about PEPPOL.
EDI Networks and Trading Partner Connectivity
As businesses continue to grow and establish connections with various partners, it can feel overwhelming to manage direct links to each one. That’s where EDI networks come in.
Think of these networks as helpful communication hubs that efficiently route messages between participants while providing essential monitoring, security, and operational support.
Value Added Networks (VAN)
For those navigating the world of trading partnerships, VAN providers can be a real asset. They manage the routing of messages between partners, allowing companies to connect to the network just once and exchange documents with numerous partners seamlessly. The typical services offered are designed to alleviate stress and include:
- message routing and delivery
- transaction monitoring
- partner onboarding
- error handling and support
Open Networks like PEPPOL
Some networks operate under standardised governance models that define how participants exchange documents. The PEPPOL network, for instance, is widely recognised for its role in electronic invoicing and public sector procurement. It lays out clear, common rules for participant identification, document specifications, and message delivery.
By utilising these standardised networks, businesses can integrate with expansive partner ecosystems while avoiding the daunting task of building individual connections to each trading partner.
Data Exchange Formats: How data is technically structured
Formats define the structure of the data, not its meaning.
XML
- Hierarchical
- Humanly readable
- Widespread
JSON
- Lightweight
- API-near
- Increasingly relevant
CSV
- Simply
- Not very standardised
- Limited explanatory power
IDoc
- SAP-specific format
- Widely used in the ERP environment
- Other structured file formats
In principle, any structured format can be EDI-compatible, provided that rules, mapping and validation exist.
EDI Standards: Defining Message Structure and Meaning
EDI standards define how business documents are structured and interpreted among trading partners. These standards ensure that data fields, message segments, and document types adhere to consistent rules.
EDIFACT
EDIFACT is an international standard developed by the United Nations, commonly used in Europe and global trade.
ANSI X12
ANSI X12 is a standard primarily utilised in North America across various industries, including retail, logistics, and healthcare.
TRADACOMS
A standard primarily used in UK across various industries, including retail, logistics, and healthcare.
PEPPOL, BIS 3.0, UBL & PINT correctly classified
- PEPPOL: Network & Governance
- BIS 3.0: Business Specification
- UBL: XML data model
- PEPPOL PINT: International Invoicing Standard
A clean separation is crucial for correct implementations. As Peppol adoption expands across Europe and beyond, it is clear that Peppol is set to become the cornerstone of a truly global, interoperable digital trade network.
Other e-invoice formats
Thera are numerous national and industry-specific e-invoicing formats, which differ in structure, mandatory fields and legal requirements.
Differing legal requirements, ongoing changes, and new versions lead to a high need for adaptation. Companies therefore require flexible EDI architectures that can support multiple formats simultaneously.
A particularly relevant example in German-speaking countries is ZUGFeRD.
ZUGFeRD Invoice and ZUGFeRD Format
ZUGFeRD (Central User Guide of the Forum for Electronic Invoicing Germany) is a widely used e-invoice format in Germany. The terms ZUGFeRD Invoice and ZUGFeRD Format are often used synonymously, but describe different aspects.
The ZUGFeRD format defines the technical and semantic structure of the invoice. It is a hybrid format that combines a PDF/A-3 file with embedded, structured XML data.
ZUGFeRD Invoice refers to the specific electronic invoice that is created, sent and received in this format.
ZUGFeRD thus combines a human-readable PDF invoice with machine-readable data and is particularly suitable for companies that want to gradually transition from paper-based processes to fully automated e-invoice processing.
As with other e-invoicing formats, clean integration into existing EDI systems is crucial here as well.
Why EDI only works as a complete system
EDI only unfolds its full potential if:
- Connections stable
- Correct formats
- Standards implemented cleanly
- Networks are used correctly
Isolated solutions quickly reach their limits. Platform-based approaches enable scalability, transparency, and future-proofing.
Frequently Asked Questions about EDI
Electronic Data Interchange is the structured digital exchange of business documents between trading partners. It allows systems to ‘talk’ to each other directly, improving transaction speed, accuracy, and compliance across industries.
An EDI format describes the technical structure of the data (e.g., XML or CSV). An EDI standard additionally defines the meaning and business logic of the data (e.g., EDIFACT or ANSI X12).
It depends on the use case. AS2 and AS4 are suitable for direct, secure connections, while Value-Added Networks (VANs) or PEPPOL can reduce operational overhead.
Yes. Productive EDI operations require solutions that cover connections, formats, standards, mapping, monitoring, and compliance.
Mini-Glossary: Key EDI Terms
AS2 / AS4: Transmission protocols for the secure, direct exchange of EDI messages between business partners.
Peppol BIS (Business Interoperability Specifications): Technical specifications within the PEPPOL network, e.g. for invoices or orders.
EDI (Electronic Data Interchange): Standardised, automated exchange of structured business data between companies.
EDI format: Technical structure of a file, e.g. XML, JSON, CSV or IDoc.
EDI standard: A rule set that defines the structure, meaning and business logic of EDI messages, e.g. EDIFACT or ANSI X12.
IDoc: An SAP-specific data format for electronic data exchange.
Mapping: Assignment of internal data fields to EDI formats and standards.
MDN (Message Disposition Notification): Acknowledgment of receipt for AS2 transmissions.
PEPPOL: European network for standardised electronic document exchange, especially in the e-invoicing environment.
Peppol PINT (PEPPOL International Invoice): International e-invoice specification based on UBL.
UBL (Universal Business Language): XML-based data model for electronic business documents.
VAN (Value Added Network): An intermediary network for EDI data exchange between many partners.
Conclusion
EDI is not a standalone project, but a strategic foundation for digital B2B processes. Those who understand EDI holistically can automate business processes, meet regulatory requirements, and achieve long-term growth.