# EDI Error Escalation Runbook Template > Source: https://netray.co/tools/edi-error-escalation-runbook-template > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A runbook defining what counts as an EDI incident, who responds, how fast, and how to resend and communicate with trading partners. ## Category erp-operations ## Audience - EDI coordinator - IT service desk - Operations manager ## Tool **Kind:** template **Output:** document **Fields:** #### Company **Key:** company **Type:** text **Default:** Acme Precision Ltd #### Runbook owner **Key:** owner **Type:** text **Default:** EDI Coordinator #### Version **Key:** version **Type:** text **Default:** 1.0 #### Effective date **Key:** date **Type:** date **Default:** 2026-10-20 #### Level 1 responder **Key:** l1 **Type:** text **Default:** EDI analyst on duty, edi-support@acme.example #### Level 2 responder **Key:** l2 **Type:** text **Default:** Integration engineer, +1 555 0101 #### Level 3 / management **Key:** l3 **Type:** text **Default:** IT manager, +1 555 0102 #### Severity 1 response target **Key:** sev1 **Type:** text **Default:** 30 minutes #### Severity 2 response target **Key:** sev2 **Type:** text **Default:** 2 hours #### Severity 3 response target **Key:** sev3 **Type:** text **Default:** 1 business day #### Monitoring tools **Key:** tools **Type:** textarea **Default:** Translator console, VAN mailbox report, ERP IDoc or staging error screen, daily reconciliation report **Blocks:** #### EDI Error Escalation Runbook **Body:** Company: {{company}} Owner: {{owner}} Version: {{version}} Effective: {{date}} #### Purpose and scope **Body:** This runbook describes how EDI errors are detected, classified, escalated and closed so that orders, shipments and invoices keep flowing between {{company}} and its trading partners. #### Monitoring sources **Body:** {{tools}} #### Severity levels **Table:** **Columns:** - Level - Definition - Response target **Rows:** **0:** Severity 1 **1:** All EDI traffic down, or a major customer cannot receive ASNs or send orders **2:** {{sev1}} **0:** Severity 2 **1:** One partner or one document type failing, orders or shipments at risk **2:** {{sev2}} **0:** Severity 3 **1:** Single document error, no immediate shipment impact **2:** {{sev3}} #### Escalation path **Table:** **Columns:** - Level - Who - When to escalate **Rows:** **0:** Level 1 **1:** {{l1}} **2:** First response to every alert **0:** Level 2 **1:** {{l2}} **2:** Not resolved within response target, or map and connectivity fault **0:** Level 3 **1:** {{l3}} **2:** Severity 1, or no fix within twice the target #### Standard response steps **Body:** 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 **Body:** 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 **Table:** **Columns:** - Item - Notes **Rows:** **0:** Incident date and duration **0:** Documents affected **0:** Root cause **0:** Corrective action **0:** Preventive action and owner #### Approvals **Signatures:** - Runbook owner - IT manager - Customer service manager **Notes:** Response targets above are examples. Set them to match your contracts and staffing. Keep the contact list current and test the escalation path periodically. ## Content **Intro:** 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. **Sections:** #### How to use the runbook **Body:** 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. **Bullets:** - 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 **Body:** 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 **Body:** 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 **Body:** 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. **Cta:** Netray can help connect ERP errors, translator logs and partner status into one alerting view if monitoring is currently spread across several consoles. **Faq:** #### What should an EDI runbook contain? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** A single runbook with partner-specific notes is usually enough. Add per-partner pages only for partners with unusual connections or strict penalties. ## Search terms edi support runbook, edi incident response template, edi escalation procedure, edi error handling procedure, b2b integration runbook, edi monitoring sop --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json