EDI isn’t an IT project. It’s an operations project.

Ask IT what EDI does, and they’ll probably talk about integrations.

Ask customer service, and they’ll talk about orders.

Ask the warehouse, and they’ll talk about shipments.

Ask finance, and they’ll talk about invoices.

They’re all talking about the same infrastructure, and that's one of the easiest things to overlook about EDI.

Because EDI connects systems, it's often treated as an IT responsibility. IT helps select the solution, connects the ERP, manages technical requirements, and gets called when something stops working. But the information moving through those connections belongs to the business.

Purchase orders. Order confirmations. Shipping information. Invoices. Product data. EDI may be technical infrastructure. But what flows through it is operations.

The technical connection is only the beginning

Imagine that a customer sends you a purchase order electronically. From an IT perspective, the objective may seem relatively straightforward: receive the message, translate it into the required format, and get the data into the ERP. But what happens next?

Customer service needs the order to contain the right products, quantities, prices, and delivery information.

The warehouse needs to know what to pick, where to send it, and when.

Logistics may need to create the correct shipping information and labels.

Finance eventually needs an invoice that corresponds with what was ordered and delivered.

And the customer expects the information coming back to follow their requirements. One electronic purchase order can therefore pass through processes owned by several different parts of the business.

The integration enables that journey, but it doesn’t define whether the journey makes sense.

Customer service experiences EDI as orders

Customer service teams probably don't spend much time thinking about EDI standards. They do notice when an order doesn't appear.

Or when it arrives with the wrong customer number.

Or when a product code can't be recognised.

Or when somebody has to manually correct information that was supposed to arrive automatically.

From their perspective, EDI isn't an integration - it's the mechanism that determines whether an order can move through the business without intervention.

When it works well, that may mean fewer orders to enter manually, fewer transcription errors, and less time spent checking information. When it doesn't, the problem quickly becomes operational.

Someone has to investigate, correct the order, and maybe even contact the customer. Suddenly, an automated process has created manual work.

The warehouse experiences EDI as physical goods

Then there's the warehouse.

This is where something interesting happens to digital information: it becomes physical. An order in an ERP eventually turns into products being picked, packed, labelled, and shipped. 

That means the quality of the data exchanged electronically can affect what happens on the warehouse floor.

A customer may require a specific delivery reference.

A retailer may expect an advance shipping notice before the goods arrive.

A logistics unit may need an SSCC label that corresponds with the information transmitted electronically.

If those processes don't line up, the problem isn't confined to the EDI platform. It can affect goods receipt, shipment matching, and the customer's ability to process a delivery efficiently. The digital transaction and the physical supply chain are two parts of the same process.

Finance experiences EDI as money

Finance sees yet another side. An invoice may be generated automatically from the ERP and sent electronically to the customer. But whether that invoice is accepted depends on much more than whether the file was transmitted successfully.

Does it reference the correct purchase order?

Do quantities and prices match?

Is the customer's required information present?

Has the invoice been created in the format the customer expects?

Increasingly, there may also be country-specific e-invoicing requirements to consider.

A technically successful transmission isn't particularly valuable if the invoice is subsequently rejected or can't be processed, and if invoice problems delay approval, an integration issue can eventually become a cash-flow issue.

IT sees all of it – but shouldn't have to own it all

None of this makes IT less important. Quite the opposite.

ERP connectivity, data transformation, communication protocols, security, monitoring, and system architecture all require technical expertise.

Modern EDI platforms exist precisely because ERP systems are primarily designed to run internal business processes, while external trading partners bring their own document formats and requirements.

But there's a difference between owning the technology and owning the business process. IT can make sure a purchase order reaches the ERP, but it shouldn't necessarily decide what should happen when the customer sends an unknown product number.

IT can enable an advance shipping notice. The warehouse and logistics teams understand when that information needs to be generated and what needs to happen before it can be sent.

IT can connect the invoicing flow.

Finance understands what needs to happen when an invoice doesn't match the original order.

The best EDI implementations therefore aren't purely technical projects. They bring technical and operational knowledge together.

This becomes especially obvious when something changes

EDI processes rarely remain completely static:

• A customer changes its specification.

• A new trading partner needs to be onboarded.

• The business changes ERP system.

• A warehouse process changes.

• A new country introduces mandatory e-invoicing.

• Or somebody discovers that a manual workaround has quietly become part of the process.

That's when ownership matters.

If EDI is understood only as an IT integration, every change risks being translated immediately into a technical task. But sometimes the first question shouldn't be how to change the integration. Rather, it should be "What should the business process actually do?"

Once that's clear, the technical requirement becomes much easier to define.

Good EDI can be almost invisible

There's a paradox at the heart of EDI. The better it works, the less most people notice it.

Orders simply appear; shipments are processed; invoices go out; customers receive the information they expect.

People can focus on exceptions instead of repeatedly moving data from one system to another. That invisibility can make EDI look like background technology, but in reality, it's supporting some of the most fundamental processes in the business.

• Order-to-cash.

• Procure-to-pay.

• Warehouse operations.

• Customer relationships.

• Financial administration.

• Supply chain collaboration.

The technology sits underneath them. The value happens above it.

So who should own EDI?

There isn't necessarily one universal answer. The technical platform may sit with IT. Day-to-day EDI management may sit with an integration team.

Customer onboarding may involve sales or customer service. Invoice processes may involve finance, and shipping requirements may involve logistics.

What matters is that EDI isn't treated as something that happens only inside IT.

The people who understand the processes should be involved in defining them.

The people who understand the systems should make those processes work technically, and the EDI setup should connect the two. That is, an EDI integration can be technically perfect and still create a poor business process.

The real objective isn't simply to move a message successfully from system A to system B - it's to make the transaction work from beginning to end.

At iEDI, we help businesses connect ERP systems, customers, suppliers and other trading partners through EDI and e-invoicing – while handling the mappings, formats and partner-specific requirements that sit between them.

EDI may connect your systems. But its real job is to connect your operations.