EDI and e-documents for New Zealand and Australian Retailers
Retail Supply • Integration
Costco, Aldi, Coles, Foodstuffs, Woolworths, Kmart and Target. If you supply major retailers, electronic trading often comes as part of the onboarding process.
ERP365 provides Business Central extensions designed to support EDI and electronic document integration with major retail networks across New Zealand and Australia.
erp365 · Auckland, New Zealand · Microsoft Dynamics 365 Business Central
For most suppliers, EDI enters the picture as a demand rather than a decision. A major retail customer sends a supplier onboarding document that lists electronic data interchange as a trading requirement, complete with message formats, transmission standards and a compliance testing process. It reads like a technical specification. What it actually describes is a system integration project with a deadline attached and a trading relationship riding on it.
The usual response is to treat it as exactly that: a one-off build, quoted and delivered, after which somebody in the business quietly becomes the person who knows how it works. Several years later that person is the single point of failure for every order the retailer sends.
The connection is the easy part. The ongoing work is keeping the flows running as requirements, ERPs and warehouses change around them.
What erp365 provides
We have built standard extensions for Microsoft Dynamics 365 Business Central covering EDI and e-document trading with the major New Zealand and Australian retail networks, including Costco, Foodstuffs, Woolworths, Kmart and Target.
Standard matters here for a specific reason. A bespoke integration is a snapshot of one retailer's requirements on one day, frozen in custom code that only its author understands. A standard extension is maintained as a product: when a network changes a requirement, the change is made once and rolls out to everyone using it. Your integration stops being something you own outright and starts being something that is looked after.
The practical result is that the trading connection becomes a configuration rather than a development project, with the orders, order responses, despatch advices and invoices moving between the retailer's systems and Business Central as part of normal operations.
The messages that make up a trading relationship
Whichever network you are joining, the transaction cycle is built from the same handful of message types. Understanding what each one does makes it much clearer where the real work sits.
Message | Direction | What it does |
|---|---|---|
Purchase order | Retailer to you | The order arrives structured, referencing your products by barcode with quantities and expected prices. It has to be validated against your catalogue and turned into a confirmed sales order. |
Order response | You to retailer | Confirms what you can actually supply - full, partial, or unable to fill. Sent from your ERP rather than typed into a portal, it tells the retailer about a shortfall before they expect the delivery, not after. |
Dispatch advice | You to retailer | Tells the network what is coming before the truck arrives. It must reflect what was actually loaded, not what was ordered, and for palletised deliveries it carries the pallet label data the receiving team scans. |
Invoice | You to retailer | Generated from your ERP in the format the network expects, matching the order so it is paid without a reconciliation exercise. Some relationships use a self-billing model instead, where the retailer raises the invoice themselves. |
Product and price data | You to retailer | Where the relationship requires it, catalogue and pricing is maintained electronically so the order that arrives matches what you actually sell. |
Where implementations come unstuck
The despatch advice
This is consistently the hardest message to get right. It has to be transmitted before the vehicle reaches the distribution centre or store, it has to describe what physically left your warehouse rather than what the order said, and for palletised deliveries it has to carry accurate pallet identification that the retailer scans on receipt. When the message and the pallets disagree, you get receiving delays and a dispute at the other end. Getting that data out of your ERP or warehouse system accurately and in real time is where most implementations do their hardest work.
The invoice that does not match
A price or quantity discrepancy between your invoice and the retailer's records does not usually generate a phone call. It generates a chargeback or a short payment, and then somebody on your side reconciles by hand what should have reconciled automatically. The fix is upstream: order, order response, despatch and invoice all have to be derived from the same data, which is precisely the argument for the flow living inside the ERP rather than beside it.
The order that never arrived
An order leaves the network but never lands in your system. Unless something is watching, nobody notices until fulfilment is already affected. Monitoring is not an optional extra on a trading connection; it is the difference between a late order and a missed one.
The change nobody owned
Networks update requirements. ERPs get upgraded. Third-party logistics providers come and go. The integration sits between all of these, and every one of those changes has an impact on it. Where the integration is bespoke and its author has moved on, that impact is discovered rather than planned for.
One thing worth clarifying early
Retail chain EDI is not the same thing as New Zealand's eInvoicing initiative built on the Peppol network. Peppol e-invoicing matters if you invoice government agencies. Trading with Foodstuffs, Woolworths and the rest runs on different protocols with formats and compliance requirements set by each retailer. They are separate ecosystems, and conflating them is a reliable way to start an implementation on the wrong foot.
Business Central's own e-document framework handles the Peppol side well. The retailer networks need the retailer-specific connections - which is what our erp365 extensions cover.
Trading across the Tasman
A point worth making for anyone supplying both markets: the New Zealand and Australian arms of these retail groups do not necessarily trade identically. Formats, portals and compliance processes can differ, and a supplier who has been trading successfully in one market should not assume the other is a copy.
Covering both from one Business Central environment, with one set of standard extensions and one place to look when something does not move, is a materially different operating position from running two separate bespoke integrations maintained by two different people.
What to ask before you start
1. Which messages does this specific relationship require?
Not which messages the network supports - which ones your trading agreement obliges you to exchange.
2. Self-billing or supplier-raised invoice?
Confirm this with the retailer before integration design begins. It changes the shape of the flow.
3. Where does the despatch data actually live?
If your pick and pack process is not producing accurate, timely data, the despatch advice will not either.
4. Who watches the flows?
Decide this before go-live rather than discovering it the first time an order goes missing.
5. What does the compliance testing process require, and how long does it take?
Certification is a scheduled activity with the retailer, not something you complete on your own timeline.
The outcome
Done properly, a retail trading connection becomes invisible.
Orders arrive and become sales orders against the right account, ready to pick. Confirmations go back automatically. The despatch advice describes what actually left. The invoice matches and gets paid. Nobody types anything, and nobody is the single person who understands it.
That is the standard we build to, and it is why these connections are a product rather than a project.
Trading with Costco, Aldi, Coles, Foodstuffs, Woolworths, Kmart or Target?
erp365 has standard Business Central extensions for EDI and e-document trading across the New Zealand and Australian retail networks. Whether you are onboarding with a new customer or your current integration depends on one person, we can help.
Published by erp365 Limited, Auckland. Microsoft, Dynamics 365 and Business Central are trademarks of Microsoft Corporation. Costco, Foodstuffs, Woolworths, Kmart and Target are trademarks of their respective owners; erp365 is not affiliated with or endorsed by them. Retailer requirements are set by each network and change over time — confirm current specifications with the retailer as part of onboarding.
