Silence is not success: what an EDI acknowledgement proves and what it does not
The most common sentence in the EDI threads I have been reading is a variant of "it had been running for months before anyone noticed". The second most common is "the acknowledgement came back fine". The two are related. A functional acknowledgement, the 997 in the American standard and CONTRL in the one used here, proves that the other side's translator received your file and could read its structure. It proves nothing about whether the order loaded, the ASN attached to a purchase order, or the invoice will be paid. Silence after that point is not success. It is the absence of a signal you never asked for.
What practitioners describe
Acknowledgements nobody reads. An analyst with years in the trade said plainly that most of the time the acknowledgements do not even get looked at, and the fallback is emailing a person. A supplier whose ASN was rejected by a large American online retailer received a bare rejection code, one or more segments in error, with no detail of which segment. A month of back and forth later, the answer had nothing to do with structure or formatting. It was a master-data problem with an item set-up on the retailer's side. Instead of sending the document designed for that purpose, an application advice, the retailer generated a generic rejection and asked the supplier to go and look in the portal.
Partners who refuse the signal. One practitioner's nightmare was a partner who announced that they do not interpret negative acknowledgements at all: if you want to reject an order, send a cancellation response instead. Another's was a retailer whose own purchase order carried the wrong product code and who then charged back every supplier who echoed it.
Faults that ran for a year. An in-house EDI programmer at a manufacturer described point-of-sale data arriving from a network with one segment formatted wrongly for an entire year, so replenishment saw at most ten stores per item. The network then resent the year twice, so the fees were paid on bad data twice. Nobody in IT caught it. It was caught by an overpayment on the business side. Their line was that EDI does not have tools to discover what you have not received; the business area is the one that gets the alerts and the reports. Another practitioner in the same thread described a text field that the order system had not been passing for years, and a vendor reported a client whose invoice fault with a large retailer sat unnoticed for four months, with the receivables ageing the whole time.
Orders that vanish. A manufacturer described inbound orders that failed in the integration layer between the EDI gateway and the order system and simply disappeared, with no queue to look at. Their proposal, written in frustration to the vendor's community, was a self-refreshing draft-orders screen so that a failed order is a thing a person can see.
What the retailers here expect
Australian and New Zealand guides are blunt about the supplier's responsibility. Myer requires an acknowledgement for every purchase order and queries discrepancies within two working days. Foodstuffs in New Zealand, which receives around five million invoices and credits a year, says that when documents arrive twice it is recorded as an error and may delay payment, and that if you use their EDI facilities it is important that you monitor any failure notifications. One grocery wholesaler's despatch-advice guide says that if the supplier has not received the acknowledgement after sending an ASN, the supplier should not despatch stock against it. That is the right instinct generalised: the acknowledgement is a gate, not a receipt.
The fix is three states, not one green tick
The clearest statement of the fix came from someone who runs a monitoring service and wrote it from support experience, and the practitioners' stories confirm every part of it. Track three things separately for every outbound document.
Transport. Did the file leave and did the connection confirm receipt. A signed receipt on a direct connection, a mailbox status on a network.
Translation. Did the functional acknowledgement come back, and was it positive. Alert on an acknowledgement that is absent past a window you set per partner, because some partners take an hour and some take a day. Read the detail segments before touching a map; a rejection with no detail is a conversation with the partner, not a mapping task.
Business acceptance. Did the order appear in the retailer's portal, did the ASN attach to the purchase order, did the invoice reach the matching run. This is the state nobody monitors, and it is the one that costs money. Where the retailer offers a status document or a portal view, use it. Where it does not, build the sanity checks on your own side: orders received per partner per day against the usual, ASNs sent against shipments despatched, invoices sent against invoices paid. One practitioner keeps dashboards of exactly this kind and says the failures are seemingly always partner inconsistencies, so they plan for them.
Manage by exception, and give the business a view
The in-house teams that sound calm in these threads run by exception. One programmer handling hundreds of files an hour said the team stays busy only with the outliers; another said ninety-nine point nine per cent of transactions run with no issues and the rest need people. Three rules kept appearing: never send a document with incomplete data; give the people who own the data a report so they can fix it at source; and fix every problem so that it cannot recur. Then put the errored and sent documents on a screen that customer service can read without calling IT. Every silent failure above was caught by someone on the business side. Give them something to look at.