EDI Error Escalation Runbook Template
When an EDI feed fails at 2 a.m., the person on call should not have to guess who to call or whether it matters. A runbook defines what an incident is, who owns it, how quickly to respond and how to restart safely.
Fill in
EDI Error Escalation Runbook Template
EDI Error Escalation Runbook
Company: Acme Precision Ltd Owner: EDI Coordinator Version: 1.0 Effective: 2026-10-20
Purpose and scope
This runbook describes how EDI errors are detected, classified, escalated and closed so that orders, shipments and invoices keep flowing between Acme Precision Ltd and its trading partners.
Monitoring sources
Translator console, VAN mailbox report, ERP IDoc or staging error screen, daily reconciliation report
Severity levels
| Level | Definition | Response target |
|---|---|---|
| Severity 1 | All EDI traffic down, or a major customer cannot receive ASNs or send orders | 30 minutes |
| Severity 2 | One partner or one document type failing, orders or shipments at risk | 2 hours |
| Severity 3 | Single document error, no immediate shipment impact | 1 business day |
Escalation path
| Level | Who | When to escalate |
|---|---|---|
| Level 1 | EDI analyst on duty, edi-support@acme.example | First response to every alert |
| Level 2 | Integration engineer, +1 555 0101 | Not resolved within response target, or map and connectivity fault |
| Level 3 | IT manager, +1 555 0102 | Severity 1, or no fix within twice the target |
Standard response steps
1. Identify the partner, document type, control numbers and time of failure. 2. Check connectivity, certificate expiry and the 997 or MDN status. 3. Locate the error in the translator and the ERP staging area. 4. Correct the data or map, or contact the partner if the fault is theirs. 5. Resend only after the cause is fixed, following the partner's rule on control numbers. 6. Confirm acknowledgment and that the ERP record is correct. 7. Log the incident and root cause.
Partner communication
Notify the partner when a Severity 1 or 2 incident affects their orders or ASNs. State what failed, which documents are affected, the current status and the next update time. Notify customer service so they can manage expectations on late shipments.
Post-incident review
| Item | Notes |
|---|---|
| Incident date and duration | |
| Documents affected | |
| Root cause | |
| Corrective action | |
| Preventive action and owner |
Approvals
Response targets above are examples. Set them to match your contracts and staffing. Keep the contact list current and test the escalation path periodically.
Unify EDI alerts and ERP errors
Optional: discuss a single monitoring view across translator, VAN and ERP.
Optional. The tool and every export work without this. No spam.
How to use the runbook
Fill in the owner, responders, response targets and the monitoring sources. Export to PDF or Word, review it with customer service and IT, and publish it where the support team can find it quickly. Revisit it after every severity 1 or 2 incident and after any change to partners, platforms or staffing.
- Define severity by business impact, not by technical cause
- Name individuals or on-call roles, not departments
- Include out-of-hours contact details
Choosing severity levels
Severity should reflect what the business loses. A total outage or a customer that cannot receive ASNs may cause chargebacks and stopped shipments within hours. A single rejected invoice can usually wait a day. Write the definitions down so analysts do not argue about them during an incident and so partners understand the commitments you make.
Safe resend practice
Resending is where duplicates are created. Before resending, confirm the original was not partly processed, check whether the partner needs new interchange control numbers, and mark the original as superseded in your log. For orders and invoices, duplicate detection on the PO number or invoice number protects both sides. Document the resend rule per partner in your requirements matrix.
Common mistakes
No one is monitoring the translator over weekends, certificates expire unnoticed, alerts go to a shared mailbox nobody reads, and partner contacts are out of date. Another is fixing the symptom without a root cause review, so the same defect returns. Test the runbook with a mock incident once or twice a year.
Frequently Asked Questions
What should an EDI runbook contain?
Scope, monitoring sources, severity definitions, escalation contacts, response steps, resend rules, partner communication and a post-incident review. It should be short enough to follow under pressure.
How fast should we respond to EDI failures?
It depends on your contracts and the cost of delay. Shipments tied to ASN deadlines justify fast response, often within an hour, while single document errors can wait. Set targets with the business.
Who should own the runbook?
Usually the EDI coordinator or integration team lead, with approval from IT and customer service. One named owner keeps contact lists and procedures current.
Do we need a separate runbook per partner?
A single runbook with partner-specific notes is usually enough. Add per-partner pages only for partners with unusual connections or strict penalties.
Netray can help connect ERP errors, translator logs and partner status into one alerting view if monitoring is currently spread across several consoles.
Related Tools
EDI 997 Functional Acknowledgment Reject Log Worksheet
Log every rejected or partially accepted 997 with the AK3/AK4 error, root cause, owner and resend status, and export it to Excel.
Developer ToolsEDI AS2 Connection Parameters Request Template
A form to exchange AS2 IDs, endpoints, certificates, MDN settings and security options with a trading partner before testing.
Supply Chain & InventoryEDI Partner Test Plan and Sign-Off Template
A test plan document with cases for inbound and outbound transaction sets, pass criteria and go-live sign-off for a new trading partner.
Costing & FinanceEDI Chargeback Dispute Tracker Worksheet
Track compliance chargebacks by partner, reason, dispute deadline and amount recovered, with automatic net loss totals.