“We have an API” does not yet tell you whether an order can be accepted, amended and then reconciled with a delivery. “We do EDI” does not say which messages or which partners are supported. To compare the two, start from the journey of an order.
EDI and API do not describe the same thing
EDI organises the exchange of structured business documents under shared rules. An API is an interface through which two systems exchange data or trigger operations. An EDI exchange can use an API as its transport, so the two are not necessarily competing.
GS1 France (French) describes, among others, the ORDERS message for the order, DESADV for the despatch advice and INVOIC for the invoice. The standard and the version are not always enough: the partner’s implementation guide states the fields, codes and rules actually expected.
| Question | EDI exchange | Exchange over an API |
|---|---|---|
| What does the document mean? | Message and partner guide | Data schema and interface contract |
| How does it arrive? | Channel agreed with the partner | Calls, events or periodic retrieval |
| How do we know it was accepted? | Technical acknowledgements and business responses as planned | Interface response and documented business status |
| How is an error handled? | Agreed rejection, correction and resend | Error codes, recovery and retry rules |
Map the flow from end to end
Take an order for twenty-four units. The system receives the request, identifies the buyer and the delivery location, finds the product, applies the terms, then accepts or rejects it. Picking can then despatch eighteen units and put six units on back order, if that possibility has been agreed.
The despatch advice must reflect what actually leaves. The invoice and any credit notes must be reconcilable with the earlier documents, following the rules of the flow. If the interface can only create an order, the follow-up work may stay entirely manual. Quantify that remaining work before comparing costs.
- Order
Identify the parties, the products, the units and the terms.
- Acceptance
Confirm processing or return a rejection that can be explained.
- Despatch
Describe the 18 units actually sent and the back order of 6.
- Reconciliation
Link invoice, delivery and any credit notes according to the flow.
A technical acknowledgement of receipt does not prove commercial acceptance.
Align the identifiers and the units
- →Parties: invoiced customer, delivered outlet and identifiers recognised on both sides.
- →Products: internal SKU, partner code or GTIN, linked to the right variant.
- →Quantities: unit, case, multiple and conversion made explicit.
- →Terms: currency, net or gross price, discounts, taxes and the relevant dates.
Unit errors are still possible in a perfectly valid message. The catalogue data core must therefore be checked before the technical tests. An unknown product code must produce an understandable rejection, not a free-text line that later escapes reconciliation.
Plan for a message being sent twice
Suppose the partner sends an order, your system records it, and then the connection drops before the acknowledgement comes back. The partner may resend the same document. If every receipt creates a new order, two parcels can leave for a single purchase.
Define the uniqueness key with the partner, and the expected behaviour when the same identifier arrives with different content. Recovery must keep a trace of the first receipt, of the corrections and of the statuses. This capability is often called idempotency; what counts in acceptance testing is the operational result.
Test the exceptions before the first real order
| Case | Result to check |
|---|---|
| Valid order | One order created, amounts and units identical to the source document |
| Same document received twice | No second order and no second despatch |
| Unknown product | Explicit rejection and a possible correction |
| Partial delivery | Despatched quantities and back order identifiable |
| Amendment after confirmation | A clear rule depending on the picking status |
| Outage then recovery | Pending documents found again and reconciled without loss |
Keep the input data, the expected result and the difference observed for each test. A green screen sometimes only proves that the file was transported successfully. You also have to check that the order was accepted by the management system and that the status returned matches that acceptance.
Choose on the partners and on the cost of running it
If a distributor requires a specific EDI message, that need is decisive. If a partner offers a complete, documented API, assess its functional coverage, its usage limits, version management and the availability of the data. In both cases, ask who handles the rejections and within what time.
An invoice flow is not enough to settle compliance
Choosing an INVOIC message or an API does not, on its own, prove that all the French electronic invoicing obligations are met. The guide to e-invoicing in distribution separates the regulatory timetable, the parties involved and the data to prepare, with the official sources.
Finally, have installation, data mapping, testing, rejection monitoring and maintenance costed. Ask for a demonstration on your documents and your exact partner. The name of a connector in a presentation guarantees neither the messages covered, nor the direction of the exchanges, nor the handling of exceptions.
By Anatole Briant
By Pierre Lerebours
By Anatole Briant
COO of Salesia
Pierre Lerebours is COO of Salesia. He is your contact for implementation, training and ongoing support.