Service · Web development

Custom EDI integration development for your trading partners.

EDI, short for Electronic Data Interchange, is how businesses exchange structured orders, invoices, deliveries and stock updates with one another. We build custom EDI integrations between your ERP and your retailers, suppliers or logistics partners: UN/EDIFACT, UBL, Peppol, ANSI X12 or XML, all from a single integration layer.

EDIFACT & UBLPeppol AccessPointAS2 / SFTP / OFTP2ERP mapping

Arrange an introductory call View integration cases

An EDI integration is not a file drop, it is a trading protocol.

EDI has been around since the 1980s and is still the way large retailers, automotive OEMs and logistics firms communicate with their suppliers. If you supply Albert Heijn, Jumbo, IKEA or a German car manufacturer, you have no choice: you integrate via EDI or you don't get invoiced. At the same time, "EDI" is not one single thing. It is a collection of standards (UN/EDIFACT, ANSI X12, UBL, VDA, TRADACOMS, XML variants such as cXML), a collection of transport protocols (AS2, OFTP2, SFTP, Peppol) and a set of business rules for each trading partner. For one partner, an "EDI integration" means one XML file a day over SFTP; for another, it means a real-time AS2 feed of thousands of ORDERS messages with functional acknowledgements coming back.

We have been building custom integrations between ERP systems and the outside world since 2015. For EDI, that means a mapping engine between your own data model and the messages your trading partners require, a transport layer that handles both classic AS2 and modern Peppol, and archiving that meets the ten-year statutory retention requirement. We don't replace large EDI providers such as Babelway, Comarch or OpenText for enterprise volumes. What we do build are smaller stacks, add-ons to existing providers, and specific integrations that simply aren't included in off-the-shelf products.

Our role doesn't end at "the message got through". We think ahead about what happens when a supplier adds a field tomorrow, how rejected messages avoid sitting in a queue, and how your finance or operations team can see discrepancies without having to read raw EDIFACT. A well-built EDI integration is mostly about catching exceptions. The standard case is ready in a sprint; the exceptions are the real work.

The standards we work with most often: UN/EDIFACT for classic retail and logistics; UBL for modern e-invoices via Peppol; ANSI X12 for American trading partners in retail and healthcare; VDA for German automotive; cXML and xCBL for B2B marketplaces; HL7 for healthcare communication; SBR for Dutch tax reporting; and XBRL/EBR for energy reporting. We do not pick a standard in advance. We choose what your trading partners require and build the stack around that.

Three types of EDI integration.

Which option fits depends on your trading partners, your invoice and order volumes, and how much control you want to keep yourself. We will advise which option suits you in the first conversation.

Compact project · fixed sprint budget

One-to-one EDI integration with a single trading partner

You need to supply one large retailer or OEM and have received their EDI specification. We build the direct integration from your ERP to their gateway: UN/EDIFACT ORDERS, DESADV and INVOIC, or the XML variant they prescribe. This includes mapping, AS2 or SFTP transport, and the first rounds of test messages in their acceptance environment.

EDIFACTAS2 / SFTPAcknowledgementsTest rounds

Mid-sized project · fixed sprint budget

Mapping engine for multiple trading partners

You connect to five, ten or more customers or suppliers, and each partner has different segments, codes or business rules. We build a central mapping engine: one source format from your ERP, multiple recipient mappings, so adding a new partner becomes a configuration task rather than a new project. Includes routing, monitoring and a dashboard for your operations team.

Mapping engineRoutingPartner onboardingMonitoring

Larger project · fixed sprint budget

Your own Peppol access point or AS2 server

You want to keep control of your e-invoicing flow to the government (Peppol BIS, SBR), or you run an AS2 server for your automotive flow. We build a production stack with your own access point or AS2 server, qualified signatures, ten-year archiving and a self-service portal for your trading partners. A genuine enterprise-grade EDI layer, in your own cloud.

Peppol access pointAS2 serverE-archivingPartner portal

What you get at the end.

A production-ready EDI integration, plus everything your team needs to manage it themselves and extend it to new trading partners.

The integration layer itselfProduction and acceptance environments, connected to both your ERP (SAP, Exact, AFAS, Dynamics) and your trading partners' gateways or a Peppol Access Point.
Mapping tables per message typeDocumented mapping between your ERP fields and the relevant EDI messages — ORDERS, DESADV, INVOIC, ORDRSP, RECADV — including fallback rules for missing data.
Transport and acknowledgementsImplementation of AS2, SFTP, OFTP2 or Peppol, with CONTRL and functional acknowledgement flows so you know when a message has genuinely arrived.
Validation and business rulesXSD or EDIFACT schema validation, plus the partner-specific business rules you supply, so rejections are visible before dispatch.
Compliant e-archivingEncrypted, tamper-proof storage of all inbound and outbound EDI messages for the ten-year statutory retention period — usable for international invoices and audits.
Operations dashboardVisibility for your finance and logistics teams into sent, accepted, rejected and pending messages — with one-click resend for failed transmissions.
Codebase and runbookFull source code, build instructions and an incident runbook — your IT team can handle escalations itself without depending on an external supplier.
Management contract (optional)Monitoring, certificate rotations, security patches and ongoing development for a fixed monthly fee — useful when Peppol or a retailer releases a new schema version.

When an EDI integration is the right choice.

Four situations in which we support organisations. If one of these sounds familiar, we'd be happy to discuss the scope further.

Retail / wholesale

Supplier to major retailers

You supply Albert Heijn, Jumbo, Hema, Bol or a major international retailer. They require EDI orders (ORDERS), despatch advices (DESADV) and e-invoices (INVOIC or UBL) via their prescribed gateway. Without a working integration, payments stall and orders fail to arrive.

Automotive / VDA

Supplier in the automotive supply chain

You supply parts or just-in-time deliveries to a German or international OEM. VDA messages via OFTP2, with strict timing for delivery confirmations and stock positions, are the norm. One missing DELJIT confirmation and the production line will notice.

Government and B2G

Peppol mandate for e-invoices

You invoice government bodies, hospitals or educational institutions that require UBL via Peppol BIS. Or you fall under the forthcoming EU-wide e-invoicing mandate and want to run your own Access Point rather than paying an external provider per invoice.

Logistics and customs

Transport orders and customs declarations

You coordinate multimodal transport using IFTMIN waybills, customs declarations (Customs / NCTS) and stock notifications to clients. Combining EDI with API gateways and track-and-trace systems is an area where we have built the most.

Healthcare

ZorgMail, Vecozo and claims flows

Healthcare providers, pharmacies and insurers exchange claim files, return messages and authorisations using HL7 and EDIFACT variants. We connect practice software or your own platform to ZorgMail, Vecozo and similar hubs, with the correct authentication and compliance requirements in place.

E-commerce to wholesale

Bol, Amazon or marketplace flow to your WMS

You sell through Bol, Amazon or another marketplace, but your stock and invoicing run on your own WMS or ERP. An EDI or cXML integration between the marketplace and your system prevents duplicate admin, missed orders and manual re-keying.

How an EDI project runs.

Introduction and partner scoping

A conversation to establish which trading partners need connecting, which messages they require (ORDERS, DESADV, INVOIC, ORDRSP, RECADV, or others) and which transport they mandate. We request their message implementation guides and review them together.

Source data from your ERP

We compare your outbound data (order confirmations, deliveries, invoices) against what the partner expects. Fields that don't match receive mapping rules, lookup tables or fixed fallbacks. The result is a mapping document your own team can maintain when the ERP changes.

Build in sprints, sandbox first

A working build with every sprint. We start in the partner's acceptance environment, testing the mapping, transport and acknowledgements there, and work through rejected scenarios together before going live. Getting a retailer to join a test batch early saves a great deal of pain on go-live day.

Validation and exception flow

Every message is pre-validated against the schema and business rules. Rejected messages go through a clean retry flow with an audit log; messages that repeatedly fail are escalated to your operations team rather than ending up in a dead queue.

Go-live and archiving setup

A phased transition from acceptance to production, archiving set up to meet fiscal retention obligations, and knowledge transfer to your IT and operations teams. Dashboards are ready for finance, supply chain and any audits.

Maintenance and new partners

The EDI landscape keeps moving: retailers release new schema versions, Peppol introduces new BIS profiles, automotive OEMs change portals. We monitor these changes and expand the integration as you onboard more partners. For partners you onboard yourself, we provide a self-service portal with a test environment, so a new supplier or customer can send a first batch of messages before going live.

Frequently asked questions.

What clients usually want to know before we start.

Which EDI standard do we need?

That depends on your trading partners and your sector. Retail and wholesale usually run on UN/EDIFACT (ORDERS, DESADV, INVOIC) or UBL; automotive on VDA with OFTP2; government and B2B e-invoicing on UBL via Peppol BIS; and US retail and healthcare on ANSI X12. At the first trading partner, we look at which message implementation guide you have received and determine from that which standards your stack must support.

What is the difference between EDI and an API integration?

EDI is a standardised batch protocol for trade documents, with defined messages and formal acknowledgements. APIs are more flexible but company-specific and rarely standardised across suppliers. In practice they coexist: a retailer may require EDI for INVOIC while also offering a REST API for stock positions. We often build an integration layer that handles both and routes at partner level.

What is UBL and how does it fit into Peppol?

UBL (Universal Business Language) is an open XML standard for trade documents such as orders, invoices and despatch advices. Peppol BIS is a set of EU-wide agreements built on top of UBL that specifies which fields are mandatory and how documents are exchanged between Access Points. For e-invoicing to government bodies within the EU, Peppol BIS has effectively become the standard, and it is becoming mandatory more broadly for B2B. Our page on Exact Online integration touches on the accounting side of this flow.

Should we set up our own Peppol Access Point or hire a provider?

That depends on your invoice volume, your need for control and your sensitivity to per-invoice costs. For lower volumes, an external Access Point (Storecove, Tradeshift, Pagero) is perfectly suitable and cheaper. For higher volumes, international flows or a requirement for maximum control, we build our own Access Point in your cloud. In the first meeting we walk through both scenarios so the choice is based on substance, not ideology.

What about e-archiving for international invoices?

Tax legislation requires invoice data to be retained for a long period; in the Netherlands and most EU countries, that is ten years. For international invoices, the strictest requirement across the countries involved applies. We set up encrypted storage with write-once, immutable logging and an audit trail showing who viewed, exported or resent which invoice, and when. Access runs through your identity provider, so it falls within your existing security policy.

Do you work with our IT department and existing EDI provider?

Almost always. Many clients already run partly on Babelway, Comarch, Cleo or OpenText/GXS. We don't replace those enterprise stacks for high volumes, but we build the additions or specific integrations that standard products lack. We connect to your existing provider via webhooks or a lightweight broker of our own, and hand over knowledge in the final sprint.

Can you also help migrate from EDIFACT to modern APIs?

Yes. More and more supply chains are running parallel APIs alongside their EDIFACT flows, with UBL or REST/JSON becoming the new standard. We build a translation layer that leaves your existing ERP output untouched, while still supporting classic EDIFACT (for partners who haven't moved on) as well as modern APIs or UBL. That way you migrate at your own pace, without forcing all your partners to switch at once.

Which retail-specific flows are most common?

For Dutch retail, it's usually the ORDERS-DESADV-INVOIC chain via EDIFACT: the retailer places an order, the supplier confirms with ORDRSP, announces the delivery with DESADV and invoices via INVOIC or UBL. A RECADV from the retailer closes the chain. International retailers and marketplaces often also use XML variants (cXML, xCBL) or their own API portals. We implement both sides: outbound to the retailer and the return flow back into your ERP.

What determines the cost of an EDI integration?

Three things: the number of trading partners and message types, the number of source systems on your side (one ERP is simpler than SAP plus AFAS plus a custom platform), and whether you run your own Access Point or AS2 server or work through an external provider. In the first conversation we walk through the scope, after which we come back with a sprint budget. No open-ended hourly billing; fixed budgets per sprint.

Talk to us about your EDI integration.

A free, no-obligation half-hour introduction. We listen to your trading-partner landscape, ask about the messages you need to exchange, and advise on scope, transport choices and any overlap with Peppol. If you already have an EDI provider, we'll look at how an additional stack can work alongside it. In the meantime, read our page on smart API integrations, and if you want to tackle your operational flows more broadly, see a custom order management system or a custom ERP system. For purchasing-side automation: procurement automation platform.

Schedule an introductory call Or browse more case studies