What actually happens after your customer sends an EDI order?

A customer places an order.

A few moments later, it appears in your ERP system without email attachment nor a  PDF to open. No order for someone to manually enter.

From the outside, that can make EDI look remarkably simple. Information leaves one system and appears in another, but the purchase order is really only the beginning of a much longer conversation between two businesses.

The order needs to be understood by your systems. You may need to confirm what you can deliver. The warehouse needs information about what to pick and ship. The customer may want to know what's coming before it arrives. And eventually, the transaction needs to become an invoice.

Behind what looks like a single automated order is therefore a sequence of structured business documents moving back and forth. Following that sequence is one of the easiest ways to understand what EDI actually does.

It starts inside the customer's system

Imagine that one of your retail customers needs 200 units of a product.

Their buyer creates a purchase order in their ERP or purchasing system, just as they would for any other order. It contains the information you would expect: product identifiers, quantities, prices, delivery dates, locations, and a purchase order number.

Without EDI, that information might reach you as an email, PDF or perhaps even through a customer portal. Someone on your side may then need to read the order and enter the relevant information into your own ERP.

With EDI, the information can instead leave the customer's system as a structured electronic purchase order. That distinction matters.

The purpose isn't simply to send the same document electronically. It's to make the information inside the document understandable to another system. But there is a complication: your customer's system and your system don't necessarily speak the same language.

The order needs translating before your ERP can understand it

Your customer may use one EDI standard while your ERP expects a completely different internal structure.

Even when two businesses use the same standard, their requirements can differ. Product identifiers, customer numbers, delivery locations, date formats, and mandatory fields may all be represented differently.

This is where the EDI layer sits between the two businesses. It receives the customer's structured message, validates it, and transforms the information into the format your ERP expects.

The customer's product identifier may need to be translated into your own item number. A delivery location might need to be matched with the corresponding customer record. Fields may need to be reformatted or mapped to different places in your ERP.

Once that work has happened, the order can enter your business system automatically. To the person working in customer service, it may simply look as though an order has appeared.

Behind the scenes, two very different systems have successfully understood one another.

Then your business needs to answer

Receiving an order isn't necessarily the end of the conversation.

Can you deliver everything the customer requested? Is the requested delivery date possible? Has anything changed?

Depending on the trading relationship, your business may send an electronic order response or order acknowledgement back to the customer.

This allows the customer's system to receive confirmation without somebody manually writing an email or updating a portal.

The important point is that EDI isn't simply a one-way mechanism for customers to push orders into your ERP. Rather, it creates a structured conversation between systems.

The customer says:

"This is what we would like to buy."

Your system can respond:

"This is what we can deliver."

And both sides can update their processes using the information exchanged.

The digital order eventually becomes a physical shipment

At some point, the transaction leaves the purely digital world.

The goods need to be picked, packed, and shipped.

This is where the relationship between EDI and warehouse operations becomes particularly visible. The order information that arrived electronically can drive the warehouse process. Products are picked according to the order, packed for the appropriate destination, and prepared for shipment.

But the flow of information doesn't have to stop when the truck leaves the warehouse.

Many customers – particularly larger retailers, distributors, and wholesalers – expect an advance shipping notice, sometimes referred to as an ASN or despatch advice.

This tells the customer what is actually on its way before the physical shipment arrives.

It might contain information about the products and quantities being shipped, the expected delivery, packaging hierarchy, or logistics units included in the shipment.

Where SSCC labels are used, the digital shipping information can also be linked to the physical pallet or logistics unit through its unique SSCC identifier. The result is a connection between the information travelling electronically and the goods travelling physically.

When the shipment reaches the customer's warehouse, they aren't necessarily seeing it for the first time. Their systems may already know what is coming.

The invoice completes another part of the conversation

Once the goods have been shipped, the financial side of the transaction follows.

An invoice can be generated from your ERP and sent electronically to the customer. Again, the value isn't simply that the invoice travels without paper.

Since the invoice data is structured, the customer's systems can use information such as the purchase order number, product identifiers, quantities, and prices to match the invoice against the transaction that came before it:

• The customer ordered something

• You confirmed it

• You told them what you shipped

• Now you're telling them what they need to pay

Those aren't four isolated documents; they're different stages of the same business transaction.

When the information across them is consistent, much of the process can happen automatically. When it isn't, somebody usually needs to investigate.

This is why data quality matters so much in EDI

Automation is extremely good at processing information according to rules, but it's considerably less forgiving when the information doesn't make sense.

If the purchase order contains a product identifier your system can't recognise, the order may need attention.

If the shipping information doesn't correspond with what the customer expects, goods receipt can become more difficult.

If an invoice references the wrong purchase order or contains a price that doesn't match the agreed information, automated invoice matching may fail.

This is why a successful EDI implementation isn't only about establishing a technical connection.

The documents need to work together as part of the underlying business process. The better the data is at the beginning of the journey, the easier it becomes to automate what happens afterwards.

Not every business uses the same document journey

The purchase order, order response, shipping notice and invoice make a useful example, but they aren't a universal EDI sequence. Different industries and trading relationships require different documents.

Some customers may only exchange orders and invoices. Others may require inventory reports, sales reports, price catalogues, delivery schedules, credit notes, or detailed logistics information.

The terminology can also vary between EDI standards. What matters, then, is the principle behind them.

Instead of people repeatedly reading documents and transferring information between systems, businesses exchange structured data that their systems can process.

EDI provides the infrastructure for those systems to have that conversation.

EDI is less about documents than it first appears

We often describe EDI in terms of document types: purchase orders, invoices, ASNs, and order responses.

That's useful because these are recognisable business documents.

But underneath them, EDI is really about business events.

A customer has ordered something.

The supplier has accepted the order.

The goods have been shipped.

The customer needs to be invoiced.

EDI turns each of those events into structured information that can move from one organisation's systems to another.

And when the process works well, the people involved don't need to spend their time moving that information manually.

They can focus on the exceptions – the order that can't be fulfilled, the shipment that has changed or the invoice that genuinely needs investigation.

One order can tell the whole EDI story

From the customer's perspective, they placed an order. From your perspective, an order appeared in the ERP.

Between those two moments – and everything that follows – there is an infrastructure quietly translating, validating, and exchanging information between businesses. That's why EDI is much more than a way of sending purchase orders electronically.

It connects the different stages of a commercial transaction, from the moment a customer decides to buy something to the moment the supplier gets paid.

At iEDI, we help businesses connect their ERP systems with customers, suppliers, and other trading partners, transforming structured business documents so information can move automatically between different systems and requirements.

Because the real value of EDI isn't that one document gets from A to B.

It's that the entire transaction can keep moving.