What is EDI and why do retailers insist on it?

Electronic data interchange is the exchange of standard business documents as structured data rather than as email attachments, paper or portal keystrokes. Large retailers insist on it because their receiving, replenishment and payables processes are automated end to end, and a supplier who cannot send a machine readable despatch advice forces a manual exception at every dock and every invoice. For the retailer it is a volume problem. For you it is a condition of trade.

Do we need EDI if we only supply one large retailer?

Not necessarily. Most large Australian retailers offer a web portal where a smaller supplier can key orders and produce compliant labels by hand. That is genuinely workable at low order volumes and we will say so rather than sell you an integration. The economics change when you add a second or third partner, when order volume means someone is keying for hours a week, or when deductions from labelling and timing errors start showing up on remittances. At that point the portal is the expensive option.

Can EDI connect to the accounting or ERP system we already run?

Yes, and it should. The point of the exercise is that an order arriving from a trading partner becomes a sales order in your system without anyone typing it, and that despatch and invoicing flow back out from the same records. This works with the mainstream Australian mid market systems and with older on premise ones, though the older ones may need a file based or database level connection rather than a modern interface. What matters is that one system remains the source of truth for stock and pricing.

What is a despatch advice and why does its timing matter so much?

A despatch advice is the advance notice of what is on the truck, described down to the pallet and carton, with a serial number on each pallet that the receiving scanner reads. It lets the distribution centre receive a pallet with one scan instead of counting it. If the message arrives after the truck does, the receiving team has nothing to scan against and has to fall back to a manual count, which is why late or missing despatch advices are one of the most commonly charged compliance failures.

How long does an EDI project take in Australia?

For a first trading partner, plan on somewhere between six and twelve weeks from kick off to live trading, with the retailer’s testing and certification queue usually accounting for more of that than the build. Subsequent partners onto the same integration layer are faster, often three to five weeks, because the connection into your ERP already exists and only the partner specific rules change. The variable that blows out timelines is almost always master data that turns out to be incomplete.

What causes deductions and can they be avoided?

The common causes are a despatch advice that arrived late or did not match the pallets, a pallet label that would not scan, a pallet built to the wrong configuration, an invoice priced differently to the order, and a delivery outside its booked window. Nearly all of them are process failures rather than commercial disputes, which means they are avoidable. The practical first step is getting the deduction reason codes into a monthly report grouped by cause, because most suppliers find a handful of repeat causes account for the bulk of the money.

Should we use an EDI service provider or build the integration ourselves?

It is not really either or. Many Australian suppliers use a service provider for the transport and message translation layer, then still need an integration between that provider and their ERP, because otherwise staff are re keying between the provider’s portal and their own system. That middle piece is where the manual work usually survives. We are happy to build only that piece and leave your existing provider in place, or to build the whole path where a provider is not adding enough to justify its fee.

For suppliers trading with the major grocery, hardware and pharmacy chains

EDI Integration in Australia: Passing Trading Partner Compliance

Electronic data interchange is the structured messaging that large Australian retailers require of their suppliers. Purchase orders arrive as data rather than email, despatch advices have to be sent before the truck arrives, and invoices are matched automatically against what was ordered and what was received. Get any of it wrong and the money comes off your remittance.

The technical part of EDI is genuinely straightforward. The part that catches suppliers is that every retailer publishes its own specification, its own timing rules and its own penalty schedule, and none of it is negotiable when you are the smaller party. This page covers the messages you will be asked for, how they connect to the ERP you already run, and where the money quietly leaks.

Book an EDI Scoping Call (03) 9003 0111

Realistic ROI

6 to 8 messages

Cover most Australian retailer programmes

Order, order response, despatch advice, invoice, receipt advice and usually a catalogue message

Same day

Is the usual window to acknowledge an order

Timing rules vary by partner and a late response is often the first compliance breach recorded

Weeks 6 to 12

Realistic time to pass partner certification

The retailer’s testing queue is normally the long pole, not the build on your side

Per trading partner

Is how specifications actually vary

Assume no reuse of business rules between partners even when the message standard is the same

Four Things That Decide Whether an EDI Programme Works

Suppliers rarely fail EDI on the file format. They fail it on four things that are decided long before the first message is sent.

The retailer’s specification is the specification

Each major chain publishes a supplier guide covering message versions, mandatory segments, timing windows, labelling and packaging rules. There is no house style and very little room to negotiate. The single most useful thing a supplier can do before signing anything is read the current guide end to end and note every rule that your current process cannot meet. That list is the real project scope.

EDI is a compliance programme, not a file transfer

The messages are the easy half. The obligations are the expensive half: acknowledging orders inside a stated window, sending the despatch advice before the goods arrive at the distribution centre, labelling pallets so the receiving scanner can read them, and invoicing at the price the retailer holds rather than the price you hold. Treat it as a data project and you will pass testing and still get deducted.

Your item and location data has to be right first

EDI messages identify products and places with globally unique numbers rather than your internal codes. Every sellable unit, carton and pallet configuration needs a correct barcode number, and every warehouse and delivery point needs its own location identifier. If your ERP holds those in a spreadsheet, or holds them inconsistently across product variants, fix that before you map a single message. Bad identifiers are the most common reason certification stalls.

Someone has to work the exceptions every day

A rejected order response, an invoice that failed matching, a despatch advice that arrived after the truck: these need a person to look at them the same day, not at month end. The integration should make that a short, specific queue with the retailer’s own reason code attached. Without a named owner and a daily habit, an EDI programme decays into a very expensive way of receiving purchase orders.

The Messages You Will Actually Be Asked For

Names and versions vary by partner, but almost every Australian retail programme is built from this set.

Order created

Purchase order inbound

The retailer sends what it wants, in what quantity, to which delivery point, for which delivery window. The integration turns that into a sales order in your ERP with the retailer’s order number preserved, because every later message and every dispute is keyed on that number. Unit of measure is the trap here: retailers order in cartons or trade units, your ERP may hold eaches, and the conversion has to be per product rather than a global rule.

Acknowledged

Order response

A structured reply confirming what you will actually supply: accepted in full, accepted with a reduced quantity, or rejected with a reason. Sending this promptly is usually a measured compliance metric in its own right. It is also commercially useful, because a short shipment declared up front is treated very differently from a short shipment discovered at the receiving dock.

Sent before the truck

Despatch advice

The advance notice of exactly what is on the way, broken down by pallet and carton, with a unique serial number on each pallet label that the receiving scanner reads. This is where most deductions originate. The despatch advice has to be transmitted before the goods physically arrive, it has to match the pallets that turn up, and the label has to scan first time under warehouse lighting on a shrink wrapped pallet.

Matched or deducted

Invoice

The invoice is matched automatically against the order and the receipt. Any difference in price, quantity, tax treatment or reference number becomes a query or a straight deduction. GST handling has to be exactly right, including the cases where the retailer self bills and issues a recipient created tax invoice instead, in which case you are reconciling their document against your ledger rather than sending your own.

Reconciled

Receipt advice and claims

What the distribution centre says it actually received, which is not always what you sent. Short receipts, damages and rejected pallets arrive here, and this is the message most suppliers ignore and most regret ignoring. Bringing it into the ERP automatically gives you an evidence trail while the pallet history is still retrievable, rather than a remittance surprise six weeks later.

Transport layer

How the messages travel

Messages move over a secure file transfer connection, a direct encrypted internet link, a value added network the retailer nominates, or in smaller programmes a web portal you key into by hand. The choice is usually the retailer’s, not yours. What matters on your side is that every message is logged, every acknowledgement is captured, and anything that fails to send raises an alert rather than sitting in a folder.

What Changes When EDI Is Connected to the ERP

Task	Traditional	Integrated EDI	Notes
Purchase order arrives	Printed from a portal and keyed in	Sales order created automatically	Keying is where wrong quantities and wrong delivery points enter the process, and both are chargeable errors.
Order acknowledgement	Emailed by the account manager, if at all	Structured response within the window	Often a scored compliance metric. Automating it removes the most avoidable breach category.
Pallet labels	Generated in a separate tool from a spreadsheet	Printed from the actual pack data	Serial numbers must be unique and never reused, which a spreadsheet cannot reliably guarantee.
Despatch advice timing	Sent when someone remembers	Triggered on despatch confirmation	Sending after arrival is treated as not sending at all by most receiving systems.
Invoicing	Raised at your price list	Raised against the agreed order price	Price discrepancies are the second largest deduction category after delivery compliance.
Short or damaged receipts	Discovered on the remittance	Flagged the day the receipt arrives	Disputes are far easier to win while the pallet, the pod and the photos still exist.
Adding a second retailer	A second portal and a second manual process	A second mapping on the same layer	The business rules differ per partner, but the connection into your ERP is built once.
A message that will not map	Fails silently in a folder	Queued with the partner’s reason code	The design decision that determines whether anyone trusts the automation after the first bad week.

Where Australian EDI Programmes Lose Money

Deductions treated as a cost of doing business

Compliance charges for late despatch advices, unreadable labels, wrong pallet configurations and invoice mismatches are usually recoverable in the sense that they are preventable. Get the deduction codes into a report your finance team sees monthly, grouped by cause. Most suppliers discover that a small number of repeat causes account for the large majority of the charges, and that fixing two of them pays for the integration.

Serial numbers reused or generated in two places

Every pallet label carries a serial number that must be unique for a long period, commonly a year or more, and must never appear twice. If labels can be produced from both a warehouse tool and a desktop spreadsheet, duplicates are inevitable and receiving systems will reject the pallet. Generate them from one place, record every number issued, and never let a reprint create a new number for the same physical pallet.

Unit of measure assumed to be consistent

Retailers order in the trade unit they buy in, which may be a carton, an inner or a display unit, while your ERP may hold eaches or kilograms. A single global conversion rule will be wrong for part of your range and the error only shows up as an over or under supply. Hold the conversion per product, validate it against the retailer’s item file, and reconcile whenever either side changes a pack configuration.

GST and recipient created tax invoices handled loosely

Some trading arrangements have the retailer generate the tax invoice on your behalf, which changes what you send, what you post and what you reconcile at BAS time. Others require GST exclusive pricing with tax calculated at the line. Confirm the arrangement in writing, mirror it in the ERP posting rules, and make sure the reconciliation catches the case where their document and your ledger disagree, because that difference is a tax exposure rather than an administrative annoyance.

One person holds the trading partner knowledge

EDI programmes accumulate undocumented local knowledge: which partner needs which reference in which field, which delivery points changed, which product codes were remapped after a range review. When that person leaves, the next range review breaks everything. Insist that the mappings, the partner rules and the exception playbook are written deliverables kept current, not tribal memory.

Testing signed off on clean data only

Certification usually passes on tidy sample orders. Production then presents split deliveries, substituted products, cancelled lines, promotional pack variants and a delivery point that opened last week. Test on a copy of real historical orders including the awkward ones before go live, and stage the first partner rather than switching every retailer over in the same week.

How Yes AI Approaches EDI Integration

We read the supplier guide before we quote

Every rule in the retailer’s current specification is checked against what your ERP and warehouse can actually do today. You get a plain list of the gaps, the ones that are configuration and the ones that are genuine process change, before anybody commits to a date.

Identifiers cleaned up first

Barcode numbers for each sellable unit and pack level, location identifiers for each delivery point, and pack configurations that match reality. Unglamorous work that determines whether certification takes six weeks or six months, done before message mapping starts.

Built, hosted and monitored by us

The connection runs on a managed cloud automation layer we operate, with transmission logging, acknowledgement tracking and same day alerting on anything that fails to send or fails to map. You do not run servers or keep a script alive on someone’s desktop.

Honest advice on when not to build

If you supply one retailer at modest volume and their portal is workable, we will say so. Custom EDI earns its keep when you have several partners, real volume, or deduction exposure that a portal cannot help you with.

From First Supplier Guide to Certified and Live

Five steps. Most of the calendar is the retailer’s testing queue rather than the build.

Gap analysis against the supplier guide

We work through the retailer’s current specification line by line against your ERP, your warehouse process and your labelling, and produce a gap list separated into configuration, integration and process change.

Fix the master data

Barcode numbers for each pack level, location identifiers for every delivery point, pack configurations verified against physical pallets, and unit of measure conversions held per product rather than globally.

Map the messages both ways

Inbound orders into ERP sales orders, outbound responses, despatch advices, invoices and receipt reconciliation, with the retailer’s reference numbers preserved end to end so disputes are traceable.

Certify with the partner

Structured testing against the retailer’s test environment, then a physical label and pallet test if required. We run the test cycles and handle the correspondence rather than leaving your team to chase it.

Go live on one partner, then extend

First partner live and watched daily for a fortnight, deduction reporting turned on, then the next partner mapped onto the same layer. Documentation updated at each step.

FAQ

Trade With the Majors Without Bleeding Deductions

Book a call. We read the supplier guide, tell you exactly which gaps you have, and give you a priced plan. The gap analysis is yours either way.