Two terms get routinely confused in the EDI world: the EDI gateway and the EDI transaction. They are technically related but distinct, and they are specified, contracted and billed separately. Understanding the difference saves money during negotiations and avoids surprises on the invoice.
This article is a short technical guide through both — what a gateway is, what a transaction is, where they differ and why billing models track transactions rather than gateways.
EDI gateway
An EDI gateway is the technical connection point — a server or service through which your ERP talks to the EDI network. It behaves like an email server: it has inbound and outbound channels, authentication, logging and monitoring. Typical protocols supported by a gateway are sFTP, AS2 (with digital certificates), AS4 (mandatory for Peppol), REST/JSON API and a classic file-drop folder.
The gateway is configured once — when the integration is set up. Its capacity and SLA are sized to expected volume (e.g. 1,000 or 50,000 messages per month) and message types (small ORDERS vs. large INVOIC with 200 line items).
EDI transaction
An EDI transaction is a single document that passes through the gateway. Examples: one purchase order (ORDERS), one dispatch note (DESADV), one invoice (INVOIC), one acknowledgement (APERAK or ORDRSP). Each of those is one transaction — and volume in EDI contracts is measured by counting them.
A transaction has its own lifecycle: ingress, validation (syntax + semantics), mapping, sending to the partner's Access Point, delivery acknowledgement. If any step fails, the transaction is reprocessed or rejected with a detailed error log.
Why the distinction matters for the contract
- The gateway is usually billed as a fixed monthly fee — covering infrastructure, certificates, monitoring and baseline SLA.
- Transactions are billed per message with volume tiers. Low activity (up to 500 per month) is often covered by the fixed fee; above that threshold there is a stepped tariff.
- Different transaction types have different „weights“ — an INVOIC with 200 line items requires more validation cycles than a short ORDRSP, and that can be reflected in the tariff.
- Validation failures are usually not billed — the document never actually left the gateway towards the partner.
REDOK as operator of both the gateway and the transaction platform
REDOK operates on both layers: it runs a physical Peppol Access Point gateway (certified AS4 and SMP) and the transaction routing and validation platform (in-house development, ~30 years). This enables unified operations: when a transaction breaks, we see both the gateway side (network, certificates) and the transaction side (content, mapping).
Practical consequence for the customer: one ticket, one team, shorter resolution time. In classic setups where the gateway and the transaction platform are with different vendors, the average incident resolution time often doubles purely due to cross-team communication.
Summary
The gateway is the „pipe“; transactions are the „water flowing through it“. You pay a fixed package for the pipe; you pay per m³ for the water. Separating the two layers in the contract prevents overpaying the fixed component for small volumes and undersizing capacity for large ones.
REDOK is happy to review your existing EDI contract — how much you are paying for the gateway vs. for transactions, and where there is room for optimisation. Reach out through the contact form.