EN

Home / Knowledge / EDI ERP integration

How does EDI ERP integration work?

There are three common ways to integrate EDI with an ERP system: an application programming interface (API), staging tables in a database, or file exchange. Which one fits is usually decided by the ERP system: whatever it already offers is almost always cheaper than building something new. Often more important than the technical route is the mapping of master data, meaning which item number, which customer and which unit are meant on each side.

Last updated 18 October 2026 · fokus it solutions, Jens Musleh

Where ERP integration sits in the EDI process

An EDI solution has two sides. Externally, it talks to the partner, in the partner's format and over the partner's transmission method (see Transmission methods). Internally, it talks to your ERP system. In between is the mapping, which translates an EDIFACT purchase order into the structure your ERP system understands and, in the other direction, an invoice from the ERP system into the partner's INVOIC.

The partner sees nothing of the ERP side. All that matters to it is that messages arrive on time and complete. For you, the ERP side determines whether orders are created as sales orders without manual work and whether despatch advices and invoices are generated automatically. Some providers therefore charge separately for ERP integration; EDI+EXPERTS, for example, lists an “individual quote” for it in its price list.

Three ways to integrate EDI with your ERP system

Via API or webhook

Many newer ERP systems offer a programming interface over HTTP, often as a REST API. The EDI solution then creates an order directly with a call, and the ERP system responds immediately with success or an error. For the other direction, the ERP system can trigger a webhook: when an event occurs, such as “delivery posted”, it calls an address of the EDI software.

How retries are handled is important. If the connection drops after sending, the EDI solution does not know whether the order was created. The HTTP standard (RFC 9110) therefore distinguishes idempotent methods, where repeating the request has the same effect as a single call. In practice, this means that every order needs a unique key so that a second attempt does not create a duplicate order.

Via staging tables (DB staging)

Many ERP systems, especially older or industry-specific ones, have their own import tables. The EDI software writes an order as records into these tables, often with header and lines separately, and sets a status field. A program in the ERP system picks up the records, checks them, creates the order and writes back the result.

The advantage: the ERP system keeps control over its validation rules, and the status of every record can be traced. The disadvantage: the EDI solution needs access to the database, and the pick-up program in the ERP system has to be running. Never write directly to the ERP system's actual order tables. That bypasses its checks, and an ERP update can break the integration without anyone noticing.

Via files

Almost every ERP system can import and export files, usually as CSV, XML or JSON. The EDI software places a file in a folder, on a file server or via SFTP, and the ERP system imports it on a schedule. In the other direction, the ERP system exports delivery notes or invoices as files, which the EDI solution collects.

Files are robust and easy to check, because you can open and read them. On the other hand, feedback is delayed, and import errors often only show up in the ERP system's log. So agree on fixed rules: unique file names, writing under a temporary name and only renaming afterwards, separate folders for successful and failed files.

IDoc as a special case

In SAP environments, the IDoc (Intermediate Document) is widespread. SAP describes it as a container for exchanging data between SAP systems and external systems, consisting of a control record, data segments and status records. An IDoc is therefore more a format than a route of its own; depending on the setup, it is transferred as a file or via an interface.

The three routes compared

API or webhook Staging tables File
Feedback immediate once the ERP system has processed the record delayed, often via a log
Troubleshooting via response codes and logs status per record in the table read the file, error folder
Prerequisite in the ERP system documented API import tables and pick-up program import and export function
Access for the EDI software network and API credentials database access, ideally limited to these tables folder or SFTP account
Avoiding duplicate orders unique key per transaction unique key in the table unique file names, archiving after import
Suitable for modern ERP systems, cloud ERP ERP systems with existing import tables almost any ERP system, including older ones

Master data mapping is the real work

Most errors in EDI ERP integration do not arise in the technology but in mapping numbers and units.

  • Item numbers: the partner orders with its material number or the GTIN, while your ERP system knows your own item number. GS1 describes the GTIN as the number a company uses to identify its trade items uniquely. You need a maintained cross-reference, in the ERP system or in the EDI solution.
  • Partners and delivery locations: the partner usually names the buyer, delivery location and invoicee by GLN. Your ERP system works with customer numbers and delivery addresses. Every GLN must be mapped to a record, or the goods end up in the wrong place. More on this under GLN and other identifiers.
  • Units: the partner orders in pieces, while your ERP system manages the item in cartons of twelve. Without conversion, quantities and prices will not match.
  • Prices and terms: if the price in the order differs from the price in the ERP system, it must be clear which one wins and who is notified.

Error handling and testing

Plan a route for every error. An order with an unknown item number must neither disappear nor be half-created. It belongs in an error list with the original file and a plain-language message, so that someone can correct it and reprocess it. Who receives which message should be settled before go-live.

Test the integration first against a test company (client) or test environment of the ERP system. Run real examples from the partner's implementation guide there, including the awkward ones: cancellations, partial deliveries, unknown items, duplicate messages. Only when these cases work cleanly does the integration belong in the production company. The EDI implementation guide checklist shows which points in the guide matter for this.

What edi-service.eu offers on the ERP side

edi-service.eu connects your ERP system via three general adapters: a REST and webhook adapter, staging tables in a database, and a file adapter for CSV, XML or JSON. A ready-made adapter for a specific ERP product is not part of the scope, nor are customisations within the ERP system itself. The AI sets up the mapping in TEST mode first, and it only goes into production after your approval. What the fixed price includes is set out under Price. If you would like to clarify whether your ERP system offers one of the three routes, you can send an enquiry.

Frequently asked questions

Which interface does my ERP system need for EDI?

Your ERP system needs a way to accept orders and output deliveries or invoices: an API, import tables or a file interface. Almost every ERP system offers at least file import. Which routes exist is set out in the ERP documentation, or your ERP consultant will know.

Does the ERP system itself have to understand EDIFACT?

No. The EDI software handles translation between EDIFACT or VDA and the ERP system's format. The ERP system only sees its own structure, such as a CSV file or an API call.

What is DB staging?

DB staging means that messages are handed over via intermediate tables in the database. The EDI solution writes to them, and a program in the ERP system reads, checks and posts the data. This keeps the ERP system's validation rules in force.

How do I prevent duplicate orders?

Every message needs a unique key, such as the partner plus the order number. Before creating anything, the EDI software and the ERP system check whether this key already exists. This also protects you if a partner sends the same order twice.

Sources

Send an enquiry · FAQ · All knowledge pages