EDI integration for NZ food distributors: what Foodstuffs and Woolworths actually require

For many NZ food distributors, EDI enters the picture as a demand rather than a decision. A major retail customer — Foodstuffs NZ or Woolworths NZ — sends a supplier onboarding document that specifies electronic data interchange as a trading requirement. The document lists message formats, transmission standards, and a compliance testing process. It looks like a technical specification; what it actually describes is a system integration project.

Purchase orders need to arrive from the retailer's procurement system, flow into your ERP, create sales orders, and trigger stock reservation. When goods go out the door, a despatch advice needs to be generated and transmitted before the truck arrives. When the invoice is issued, it needs to match the retailer's records precisely — a price discrepancy triggers a chargeback, not a call. None of this happens with manual data entry; it all depends on how well your ERP is connected to the EDI layer.

This guide explains what EDI actually involves for NZ food distributors — the message types, the retailer requirements, the integration challenge, and the three approaches that work in practice.

What EDI is and what it is not

Electronic Data Interchange is the structured, machine-to-machine exchange of business documents — purchase orders, invoices, despatch notifications — between trading partners. Unlike an emailed PDF, an EDI document is structured data transmitted via a defined protocol and processed directly by the recipient's system without human intervention.

EDI is not the same as New Zealand's government eInvoicing initiative, which is built on the Peppol network and is primarily designed for business-to-government transactions. That initiative is relevant for businesses that invoice government agencies. Retail chain EDI in NZ — Foodstuffs, Woolworths — runs on different protocols (typically AS2 or VAN-based transmission) with formats and compliance requirements specified by each retailer. They are separate ecosystems with different requirements.

EDI also does not replace a B2B ordering portal. These tools serve different trading relationships, which is covered in more detail below.

The four core EDI messages NZ distributors need

The core transaction cycle between a NZ food distributor and a retail chain buyer involves four message types. Understanding what each message does — and who generates it — clarifies where the integration complexity sits.

• ORDERS (purchase order). An inbound message: the retailer's procurement system sends a purchase order to your system. It arrives in a structured format, references your products by GTIN (barcode), specifies quantities and expected prices, and needs to be received, validated against your product catalogue, and turned into a confirmed sales order in your ERP.
• ORDRSP (order acknowledgement). Your outbound reply to the purchase order. It confirms what you can supply — full quantity, partial, or items you can't fill. This matters operationally: if you're short on a line, the ORDRSP tells the retailer's system before they expect delivery, not after. Late or missing acknowledgements create planning problems on the retailer's side.
• DESADV (despatch advice). Your outbound notification that goods have left your warehouse. This is typically the hardest message to get right in practice. It must be sent before the vehicle arrives at the retailer's distribution centre or store, must accurately reflect what was actually loaded (not what was on the order), and — for palletised deliveries — must include SSCC (Serial Shipping Container Code) data that the retailer's receiving team scans to match against their expected delivery. Getting this data out of your ERP or WMS accurately, in real time, and in the required format is where most implementations do the hardest work.
• INVOIC (invoice). Your outbound invoice for the despatched goods. Some retailers use a self-billing (evaluated receipts settlement) model where they generate the invoice themselves from the DESADV and ORDRSP data — in that case, you receive a remittance rather than sending an INVOIC. Which model applies to your specific trading relationship is one of the first things to confirm with the retailer before integration design begins.

What Foodstuffs NZ and Woolworths NZ actually require

Foodstuffs NZ operates the Foodstuffs Exchange — a dedicated EDI platform with technical specifications and a compliance testing environment for suppliers trading with Pak'nSave, New World, and Four Square stores. Suppliers are required to pass compliance testing before going live on each message type. Foodstuffs works with a range of managed EDI service providers who can handle the transmission layer; the integration between the managed service and your own ERP is your responsibility.

Woolworths NZ has equivalent supplier onboarding requirements. Their specifications cover the same core messages and operate through their own supplier portal and preferred trading partners. Requirements differ between Foodstuffs and Woolworths in specifics — message formats, testing processes, timeline expectations — which is why understanding each retailer's documentation separately matters before any integration work begins.

Both retailer groups have been tightening EDI compliance expectations in recent years. Chargebacks for despatch advice discrepancies, price mismatches, and late or missing messages are increasingly common for suppliers who aren't operationally tight on their EDI flows.

The integration problem: connecting EDI to your ERP

A managed EDI service can receive a Foodstuffs purchase order, translate it from the retailer's format into a structured file or API call, and deliver it to a location your ERP can read. What the service does not do is create the sales order in Accredo, MYOB Acumatica, or CSB-System, confirm available stock, generate the despatch advice from your dispatch records, or post the invoice. That work is done by the integration layer between the EDI service and your ERP.

What that integration needs to handle:

• Receive inbound ORDERS messages and validate them against your product catalogue — matching GTINs to internal product codes, checking prices against the retailer's agreed price list, flagging discrepancies before they become chargebacks.
• Create sales orders in the ERP for confirmed lines, with the retailer's purchase order number recorded as a reference field that carries through to the invoice.
• Generate the ORDRSP from ERP availability data — ideally in real time, or within a defined response window.
• At dispatch, read confirmed quantities from the ERP or warehouse operation and generate a compliant DESADV — including pallet-level SSCC data where the retailer requires it.
• Generate or reconcile the invoice. If you're sending an INVOIC, it must match the purchase order and despatch advice data precisely. If the retailer self-bills, you receive their remittance and need to reconcile it against your ERP records.

Price discrepancy chargebacks deserve specific attention. If the price on your EDI invoice doesn't match the retailer's purchase order price in their system, the chargeback is often automatic — no call, just a deduction on the next payment. Maintaining accurate retailer-specific pricing in your ERP, and ensuring it flows correctly into every outbound EDI document, is operationally important in a way that general trade pricing often is not.

Three approaches to EDI implementation

NZ food distributors typically approach EDI implementation one of three ways, depending on existing ERP capability and internal technical resource:

Managed EDI service with ERP integration. The most common approach. A service provider — EDIStech, SPS Commerce, Crossfire, and others operate in the NZ and Australian market — handles the transmission layer, format translation, and retailer-specific compliance. You integrate their API or file output into your ERP. The managed service takes care of staying current with retailer format changes; your integration handles the ERP-side data flows. This is a practical choice for distributors who don't have in-house EDI expertise.

ERP-native EDI. Larger ERP platforms (SAP, NetSuite) have built-in EDI modules or certified network connections. For distributors on Accredo, MYOB, or CSB-System, a native EDI path is not typically available — an integration layer is still required regardless of the EDI provider.

Custom ERP integration with EDI provider. A direct integration between your ERP and an EDI provider's API, built to your specific trading partner requirements. This gives the tightest integration — real-time stock confirmation in the ORDRSP, DESADV generation triggered directly by your dispatch process — but requires custom development and maintenance as retailer requirements evolve. If your ERP already has a well-designed integration layer connecting it to other systems (your B2B portal, for example), EDI flows can often be added to that same layer without a separate integration architecture.

EDI and your B2B portal: different channels, same ERP

A B2B ordering portal is for your trade customers — foodservice operators, restaurants, cafes, independent retailers, caterers — who log in, browse your catalogue, and self-serve their orders. It is a direct, controlled buying experience for your wholesale relationship. The portal we build and operate — Provender — handles this channel for NZ food distributors.

EDI is for large retail chain buyers whose procurement systems generate purchase orders automatically from their own demand planning and inventory systems. They are not browsing your catalogue; their system is sending machine-generated orders based on their replenishment logic.

Both can run simultaneously from the same ERP back-end. A NZ food distributor might process 80% of their order volume through the B2B portal (smaller accounts, self-service) and serve their Foodstuffs account via EDI (high-volume, automated). The integration layer handles different inbound formats — a portal order arrives as a structured API call; an EDI order arrives via the managed service — but both write to the same ERP as a sales order. There is no technical reason these two channels can't coexist, and for distributors serving both retail chains and trade customers, they typically do.

What to confirm before you start

Before engaging an EDI provider or beginning integration work, get clear answers to these questions — they shape both the implementation scope and the timeline:

• Which retailers require EDI, and what are their specific technical specifications? Foodstuffs and Woolworths NZ each have their own documentation; don't assume they're the same.
• Does the retailer use self-billing (evaluated receipts) or invoice receipt? This determines whether you're sending an INVOIC or receiving a remittance.
• Is SSCC (pallet-level barcode) data required in the DESADV? This has warehouse process implications — your team needs to scan or generate SSCCs at pack time, not as an afterthought when the truck is leaving.
• Do your products have GTINs (GS1 barcodes) registered for every line you sell to this retailer? EDI purchase orders reference GTINs, not your internal product codes. If any products are missing GTINs, registration needs to happen before compliance testing.
• What does your ERP currently expose via API or file export at the dispatch stage? This determines how much integration work is required to generate the DESADV from actual dispatch records — not from the original order.
• What is the retailer's timeline for go-live, and is there a compliance testing period that must be passed before live trading begins? Build this into your implementation timeline — compliance testing with a major retailer often takes four to eight weeks.

EDI is a mature technology, but the integration work that connects it to a specific ERP for specific retailer requirements is always a custom project. The transmission layer is solved; the ERP-side data flows — accurate DESADV generation, real-time ORDRSP confirmation, clean price matching — are where the implementation does its most important work.

If you're a NZ food distributor scoping an EDI integration for Foodstuffs or Woolworths NZ, or adding EDI to an existing Accredo-integrated ordering platform or custom ERP build, reach out to the Zeabyte team. We build and maintain system integrations for NZ food distributors and wholesalers — connecting Accredo, MYOB, CSB-System, and more to the channels and systems their operations depend on.