Contents
Orders may continue to arrive while an ERP system is unavailable for six hours. The real risk is not knowing which orders were processed, which are still pending and which were submitted twice after the system comes back. EDI business continuity is the operating model that preserves the trace of every message throughout an outage and enables a controlled recovery.
This model goes beyond a server backup. Orders, dispatch notices and invoices have different business impacts. The operations team should define in advance the waiting threshold, alert owner, reprocessing method and reconciliation evidence for each document type.
Contents
- Why does an EDI outage not end when the system restarts?
- How are RTO and RPO translated into message-flow targets?
- Which gaps does the four-record test reveal?
- How should retry, resend and reprocess be distinguished?
- How can a manufacturer in Türkiye manage an outage?
- How should an EDI continuity plan be tested?
Why Does an EDI Outage Not End When the System Restarts?
An EDI flow passes through transport, transformation, business-rule and target-application layers. An AS2 connection may be working while the ERP rejects the order. The mapping may finish while the trading partner's acknowledgment never arrives. A connection shown in green does not prove that the business transaction has been completed.
In Uptime Institute's 2025 research, IT and network issues accounted for 23 percent of impactful outages in 2024. Among respondents who reported the cost of their most recent outage, 20 percent cited more than USD 1 million, while 37 percent reported a range of USD 100,000 to USD 1 million. These figures do not measure EDI outages alone; they illustrate the financial dimension of recovery discipline in digital operations.
For EDI, recovery is not complete when the technical service restarts. The pending queue must be counted, messages that reached the counterparty must be separated and the result must be reconciled with ERP records. Otherwise, the team may process the same order twice or fail to notice a dispatch notice that disappeared silently.
NIST's EDI security guidance recommends using transaction logs and status feedback to identify lost, incorrectly processed or duplicate messages. It also treats recovery from a network failure without skipping or duplicating messages as a separate control.
How Are RTO and RPO Translated into Message-Flow Targets?
RTO defines how long a system can remain unavailable before the impact becomes unacceptable. RPO indicates how much data may acceptably need to be recreated during recovery. A single “EDI RTO” conceals the different impacts of individual document flows.
An automotive production schedule, a retail order and a period-end invoice may not have the same time limit. Operations should set separate targets by document type, trading partner and intraday cut-off. ISO/TS 22317 calls for business impact analysis to identify products, services, dependencies, RTO and appropriate RPO requirements together.
A practical decision sequence is:
- Which business outcome does the outage stop: production, picking, shipping, collection or reporting?
- After how many minutes or hours does the impact become unacceptable?
- Are messages held in a secure queue, and can its capacity cover the target duration?
- During recovery, which control number and acknowledgment identify the last known-good point?
- Which documents require manual approval if the processing order is disrupted?
NIS2 Article 21(2)(c) groups business continuity, backup management, disaster recovery and crisis management within the same set of measures. Commission Implementing Regulation 2024/2690 also requires a written plan covering recovery order, objectives, resources and the return from temporary measures to normal operations. Even where a company is outside the scope of NIS2, this structure can be used to measure EDI dependencies.
Which Gaps Does the Four-Record Test Reveal?
Verify the fate of an EDI message using four records. If any one is missing, the continuity plan has a visibility gap.
- Identity: Are message ID, control number, sender, recipient and document type recorded?
- Time: Can you see receipt, transformation, target-system transfer and acknowledgment times?
- Status: Are technical delivery and business acceptance stored as separate states?
- Action: Is the person who acted after an error, the reason for a retry or resend and the outcome recorded?
This test does not treat a “file sent” record as sufficient evidence. An X12 997 or EDIFACT CONTRL, for example, reports a particular level of technical acceptance. It does not always prove that the trading partner accepted business content such as quantity, price or delivery date.
MAP Monitor, MAP's EDI monitoring and tracking solution, presents the current status and history of incoming and outgoing documents in one place. Authorised suppliers can also access the same data. This visibility helps teams work from a shared message record during an incident. Queuing, automatic retry and disaster-recovery behaviour must still be verified separately for the integration architecture in use.
How Should Retry, Resend and Reprocess Be Distinguished?
An incorrect repetition can create a data problem more expensive than the outage itself. Processing a purchase order twice may cause excess production. A duplicate invoice creates additional accounting and reconciliation work.
Separate the three actions:
- Retry: The transfer did not complete and there is evidence that the message did not reach the recipient. The same technical delivery is attempted again.
- Resend: The recipient rejected the message. The data is corrected, the version and control number are managed according to the applicable rule, and the document is sent again.
- Internal reprocess: The EDI layer completed acceptance, but the ERP, WMS or another target application rejected processing. The message is processed again internally without being sent outside the company.
Microsoft's EDI disaster-recovery guidance recommends synchronising X12 and EDIFACT control numbers across regions. The purpose is to avoid generating duplicate control numbers after switching to a secondary environment. SAP Business Network documentation likewise shows that retry and acknowledgment behaviour can vary by connection type. Instead of making assumptions for every platform, check the product documentation and the trading-partner agreement.
The decision record should contain the original message ID, error layer, evidence of delivery to the counterparty, selected action and new message ID. Put an upper limit on automatic retry attempts. If the same error occurs repeatedly, move the message to a review queue and route it to the responsible team.
How Can a Manufacturer in Türkiye Manage an Outage?
Consider a hypothetical automotive supplier in Bursa. During one shift, the company processes 600 ORDERS, 420 DESADV and 180 INVOIC messages. Its ERP connection is unavailable for 90 minutes while the EDI gateway continues to receive messages.
The team first fixes the last successful control number at the start of the outage. New ORDERS messages are held in a secure queue. Orders affecting the production plan are sorted by trading partner and delivery time. DESADV records for imminent shipments are placed on a second worklist. INVOIC messages can wait in a controlled state until the financial cut-off.
When the ERP becomes available, releasing the entire queue with one command is risky. The team first processes five ORDERS messages and compares their status with the ERP records. If the control succeeds, it continues in small batches. After each batch, accepted, rejected and pending counts are recorded.
Four reconciliations follow: the number of messages received by the gateway, the number transformed, the business records created by the ERP and the acknowledgment messages sent. When the counts do not match, the difference is investigated at message-ID level. The 90-minute outage therefore does not turn into an uncertain data-cleanup exercise.
This scenario is not a capacity promise. Each organisation should define queue limits, shift volume and priority order through its own business impact analysis.
How Should an EDI Continuity Plan Be Tested?
Uptime Institute reports that approximately 40 percent of organisations experienced a major human-error-related outage over the previous three years. Of those incidents, 85 percent were associated with failure to follow procedures or with procedural defects. Leaving a written plan untested is therefore a measurable risk.
Schedule a 60-to-90-minute exercise every quarter. In the test environment, stop ERP access or introduce a specific mapping error. Do not use real customer data. The team should time how quickly the alert appears, an incident owner is assigned, the pending-message list is produced and controlled recovery is completed.
Keep the following evidence after the exercise:
- Expected and actual RTO
- Age of the oldest message remaining in the queue
- Number of lost, duplicate and out-of-sequence messages
- Time between the first alert and owner assignment
- Time required to complete reconciliation
- Procedures, mappings or alert rules to be updated
As a first implementation step, choose the three document flows with the highest business impact. For each one, document how to find the last known-good record and which counts must match during controlled recovery. You can follow EDI business continuity together with other integration and supply chain topics on the MAP Blog.
