Why your product master data breaks your EDI
When a retailer rejects a document, the instinct is to call it an EDI problem and send it to whoever looks after the mapping. In most of the cases I have worked on, the mapping did exactly what it was told. The data it was given was wrong, and it was wrong in the ERP before the document existed.
The dependencies
Every EDI document is assembled from master data. Follow the fields back and they land on a handful of records:
- GTINs. The item on the purchase order, the item in the carton on the ASN, and the item on the invoice line have to be the same identifier at the right pack level. An inner GTIN where the retailer ordered cartons is a quantity mismatch three documents later.
- Pack configurations. Units per inner, inners per carton, cartons per pallet. The ASN hierarchy is built from these numbers. If the configuration says twelve and the carton holds ten, the receiving scan will disagree with the message.
- GLNs. Every ship-to, ship-from and bill-to location. A new store the retailer opened last month, missing from your customer master, is a purchase order you cannot accept.
- Costs, RRP and promotions. The invoice has to agree with the price the retailer holds. A supplier cost update loaded late, or a promotion that ended in the retailer's system but not in yours, is an invoice rejection or a deduction.
- Hierarchy and ranging. Which products a retailer is allowed to order, and under which category. Orders for items you have ranged out still arrive, and the response has to say so cleanly rather than fail.
None of these live in the EDI layer. They live in product, customer and pricing tables inside the ERP, and in the processes that maintain them: the month-end cost update, the new-line form, the promotion calendar.
How a data fault shows up
The symptom appears far from the cause, which is why it gets misdiagnosed. A pack configuration entered wrong on the day a product was created becomes an ASN rejection months later, on a different person's desk, described in the retailer's words rather than yours. A cost update loaded with one line misaligned becomes a batch of invoice deductions at the end of the month. Nobody connects the two unless someone is looking across both.
A validation routine
The way out is to check the data before the document exists, not after the rejection arrives. A routine I would put in front of any trading-partner feed:
- Every GTIN on a ranged item has a check digit that passes and exists at the pack level the retailer orders.
- Every pack configuration multiplies through: units, inners, cartons, pallet, with no zeros and no blanks.
- Every retailer location that has ever sent an order has a GLN in the customer master, and every GLN in the customer master is one the retailer recognises.
- Every item that will appear on an invoice this week has a current cost and a current price, and both agree with the retailer's price file.
- An exception report that lists what failed, with an owner, before the load reaches the live system.
Run as a load check, this turns a weekly stream of rejections into a short exception list on a Monday morning. Run before an upgrade or a migration, it is the difference between a clean cutover and a month of chargebacks.
Who should own it
Product and price data is usually owned by a merchandising or buying team, EDI by IT or a network provider, and the retailer relationship by sales. The faults fall between them. The practical fix is one person, or one role, that reads the retailer's compliance guide and the ERP's product master in the same sitting and is accountable for both agreeing. In a small business that is often the same person who does the month-end cost load. Give them the validation routine and the rejection history, and most of the noise stops.