Flxpoint Parser Rules — Authoritative Reference

This page captures the Flxpoint parser's actual behavior as confirmed by the Integrations team (Faiyaz Ahmed) on 2026-04-14 (parser spec) and 2026-04-16 (envelope + enum follow-up). It is the authoritative source for what Flxpoint accepts, rejects, or quietly ignores.

Use this page to answer the two most common partner questions:

1. "Will Flxpoint accept my file?"
2. "Is this rule a generic X12 requirement or a Flxpoint-specific one?"

---

1. Envelope Layer (ISA / GS / ST)

Envelope validation is delegated to the core EDI library. Flxpoint's Accept vs. Reject behavior on envelope fields is as follows:

Supported Versions (GS08 / ISA12)

Hard rejection on version strings only happens when the segment structure itself fails to parse — not the version literal.

ISA06 / ISA08 — Sender / Receiver IDs

• Must be exactly 15 characters, right-padded with spaces when the ID is shorter.
• Missing padding → the internal parser fails to find the segment terminator → hard reject.

GS01 — Functional Identifier Code

A GS01/ST01 mismatch is a hard reject.

Control Numbers

• ISA13 must be unique within a 24-hour window from the same Sender ID. Duplicate ISA13 from the same sender is rejected.
• GS06 ↔ GE02 must match; mismatch is rejected.
• ST02 ↔ SE02 must match; mismatch is rejected.

ISA15 — Usage Indicator

• T (Test) and P (Production) are both processed.
• Test files are badged in the Flxpoint UI as "Test Mode" to prevent accidental real-world fulfillment.

---

2. 997 Functional Acknowledgement

Pending formal confirmation from Integrations (2026-04-16 follow-up). Unofficial guidance from Raja Bhanu (2026-04-08): Flxpoint treats 997 as an acknowledgement only. The payload is not run through content validation. Flxpector mirrors this stance — it parses the envelope but does not enforce a content schema on 997.

---

3. 832 Price / Sales Catalog

Pending formal confirmation from Integrations (2026-04-16 follow-up). Himanshu Katyal has a custom 832 implementation for AmerisourceBergen; INT-55281 is the evaluation ticket for a standard 832 structure. Until Flxpoint publishes an official 832 schema, Flxpector emits generic X12 validation only.

---

4. Enum Whitelists

These are the exact values the parser checks against. When the inspector says "invalid ___", partners can use this table to pick a valid value.

SCAC Codes (TD503)

• Flxpoint does not maintain an exhaustive list. New carriers are added constantly.
• Validation is format-only: 2 to 4 alphanumeric characters (e.g. UPSN, FDXE, USPS).
• Flxpector warns when a SCAC is not in the common-carrier list, but the file still processes.

DTM Qualifiers (DTM01)

ACK01 — 855 Line Item Status Codes

Broader X12 codes (AC/AD/AE/AK/BP/DR/IC/ID/IF/IS/IW/RD/RJ/SP) are accepted by the parser for backward compatibility, but only the four above are actively processed by Flxpoint.

SAC02 — 810 Service / Allowance / Charge Codes

Any other SAC code (e.g. AFEE, G740, H750) will be flagged by Flxpector as "may not be processed".

---

5. X12-Standard vs. FLX-Custom Rules

When a partner argues "my file is X12 compliant", these are the rows where Flxpoint diverges from the industry standard. Everything else in the inspector is generic X12 syntax.

Flxpector tags every validation finding with this provenance so the UI can badge FLX-Custom rules distinctly.

---

6. CTT Handling by Transaction Type

---

Source

• 2026-04-14 parser spec (INT-55283) — 846, 856, 855, 850, 810 parser rules.
• 2026-04-16 envelope + enum follow-up (Slack, Faiyaz Ahmed) — ISA/GS rules, SCAC format, DTM/ACK01/SAC02 whitelists, X12-vs-FLX labels, CTT in 846.

Still pending from Faiyaz: formal 997 stance and 832 standard structure.