EDI 997 — Functional Acknowledgement

Purpose

Confirm receipt of an EDI transaction. Flxpoint sends a 997 to you every time it receives a file from you. It confirms the file arrived and was structurally valid — it does not confirm business logic.

How It Works

The 997 is the receipt. Every time you send Flxpoint a file — an 850, an 856, an 810 — Flxpoint writes a tiny 997 back to your outbound folder that says "got it, the envelope was readable." It is not a business confirmation: it does not promise the inventory was updated, the shipment was accepted, or the order was processed. That is what the 855 (PO acknowledgement) and 810 matching are for. Think of the 997 like a delivery receipt for a certified letter — it proves the letter arrived, not that the recipient agreed with what was inside. Most "overdue 997" support tickets turn out to be SFTP round-trip issues (the partner never picked up the file from /out), not actual processing failures.

Frequency

Sent by Flxpoint automatically in response to every inbound transaction. Find 997s in your /out (outbound from Flxpoint) directory.

Business Rules

• You must generate a 997 for every transaction Flxpoint sends you (850, etc.)
• A 997 with AK501=A means the transaction was accepted
• A 997 with AK501=E means accepted with errors — review the AK5 detail
• A 997 with AK501=R means rejected — the file had structural issues

Acknowledgement Status Codes

AK501 — Transaction Set Acknowledgement Code

AK901 — Group Acknowledgement Code

Segment Hierarchy

ISA  Interchange Header
 GS  Group Header (GS01 = "FA")
  ST   Transaction Set Header (ST01 = "997")
  AK1  Functional Group Response Header
  ┌─ AK2 Loop (one per transaction set)
  │  AK2  Transaction Set Response Header
  │  AK5  Transaction Set Response Trailer
  └─
  AK9  Functional Group Response Trailer
  SE   Transaction Set Trailer
 GE  Group Trailer
IEA  Interchange Trailer

Segment Specifications

ST — Transaction Set Header

AK1 — Functional Group Response Header

AK2 — Transaction Set Response Header

AK5 — Transaction Set Response Trailer

AK9 — Functional Group Response Trailer

SE — Transaction Set Trailer

Example — Accepted 997

ISA*00*          *00*          *ZZ*FLXPOINT       *ZZ*SUPPLIER       *240115*1200*U*00401*000000015*0*P*>~
GS*FA*FLXPOINT*SUPPLIER*20240115*1200*15*X*004010VICS~
ST*997*0001~
AK1*SH*253~
AK2*856*3936~
AK5*A~
AK9*A*1*1*1~
SE*5*0001~
GE*1*15~
IEA*1*000000015~

What this means: Flxpoint received your 856 (Ship Notice, GS control number 253, ST control number 3936) and it was accepted (AK5*A).

Reading 997 Errors

If you receive a 997 with AK501=E or AK501=R, the AK5 segment will include error codes:

How Flxpoint Handles 997s

Because the 997 is an envelope-level acknowledgement (not a business validation), Flxpoint treats it differently from transactions like the 846 or 856:

• Generation is automatic. Every inbound 850 / 855 / 810 / 846 / 856 that Flxpoint receives triggers a 997 response. You do not request it — it is written to your outbound SFTP directory as soon as the file is read.
• Validation is structural only. Flxpoint does not open the business content to produce the 997. The 997 confirms that the interchange, group, and transaction-set envelopes are well-formed — that is all.
• Envelope and delimiters only inside Flxpector. The Flxpector inspector does not run schema checks on 997 content because there is no business payload to validate. It does check the envelope (ISA/GS/ST/SE/GE/IEA counts and control numbers) and the delimiters: a 997 whose segment terminator is corrupted (TOK-003) is reported as invalid, because that is a real reason a partner cannot read it. A well-formed 997 parses with no findings.
• Flxpector focuses on the transactions that carry business data (846, 850, 855, 856, 810). If you need to confirm a 997 round-trip, check your SFTP /out folder and your partner's pickup logs.

This is the same approach most X12 processors take: the 997 is infrastructure, not content.

Troubleshooting — "We didn't receive your 997"

This is one of the most common support requests. Partners occasionally send an "Overdue Ack Report" email listing ASNs or invoices they say were not acknowledged within the expected window.

Before assuming the 997 is missing, verify the round trip:

1. Was the original file received? Check Flxpoint's inbound logs for the ASN / invoice control number (ISA13 / GS06 / ST02) listed in the overdue report. If it is not in the logs, the partner never delivered it — the issue is upstream of Flxpoint.
2. Did Flxpoint generate the 997? Ninety-nine percent of the time the 997 was generated and written to the outbound folder within seconds of receipt. Confirm the file exists in your outbound SFTP directory with the matching control numbers.
3. Did the partner pick it up? If the 997 is on the outbound server and the partner says they did not receive it, the issue is on the partner side or in the SFTP connection configuration. Options:
   • Verify the partner is polling the correct outbound path.
   • Confirm their whitelist includes the Flxpoint SFTP host and static IP.
   • If the partner hosts the SFTP, confirm Flxpoint has write credentials to the expected drop path.

Who handles it? This is operational (SFTP / logs), not parsing. It is worked by the integrations team through backend logs — it is not a Flxpector validation case. When the chatbot is asked about "overdue 997s," it should point the user to this troubleshooting flow and avoid suggesting parser fixes.

Troubleshooting — "Your 997 has an invalid segment separator"

The partner opens Flxpoint's 997 and every segment ends in a strange character (�, �, or a ?) instead of ~. Their translator rejects the file with a message like "segment separator qualifier is invalid" and asks for ~.

What happened. Flxpoint's 997 reuses the delimiters of the file it acknowledges, terminator included. If the partner's inbound file (usually an 856 or 810) ended its segments with a byte that is not valid UTF-8 (a common one is 0x85, the NEL control character), Flxpoint read that byte as the Unicode replacement character U+FFFD and wrote it back as the 997's terminator. Flxpoint processed the inbound file fine; only the acknowledgement is unreadable.

How to confirm. Paste the 997 into Flxpector: it reports a single finding, TOK-003 Invalid segment terminator, naming the character. The Breakdown tab shows the terminator in red at the end of every row.

Resolution.

1. The partner cannot fix the root cause on their side because Flxpoint wrote the file. Ask them to send the 997 to support@flxpoint.com (or open the ticket for them) so it can be re-issued. Flxpector's "Apply fix" gives them a readable copy with ~ in the meantime.
2. Ask the partner to end segments in their outbound files with ~ (or another printable ASCII character). That is what stops the next 997 from inheriting the byte. Recommend ~ over ?: ~ is the X12 convention and ? is a release character in EDIFACT.
3. Internal: engineering can pin the 997 syntax to ~ in the generator regardless of the inbound file (dmx-core, setAcknowledgment(writer, SyntaxDescriptor)); until that ships, this section applies.

Do not tell the partner "the 997 is only a receipt, nothing to fix": in this case the file itself is malformed and their translator is right to reject it.