EDI systems are the software that lets two businesses exchange purchase orders, shipment notices and invoices computer to computer, in a structured format both sides have agreed, without anyone rekeying a line. An EDI system takes an order out of your ERP, translates it into a standard such as X12 or EDIFACT, sends it to a trading partner over a secure channel, and turns the reply back into records your own systems understand.
That core job has barely changed since the 1980s, but the market around it has. In 2026 the choice of EDI system is being reshaped by usage-priced cloud services, API-first platforms that speak JSON, and a wave of e-invoicing mandates. Belgium made structured e-invoices compulsory between VAT-registered businesses on 1 January 2026, Poland’s KSeF became mandatory in February and April 2026, France’s reform starts on 1 September 2026, and the UK plans to mandate e-invoicing for VAT invoices from April 2029.
This guide replaces our shorter 2025 overview of EDI systems and software solutions. It explains what an EDI system does, the documents, standards and protocols involved, the six main types of EDI software, what published prices look like, and how to choose and implement one. If EDI is part of a wider programme of business process automation, the selection and implementation sections show where it fits.
Table of contents
- What Is an EDI System?
- How an EDI System Works, Step by Step
- The Documents an EDI System Exchanges
- EDI Standards in 2026: X12, EDIFACT, EANCOM and TRADACOMS
- How an EDI System Connects: AS2, AS4, OFTP2, SFTP, VANs and APIs
- Why E-Invoicing Mandates Shape Your EDI System Choice in 2026
- The Six Types of EDI System in 2026
- EDI System Vendors to Shortlist in 2026
- What an EDI System Costs
- How to Choose an EDI System
- Implementing an EDI System: A Practical Plan
- EDI vs API: Does Every Business Still Need an EDI System?
- Common EDI System Mistakes to Avoid
- EDI System FAQs
- References
What Is an EDI System?
EDI stands for electronic data interchange: the computer-to-computer exchange of business documents in a standard electronic format between trading partners. The concept is simple. The engineering that keeps it running across hundreds of partners, standards and versions is not.
A Plain Definition
An EDI system is the combination of software, standards, connections and partner agreements that makes that exchange happen automatically. The word “system” matters. A working EDI system is never just a translator program; it also includes the maps for each partner, the communication channels, the monitoring, and the people who fix rejected documents when something changes.
The defining feature is structure. An emailed PDF invoice is electronic, but a person or an extraction tool still has to read it. An EDI invoice arrives as data, segment by segment, so the buyer’s EDI system can post it straight into accounts payable and match it against the order and the goods received.
What an EDI System Replaces
Before EDI, a retailer’s order went out by post, phone or fax, and a clerk at the supplier typed it into the order system. The shipment details and the invoice travelled back the same way and were keyed in again at the other end. Every rekey is a chance to transpose a quantity or a price, and every delay is another day of stock and cash in limbo.
An EDI system removes the rekeying on both sides. The buyer’s purchasing system creates the order, the supplier’s EDI system receives it and creates a sales order, and every later document refers back to the same order number without anyone typing it twice. Most businesses still keep a few manual channels for very small partners, which is why the web EDI portals covered later still exist.
Where an EDI System Sits in Your Architecture
Picture three layers. At the centre are your business applications: ERP, warehouse management, transport management and finance. At the edge are your trading partners, each with their own systems and their own EDI requirements. The EDI system sits between the two, owning translation, validation, partner configuration and transport.
That position is why an EDI system project is really an integration project. The quality of the connection to your ERP decides whether EDI saves labour or simply moves the typing from order entry to a screen full of rejected documents. Treat it with the same discipline as any other integration, including clear vendor management when an outside provider runs part of it.
How an EDI System Works, Step by Step
Every EDI system performs the same five steps for each document, whether it runs on a mainframe or behind a cloud API. Knowing them makes vendor demonstrations easier to judge, because each product automates some of the steps and quietly leaves the rest to you.
Step 1: Extract the Data From the Business Application
The process starts inside your own systems. A purchase order is approved in the ERP, a shipment is confirmed in the warehouse system, or an invoice is posted. The EDI system collects that data through a database query, an export file, a prebuilt connector or an API call. The cleaner and more complete the source data, the less work every later step has to do.
Step 2: Map and Translate
Your ERP’s idea of an order does not match X12’s or EDIFACT’s. Mapping is the rule set that says which field in your system becomes which element in the standard, and it is usually specific to each trading partner, because partners use different subsets, codes and qualifiers. Translation software applies the map and produces the standard document. Mapping is where most EDI system effort, cost and fragility lives.
Step 3: Envelope and Validate
EDI documents travel inside envelopes. In X12, an interchange envelope (the ISA and IEA segments) wraps a functional group (GS and GE), which wraps each transaction set (ST and SE). EDIFACT uses UNB and UNZ around the interchange and UNH and UNT around each message. The EDI system fills in sender and receiver identifiers and control numbers, then validates the result against the standard and the partner’s implementation guide before anything leaves the building.
Step 4: Transmit to the Trading Partner
The validated document is sent over an agreed channel: AS2 over the internet, SFTP, a value-added network, OFTP2 in the automotive sector, AS4 in the Peppol network, or an HTTPS API. The channel handles delivery and encryption and, for AS2 and OFTP2, returns a signed receipt that proves the partner received the file.
Step 5: Acknowledge, Reconcile and Handle Errors
The receiving EDI system checks the document and returns an acknowledgement. In X12 that is usually a 997 Functional Acknowledgment or a 999 Implementation Acknowledgment; in EDIFACT, a CONTRL message. Business replies follow: an order acknowledgement, then a shipment notice, then an invoice. A good EDI system tracks the whole chain, flags documents that were never acknowledged, and routes each error to someone who can fix it the same day.
The Documents an EDI System Exchanges
Retail and distribution EDI revolves around a short list of documents. X12 publishes a supply chain transaction flow that puts them in order, starting with item data before the sale and ending with payment after delivery.
The Order-to-Cash Cycle in X12
Before any order, a seller can send an 832 Price/Sales Catalog so the buyer’s systems know the items and prices. The buyer then sends an 850 Purchase Order, and the seller answers with an 855 Purchase Order Acknowledgment that accepts the order or reports changes. When goods ship, the seller sends an 856 Ship Notice/Manifest, which X12 describes as the transaction that ties the order to the delivery process. The seller then sends an 810 Invoice, and the buyer can pay with an 820 Payment Order/Remittance Advice.
The 856 deserves special attention. X12 notes that an accurate shipment notice gives the buyer a short cut through receiving, matching incoming cases and pallets to open orders by their markings. When the notice is late or wrong, that short cut disappears and someone counts stock by hand, which is why retailers set strict rules for it and why it is the document most worth testing in any EDI system.
EDIFACT and EANCOM Equivalents
Outside North America the same cycle usually runs on UN/EDIFACT messages, and in retail typically through GS1’s EANCOM subset. The table maps the common documents across the two families, so an EDI system that serves partners on both sides of the Atlantic can be specified in one place.
| Business document | X12 transaction set | UN/EDIFACT message | Usually sent by |
|---|---|---|---|
| Product and price catalogue | 832 Price/Sales Catalog | PRICAT | Seller |
| Purchase order | 850 Purchase Order | ORDERS | Buyer |
| Order acknowledgement | 855 Purchase Order Acknowledgment | ORDRSP | Seller |
| Shipment notice | 856 Ship Notice/Manifest | DESADV | Seller |
| Invoice | 810 Invoice | INVOIC | Seller |
| Remittance advice | 820 Payment Order/Remittance Advice | REMADV | Buyer |
| Stock position | 846 Inventory Inquiry/Advice | INVRPT | Seller |
| Syntax receipt | 997 Functional Acknowledgment or 999 Implementation Acknowledgment | CONTRL | Receiver |
Acknowledgements Are Part of the Deal
It is tempting to treat 997 and CONTRL messages as background noise. They are the only proof that the other EDI system accepted your file. Trading partner agreements often set a window for returning them, and a missing acknowledgement is frequently the first sign that a map broke after a partner changed its requirements. Alerting on overdue acknowledgements is one of the cheapest controls any EDI system can have.
EDI Standards in 2026: X12, EDIFACT, EANCOM and TRADACOMS
A standard defines the syntax, segments and data elements a document must follow. Which ones your EDI system needs depends almost entirely on your trading partners, your industry and your geography, not on which standard is technically better.
X12 and Its Annual Release Cycle
X12 is the dominant standard in North America across retail, transport, finance and healthcare. X12 says its EDI Standard is published once a year, usually in January. Its release schedule shows version 008060 approved for stakeholder ballot in December 2024 and available in February 2025, with 008070 scheduled for its Glass viewer in March 2026. Trading partners pin a version in their implementation guides, so a new release does not force an immediate EDI system upgrade.
Healthcare EDI Under HIPAA
US healthcare runs on X12 transactions adopted under HIPAA: 837 claims, 835 payment and remittance advice, 270 and 271 eligibility, 276 and 277 claim status, 278 authorisations, 834 enrolment and 820 premium payments. These are mandated at the 005010 version. X12 has published 008060 versions of all the HIPAA-mandated implementation guides, but a healthcare EDI system must keep producing the mandated 005010 versions until the regulator adopts a newer one.
UN/EDIFACT and GS1 EANCOM
UN/EDIFACT is the United Nations standard for electronic data interchange in administration, commerce and transport, maintained through UNECE and used widely in Europe and in international trade. GS1 EANCOM is a subset of UN/EDIFACT for retail and consumer goods, based on directory D.01B with syntax version 3. It keeps only the elements GS1 users need and relies on GS1 identifiers such as GTINs, GLNs and SSCCs. GS1 also maintains GS1 XML, and says new message development now defaults to XML.
TRADACOMS in UK Retail
TRADACOMS was developed in the early 1980s for UK retailers and wholesalers. According to GS1 UK, no new TRADACOMS message types have been developed since 1998, and GS1 UK stopped supporting the standard on 1 July 2017, advising new users to adopt EANCOM or GS1 XML wherever possible. Some long-established UK supplier relationships still run on it, so an EDI system for UK grocery or wholesale may need TRADACOMS maps alongside EANCOM ones.
Peppol BIS Billing and EN 16931
E-invoicing has added another family. Peppol BIS Billing 3.0 is built on the European e-invoicing standard EN 16931, inheriting its element names, and is published as UBL invoice and credit note syntax, with a May 2026 release current at the time of writing. It is the format Belgian businesses now exchange over Peppol. Supporting X12 or EDIFACT does not mean an EDI system supports Peppol, so check whether a vendor is a Peppol service provider or works with one.
| Standard | Main users | Maintained by | Status in 2026 |
|---|---|---|---|
| X12 | North American retail, transport, finance and US healthcare | Accredited Standards Committee X12 | Annual releases; 008060 available since February 2025; HIPAA fixed at 005010 |
| UN/EDIFACT | Europe, international trade, transport and customs | UNECE and UN/CEFACT | Current, published as directories |
| GS1 EANCOM | Retail and consumer goods worldwide | GS1 | Current; based on D.01B; GS1 XML preferred for new messages |
| TRADACOMS | Long-standing UK retail and wholesale links | No active maintainer | Legacy; no new messages since 1998; GS1 UK support ended 2017 |
| Peppol BIS Billing 3.0 | E-invoicing in Peppol countries | OpenPeppol | Current; May 2026 release; based on EN 16931 |
How an EDI System Connects: AS2, AS4, OFTP2, SFTP, VANs and APIs
The standard defines what a document says; the protocol defines how it travels. Most EDI system estates need several protocols at once, because a single business often has partners on different channels and cannot dictate a switch to any of them.
AS2
AS2, defined in RFC 4130 in July 2005, exchanges structured business data securely over HTTP instead of email. It uses S/MIME to sign and encrypt messages and returns a signed Message Disposition Notification (MDN) as a receipt, either in the same HTTP response or asynchronously. The signed MDN gives both sides proof of delivery, which is why AS2 is widely used for direct links with large retailers. Running AS2 means managing certificates, and an expired certificate is a classic cause of a sudden EDI system outage.
AS4 and the Peppol Network
AS4 is a profile of the OASIS ebMS 3.0 messaging standard. The European Commission’s eDelivery AS4 profile builds on it, and Peppol’s own AS4 specification follows that profile for exchanges between access points. Peppol uses a four-corner model: your software hands a document to your service provider’s access point, which delivers it to your partner’s access point, which passes it on to your partner. You connect once and can reach every registered participant.
OFTP2
OFTP2, the ODETTE File Transfer Protocol version 2, was published as RFC 5024 in November 2007 for EDI between trading partners. ODETTE is the European automotive industry organisation, and the protocol is a fixture of that supply chain. It runs over TLS, encrypts, signs and compresses files using Cryptographic Message Syntax, and returns signed receipts. If you supply a European vehicle manufacturer, confirm OFTP2 support early in any EDI system evaluation.
SFTP
SFTP moves files over SSH. It is simple, inexpensive and supported almost everywhere, which makes it popular for links with logistics providers, marketplaces and smaller partners. It does not return a business-level receipt the way an AS2 MDN does, so the EDI system has to rely on functional acknowledgements to confirm that a file was processed rather than merely delivered.
Value-Added Networks
A value-added network (VAN) is a managed network that acts as a mailbox service between trading partners. You connect to the VAN once, and it routes documents to partners on it or on networks it interconnects with. VANs add tracking, storage and support. OpenText describes its Trading Grid as the world’s largest VAN, and IBM sells a Sterling B2B Integration VAN. The trade-off is ongoing network charges that grow with your trading volume.
APIs and JSON
Newer platforms put an HTTPS API in front of the EDI system. Your application sends and receives JSON, and the platform converts it to and from X12 or EDIFACT for partners who still require EDI. Orderful’s API converts JSON payloads into EDI formats, and AWS B2B Data Interchange transforms EDI documents into JSON or XML for your applications. This does not remove EDI from the picture; it moves translation into a managed service and gives developers a familiar interface.
| Protocol | Defined in | Proof of delivery | Typical use |
|---|---|---|---|
| AS2 | RFC 4130, July 2005 | Signed MDN receipt | Direct retail and distribution partners |
| AS4 | OASIS ebMS 3.0 AS4, profiled by EU eDelivery and Peppol | Signed receipts | Peppol e-invoicing and government exchanges |
| OFTP2 | RFC 5024, November 2007 | Signed receipts | European automotive supply chains |
| SFTP | SSH file transfer | None at protocol level | Logistics providers, smaller partners and batch files |
| VAN | Commercial network service | Network tracking and mailbox reports | Reaching many partners through one connection |
| HTTPS API | Vendor-defined, usually JSON | API responses and webhooks | API-first EDI inside your own applications |
Why E-Invoicing Mandates Shape Your EDI System Choice in 2026
For decades, EDI was a commercial choice imposed by large customers. E-invoicing mandates turn part of it into a legal requirement set by tax authorities, and they often prescribe networks and formats that a traditional EDI system does not speak out of the box.
The EU: VAT in the Digital Age
The EU adopted its VAT in the Digital Age (ViDA) package on 11 March 2025, and it entered into force on 14 April 2025. The European Commission says Member States are able to introduce mandatory e-invoicing under specific conditions, that digital reporting requirements will affect cross-border B2B transactions from 1 July 2030, and that by 1 January 2035 Member States with domestic real-time reporting must align their systems with the EU model.
Belgium and Poland Are Already Live
Belgium’s official e-invoicing site says that since 1 January 2026 all Belgian enterprises liable to VAT have had to use structured electronic invoices with each other, exchanged through the decentralised Peppol network. Invoices to private individuals are outside the sending obligation.
Poland’s Ministry of Finance made KSeF, the National e-Invoice System, mandatory from 1 February 2026 for businesses whose 2024 sales exceeded PLN 200 million, and from 1 April 2026 for all other businesses. Several transitional simplifications, including the option to issue paper invoices below PLN 10,000 a month, end on 31 December 2026. An EDI system serving Polish entities therefore needs a KSeF route, not just a partner connection.
France and Germany Are Next
France’s official business portal says every company must be able to receive e-invoices from 1 September 2026. Large and mid-sized companies must also issue them from that date, while SMEs and micro-enterprises have until 1 September 2027. Invoices flow through approved platforms rather than directly between trading partners’ EDI systems.
Germany’s Federal Ministry of Finance says all domestic businesses have had to be able to receive e-invoices since 1 January 2025. Issuers may keep sending other invoices until 31 December 2026, or until the end of 2027 if prior-year turnover was up to €800,000. Accepted formats include EN 16931 invoices, XRechnung and ZUGFeRD from version 2.0.1, and EDI invoices that do not yet meet the e-invoice rules can continue until the end of 2027.
The United Kingdom: April 2029
The UK government’s November 2025 consultation response confirmed mandatory e-invoicing for VAT invoices from 2029, covering business-to-business and business-to-government invoices but not sales to consumers, using a decentralised model. HMRC’s 2026 transformation roadmap update puts the start at April 2029 and names Peppol as the core interoperability network, with a detailed implementation roadmap due at Budget 2026. Any EDI system you buy for UK entities now should have a credible Peppol path.
| Jurisdiction | Milestone | Date | What it asks of an EDI system |
|---|---|---|---|
| Belgium | Structured B2B e-invoices compulsory | 1 January 2026 | Peppol invoices through a service provider |
| Poland | KSeF mandatory above PLN 200 million sales | 1 February 2026 | Invoices submitted through the national KSeF platform |
| Poland | KSeF mandatory for all other businesses | 1 April 2026 | Same route for every remaining taxpayer |
| France | All companies receive; large and mid-sized issue | 1 September 2026 | Connection to an approved platform |
| Germany | Transition ends for issuers above €800,000 | 1 January 2027 | EN 16931 formats such as XRechnung or ZUGFeRD |
| France | SMEs and micro-enterprises issue | 1 September 2027 | Same obligation extends to small firms |
| Germany | Transition ends for all issuers | 1 January 2028 | Non-compliant EDI invoice option has ended |
| United Kingdom | Mandatory e-invoicing for VAT invoices | April 2029 | Peppol as the core network |
| European Union | ViDA cross-border digital reporting | 1 July 2030 | Structured invoicing and reporting for intra-EU B2B sales |
Counted from the publication date of this guide, 14 September 2026, the next milestones are months away rather than years, which leaves little slack for an EDI system selection that has not started:
EDI and E-Invoicing Are Related, Not Identical
A classic EDI system already sends invoices electronically, but that does not make it compliant everywhere. Mandates typically require a specific format, such as EN 16931, Peppol BIS, XRechnung or KSeF’s own structure, and a specific route, such as Peppol, the KSeF platform or an approved platform in France. When you evaluate an EDI system in 2026, ask which mandates it covers natively, which it covers through a partner, and who carries the risk when a tax platform rejects an invoice.
The Six Types of EDI System in 2026
EDI software is sold in six broad shapes. Most vendors now offer more than one, so treat these as operating models rather than vendor categories. The right EDI system type depends on who will run the maps, how many partners you have, and how deeply you want EDI woven into your own applications.
1. Web EDI Portals
A web EDI portal lets a small supplier key in or view EDI documents in a browser, and the provider converts the screen entries into EDI for the trading partner. TrueCommerce, for example, sells a web EDI portal as an entry-level option that needs no hardware, software or prior EDI knowledge. A portal meets a customer’s requirement quickly, but staff still rekey orders into their own systems, so it is a compliance tool rather than a fully automated EDI system.
2. Full-Service or Managed EDI
With full-service EDI, the provider builds and maintains maps, connections, testing and monitoring on your behalf. SPS Commerce positions its Fulfillment product this way, saying it handles mapping, connectivity, testing and monitoring for its customers, and TrueCommerce and OpenText also sell managed services. This model suits suppliers with many retail partners and little in-house expertise, at the price of recurring fees and less direct control over change.
3. On-Premises Translators and B2B Gateways
Enterprises with high volumes, strict data residency rules or complex routing often run their own B2B gateway. IBM Sterling B2B Integrator is the long-standing example: IBM describes it as a single B2B gateway available on-premises and in hybrid cloud, supporting protocols including SFTP, HTTP/S and the AS1 to AS4 applicability statements. You get full control of the EDI system and pay for it with infrastructure, upgrades and specialist staff.
4. Integration Platforms With EDI Modules
Integration platforms treat EDI as one connection type among APIs, files and application connectors. Boomi’s B2B/EDI Management supports X12, EDIFACT, TRADACOMS, HL7, RosettaNet and ODETTE over AS2, SFTP and web services. MuleSoft’s Anypoint Partner Manager manages EDI and API partners from one interface. Azure Logic Apps offers X12, EDIFACT and AS2 through integration accounts that store partners, agreements, maps, schemas and certificates. This model fits businesses that already use one platform for workflow automation and application integration.
5. Cloud B2B Integration Suites and Networks
Some vendors combine a cloud integration platform with a trading partner network and optional managed services. Cleo Integration Cloud handles API payloads in JSON and EDI in X12, TRADACOMS and EDIFACT, plus flat files, spreadsheets and XML, and offers self-service, managed or blended operation. OpenText Trading Grid combines EDI, API and managed file transfer with pre-built ERP integrations, and IBM sells Sterling B2B Integration SaaS, formerly Sterling Supply Chain Business Network.
6. API-First and Usage-Priced EDI
The newest EDI system designs are built for developers. Orderful’s platform translates between JSON and X12 and manages the communication protocols. Stedi publishes per-transaction prices for healthcare EDI, with no monthly minimum or setup fees on its pay-as-you-go plan. AWS B2B Data Interchange charges per trading partnership and per document transformed. These services suit software companies and product teams that want EDI inside their own applications, but they expect you to build and operate the integration around them.
| EDI system type | Who runs the maps | Best fit | Watch out for | Examples |
|---|---|---|---|---|
| Web EDI portal | Provider | Suppliers with few partners and low volumes | Manual rekeying into your own systems | TrueCommerce Web EDI |
| Full-service EDI | Provider | Suppliers to many retailers with no EDI team | Recurring fees; changes queue behind the provider | SPS Commerce Fulfillment, TrueCommerce managed service |
| On-premises B2B gateway | Your team | High volumes, strict control and complex routing | Infrastructure, upgrades and specialist skills | IBM Sterling B2B Integrator |
| Integration platform with EDI | Your team or an integrator | Businesses already standardised on the platform | EDI depth varies; partner onboarding effort | Boomi, MuleSoft Anypoint Partner Manager, Azure Logic Apps |
| Cloud B2B suite and network | Your team, the provider or both | Mid-market and enterprise firms with mixed EDI and API partners | Contract complexity and network charges | Cleo Integration Cloud, OpenText Trading Grid, IBM Sterling B2B Integration SaaS |
| API-first, usage-priced | Your developers | Software companies and product teams | You own error handling, monitoring and ERP links | Orderful, Stedi, AWS B2B Data Interchange |
EDI System Vendors to Shortlist in 2026
The right shortlist depends on who your partners are and who will run the EDI system day to day. Here is how the main vendors line up against the problem they solve, based on their own product documentation. Treat every vendor claim as a question to test in a demonstration, not as a conclusion.
For Suppliers to Large Retailers
SPS Commerce and TrueCommerce concentrate on retail and distribution. Both maintain libraries of retailer requirements, which shortens onboarding when a new customer demands EDI, and both offer managed options. If most of your EDI system exists to satisfy supermarket, department store or marketplace requirements, start here and compare how each handles your specific retailers’ shipment notice, labelling and chargeback rules.
For Enterprises With Complex Partner Networks
OpenText Trading Grid and IBM Sterling suit large organisations with thousands of partners, several ERPs and operations in many countries. Both combine network services with integration software and managed services. Expect longer procurement cycles, enterprise contracts and a need for internal or partner expertise to get full value from either EDI system.
For Businesses Standardising on an Integration Platform
If you already run Boomi, MuleSoft or Azure Logic Apps, adding EDI there avoids a second integration stack and gives you one place to monitor every connection. The risk is that partner onboarding, map maintenance and acknowledgement tracking take more configuration than a dedicated EDI system. Microsoft notes, for example, that its Logic Apps map and schema design extension works with Visual Studio 2019 and is unavailable for Visual Studio 2022 and later.
For Mid-Market Firms Mixing EDI and APIs
Cleo Integration Cloud targets companies that trade with a mix of EDI and API partners and want to switch between self-service and managed operation as their team grows. It sits between a pure integration platform and a full-service provider, which makes it a sensible benchmark when neither extreme fits the EDI system you need.
For Developers and Software Products
Orderful, Stedi and AWS B2B Data Interchange expose EDI through APIs and usage pricing. Stedi focuses on healthcare transactions such as eligibility checks, claims and remittances, while AWS B2B Data Interchange runs inside an AWS account and turns EDI into JSON or XML. These are strong choices when EDI is a feature of your own product and weak ones when you want someone else to run your EDI system. A software development team can build the ERP connections, error queues and dashboards that these services leave to you.
What an EDI System Costs
EDI pricing is famously opaque, because most full-service and enterprise vendors quote per customer. The total cost of an EDI system is best understood as a set of components, then priced against real quotes for your own partner list and volumes.
The Cost Components
Almost every quote breaks down into the same six parts, even when a vendor bundles them into one monthly figure:
- Software or subscription: licence, platform subscription or portal fee.
- Trading partner setup: mapping, testing and certification for each new partner.
- Transaction or network charges: fees per document, per partnership or per unit of data sent through a VAN.
- Integration: connecting the EDI system to your ERP, warehouse and finance systems.
- Operations: monitoring, error handling, certificate renewals and map changes.
- Compliance: e-invoicing access, archiving and tax reporting where mandates apply.
What Published Prices Show
A few vendors publish list prices, which makes the usage-priced model easy to reason about. AWS B2B Data Interchange charges $8 per partnership per month and $0.01 per EDI document transformed into its default JSON or XML format, plus another $0.01 per document if that JSON is transformed into a custom format. AWS’s own worked example, one partnership receiving 10,000 documents transformed to custom JSON, comes to $208 a month.
Applying those list prices to three illustrative volumes shows how the fixed partnership fee matters less as document volume grows. The volumes are examples, not benchmarks, and the totals exclude storage, compute, data transfer, mapping work and ERP integration:
| Illustrative profile | Partnerships | Documents a month | Partnership fees | Default transformation | Monthly total | Per document | With custom JSON step |
|---|---|---|---|---|---|---|---|
| Small supplier | 5 | 2,000 | $40 | $20 | $60 | $0.030 | $80 |
| Growing distributor | 25 | 20,000 | $200 | $200 | $400 | $0.020 | $600 |
| Large wholesaler | 100 | 100,000 | $800 | $1,000 | $1,800 | $0.018 | $2,800 |
At AWS list prices, the monthly service charge for those three profiles rises from $60 to $1,800 before a single hour of integration or support work is counted:
Healthcare EDI shows a different model. Stedi prices each transaction in volume tiers, so the unit price falls as monthly volume rises, with no monthly minimum on its pay-as-you-go plan:
| Stedi transaction | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
|---|---|---|---|---|
| 270/271 eligibility check | $0.30 (1 to 250) | $0.15 (251 to 3,500) | $0.10 (3,501 to 10,000) | $0.08 (10,001+) |
| 837 claim submission | $0.30 (1 to 500) | $0.20 (501 to 2,500) | $0.12 (2,501 to 10,000) | $0.10 (10,001+) |
| 835 electronic remittance advice | $0.20 (1 to 500) | $0.15 (501 to 2,500) | $0.10 (2,501 to 10,000) | $0.08 (10,001+) |
The Costs That Never Appear on a Price List
The largest costs of an EDI system are usually people and change. Every new trading partner needs mapping and testing, and every partner guide update can break a working map. Retailers may charge for non-compliant documents, staff spend time on rejected transactions, and certificates must be renewed before they expire. Budget an EDI system as a service with running costs, not as a one-off software purchase.
How to Choose an EDI System
Feature lists from EDI vendors look alike. The differences that matter appear only when you test a candidate EDI system against your own partners, data and team.
Start With Your Trading Partners
List every partner that requires EDI or could use it, with their standard and version, the documents they exchange, their protocol, and any labelling or compliance rules. Add the partners you expect to win in the next two years. This inventory decides more than any feature matrix, because an EDI system that already supports your largest partners’ requirements saves months of mapping.
Decide Who Will Run It
Be honest about skills. If nobody in the business can read an X12 file or renew an AS2 certificate, choose a managed or full-service model, or budget for a partner. If you have integration engineers, a platform or API-first EDI system may be cheaper and more flexible over time.
Test ERP Integration Depth
Ask for a demonstration with your ERP, not a generic one. Check how orders become sales orders, how shipment confirmations produce 856 notices, how invoices reconcile, and what happens to a document the ERP rejects. Clean item, customer and location master data matters as much as the connector, which is where good data management and analytics practice pays off.
Check E-Invoicing Coverage
If you trade in Belgium, Poland, France, Germany or the UK, ask each vendor which mandates the EDI system covers natively, which through a partner, and how rejections from tax platforms are surfaced. Ask whether the vendor is a Peppol service provider or relies on one.
Security and Resilience
EDI carries prices, bank details and customer data, so treat the EDI system as part of your cybersecurity scope. Confirm how certificates and keys are managed, how data is encrypted in transit and at rest, how access is controlled and logged, and how quickly the service recovers from an outage. A missed certificate renewal can stop every AS2 partner at once.
| Criterion | Question to ask every vendor | Priority |
|---|---|---|
| Partner coverage | Do you already support our partners’ standards, versions and protocols? | Must-have |
| ERP integration | Is there a tested connector for our ERP and warehouse system, and who maintains it? | Must-have |
| Partner onboarding | Who maps, tests and certifies a new partner, and what does it cost? | Must-have |
| Acknowledgement tracking | Are overdue 997, 999 and CONTRL acknowledgements flagged automatically? | Must-have |
| E-invoicing | Which national mandates are covered natively, and which through partners? | Must-have where a mandate applies |
| Security | How are certificates, keys, access rights and audit logs managed? | Must-have |
| Pricing model | What drives cost: partners, documents, data volume, users or services? | Important |
| Exit | Can we export maps, partner profiles and message history if we leave? | Important |
Implementing an EDI System: A Practical Plan
Most EDI system projects fail slowly rather than dramatically: go-live happens, then rejected documents pile up until someone rebuilds the maps. A phased plan with partner testing and a defined hypercare period prevents that.
Phase 1: Discovery and Partner Inventory
Build the partner inventory described above, collect every implementation guide, and rank partners by revenue and document volume. Agree which documents go live first; for most suppliers that is the 850 order, the 855 acknowledgement, the 856 shipment notice and the 810 invoice.
Phase 2: Design and Data Readiness
Design the integration between the EDI system and your ERP, and fix master data before mapping starts. Retail partners expect correct GTINs, GLNs and units of measure, and a wrong pack size in the item master will produce a wrong shipment notice however good the map is.
Phase 3: Build Maps and Integrations
Build and unit-test maps for the first wave of partners, connect the transport channels, and set up monitoring for failed translations and overdue acknowledgements. Keep partner-specific rules in the EDI system rather than hard-coding them into the ERP, so a partner change does not become an ERP release.
Phase 4: Partner Testing and Certification
Most large trading partners run their own test process and will not accept production documents until you pass it. Schedule this early, because partner test teams set the pace. Define acceptance criteria in advance, in the same way as any IT project acceptance process, so everyone knows what “ready” means.
Phase 5: Go-Live and Hypercare
Go live partner by partner, not all at once. Watch every document for the first weeks, confirm acknowledgements, reconcile invoices against orders and shipments, and only then move the next wave of partners onto the EDI system.
EDI vs API: Does Every Business Still Need an EDI System?
APIs are real time, familiar to developers and flexible. EDI is standardised, often batch based, and understood by thousands of trading partners at once. The question is rarely which is better; it is which your partners require.
Large retailers, distributors, carriers and US healthcare payers still require EDI, and mandated e-invoicing adds structured formats and networks rather than replacing them. Some partners offer APIs as well, and platforms such as Orderful and AWS B2B Data Interchange let your developers work in JSON while partners keep receiving EDI. For most businesses the practical answer in 2026 is a hybrid EDI system: EDI where partners require it, APIs where they are offered, and one monitoring layer across both.
Common EDI System Mistakes to Avoid
The same handful of errors appear in EDI system projects of every size. Each is cheap to prevent and expensive to discover in production.
Treating Mapping as a One-Off Job
Partners update their implementation guides, standards publish new versions, and your own ERP changes. Assign ownership for maps after go-live and budget for regular changes to the EDI system.
Underestimating the Shipment Notice
The 856 depends on warehouse data, carton labels and timing, not just the order. Test it with real shipments and real labels before any partner sees it.
Letting Certificates Expire
AS2 and OFTP2 depend on certificates with fixed expiry dates. Keep a renewal calendar, coordinate changes with partners in advance, and monitor for failed handshakes.
Hard-Coding Partner Rules in the ERP
Customer-specific codes and qualifiers belong in the EDI system’s partner configuration. Hard-coding them into ERP customisations makes every partner change a software release.
Leaving E-Invoicing to the Last Minute
Mandates have fixed dates and national platforms have their own onboarding and testing. Map each legal entity to its mandate now, and make e-invoicing coverage part of the EDI system contract rather than a later add-on.
EDI System FAQs
Is EDI still used in 2026?
Yes. X12 still publishes an annual release, US healthcare runs on HIPAA-mandated X12 transactions, and large retailers and distributors still require EDI from suppliers. E-invoicing mandates in Europe and the UK are expanding structured document exchange, not shrinking it.
What is the difference between an EDI system and an ERP?
An ERP runs your internal processes: orders, stock, purchasing and finance. An EDI system connects that ERP to your trading partners by translating, sending and receiving standard documents. Some ERPs include EDI modules, but most businesses use a separate EDI system or service.
Do small businesses need an EDI system?
Only if their customers or suppliers require it, or if e-invoicing mandates apply. A small supplier with one EDI customer can often start with a web EDI portal or a full-service provider and move to an integrated EDI system as volumes grow.
What is the difference between X12 and EDIFACT?
Both define the structure of business documents. X12 dominates in North America and names documents with numbers, such as 850 for a purchase order. UN/EDIFACT is the international standard used widely in Europe and names messages with codes, such as ORDERS. GS1 EANCOM is a retail subset of EDIFACT.
Is AS2 better than SFTP for EDI?
AS2 returns a signed MDN receipt that proves delivery and is widely used for direct links with large retailers. SFTP is simpler and cheaper but gives no business-level receipt. The deciding factor is usually what each trading partner supports.
Can an EDI system send Peppol e-invoices?
Only if it supports Peppol BIS formats and connects through a Peppol access point, either as a Peppol service provider or through a partner. Supporting X12 or EDIFACT does not by itself make an EDI system Peppol-ready.
How long does it take to set up an EDI system?
It depends far more on trading partners than on software. A web EDI portal can be working quickly, while an integrated EDI system needs mapping, ERP integration and partner certification for each partner, and partner test schedules usually set the pace.
References
X12 Supply Chain Transaction Flow
X12 Publishes 008060 Versions of all HIPAA-Mandated Implementation Guides
GS1 UK: Ending Support for TRADACOMS
RFC 4130: Applicability Statement 2 (AS2)
RFC 5024: ODETTE File Transfer Protocol 2.0
European Commission: VAT in the Digital Age (ViDA)
Belgium: Structured Electronic Invoices Between Companies Are Compulsory Since 2026
KSeF: Legal Basis and Key Dates
Entreprendre.Service-Public.gouv.fr: Electronic Invoicing Reform
Bundesfinanzministerium: E-Rechnung FAQ
GOV.UK: Promoting Electronic Invoicing Consultation Response
GOV.UK: HMRC Transformation Roadmap Update 2026
AWS B2B Data Interchange Pricing
Microsoft Learn: B2B Enterprise Integration Workflows in Azure Logic Apps