Your customer wants EDI. Who actually needs to be involved?

It often starts with a relatively straightforward request.

One of your customers announces that they want to exchange orders and invoices through EDI. Perhaps they're introducing new supplier requirements, replacing an existing system, or expanding their automated purchasing processes.

From the customer's perspective, the request may sound simple: Can you support EDI?

But inside your business, that question can quickly lead to several others.

Who needs to approve the project? Can your ERP handle the required information? Does the warehouse need to change anything? Who understands the customer's document requirements? And who will make sure everything works before the first live order arrives?

It's tempting to hand the request to IT and consider the matter underway. After all, EDI involves connecting systems and exchanging data.

But a successful implementation depends on more than establishing a technical connection. It requires several parts of the business to agree on how information should move through the entire order-to-invoice process.

And understanding who needs to be involved from the beginning can make a considerable difference to how smoothly the project progresses.

The first challenge is understanding what the customer actually wants

Before anyone starts building an integration, someone needs to understand the customer's requirements.

That responsibility often falls to the account manager, customer service team, or another colleague who manages the commercial relationship.

The customer may say they require EDI, but that doesn't necessarily tell you which business documents need to be exchanged, what information those documents must contain, or how the process is expected to work.

Are they asking for electronic purchase orders and invoices? Do they also expect order responses or advance shipping notices? Are there specific requirements for delivery locations, product identifiers, packaging information, or logistics labels?

The answers matter because different documents affect different parts of your business.

An electronic purchase order primarily concerns how orders enter your ERP. An order response may depend on order management and stock availability. An advance shipping notice involves warehouse and logistics processes, while an electronic invoice brings finance into the picture.

A customer request that initially sounds like one integration can therefore involve several interconnected workflows.

This is why the commercial team plays an important role early in the project. They help establish what the customer expects, clarify deadlines, and ensure the right requirements reach the people responsible for implementation.

IT understands the systems. Operations understands the process.

Once the requirements are clear, the technical work can begin.

IT or the company's ERP specialists will typically need to understand how information can enter and leave the internal systems. They may be involved in identifying integration interfaces, assessing data structures, arranging access, and supporting testing.

But technical compatibility is only part of the picture.

Consider an incoming purchase order. IT may be able to explain how the ERP receives order data, but customer service or order management often understands what makes an order valid in practice.

What happens if the customer uses an unfamiliar product number? How should a different delivery address be handled? What if the requested quantity doesn't match the available stock? Should an order be accepted automatically, or are there circumstances where someone needs to review it?

These are operational questions, not simply technical ones.

The same distinction applies to outgoing documents. An ERP may be technically capable of generating an order response, but the business still needs to decide when that response should be sent and what information it should contain.

The integration needs to reflect how the business actually works, not just how its systems are configured.

That requires cooperation between the people who understand the technology and the people who understand the process.

The warehouse may be more involved than expected

Warehouse involvement is particularly important when the customer requires shipping-related EDI documents.

An advance shipping notice, for example, tells the receiving customer what goods are on their way. Depending on the customer's requirements, it may include quantities, packaging information, pallet identifiers, and other shipment details.

For that information to be accurate, the EDI process needs to reflect what actually happens in the warehouse.

Imagine that a customer orders 100 units, but only 80 are available for shipment. The warehouse processes the available quantity and prepares the goods for dispatch.

If the shipping notice is generated using the original order quantity rather than the actual shipment, the customer's system may expect goods that aren't arriving.

Similarly, if a customer requires SSCC labels, the business needs to ensure that the identifiers on the physical logistics units correspond with the information sent electronically.

These requirements can affect picking, packing, labelling, and shipment confirmation.

That's why warehouse or logistics colleagues should be involved when the EDI scope includes their processes. They can help determine where the necessary information originates, when it becomes available, and how the electronic messages should reflect physical operations.

Without that involvement, an integration can appear technically successful while creating problems further down the supply chain.

Finance needs to be part of the conversation too

Invoices are often treated as the final document in an EDI implementation, but they shouldn't be an afterthought.

Finance needs to understand how invoices are generated, what information customers require, and how the electronic process fits with existing accounting procedures.

For example, a customer may expect invoices to reference specific purchase order numbers, delivery locations, or other identifiers. If that information isn't consistently available in the ERP, the invoice may be rejected or require manual investigation.

Credit notes, tax information, payment terms, and invoice corrections may also need attention, depending on the scope of the integration.

And for businesses operating internationally, country-specific e-invoicing requirements can introduce additional considerations.

The finance team's involvement helps ensure that the information exchanged electronically isn't only technically valid but also consistent with the underlying financial process.

After all, successfully sending an invoice doesn't necessarily mean the customer can process it without problems.

Who coordinates everything?

With several departments involved, another question becomes important: who's responsible for bringing the project together?

This is where many implementations can become unnecessarily difficult.

IT may be waiting for customer requirements. Customer service may assume the EDI provider is handling everything. The warehouse may not know that a new shipping document is required. Finance may only discover a missing invoice field during final testing.

None of these situations necessarily reflects a lack of effort. They often happen because responsibilities were never clearly established.

An internal project owner can help prevent that.

The person doesn't necessarily need to be an EDI specialist. Their role is to coordinate the people involved, make sure decisions are made, and ensure that outstanding questions don't disappear between departments.

They should also maintain a clear relationship with the EDI provider and the customer's implementation team.

When a requirement needs clarification, someone should know who to contact. When testing reveals a problem, someone should know who's responsible for resolving it. And when the project approaches go-live, someone should be able to confirm that the relevant business processes are ready.

Clear ownership doesn't eliminate implementation challenges, but it makes them much easier to manage.

The EDI provider connects more than systems

An experienced EDI provider can help bridge the gap between the customer's requirements and the supplier's internal environment.

That typically involves understanding the relevant document formats, communication methods, mappings, and trading partner specifications.

But the value also lies in translating technical requirements into practical implementation decisions.

If a customer requires a particular field in an order response, for example, the question isn't only where that field belongs in the EDI message. It's also where the information comes from inside the supplier's business and whether it can be generated reliably.

Likewise, when testing reveals an error, the issue may originate in the mapping, the ERP data, the customer's specification, or the business process itself.

Resolving it efficiently requires understanding how those elements fit together.

This is why cooperation between the EDI provider, internal stakeholders, and the trading partner is so important.

A provider can manage much of the technical complexity, but the business still needs to contribute the operational knowledge that makes the integration meaningful.

Testing is where everyone’s assumptions meet reality

An EDI connection may be technically established long before the business is ready to use it.

Testing is the stage where the agreed requirements need to work together in practice.

Can the ERP receive a purchase order with the expected product and delivery information? Does the order response accurately reflect what the business can fulfil? Does the shipping notice correspond to the goods leaving the warehouse? Can the customer's system accept the invoice?

These questions can't always be answered through technical testing alone.

Business users need to confirm that the information is correct and that the resulting processes make sense.

Testing should also consider realistic exceptions rather than only ideal transactions. Orders may contain unfamiliar identifiers, quantities may change, deliveries may be split, and documents may fail validation.

The objective isn't to prove that every possible situation will work automatically.

It's to understand how the integration behaves in normal operations, where exceptions are likely to occur, and how those exceptions will be handled.

That preparation can prevent a successful technical go-live from becoming a difficult operational one.

Not every department needs to attend every meeting

All of this might make an EDI implementation sound like a project requiring the entire organisation.

It doesn't. The people involved should reflect the actual scope of the integration.

If a customer only requires electronic purchase orders, the project may primarily involve customer service, IT, or ERP specialists and the EDI provider.

If the requirements include shipping notices, SSCC labels, and electronic invoices, warehouse and finance involvement becomes much more important.

The goal isn't to create more meetings or involve departments unnecessarily. It's to identify the people whose knowledge or decisions are needed before their absence becomes a bottleneck.

A short conversation with the right colleague early in the project can prevent considerably more work later.

Successful EDI onboarding starts before the technical connection

When a customer requests EDI, the natural instinct is to focus on the connection.

Which format do they use? Which communication method is required? How will the messages reach the ERP?

Those questions matter, but they aren't the whole implementation.

The business also needs to understand what the customer expects, where the necessary information comes from, how its internal processes should respond, and who's responsible when something doesn't work as intended.

When those questions are answered early, the technical work has a much stronger foundation.

At iEDI, we help businesses connect their ERP systems with customers and suppliers, managing the exchange and transformation of business documents across different systems and trading partner requirements.

Because implementing EDI isn't simply about getting two systems to communicate.

It's about making sure the businesses behind those systems understand one another, too.