EDI 997 — Functional Acknowledgement

Purpose

Confirm receipt of an EDI transaction. Flxpoint sends a 997 to you for every file of yours it reads successfully. It confirms the file arrived and could be read — it does not confirm business logic. A file Flxpoint cannot read gets no 997 at all.

How It Works

The 997 is the receipt. Every time you send Flxpoint a file it can read — an 846, an 855, an 856, an 810, an 870 — Flxpoint writes a tiny 997 back to your outbound folder that says "got it, the file 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, when a job on the Flxpoint source runs, for every inbound file it reads successfully. Find 997s in your /out (outbound from Flxpoint) directory, named 997_ followed by the name of the file they acknowledge.

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 846 / 855 / 856 / 810 / 870 file that Flxpoint reads successfully triggers a 997 response. You do not request it — it is written to your outbound SFTP directory when the file is read.
• No 997 for a file that fails. Flxpoint writes the 997 only after every transaction in the file has passed its parser. A file it cannot read, or a file in which any transaction fails to parse (a structural error, an unmapped segment, or a transaction set Flxpoint does not process, such as the 860), gets no 997 at all, not a 997 with a rejection code. So a missing 997 after the next job run is the signal that the whole file was rejected and nothing in it was applied: run it through Flxpector, fix it, and send it again under a new file name.
• A 997 is not proof the order changed. The 997 is written before the documents are matched to orders, so a file can be acknowledged and still not update an order (for example, a PO number that matches no open order).
• The 997s you send are accepted but not acted on. Flxpoint downloads them with your other files and skips them; they do not change any order. A file that holds only 997s gets no 997 back, and the connection's file setting (move, delete or rename after reading) does not touch it.
• 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 and read? Check Flxpoint's inbound logs for the ASN / invoice listed in the overdue report. If it is not in the logs, Flxpoint never picked it up: the partner never delivered it, or it reused a file name Flxpoint had already downloaded. If it is in the logs with a parsing error, Flxpoint rejected it and sent no 997 by design: the partner needs to fix the file and resend it under a new name.
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.