Screenshot 2025-02-21 at 10.24.24 AM.png
Erik Kiser
Feb 28, 2025 8 Min Read

EDI 997 Document Type: Functional Acknowledgement, Explained

What is EDI 997? Learn about its purpose, format, and usage to enhance efficiency and trust in your electronic data interchange processes.

EDI 101

When businesses exchange documents through Electronic Data Interchange (EDI), they need a way to confirm whether those transactions were received and processed correctly. The EDI 997 (Functional Acknowledgment) serves as a digital receipt that lets the sender know if their EDI transaction was accepted, rejected, or flagged for errors.

Thanks to the EDI 997, businesses catch mistakes earlier, prevent delays, and keep supply chains running smoothly.

In this guide, we'll explain what the EDI 997 is, how it helps improve accuracy in B2B transactions, and offer solutions to common issues that can happen during processing.

What Is EDI 997? EDI 997 Definition

The EDI 997 (Functional Acknowledgement) is a confirmation document that tells the sender whether their EDI transaction was received, accepted, rejected, or contained errors. It’s just one of many EDI transaction sets, each designed for specific business functions. For example, an EDI 850 is used for purchase orders, an EDI 810 handles invoices, and an EDI 856 provides shipping details. Together, these standardized documents help businesses exchange information quickly and accurately.

EDI 997 Specifications and Validation

Let’s break down the technical aspects of the EDI 997 and its validation process.

EDI 997 Technical Structure

The EDI 997 follows the ANSI X12 format, which organizes data into digital containers called "envelopes." These envelopes group multiple transactions into a single electronic message, ensuring structured and efficient processing. Each section of the document serves a specific purpose:

  • ISA (interchange control header): This marks the start of the data exchange and contains sender/receiver details.

  • GS (functional group header): This groups related transaction sets together (e.g., multiple invoices or orders).

  • ST (transaction set header): This marks the beginning of the EDI 997 transaction set.

  • Functional acknowledgment segments: These segments indicate whether each transaction set was accepted, rejected, or partially accepted due to errors. They also help the sender confirm that their data was properly formatted and received by the recipient's system.

  • SE (transaction set trailer): This indicates the end of the 997 transaction set.

  • GE (functional group trailer): This closes the functional group of transactions.

  • IEA (interchange control trailer): This ends the interchange envelope, confirming that all included transactions have been received.

EDI 997 Validation Process

When a business receives an EDI 997, it goes through a validation process to check for accuracy and compliance with industry regulations like HIPAA (for healthcare) and Sarbanes-Oxley (for financial reporting). This step is important because, without proper validation, errors in invoices, purchase orders, or payment records could lead to shipping delays, financial mistakes, or legal penalties.

To prevent these issues, the EDI 997 validation process includes the following steps:

  1. Control number verification ensures that the control numbers from the original document match, confirming receipt and preventing duplicate processing.

  2. Syntax checks confirm that elements and segments follow ANSI X12 syntax rules to avoid formatting errors.

  3. Semantic validation checks that data values make sense and are accurate. For example, it confirms that invoice totals match itemized amounts, dates are correct, and required fields are filled in.

  4. Error reporting uses AK3 (Segment Error Report) and AK4 (Element Error Report) to highlight specific transaction errors so they can be corrected.

  5. Acknowledgment codes let the sender know whether a transaction was received and if it was accepted, rejected, or accepted with errors. The AK5 (Transaction Set Response) applies to individual transactions, while the AK9 (Functional Group Response) applies to groups of transactions in an interchange. For example, if a supplier sends an invoice (EDI 810) and receives an EDI 997 with an AK5 rejection code, they know there’s an issue — such as missing data or incorrect pricing — that must be corrected before resending.

EDI 997 Sample Document

Here’s an example of a typical ANSI X12 EDI 997 that businesses use to confirm they received an EDI transaction and to communicate whether there were any issues with the data:

ISA*00*          *00*          *ZZ*SENDERID      *ZZ*RECEIVERID    *230214*1234*U*00401*000000001*0*P*>~

GS*FA*SENDERID*RECEIVERID*20230214*1234*1*X*004010~

ST*997*0001~

AK1*IN*123456~

AK2*810*987654~

AK5*A~

AK9*A*1*1*1~

SE*6*0001~

GE*1*1~

IEA*1*000000001~

EDI 997 Elements

We listed the main EDI 997 segments earlier, but here’s a closer look at what each one does:

Control Numbers

Each EDI 997 document, transaction set, and functional group has a unique control number. This number must match the control number of the original document to confirm that the transaction was received correctly. Matching control numbers let businesses know they're tracking the right documents, and they prevent duplicate transactions from being processed by mistake.

EDI Functional Acknowledgement Status

When a business sends an EDI document, it needs to know if it was received and processed correctly. The EDI 997 provides this confirmation using three main status codes:

  • Accepted (A): The transaction was received and successfully processed.

  • Rejected (R): There was an issue, and the document needs to be corrected and resent.

  • Accepted with errors (E): The transaction went through but contains issues that may require attention.

These codes appear in AK5 (Transaction Set Response Status) for individual transactions and AK9 (Functional Group Summary) for grouped transactions (more on those below).

Data Elements

Every EDI 997 segment serves a specific role in confirming whether a transaction was received, accepted, or rejected. Here’s what each one does:

AK1: Functional Group Acknowledgment

The AK1 segment confirms that an entire functional group of transactions was received.

  • AK101 identifies the transaction type (e.g., "IN" for invoices).

  • AK102 matches the functional group control number from the original document.

AK2: Transaction Set Acknowledgment

The AK2 segment acknowledges each individual transaction within a functional group.

  • AK201 identifies the type of transaction (e.g., "850" for purchase orders and "810" for invoices).

  • AK202 matches the transaction set control number from the original document.

AK3: Identifying Segment-Level Errors

The AK3 segment pinpoints errors in specific segments of the transaction.

  • AK301 identifies the segment with the issue (e.g., "REF" for reference number errors).

  • AK302 indicates where the segment appears in the transaction.

  • AK303 specifies the loop (if applicable), identifying errors in repeating data groups, such as multiple line items in a purchase order.

  • AK304 provides an error code explaining the issue (e.g., "missing mandatory segment").

AK4: Identifying Data Element Errors

The AK4 segment highlights errors in specific data elements.  

  • AK401 identifies the exact position of the error.

  • AK402 pinpoints its location within a composite structure, if applicable.

  • AK403 provides an error code (e.g., "invalid characters" or "missing mandatory data").

AK5: Transaction Set Response Status

The AK5 segment summarizes whether a transaction set was accepted, rejected, or flagged for review.

  • AK501 displays the status code (“A” for accepted, “R” for rejected, or “E” for accepted with errors).

  • AK502–AK506 provide additional error details if the transaction was rejected.

AK9: Functional Group Summary

The AK9 segment summarizes the status of an entire functional group of transactions.

  • AK901 indicates whether the group was accepted, rejected, or accepted with errors.

  • AK902 shows the total number of transactions in the group.

  • AK903 displays how many were successfully received.

  • AK904 specifies how many were accepted without errors.

5 Benefits of Using EDI 997

Calling the EDI 997 a transaction receipt is arguably an understatement. In reality, it does so much more. Of its many benefits, here are five of the most noteworthy:

1. Faster Transaction Processing

Instead of waiting for a confirmation email or phone call, businesses receive instant acknowledgment that their EDI documents arrived. There’s no need to confirm directly with the recipient.

2. Clearer Transaction Tracking

With EDI 997, businesses always know whether their documents were accepted, rejected, or had errors. If something goes wrong, the acknowledgment pinpoints where the issue is, making it easier to correct mistakes before they cause bigger problems.

3. Lower Costs and Less Paperwork

Since EDI 997 replaces manual tracking and paper-based acknowledgments, businesses save time and money. Employees don’t have to chase down missing documents, and companies cut back on printing, mailing, and storage costs.

4. Fewer Errors in Data Exchange

Each EDI document comes with control numbers and transaction IDs to make sure it matches the right transaction. EDI 997 checks these details automatically, reducing errors from duplicate or mismatched records.

5. Early Problem Detection

If there’s an issue — like a missing field, incorrect price, or formatting mistake — EDI 997 flags it immediately. Fixing errors early prevents shipping delays, payment disputes, and supply chain disruptions down the line.

4 Common Issues with EDI 997 and Ways to Solve Them

While EDI 997 helps businesses confirm transactions, mistakes in formatting or processing can lead to delays and errors. Let’s look at four common challenges and how to fix them.

1. Not Following Partner Specifications

Each trading partner has its own rules for how EDI transactions should be formatted. If an EDI 997 document doesn’t match those requirements, it can lead to delays, processing errors, or rejections.

Solution: Use EDI mapping tools to adjust document formatting based on each partner’s specifications. Regularly update your EDI setup to keep up with any changes they make.

2. Not Complying with EDI Document Standards

EDI 997 documents have to follow the ANSI X12 standard to be processed correctly. If they don’t meet these guidelines, the recipient’s system might reject them or flag errors.

Solution: Choose an EDI provider that offers built-in validation tools that check for compliance before sending documents. Running test transactions with trading partners can also help catch problems early.

3. Missing Segments or Data Elements

Every EDI 997 document needs specific segments, like control numbers, to be processed correctly. If any required data is missing, the acknowledgment may be incomplete and can cause system errors or other delays.

Solution: Set up your EDI software to check for missing segments before sending documents. Using pre-built EDI 997 templates ensures that all necessary information is included every time.

4. Invalid or Corrupted Data

If an EDI 997 document contains wrong, corrupted, or poorly formatted data, the recipient’s system may reject it. This takes time and extra work to fix the problem.

Solution: EDI validation tools also check for errors before sending the document. Regularly reviewing and auditing transaction data will also help catch recurring mistakes and prevent processing disruptions.

Automate EDI 997 with Cloud-Based EDI

Managing EDI 997 acknowledgments manually can be time-consuming and prone to errors, but cloud-based EDI solutions automate the process, allowing for faster, more reliable data exchanges. With real-time tracking, built-in compliance checks, and seamless integration with your existing systems, a cloud-based EDI managed service guarantees that every transaction is received, validated, and acknowledged.

Connect with an EDI expert today to learn more about what cloud-based EDI can do for you.