Who sends it
Sent by whichever side received a transaction, back to the sender. Every partner in an EDI relationship both sends and expects 997s.
When it fires
Within minutes of any transaction being transmitted. A 204, 990, 214, or 210 is not considered delivered until its 997 comes back.
What it carries
- The control numbers of the functional group being acknowledged, so the ack ties to a specific transmission.
- An acknowledgment code for the group and, optionally, per transaction set.
- For a rejection, the segment and element where the error was found and an error code.
Group acknowledgment codes
Standard ANSI X12 997 (AK9) values.
| Code | Meaning |
|---|---|
A | Accepted |
E | Accepted, but errors were noted |
P | Partially accepted — some transaction sets rejected |
R | Rejected |
M | Rejected — message authentication code failed |
W | Rejected — assurance failed validity tests |
X | Rejected — content decryption failed |
Where it breaks
- A 997 that never arrives — the sender does not know if the transaction was received, and has to chase it manually or re-send and risk a duplicate.
- A rejection (R) with an error location the sender’s mapping does not recognise, which stalls the exchange until a person reads the raw error.
- Treating an "E" (accepted with errors) as a clean accept, so a partially bad transaction is assumed good.
How Trailflow handles it
Trailflow EDI (beta) tracks acknowledgments against each transmission so a message stuck without a 997, or one rejected, surfaces as an error that can be retried from its raw content once fixed.
See Trailflow EDI for the product. It is in beta; supported behavior may change.