Resolving EDI 997 Rejection Codes

Last updated: 2025-11-23

Understanding the EDI 997 Functional Acknowledgment

The 997 transaction is a standardized functional acknowledgment used in X12 EDI to confirm receipt and report acceptance or rejection of EDI documents. When your trading partner receives an EDI file (such as an 850 Purchase Order or 810 Invoice), their system sends back a 997 to indicate whether the transaction was successfully processed or rejected due to validation errors.

997 rejection codes indicate that the receiving party's EDI system could not successfully process the transaction due to specific validation errors. These errors often stem from incorrect mapping configurations, data format issues, or violations of predefined business rules. The 997 document provides a detailed account of which segments or elements failed validation, guiding you to the root cause of the problem.

For background on EDI transaction structures and validation, see Understanding EDI X12 delimiters and structure. For related information on other acknowledgment types, see 997 transaction reference.

997 Structure and Key Segments

Understanding the structure of a 997 is critical to diagnosing rejection codes. The key segments include:

• ST segment: Transaction set header that identifies the document as a 997
• AK1 segment: Functional group response header, identifies the functional group being acknowledged
• AK2 segment: Transaction set response header, identifies the specific transaction being acknowledged (like an 850 or 810)
• AK3 segment: Data segment note, provides details about segment-level errors including segment ID, position, and loop ID
• AK4 segment: Data element note, provides details about element-level errors including element position and error codes
• AK5 segment: Transaction set response trailer, indicates overall acceptance or rejection with a code (A=Accepted, E=Accepted but errors noted, R=Rejected)
• AK9 segment: Functional group response trailer, summarizes the entire functional group acknowledgment
• SE segment: Transaction set trailer

Example 997 with Rejection

ISA*00*          *00*          *ZZ*SENDERID       *ZZ*RECEIVERID     *251123*1430*U*00401*000000001*0*P*>~
GS*FA*SENDERAPP*RECEIVERAPP*20251123*1430*1*X*004010~
ST*997*0001~
AK1*PO*12345~
AK2*850*0001~
AK3*ST*1~
AK4*1*66*7~
AK5*R*5~
AK9*R*1*1*0~
SE*7*0001~
GE*1*1~
IEA*1*000000001~

In this example, the AK3 segment indicates an error in the ST segment at position 1. The AK4 segment shows that element 1 (position 66 in element reference) has error code 7, meaning "segment has data element errors." The AK5 segment shows "R" (rejected) with error code 5 (one or more segments in error).

Common 997 Error Codes

The AK4 and AK5 segments contain error codes that explain why a transaction was rejected. Understanding these codes is essential for troubleshooting.

AK4 Data Element Error Codes

• 1: Mandatory data element missing
• 2: Conditional required data element missing
• 3: Too many data elements
• 4: Data element too short
• 5: Data element too long
• 6: Invalid character in data element
• 7: Invalid code value
• 8: Invalid date
• 9: Invalid time
• 10: Exclusion condition violated
• 12: Too many repetitions

AK5 Transaction Set Acknowledgment Codes

• A: Accepted
• E: Accepted but errors were noted
• M: Rejected, message authentication code (MAC) failed
• R: Rejected
• W: Rejected, assurance failed validity tests
• X: Rejected, content after decryption could not be analyzed

AK5 Error Code Reasons

• 1: Transaction set not supported
• 2: Transaction set trailer missing
• 3: Transaction set control number in header and trailer do not match
• 4: Number of included segments does not match actual count
• 5: One or more segments in error
• 6: Missing or invalid transaction set identifier
• 7: Missing or invalid transaction set control number

Common Rejection Scenarios

1. Mapping Errors

Incorrect mapping of segments or elements that don't align with the trading partner's requirements. This is one of the most frequent causes of rejections.

Example: Sending an EDI 850 Purchase Order with a missing N1 segment (Name/Address) when the trading partner requires it for drop-ship orders. The 997 would show:

AK3*N1*10~
AK4*1*98*1~
AK5*R*5~

This indicates a mandatory data element is missing in the N1 segment.

2. Data Format Issues

Noncompliance with required data formats is a common issue, especially with dates, times, and numeric values.

Example: Sending a date as MM/DD/YYYY when the partner expects CCYYMMDD format. If you send "11/23/2025" instead of "20251123", the 997 would show:

AK3*DTM*5~
AK4*2*373*8~
AK5*R*5~

Error code 8 indicates "invalid date."

3. Business Rule Violations

Trading partners often enforce business rules beyond the base EDI standard. These can include mandatory elements, valid value ranges, or conditional requirements based on other fields.

Example: A retailer requires that all PO line items include a UPC code in the LIN segment. If you send a vendor part number instead, you'll receive a rejection even if the format is technically valid:

AK3*LIN*12~
AK4*3*235*7~
AK5*R*5~

Error code 7 indicates "invalid code value" - the UPC was expected but a different identifier type was provided.

4. Segment Termination and Delimiter Issues

Incorrect use of delimiters can cause the entire transaction to be rejected before it's even parsed.

Example: Using the wrong segment terminator (e.g., using a newline character instead of ~) causes segments to run together. The receiver cannot parse the file and returns:

AK2*850*0001~
AK5*R*6~

Error code 6 indicates "missing or invalid transaction set identifier" because the ST segment couldn't be parsed correctly.

5. Version Mismatch

Using a different EDI version than what was agreed upon with the trading partner.

Example: Sending an 850 in version 4010 when the partner expects 5010. Field positions and qualifiers differ between versions, leading to widespread validation errors. The 997 might show multiple AK3/AK4 segments with various error codes.

6. Control Number Mismatches

Transaction set control numbers must match between the ST and SE segments.

Example:

ST*850*0001~
... [transaction content]
SE*25*0002~  ← Mismatch!

The 997 would return:

AK2*850*0001~
AK5*R*3~

Error code 3: "Transaction set control number in header and trailer do not match."

7. Segment Count Errors

The SE segment declares how many segments are in the transaction. If this count is wrong, the transaction is rejected.

Example: An 850 has 28 segments but the SE declares 25:

SE*25*0001~  ← Should be SE*28*0001~

The 997 returns:

AK2*850*0001~
AK5*R*4~

Error code 4: "Number of included segments does not match actual count."

Step-by-Step Troubleshooting Process

Step 1: Review the 997 Acknowledgment

When you receive a rejected 997, systematically extract the error information:

1. Open the 997 document and locate the AK segments
2. Identify the AK1 and AK2 segments to determine which functional group and transaction are being acknowledged
3. Locate all AK3 segments - these tell you which segment had the error
4. For each AK3, check for corresponding AK4 segments that provide element-level details
5. Review the AK5 segment for the overall rejection code and reason

Tip: Convert the 997 to CSV using PlainEDI to view segments in a spreadsheet format. This makes it easier to spot the AK3/AK4 patterns and cross-reference error codes.

Step 2: Analyze the Error Codes

Use the error codes from AK4 and AK5 to understand the specific problem:

• AK3 segment: Provides the segment ID (e.g., "N1", "DTM", "REF"), position of the segment in the transaction, and the loop ID where the error occurred
• AK4 segment: Gives you the element position within the segment, the element reference number, and the specific error code (1-12)

Example analysis:

AK3*DTM*8~
AK4*2*374*8~

This means:

• The error is in the DTM (Date/Time) segment at position 8 in the transaction
• Element 2 of the DTM segment (the actual date value) has an error
• Element reference 374 corresponds to "Date" in the DTM segment
• Error code 8 means "Invalid date" - the date format is wrong

Step 3: Cross-Reference with Original Transaction

Compare the error information from the 997 with your original EDI transaction:

1. Locate the problematic segment by counting from the ST segment (position 1) to the position indicated in AK3
2. Identify the specific element within that segment using the AK4 element position
3. Compare the actual value against the trading partner's implementation guide to see what was expected
4. Check for typos, format issues, missing delimiters, or incorrect qualifiers

Tip: Use PlainEDI's converter to export both your original transaction and the 997 to CSV. You can then use spreadsheet functions to quickly locate segments by position and compare values side-by-side.

Step 4: Fix Mapping or Data Errors

Based on your analysis, apply the appropriate fix:

For mapping errors:

• Update your EDI mapping configuration to include required segments or elements
• Remove segments that shouldn't be present
• Adjust segment ordering if the partner requires a specific sequence
• Verify loop structures match the implementation guide

For data format errors:

• Correct date formats (CCYYMMDD, CCYYMMDDHHMM, etc.)
• Fix numeric field lengths and decimal positions
• Update code list values to match allowed qualifiers
• Ensure alphanumeric fields don't contain invalid characters

For business rule violations:

• Add mandatory fields required by the trading partner
• Implement conditional logic for dependent fields
• Update source data to include required identifiers (UPCs, GLNs, etc.)
• Configure validation rules in your EDI software to match partner requirements

Step 5: Validate Before Resending

Before resending the corrected transaction:

1. Run the file through a local EDI validator to catch syntax errors
2. Compare against the trading partner's implementation guide
3. Check all mandatory segments and elements are present
4. Verify all data formats match requirements (dates, times, identifiers)
5. Confirm control numbers are correct and unique
6. Test segment count in SE segment matches actual segments

Tools like PlainEDI can help by converting your corrected file to CSV so you can visually verify all fields are populated correctly before transmission.

Prevention Strategies

1. Regular Mapping Reviews

Periodically review and update your EDI mappings to ensure they adhere to the latest trading partner specifications. Retailers often update their implementation guides, and you need to stay current.

2. Automated Data Quality Checks

Implement automated validation in your EDI software or middleware:

• Validate date formats before generating EDI
• Check for required identifiers (UPCs, GLNs, PO numbers)
• Verify numeric fields are within allowed ranges
• Ensure all mandatory fields are populated from source data
• Test that code qualifiers match allowed values

3. Maintain Clear Documentation

Keep detailed mapping documents that show:

• Which source system fields map to which EDI segments/elements
• Business rules and conditional logic
• Trading partner-specific requirements
• Date format conversions and transformations
• Version and implementation guide references

4. Training and Knowledge Transfer

Provide ongoing training for your EDI team on:

• Reading and interpreting 997 acknowledgments
• Understanding trading partner implementation guides
• Using validation tools and converters
• Troubleshooting common error patterns

5. Proactive 997 Monitoring

Set up automated monitoring for incoming 997 acknowledgments:

• Alert when AK5 shows "R" (rejected) or "E" (errors noted)
• Track rejection rates by trading partner and transaction type
• Create dashboards showing common error codes
• Implement automatic retry logic for correctable errors

6. Testing with Trading Partners

Before going live with a new trading partner or transaction type:

• Request access to their test environment
• Send sample transactions covering typical and edge cases
• Review 997 responses carefully and fix all warnings
• Validate against their most recent implementation guide

Using PlainEDI for Faster Troubleshooting

PlainEDI simplifies the 997 troubleshooting process by converting EDI files to CSV/Excel format for visual review and analysis.

How PlainEDI Helps with 997 Errors

• Visual Segment Review: See all segments in a spreadsheet with row numbers matching the positions referenced in AK3
• Easy Element Identification: Quickly locate specific elements within segments using column positions
• Side-by-Side Comparison: Export both your original transaction and the 997 to compare error references
• Data Validation: Spot format issues visually (wrong date formats, missing values, invalid codes)
• Team Collaboration: Share CSV exports with non-technical teams who need to review data issues
• Error Pattern Analysis: Use spreadsheet filters and sorting to identify recurring error patterns across multiple transactions

Example Workflow with PlainEDI

1. Receive 997 rejection with AK3/AK4 error codes
2. Upload original transaction to PlainEDI and export to CSV
3. Upload 997 to PlainEDI and export to CSV
4. Open both CSV files in Excel/Google Sheets
5. Use the segment position from AK3 to locate the error row in your original transaction
6. Use the element position from AK4 to find the exact field with the error
7. Cross-reference the error code against your trading partner's guide
8. Fix the data in your source system or EDI mapping
9. Regenerate the transaction and validate before resending

Additional Resources

For further reading and related troubleshooting, consult these guides on PlainEDI:

• How to validate EDI files before sending
• Understanding EDI X12 delimiters and structure
• Common EDI 850 validation errors and fixes
• 997 Functional Acknowledgment reference
• 850 Purchase Order reference
• 810 Invoice reference

Frequently Asked Questions

What's the difference between AK3 and AK4 segments?

AK3 identifies which segment in your transaction had an error (by segment ID and position). AK4 provides element-level details within that segment, including which specific field failed and why (via error codes). You need both to fully diagnose the issue.

Can I ignore 997 errors marked with "E" (Accepted but errors noted)?

While "E" means the transaction was technically accepted, the errors noted should still be investigated and fixed. Some trading partners treat accumulated "E" responses as compliance violations and may impose penalties or require corrective action plans.

How do I know which EDI version my trading partner expects?

Check your trading partner agreement or implementation guide. The version is also declared in the ISA and GS segments of EDI files (e.g., "00401" for 4010, "00501" for 5010). If you're unsure, contact your trading partner's EDI coordinator.

What if I keep getting rejections even after fixing the errors?

Double-check that you're using the latest implementation guide from your trading partner. Verify your EDI software or middleware is correctly implementing the mapping changes. Consider requesting a mapping review session with the trading partner's technical team. Use PlainEDI to generate CSV exports you can share with them for troubleshooting.

Should I fix errors manually in the EDI file or update my mapping?

Always fix the root cause in your EDI mapping or source system data. Manual file edits are only acceptable for one-time test scenarios. Production errors should be resolved by updating mappings, data transformations, or source system configuration so future transactions are generated correctly.

How long should I wait before resending a rejected transaction?

Fix the underlying issue first, then validate the corrected transaction locally before resending. Most trading partners expect corrected transactions within 24-48 hours, but check your agreement for specific SLAs. Don't resend without fixing the problem - you'll just get another rejection.

Where can I get help if I can't resolve the 997 rejection?

Contact your trading partner's EDI support team with the specific AK3/AK4 error codes and a copy of both your original transaction and the 997 response. Include a CSV export from PlainEDI to make it easier for non-technical support staff to review. If the issue is with your EDI software or mapping tool, escalate to your vendor's support team with the same documentation.

Ready to streamline your EDI troubleshooting? Try PlainEDI's free converter to turn your EDI files into CSV format and resolve 997 rejections faster. For pricing and volume options, see /pricing.