Supply Chain & InventoryFree referencePDF, Excel, Word export

X12 997 AK3, AK4, AK5 and AK9 Error Codes Reference

A 997 comes back and says R or P. Now what? This reference lists the codes you will see in AK1 to AK9 with a plain meaning and the first thing to check in your outbound file. Filter by element or search for a code.

Download:

Element	Code	Meaning	What to check first
AK501	A	Transaction set accepted	Nothing to fix. Mark the document acknowledged in your tracker.
AK501	E	Accepted, but errors were noted	Read the AK3/AK4 detail. The partner took the document but flagged data issues.
AK501	M	Rejected, message authentication code failed	Rare. Only relevant where authentication segments (AK5 and X12.58) are agreed.
AK501	R	Transaction set rejected	Fix the cause given in AK502 to AK506 and resend with a new control number.
AK501	W	Rejected, assurance failed validity tests	Only seen where security assurance is used. Confirm the setup with the partner.
AK501	X	Rejected, content after decryption could not be analyzed	Encrypted payload could not be read. Check keys and the encryption agreement.
AK502	1	Transaction set not supported	Confirm the partner has your transaction set (for example 856) enabled for this version.
AK502	2	Transaction set trailer missing	The SE segment is missing or the file was truncated in transit.
AK502	3	Transaction set control number in header and trailer do not match	ST02 must equal SE02. Check the control number counter in your translator.
AK502	4	Number of included segments does not match actual count	SE01 must count every segment from ST to SE inclusive. Check custom segments added after mapping.
AK502	5	One or more segments in error	Look at the AK3 loops that follow to find which segments failed.
AK502	6	Missing or invalid transaction set identifier	ST01 must be a valid set such as 850 or 856, and match the GS01 functional group code.
AK502	7	Missing or invalid transaction set control number	ST02 must be present and at least 4 characters, usually unique within the interchange.
AK304	1	Unrecognized segment ID	A segment tag the partner does not know. Check for typos and for a version mismatch.
AK304	2	Unexpected segment	A valid segment in the wrong place for this transaction set and version.
AK304	3	Mandatory segment missing	The partner's implementation guide requires a segment you did not send (often N1, REF or DTM).
AK304	4	Loop occurs over maximum times	Too many repetitions of a loop, for example more N1 loops than allowed.
AK304	5	Segment exceeds maximum use	A segment repeated more often than the standard or guide allows.
AK304	6	Segment not in defined transaction set	The segment does not belong to this transaction set at all.
AK304	7	Segment not in proper sequence	Segment order differs from the standard. Check mapping order for the header, detail and summary areas.
AK304	8	Segment has data element errors	Read the AK4 segments that follow for the specific element.
AK403	1	Mandatory data element missing	A required element is blank. Check the source field in your ERP extract.
AK403	2	Conditional required data element missing	A relational rule fired, for example a qualifier was sent without its value.
AK403	3	Too many data elements	More elements than the segment allows. Often a stray delimiter inside a text value.
AK403	4	Data element too short	Value shorter than the minimum length, such as a 2 digit ZIP or short UPC.
AK403	5	Data element too long	Value longer than the maximum length. Truncate descriptions and names in the map.
AK403	6	Invalid character in data element	Characters outside the basic or extended character set, or a delimiter in the data.
AK403	7	Invalid code value	Value not in the code list for that element. Check unit of measure and qualifier mappings.
AK403	8	Invalid date	Date not in CCYYMMDD form or not a real date.
AK403	9	Invalid time	Time not in HHMM or HHMMSS form.
AK403	10	Exclusion condition violated	Two elements were sent that must not appear together.
AK901	A	Functional group accepted	All transaction sets in the group were accepted.
AK901	E	Accepted, but errors were noted	At least one set was accepted with noted errors. Review the AK5 for each set.
AK901	P	Partially accepted, at least one transaction set rejected	Resend only the rejected sets after fixing them.
AK901	R	Functional group rejected	Whole group failed. Check the GS and GE segments first.
AK901	W	Rejected, assurance failed validity tests	Same as AK501 W but at group level.
AK901	X	Rejected, content after decryption could not be analyzed	Same as AK501 X but at group level.

Codes follow the X12 997 and 999 code sources as commonly implemented. Partners may use a subset or add their own rules in the implementation guide, so always confirm against the partner guide. The 999 acknowledgment uses richer IK codes and is not covered here.

Automate 997 matching to your ERP documents

An optional review of how 997 rejects could be matched to source documents and surfaced to the EDI desk.

Optional. The tool and every export work without this. No spam.

How to read a 997

A 997 echoes the group it acknowledges (AK1), then one AK2/AK5 pair per transaction set. If a set has problems, AK3 names the segment and its position, AK4 names the element and the reason, and AK5 gives the set level result. AK9 closes with the group level verdict and counts of sets included, received and accepted. Read from the bottom: AK9 tells you how bad it is, AK5 tells you which sets, AK3 and AK4 tell you where.

AK1 identifies the functional group and its control number (GS06).
AK2 identifies the transaction set and ST02 control number.
AK3 gives the segment ID and its position in the set.
AK4 gives the element position, the error code and the bad value.

Worked example

Suppose AK5 returns R with code 5, and the AK3 reads PO1, position 12, error 8. The AK4 that follows says element 7, error 7, bad value PC. Translation: line 3 of your 850 acknowledgment carried a unit of measure of PC, which is not in the partner's accepted list. The fix is a UoM cross reference in your map (EA instead of PC), not a resend of the same file. Resend with a new ST02 and a new ISA13 so it is not treated as a duplicate.

Common mistakes

Most reject loops come from the same few causes. Fixing the data but reusing the old control numbers gets the new file rejected as a duplicate. Treating an E as success hides data quality problems that later show up as chargebacks. Assuming the 997 means the business accepted the order is also wrong: a 997 only says the syntax was readable, not that the order was accepted.

Always issue new ISA13, GS06 and ST02 on a resend.
Review E results, do not just clear them.
A 997 accepted is not a business acceptance. Use the 855 for that.
Check partner guides: some partners require 999 instead of 997.

Frequently Asked Questions

What is the difference between AK5 and AK9?

AK5 reports on one transaction set, for example a single 850. AK9 reports on the whole functional group and counts the sets included, received and accepted. You can have an AK9 of P (partial) because one AK5 returned R while the others returned A.

Why did I get an E instead of A?

E means the partner accepted the set but noted errors in AK3 and AK4. It is a warning that the data has quality problems. Treat it as a fix-forward item, and check the partner guide for whether they will process the order as received.

Do I resend the same file after a 997 reject?

No. Fix the cause, regenerate the document, and send it with new control numbers (ISA13, GS06 and ST02). Resending identical control numbers is usually treated as a duplicate and rejected again.

Is the 999 the same as the 997?

The 999 implementation acknowledgment replaces the 997 in HIPAA and some newer programs. It uses different segments (IK3, IK4, IK5) and richer error codes. Many manufacturing and retail partners still use the 997, so check the partner guide.

If your 997 rejects are being worked by hand from emailed files, Netray can help set up a read-only view that matches 997 results to the source document in your ERP and shows the failing element.

Talk to an Expert Explore More Free Tools