How to read a 997 reject, segment by segment

A 997 Functional Acknowledgement is the most useful file your trading partner sends you, and the most commonly ignored. When a transaction rejects, the 997 already contains the answer. The problem is that the answer is spread across four segments that each say one small thing.

The segments that matter

Reading a 997 top to bottom, these are the four that carry the diagnosis:

Segment	What it tells you
AK1	Which functional group is being acknowledged
AK3	Which segment had the problem, and where it sat in the transaction
AK4	Which element inside that segment, and what was wrong with it
AK5	The verdict for the whole transaction set

Most people skip to AK5, see an R, and start guessing. The actual cause is almost always sitting in the AK3 and AK4 pair immediately above it.

Worked example

Here is a constructed acknowledgement rejecting a single transaction. The identifiers are invented; the structure and the error are what matter:

AK1*PO*000000123~
AK2*850*0001~
AK3*N1*12**8~
AK4*2*98*7*ZZ~
AK5*R*5~

Read it backwards and it resolves cleanly:

• AK5*R means the transaction set was rejected, and the 5 is the reason code
• AK4*2*98*7*ZZ points at element 2 of the segment, says the data is invalid, and echoes the value
• AK3*N1*12**8 identifies the segment as N1, sitting at position 12, with error code 8

So the partner received an N1 segment carrying an entity identifier code they do not accept. Not a mapping bug, not a connectivity problem. A code value your partner has not enabled.

What to check first

When you get a reject, work in this order:

1. Read AK3 and AK4 before anything else, since they name the exact segment and element
2. Check the value against the partner’s implementation guide, not the X12 standard, because the partner’s accepted subset is almost always narrower
3. Only then look at your map

The third step is where most people start, and it is why a fifteen minute fix turns into an afternoon.