— May 18, 2026 · 8 min read
Onboarding an EDI partner in 15 days: a field report
Fifteen working days is the reasonable target for a classic EDI partner onboarding (AS2 or AS4, EDIFACT or UBL). The detailed plan below is drawn from real cycles in retail and automotive 2024-2025; it documents RACI, deliverables, exit criteria and recurring blockers.
D1-D3: framing and spec collection
Deliverables: partner profile (legal name, GLN, technical contact, escalation contact), list of flows to set up (ORDERS, DESADV, INVOIC, etc.), target volumetrics (messages/day, average size), protocol choice (AS2, AS4, OFTP2, SFTP), standard choice (EDIFACT D.96A, UBL 2.1, X12 4010 or 5010).
RACI: Responsible on the EDI team side, Accountable on the business partner manager side, Consulted on legal (NDA, DPA if personal data), Informed on partner finance.
Exit criterion: a document signed by both sides cataloguing each flow, its standard, its target volume and its business criticality. Without it, D4 starts on a false footing.
D4-D6: certificate exchange and endpoints
Deliverables: X.509 production certificates exchanged over a secure channel (never email alone; ideally self-service portal or signed+encrypted upload), AS2/AS4 endpoint URLs on each partner side, AS2-FROM / AS2-TO or Party IDs agreed.
Typical blocker: certificate expiring within less than 6 months or self-signed. Systematic rejection by a modern hub — require a commercial certificate (DigiCert, GlobalSign, Sectigo) or one issued by a recognised internal PKI. The partner side often discovers it on D6, which delays everything else.
Exit criterion: mutual test handshake on the sandbox endpoint with signed+encrypted MDN received in less than 10 seconds. A failure here is almost always wrong sign/encrypt order or a non-common cipher suite.
D7-D10: mapping and syntactic tests
Deliverables: detailed mapping spec (segment-by-segment for EDIFACT, element-by-element for UBL/XML), validation of business assumptions (who supplies article ILN/GLN? what UNB+UNH header structure for a multi-site partner? what DESADV granularity — per truck or per order?), Schematron or XSD validators in CI on the hub side.
Typical blocker: charset. The partner uses CP1252 (Windows-1252) on accented characters, the hub expects UTF-8. Often detected at test 1, drags on because the partner has to reconfigure its generator. Explicitly agree on UNB+UNOC:3 (encoded ISO-8859-1 strict) or UNOY:3 (UTF-8) in the partner profile.
Exit criterion: 5 test messages per flow accepted by the hub validator, with functional ACK (CONTRL or APERAK) returned in less than 60 seconds.
D11-D13: end-to-end business tests
Deliverables: real business test set (real articles, real prices, real delivery GLNs), complete ORDERS → ORDRSP → DESADV → RECADV → INVOIC path, 3-way matching ORDERS/DESADV/INVOIC verification on the buyer ERP side.
Typical blocker: time window. The partner emits its DESADV in a nightly batch 02h-04h local time. The hub expected real-time. The agreed acknowledgement SLA (4h max) is theoretically met but in practice all DESADV arrive at 04h00, saturate the queue, and acks only leave around 06h00. Solution: agree on progressive staggering or scale parser capacity from 02h to 06h.
Exit criterion: 3 complete cycles validated without human intervention, signed off by business (product manager on buyer side, sales ops on seller side).
D14-D15: progressive go-live and monitoring
Deliverables: sandbox-to-prod cutover (typically URL and certificate change), traffic limited to 10% on day 1, ramp to 100% on day 2, partner SLA dashboards published.
Typical blocker: prod certificates differ from sandbox. The partner tests its new prod cert on the prod hub, it works, but its flows do not leave — its internal tool still pointed at the sandbox URL. Always verify both sides the day before go-live.
Exit criterion: 72 consecutive hours without a blocking incident, syntactic error rate < 0.5%, acknowledgement SLA held at 99%.
Final deliverables and handoff to run
At D16, the partner is in production with: a profile sheet in the hub's technical CRM (cert, endpoints, contacts, SLA), a published SLA dashboard accessible to the partner, a documented escalation runbook (who to call on an outage, when, on which channel). The handoff to nominal run frees the onboarding team for the next partner, provided the ops team levelled up in parallel — a poorly documented partner profile is the number-one incident source 2 months after go-live.
Conclusion: industrialise, not accelerate
Fifteen days is not a record to break, it is a threshold above which the organisation becomes shaky. The true operational performance of a mature EDI team is repeatability: holding 15 days for 90% of standard partners, identifying quickly the 10% that need 30 (government mandates, complex multi-site partners, custom ERP integration), and never deploying a partner "rushed" that pollutes KPIs for months. To dig further, see our EDI partner onboarding playbook.