Changing an ERP system is a major project. It can improve reporting, simplify workflows and give teams a better foundation for growth, but it also changes the systems that create, receive and process the data your trading partners rely on. For businesses using electronic data interchange (EDI), that makes EDI an important part of the ERP transition plan. Purchase orders, order responses, advanced shipping notices, invoices and other messages may be moving automatically today, but changes to fields, formats, workflows or integrations can affect that flow if they are not considered early. The goal is not to rebuild EDI from scratch every time an ERP changes. It is to understand what’s changing, test the right things and make sure day-to-day trading can continue with minimal disruption.

Start by mapping what EDI depends on today

Before making changes, document how EDI fits into your current environment. It is easy to think of EDI as a connection between two businesses, but internally it often touches several systems and teams.

• Which ERP fields are used to create each EDI message?
• Which messages are sent and received for each trading partner?
• How product, customer, supplier and location data is referenced?
• What business rules and validations are applied?
• Where are acknowledgements, errors and exceptions monitored?
• Which downstream systems rely on the EDI data once it arrives?

This gives the project team a baseline. It also helps identify dependencies that may not be obvious until testing begins.

Look beyond the file format

An ERP migration can change more than whether a file is XML, CSV or another format. The structure of the data can change as well. Field names may be different, product identifiers may be stored differently, optional fields may become mandatory and workflows may create information at a different point in the process. That is where EDI mapping becomes important. Mapping translates the format and structure produced by your software into the format required by your trading partners. If the ERP output changes, the mapping may need to change too. Reviewing this before go-live can help prevent a situation where the new ERP is working internally, but trading documents are failing because a required field is missing, moved or populated differently.

Test complete business scenarios, not just individual messages

A successful connectivity test is a good start, but it does not prove the whole order flow will work as expected. The safest approach is to test the business process from end to end. For example, a retailer and supplier might test a complete scenario that includes:

• sending a purchase order
• receiving and processing the order in the new ERP system
• returning an order response
• creating an advanced shipping notice
• generating the invoice
• confirming each message is accepted and processed correctly at the other end.

It is also worth testing exceptions. Part-filled orders, changed quantities, invalid product codes, cancelled lines and other real-world scenarios can expose issues that a simple happy-path test will miss.

Check master data before cutover

EDI relies heavily on consistent master data. Product codes, GLNs, supplier identifiers, customer numbers, units of measure and delivery locations need to line up across systems and trading partners. During an ERP migration, master data is often cleaned up or restructured. That can be beneficial, but any identifier changes that affect EDI need to be coordinated. A new customer code in the ERP, for example, may need to be reflected in a mapping or trading-partner configuration before transactions can flow correctly. Treat master data as part of the EDI workstream, rather than assuming it sits only within the ERP project.

Plan the cutover around real trading activity

ERP projects often have a technical cutover plan. EDI needs an operational cutover plan as well. Think about what happens to transactions that are already in flight when the switch occurs.

• Will orders created in the old ERP still need responses from the new ERP?
• How will invoices be handled for goods shipped before cutover?
• What happens to messages received during a planned system outage?
• Who will monitor failed or delayed messages immediately after go-live?

For retailers, suppliers and manufacturers, timing matters. Avoiding a cutover during peak trading periods can reduce risk, but even outside peak periods, teams should know how open orders and outstanding documents will be handled.

Keep your trading partners in the loop

Not every ERP change will require action from every trading partner, but communication is still important when testing or identifiers are changing. Let the affected partners know what is happening, what they need to test, if anything, and when the production change will occur. Clear communication is particularly useful when a retailer has a large supplier community. A structured testing process can reduce back-and-forth and make it easier to confirm that each supplier is ready before the change goes live.

Monitor closely after go-live

The first few days after cutover are when small issues can become operational problems if they are not picked up quickly. Monitor message volumes, acknowledgements and exceptions closely, and compare them with normal trading patterns. Useful checks include whether expected purchase orders are being sent, whether order responses and ASNs are arriving, whether invoices are being accepted and whether any trading partner is experiencing an unusual level of failures. This lets the team deal with genuine exceptions quickly instead of waiting for a supplier, customer or finance team to report that something has gone missing.

Your ERP can change without disrupting your EDI

An ERP migration is a significant change, but it does not need to interrupt the way you trade electronically. The key is to treat EDI as part of the project from the beginning, rather than something to check at the end. By understanding existing dependencies, reviewing mappings and master data, testing complete workflows and planning the cutover carefully, businesses can move to a new ERP with greater confidence that orders, deliveries and invoices will keep moving.If you are planning an ERP change and want to understand what it could mean for your EDI setup, MessageXchange can help with integration, mapping and testing. Get in touch with our EDI experts.

Request a call

Chat with one of our experts

Just fill out your details below and we'll be in touch within one business day.

When something goes wrong in the supply chain, speed matters. Whether it is a product recall, a shipment discrepancy or a batch that needs to be isolated, businesses need to know what moved, where it went and which trading partners were involved. Electronic data interchange (EDI) can help create that digital trail as part of everyday trading. For Australian and New Zealand businesses, traceability is particularly important in sectors such as food, grocery, pharmaceuticals and retail. In Australia, Food Standards Australia New Zealand (FSANZ) reported 92 food recalls during 2025, above the 10-year average of 87. The point is not that EDI prevents every recall. It is that structured, timely transaction data can make it easier to identify affected products, trading partners and movements when action is required.

What does traceability mean in an EDI environment?

Traceability is the ability to follow products and related information through the supply chain. EDI supports this by creating consistent electronic records as business documents move between systems. Instead of relying on emails, spreadsheets or paper records, organisations can build a history of transactions that is easier to search and reconcile. Depending on the EDI process, that history can include:

• purchase orders showing what was ordered and when
• order responses confirming what a supplier can fulfil
• advanced shipping notices (ASNs) showing what is being despatched
• SSCC information identifying logistics units such as pallets or cartons
• invoices connecting the financial transaction back to the original order
• timestamps, message status and other transaction history held within the EDI platform.

Why this matters when a recall or issue occurs

When a product issue is identified, teams often need to answer several questions quickly: Which product or batch is affected? Which customers received it? When was it shipped? How much product is still in the network? Which orders or deliveries are connected to it? If that information is spread across inboxes, PDFs and different systems, getting a reliable answer can take time. EDI does not replace a formal recall or traceability system, but it can provide a strong digital data source to support it.

1. Create a consistent transaction trail

EDI messages follow defined structures and business rules. That consistency makes it easier to connect one transaction to another. A purchase order can be linked to an order response, despatch advice and invoice, giving teams a clearer picture of the end-to-end transaction rather than isolated documents.

2. Improve shipment-level visibility with ASNs and SSCCs

Advanced shipping notices can tell a customer what is coming before the physical delivery arrives. When SSCC labels are used, individual logistics units can also be identified and scanned through receiving and warehouse processes. This can help narrow the scope of an investigation and support faster identification of affected stock.

3. Reduce the time spent piecing records together

In a manual environment, a recall investigation can involve checking purchase orders, delivery records, emails and invoices separately. With integrated EDI, much of that information is already available electronically and can flow into ERP, warehouse or other business systems. That gives teams a stronger starting point when time is critical.

4. Support communication across trading partners

Traceability is not only an internal process. Retailers, suppliers, manufacturers and logistics providers may all need to share information. Standardised EDI messages can help keep that exchange consistent and reduce reliance on rekeying information between systems.

What data should you think about capturing?

The value of EDI for traceability depends on the quality and detail of the data being exchanged. It is worth reviewing whether your EDI messages capture the identifiers your business would need during an investigation.

• product identifiers such as GTINs or retailer item numbers
• purchase order and shipment references
• batch or lot information where relevant to the process
• quantities and dates
• supplier, customer and delivery location identifiers
• SSCCs for logistics units
• clear message status and exception information.

Not every trading relationship will use every field. The important part is making sure the data exchanged supports the way your business actually needs to track goods and transactions.

Make traceability part of normal EDI design

Traceability is easiest when it is built into everyday processes rather than treated as something to reconstruct after an incident. When designing or reviewing an EDI setup, consider the full document flow, the identifiers carried between messages and where that information is stored once it enters your systems. It is also worth testing the process. Can your team locate a shipment from its order number? Can you identify the ASN connected to a delivery? Can you see which trading partner received a particular transaction? A practical test can highlight gaps before they become urgent.

A stronger digital trail across the supply chain

EDI is often introduced to remove manual data entry and speed up procurement. But the same structured data can also strengthen visibility and traceability across the supply chain. For businesses handling high volumes of products and transactions, that digital trail can become an important part of operational readiness.If you want to review how your EDI setup supports traceability across orders, shipments and invoices, get in touch with the MessageXchange team.

Request a call

Chat with one of our experts

Just fill out your details below and we'll be in touch within one business day.