EDI 997 functional acknowledgment: What it is and how it works

In B2B automation, sending an EDI document is only half the job. The sender also needs to know whether the receiving EDI system processed the file and whether it passed basic X12 syntax validation.

That is where the EDI 997 functional acknowledgment comes in.

An EDI 997 acts as an operational checkpoint in an EDI X12 workflow. It tells the sender whether a transaction set, such as an EDI 850 purchase order or EDI 810 invoice, was received by the EDI process and syntactically accepted, accepted with errors, or rejected.

A 997 should not be confused with a transport acknowledgment. For example, an AS2 MDN confirms message disposition at the transport level, while an EDI 997 confirms functional acknowledgment at the X12 transaction-processing level.

For integration developers, the EDI 997 is more than a compliance artifact. It is a key signal for monitoring B2B transaction health, troubleshooting partner issues, and ensuring that failed documents are caught before they disrupt downstream operations.

What is EDI 997 and what does it confirm?

EDI 997 is an X12 functional acknowledgment transaction. It is sent by the receiver of an EDI document to confirm that the document reached the receiving EDI process and was checked against EDI syntax rules.

The most important point: an EDI 997 does not confirm that the underlying business transaction was accepted.

For example, if a retailer receives an EDI 850 purchase order and returns a 997 with an accepted status, that means the purchase order was received by the EDI process and passed syntax validation. It does not mean the retailer accepted the order, committed inventory, approved fulfillment, or agreed to pricing.

An EDI 997 can confirm:

• The EDI transaction reached the receiving EDI process
• The transaction was checked for X12 syntax
• The transaction was accepted, accepted with errors, or rejected
• Specific segment or data element errors were found

An EDI 997 cannot confirm:

• Purchase order acceptance
• Inventory availability
• Shipment commitment
• Invoice approval
• Fulfillment status
• Business-level approval
• Transport-level delivery confirmation in the same way as an AS2 MDN

In a standard EDI workflow, the 997 is typically generated shortly after the receiving system validates the inbound file. It gives the sender an early signal that the document was technically processed, or that it needs correction and resubmission.

Key segments in an EDI 997 document

An EDI 997 is made up of defined segments that describe the functional group, transaction set, and any errors found during validation.

AK1: Functional group acknowledgment

The AK1 segment identifies the functional group being acknowledged. It includes the functional identifier code and the group control number from the original EDI transmission.

For example, if the original document was an EDI 850 purchase order, the AK1 segment may reference the purchase order functional group.

AK2: Transaction set header

The AK2 segment, when included, identifies the specific transaction set being acknowledged within the functional group.

It typically includes the transaction set ID, such as 850, 810, or 856, and the transaction set control number. This allows the sender to connect the acknowledgment back to the original EDI document.

AK3: Data segment note

The AK3 segment identifies a specific segment that contains an error.

It may include the segment ID, the segment position, and the loop identifier where the error occurred. This helps integration teams locate the problem inside the original EDI transaction.

AK4: Data element note

The AK4 segment identifies the specific data element in error within the segment flagged by AK3.

This is useful when the issue is not just a missing or invalid segment, but a specific field inside that segment. For example, a required date, code, or identifier may be missing or incorrectly formatted.

AK5: Transaction set response trailer

The AK5 segment reports whether an individual transaction set was accepted, accepted with errors, or rejected.

This is one of the most important segments in the 997 because it indicates the status of the transaction set to the sender. AK5 may also include syntax error codes that explain why a transaction was accepted with errors or rejected.

AK9: Functional group response trailer

The AK9 segment reports the status of the full functional group.

It includes the number of transaction sets included, received, and accepted. While AK5 applies to an individual transaction set, AK9 gives the overall acknowledgment status for the group.

EDI 997 acknowledgment codes and error types

The acknowledgment codes in an EDI 997 indicate whether the transaction was accepted, accepted with errors, or rejected.

AK5 acknowledgment codes

AK5 reports the status of an individual transaction set.

Common AK501 values include:

• A: Accepted. The transaction set was accepted.
• E: Accepted with errors. The transaction set was accepted, but errors were found.
• R: Rejected. The transaction set was rejected and typically needs correction and resubmission.

If a transaction is rejected, the sender should review the associated AK3 and AK4 segments to identify the segment or data element that caused the failure.

AK9 acknowledgment codes

AK9 reports the status of the functional group.

Common AK901 values include:

• A: Accepted. The functional group was accepted.
• E: Accepted with errors. The functional group was accepted, but errors were found.
• R: Rejected. The functional group was rejected.

AK9 may also include additional syntax error codes that explain group-level validation issues.

How EDI 997 works in an EDI workflow

The EDI 997 is typically generated automatically by the receiving system after an inbound EDI transaction is validated.

A standard flow looks like this:

1. A sender transmits an EDI transaction, such as an 850 purchase order, 810 invoice, or 856 advance ship notice.
2. The receiver’s system validates the file against X12 syntax and configured EDI validation rules, which may include trading partner-specific requirements.
3. The receiver generates an EDI 997 functional acknowledgment.
4. The sender receives the 997 and reviews the acknowledgment status.
5. If the transaction was rejected, the sender investigates the error, corrects the document, and resubmits it.

In production B2B environments, this process needs to be automated and monitored. Manual tracking creates risk, especially when teams are exchanging large transaction volumes across many trading partners.

Common operational problems include:

• A 997 is never received
• A transaction is rejected but no one notices
• Accepted-with-errors responses are not investigated
• Partner-specific validation rules cause unexpected failures
• Teams cannot easily reconcile inbound documents with outbound acknowledgments

This is where EDI acknowledgment handling becomes an integration operations problem, not just an EDI standards problem.

How Celigo simplifies EDI 997 functional acknowledgments

Celigo helps teams automate and monitor EDI 997 functional acknowledgments as part of a broader B2B integration workflow.

Instead of manually generating, tracking, and reconciling acknowledgments across trading partners, teams can manage EDI 997 handling inside Celigo’s integration platform.

With Celigo, teams can support EDI 997 workflows through:

Automated acknowledgment generation. Celigo can generate functional acknowledgments for inbound EDI X12 transactions received from trading partners. This reduces the manual work required to confirm receipt and validation status.

Validation using EDI profiles and rules. Inbound EDI files can be parsed and validated using EDI profiles, validation rules, and file definition rules before acknowledgment generation. The parsing and validation results help determine whether the acknowledgment status is accepted, accepted with errors, or rejected.

Acknowledgment reconciliation. Celigo helps teams connect the functional acknowledgment back to the original EDI transaction, making it easier to understand which documents were accepted, rejected, or require follow-up.

EDI activity monitoring. The Celigo EDI activity dashboard gives teams visibility into EDI flows, documents, and acknowledgment statuses. This helps integration teams monitor whether transactions were accepted, accepted with errors, rejected, failed, in progress, not applicable, or not received without manually reviewing each file.

Exception handling and operational visibility. When transactions fail, teams need more than a raw EDI error. They need a way to identify the issue, route it to the right owner, correct it, and keep the B2B workflow moving. Celigo supports this operational layer by helping teams monitor errors and manage exceptions across integration flows.

For enterprise B2B teams, the value is not just generating a 997. The value is managing acknowledgments as part of a reliable transaction lifecycle: partner onboarding, EDI validation, functional acknowledgment, monitoring, exception handling, and downstream integration with ERP, WMS, CRM, and fulfillment systems.

Celigo gives integration teams the automation and visibility needed to manage EDI acknowledgments at scale.

→ Request a demo to see how Celigo helps teams automate EDI acknowledgments, monitor transaction status, and manage B2B workflows at scale.