What happens to your orders when a system goes down?

It's the busiest trading week of the year.

Orders are arriving from some of your largest customers. The warehouse is operating at full capacity. Customer service is already busy. Every hour matters.

Then something stops working.

Perhaps your ERP becomes temporarily unavailable. Perhaps an integration fails. Perhaps a network problem prevents one system from communicating with another.

For the next six hours, part of your order-processing infrastructure is effectively offline.

The obvious problem is the outage itself, but the more important question is:

What happens to the transactions while you're down?

Because when systems come back online, you don't just need them to work again. You need to know what happened while they didn't.

Six hours can create much more than six hours of work

Imagine an order process that depends heavily on people.

Purchase orders arrive by email. Someone downloads them, checks the information, and enters it into the ERP. Colleagues confirm availability. Picking information is passed to the warehouse, and questions are handled manually when something doesn't look right.

Now interrupt that process.

Orders may continue arriving, but processing stops. The warehouse may not know which orders are ready to pick. Customer service may have limited visibility into what has been received. Buyers start asking for confirmations.

And when the system returns, the backlog begins:

• Which orders arrived first?

• Which have already been processed?

• Did anything get entered twice?

• Was something missed?

• Which customers are waiting for an acknowledgement?

This is why the operational impact of downtime isn't necessarily measured by the duration of the outage.

A six-hour interruption can create a backlog that takes considerably longer to untangle.

Automation isn't only about speed

EDI is usually discussed in terms of efficiency.

Instead of someone reading a purchase order and entering it manually, structured order data can move from the customer's system into the supplier's business systems automatically. That's clearly faster. But there's another benefit that receives less attention:

A well-designed integration creates a controlled transaction flow.

Messages can be identified individually. Their status can be monitored. Failed transactions can be detected. Depending on the architecture, messages can be queued and retried rather than simply disappearing when a receiving system is temporarily unavailable.

Protocols commonly used for B2B exchange, such as AS2, also provide mechanisms for secure transmission and acknowledgements.

The important point isn't that EDI prevents systems from going down. It doesn't.

The point is that when something does fail, you can design the surrounding process so the business has a much clearer answer to questions such as:

What arrived? What was successfully processed? What failed? And what still needs attention?

That's a very different position from reconstructing events from inboxes, spreadsheets, and phone calls.

But EDI isn't automatically resilient

This distinction matters. Connecting two systems doesn't, by itself, create business continuity.

An EDI environment can still have single points of failure. ERP systems can become unavailable, and integrations can fail. Incorrect mappings can reject messages. Certificates can expire. Network problems can interrupt communication.

So resilience has to be designed into the integration. That means thinking beyond the happy path where every order arrives correctly and every connected system is available.

A robust B2B integration setup should also consider what happens when something goes wrong.

Can transactions wait safely if the receiving system is temporarily unavailable, and are failed messages visible?

Who's alerted?

Can a message be retried without creating a duplicate transaction?

Can you see whether the trading partner successfully transmitted the document?

When systems return, can processing resume in a controlled way?

Those questions aren't really about EDI technology. They're about operational resilience.

The dangerous failure isn't always the obvious one

A complete outage is relatively easy to notice since everyone knows when the ERP is down. A more difficult scenario, however, is when most of the process still appears to work.

Imagine 1,000 orders arriving; 997 process successfully, and three don't. There's no dramatic blackout, and the warehouse keeps moving. Customer service carries on. Nobody necessarily notices anything unusual.

But those three orders still belong to customers. That's why monitoring and handling exceptions matter just as much as automation.

The goal shouldn't simply be to automate as many transactions as possible. but to make the exceptions visible when automation can't complete them.

Business continuity starts before the outage

The worst time to decide how failed orders should be handled is while orders are already failing.

Businesses that depend on high-volume B2B transactions should know in advance what happens when a critical component becomes unavailable.

Which transactions can wait?

Where are they held?

How are failures detected, and who receives the alert?

How is processing restarted?

How do you verify that nothing was lost or duplicated?

And how do you communicate with customers while the problem is being resolved?

Those questions become particularly important during peak periods, when the cost of disruption is highest and there is the least capacity for manual recovery.

EDI is infrastructure, not just automation

Saving employees from manually entering orders is valuable. Reducing errors is valuable. Processing invoices faster is valuable.

But once a significant share of your business transactions moves through EDI, the integration becomes something more fundamental.

It becomes part of the infrastructure connecting your business with your customers and suppliers.

And infrastructure shouldn't only be designed for the days when everything works. It should also be designed for the day when something doesn't.

At iEDI, we help businesses build and operate structured B2B integrations between trading partners and business systems, with visibility into the document flows that those operations depend on.

Because the real test of an integration isn't only how efficiently it processes an order when everything is working. It's whether you still know where that order is when something isn't.