The flows
Acknowledgements
A receipt is not a confirmation. It says the document got there, or that it did not, and it is the only way to know the difference between delivered and read.
Sending a document tells you it left. An acknowledgement tells you it arrived. Without one, a document that vanishes looks exactly like a document that was delivered and acted on, and you find out at the end of the month.
Two layers, answering two questions
| Layer | The question it answers | EDIFACT | X12 | UBL |
|---|---|---|---|---|
| Envelope | Did the interchange arrive, and could it be read at all? | CONTRL | 997 | Application response |
| Document | Was the business document accepted? | APERAK | 997 | Application response |
The first is technical: the file arrived, the syntax was legal, the envelope was addressed to someone who exists. The second is a business answer: the invoice was accepted, or it was rejected because the reference is missing.
A document can pass the first and fail the second, and that is the case worth catching. The interchange was fine; the invoice was refused. Nothing is wrong with your EDI and you are not getting paid.
What the states mean
| State | What it says |
|---|---|
| Not expected | You did not agree to one for this document. Its absence means nothing |
| Pending | You expect one and it has not arrived. Normal, up to the deadline |
| Positive | It arrived and it was good |
| Negative | It arrived and the document was refused. The reason is on the message |
Each message carries both states independently. A message can be positive on the envelope and pending on the document, which is the ordinary state of affairs for the minutes between a partner receiving your invoice and their system accepting it.
Overdue
Pending stops being normal at the deadline the agreement sets. After that the message shows as overdue and turns up in the operations workspace as something to chase.
Reading a negative one
A rejection carries codes and text from the partner's system, and the module keeps them as they were sent, with the document they refer to. That matters because the codes are the partner's, not ours: the module does not translate them into something friendlier and lose the original in the process.
The detail rows say which document was refused, what the sending system called the problem, and when. That is what you quote when you ring them.
Answering, when you are the receiver
The inbound agreement decides whether you send receipts, per layer. Sending them is generally good manners and often a requirement: a partner who asked for a receipt is a partner whose system is waiting for one, and their message will go overdue on their side if you never answer.
Correlation
A receipt has to be matched to the document it answers, and the reference the partner echoes is not always the one you would expect. The module records how confident the match was and why, so a receipt that landed on the wrong message can be seen to have done so rather than quietly being believed.
In practice you will not think about this until a partner changes their system. When they do, the confidence field is the first thing to look at.