Audience: EDI developers, B2B integration teams, trading partner technical contacts

When Orderful cannot parse your EDI file as valid ANSI X12, the transaction is not created. You will receive a "Transaction not created" email with a link to the EDI job where you can download the original payload and review the error. There will be no transaction record in Orderful.

X12 parsing errors are distinct from validation errors. Parsing errors occur when the file structure itself cannot be read — Orderful cannot interpret where segments begin and end, or encounters segment identifiers it cannot place in the transaction structure. Validation errors occur after a transaction is successfully created but fails content checks. This article covers parsing errors only.

X12 parsing errors occur when Orderful's parser cannot read your EDI file as a valid ANSI X12 structure. The parser reads the file sequentially — it identifies segment boundaries using the delimiters defined in your ISA header, then attempts to place each segment into the expected transaction structure for your transaction type and version.

A parsing error means this process broke down at a specific point. Either the parser encountered a segment identifier it cannot place in the structure (wrong position), a segment identifier it doesn't recognize at all (unknown segment or rogue delimiter), or the file structure itself is corrupt in a way that prevents sequential reading.

Because the file cannot be read, no transaction is created. The error is logged at the EDI job level, not the transaction level.

Segment in wrong position:

Unknown or unrecognized segment

Invalid X12 characters

When a parsing error occurs:

There is no transaction record to look up in Orderful. The EDI job is the only entry point for diagnosing parsing failures.

What's happening: A valid X12 segment appears at a position in the file where the parser doesn't expect it. Because it cannot be placed in the transaction structure, the parser treats it as an unrecognized segment ID and halts.

For example, an N3 segment appearing before the expected N1 segment, or outside its allowed loop, will cause the parser to report "N3" as an unrecognized segment ID — even though N3 is a valid X12 segment.

How to fix it:

Review the X12 specification for your transaction type and version to confirm the correct segment order and loop structure. Locate the segment identified in the error and move it to its correct position. Update your EDI generation logic to output segments in the order the specification requires.

What's happening: The parser encounters a segment identifier it cannot recognize at all — either because it doesn't exist in the X12 specification, contains a typo, or is the result of rogue separator characters in element data corrupting the file structure.

For example, NN3 is not a valid X12 segment. This could be a typo in the EDI generator, or it could be caused by a separator character appearing inside data — splitting what should be a single element value into what the parser reads as a new segment ID.

How to fix it:

First, check whether the segment ID in the error is a recognizable typo of a valid segment (e.g., NN3 vs N3). If so, correct the segment ID in your EDI generation.

If the segment ID looks like garbled data rather than a typo, the cause is likely a rogue separator character. Check your ISA header delimiter definitions — the element separator, component element separator, and segment terminator — and look for any of those characters appearing inside your data values. See the Invalid Characters in EDI Transactions article for detailed guidance on diagnosing and fixing separator conflicts.

What's happening: A character that matches one of the X12 delimiters defined in your ISA header — the element separator, component element separator, or segment terminator — appears inside a data value. The parser reads it as structure rather than data, splitting the value at that point and causing everything that follows to be misread. Newline characters embedded in element data cause the same problem.

The error message will reference an unrecognizable segment ID that is clearly not a real X12 segment — often a fragment of data that happened to follow the rogue delimiter.

How to fix it:

Check your ISA header delimiter definitions and scan the element data around the segment identified in the error for any of those characters. Remove the conflicting characters from the source data before resubmitting. This cannot be fixed with a transformation rule — the file fails before rules execute.

Some X12 content issues does not cause parsing errors — Orderful handles it silently:

If you cannot identify the cause from the error message and payload, contact [email protected] with:

I got a "Transaction not created" email but can't find the transaction in Orderful. Where is it?

Parsing errors prevent transaction creation entirely. There is no transaction record — only the EDI job linked in the email. Start your investigation there.

The error identifies a valid segment ID. Does that mean the segment itself is wrong?

Not necessarily. A valid segment appearing in the error usually means it's in the wrong position, not that the segment is inherently incorrect. Check the X12 specification for where that segment is allowed in your transaction type and version.

My EDI file looks correct but the error points to a segment that seems fine. What else could cause this?

Rogue separator characters in your data are a common hidden cause. If a character that matches your element separator or segment terminator appears inside a data value, the parser will misread everything that follows. Check your ISA delimiters and scan the element data around the segment identified in the error.

Why doesn't Orderful show floating segment data in the transaction view?

Floating segments are not mapped to the structured JSON representation Orderful uses internally. They are typically free-text annotation fields that don't correspond to fields in standard ERP or SOR systems. The data is preserved in the raw X12 payload available from the EDI job.

My trading partner says the file is valid. Why is Orderful rejecting it?

Orderful parses strictly against the ANSI X12 specification for the transaction type and version in your relationship. Other systems may be more permissive. The file structure needs to conform to the X12 standard — segment order, loop structure, and delimiter usage all matter.