The key point: A successful ERP go-live does not automatically mean your supply chain is connected. Most UK and Irish businesses running Microsoft Dynamics, NetSuite, SAP, or Sage discover this gap after the project closes. This article explains what trading partner connectivity means in practice, how the main ERP systems handle it natively, and what questions to answer before your implementation is finished.
What Does "Connected" Really Mean for Your Supply Chain?
When an ERP project team talks about integration, they usually mean connecting internal systems: finance talking to warehouse, purchase orders flowing into accounts payable, inventory syncing with sales.
Trading partner connectivity is different. It means your ERP can send and receive the right documents, in the right format, to meet the specific requirements of each retailer or supplier you trade with.
That sounds like a small addition. In practice, it is a separate project.
A UK grocery retailer like Sainsbury's or Tesco does not just need a purchase order. They need it in a specific EDI format, with exact field values mapped to their current spec, sent within a defined time window, and confirmed with a specific acknowledgement. The same is true for invoices, advance ship notices (ASNs), and every other document in the order cycle.
Each major retailer has their own version of these requirements. They update them independently. And when they do, every supplier connected to them needs to reflect the change.
That is what "connected" means for supply chain automation. Not just data flowing, but the right data, in the right format, on the right timeline, for every trading partner at once.
What Your ERP's Native EDI Integration Covers
Microsoft Dynamics, NetSuite, SAP, and Sage all include some level of EDI capability as part of their standard functionality. The scope varies by system, but the core limitation is consistent: your ERP's native EDI gives you the infrastructure to exchange documents. It does not manage the ongoing relationship with each trading partner's specific requirements.
Here is how the main ERP systems compare at a high level:
Microsoft Dynamics 365 has strong native data exchange capabilities but relies on your team or implementation partner to map and maintain each trading partner's specific EDI specs. Business Central includes EDI apps via its marketplace, but spec management remains your responsibility.
NetSuite offers native EDI through SuiteCommerce and partner apps, with good flexibility for custom mapping. As with Dynamics, the spec knowledge for each trading partner needs to be built and maintained inside your implementation.
SAP has some of the most mature native EDI tooling of any ERP, particularly in S/4HANA through the Integration Suite. For large enterprises with dedicated EDI teams, SAP's native capability can be sufficient. For mid-market businesses, the overhead of managing individual trading partner specs in SAP is significant.
Sage (including Sage 200, Sage X3, and Sage Intacct) handles EDI through partner connectors rather than native tooling. Sage ERP integration in the UK almost always require a third-party EDI integration layer from the start.
At a glance:
ERP | Native EDI capability | Who owns spec management? |
|---|---|---|
Microsoft Dynamics 365 | Via marketplace apps | Your team or implementation partner |
NetSuite | Via SuiteCommerce and partner apps | Your team or implementation partner |
SAP | Most mature native tooling | Dedicated EDI team required |
Sage | Third-party connector required | Connector provider |
The common thread: every system can technically send and receive EDI documents. The question is who manages the spec knowledge for each trading partner, and what happens when those specs change.
Why Retail Requirements Create a Specific Gap
Retail in this region creates a specific challenge that generic EDI documentation does not cover well.
Major grocery and retail chains here update supplier requirements more frequently than in many other markets. A retailer may update their ASN specification, change a required field in their purchase order acknowledgement, or revise their invoice format. They communicate these changes through compliance bulletins and supplier portal updates. The expectation is that suppliers reflect the change before it affects live transactions.
For a supplier managing five or six retail accounts, that means monitoring five or six separate portals for updates, translating each update into a change inside their ERP integration, testing the change, and deploying it without disrupting live orders.
Multiply that across a growing retailer base and the maintenance burden becomes a full-time job inside your IT team.
Post-Brexit cross-border requirements add to this. Businesses moving goods between Great Britain and the Republic of Ireland, or into EU markets, now carry customs documentation requirements that sit alongside their standard EDI flows. Businesses that scoped their ERP integration before 2021 often find that the cross-border piece was never properly built in.
Three Ways to Connect Your ERP for Supply Chain Automation
When you scope your ERP integration for supply chain connectivity, there are three main approaches. Each has different implications for your IT team, your go-live timeline, and your ongoing maintenance burden.
1. Build your own ERP integration
You map each trading partner's EDI requirements directly into your ERP. Your IT team or implementation partner owns the spec knowledge, builds the transformations, and maintains them when trading partners update their requirements.
This gives you full control. The cost is ongoing: every retailer spec change requires an internal change request, testing, and deployment. For businesses with a small number of stable trading partners, this can work. For businesses with a growing retailer base or frequent spec changes, the maintenance overhead compounds quickly.
2. Use your ERP vendor's EDI module or marketplace app
Most ERP vendors have their own EDI tooling or approved partner apps. These reduce the build burden but do not fully remove the spec management problem. You still own the trading partner relationships and are responsible for keeping mappings current.
The advantage is tighter integration with your ERP's native data model. The limitation is that the spec knowledge for UK and Irish retailers still needs to be maintained somewhere, usually by your team or your implementation partner.
3. Connect through a managed trading partner network
A managed EDI network carries pre-built EDI connectors and maintained spec knowledge for major UK and Irish retailers. When you connect your ERP to the network, you get access to current specs for your trading partners without building or maintaining them yourself.
When a retailer updates their requirements, the network reflects the change centrally. Your integration does not need an internal change request for each update. New trading partners go live faster because the spec knowledge already exists in the network.
The trade-off is that you rely on the network provider to keep specs current and accurate. For businesses with complex, bespoke retailer relationships, some custom mapping may still be required.
What to Include in Your ERP Project Scope: Trading Partner Connectivity
ERP implementation supply chain decisions are easiest to make during the project itself. Retrofitting EDI integration after go-live is more disruptive, more expensive, and often means running manual processes for longer than planned.
These are the questions worth answering before your project closes:
Who are your top 10 trading partners, and what do they each require? Get the current EDI spec documents from each retailer or supplier before your integration work begins.
Which documents are in scope? At minimum: purchase orders (850), purchase order acknowledgements (855), advance ship notices (856), and invoices (810).
Who owns spec maintenance after go-live? Assign this before the project closes. If it is not, it defaults to whoever has capacity and usually gets missed.
Does your implementation partner have UK and Irish retail network knowledge? Generic EDI experience and regional retail expertise are different things. The team that builds your integration should understand how major retailers here communicate requirement changes.
Is post-Brexit cross-border documentation in scope? If you move goods between Great Britain and Ireland or trade with EU partners, confirm your ERP integration covers customs-adjacent documentation, not just the standard retail EDI flow.
The Right Time to Make This Decision
ERP projects have a natural close point: the go-live date. After that, the implementation team moves on, the budget is spent, and any gaps in scope become operational problems rather than project tasks.
Trading partner connectivity is one of the most common gaps. It feels like an integration detail during the project. After go-live, it becomes a manual process that your operations team absorbs, often without anyone formally recognising the cost.
The businesses that handle this well address it as a defined workstream inside the ERP project, with the same rigour as any other integration. They document their trading partner requirements, assign ongoing ownership, and choose an approach that matches their retailer base and their team's capacity to maintain it.
If your ERP project is still in scope, that conversation belongs in the room now.
If you want to explore what pre-built EDI integration looks like for Microsoft Dynamics, NetSuite, SAP, or Sage, SPS Commerce's integration options for businesses are a practical starting point.