Skip to main content

EDI delimiter conflicts — data truncation and segment errors

Why is my EDI data being truncated after a colon or other separator character?

A
Written by Ashwath Kirthyvasan
Updated over a month ago

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

When EDI transactions data appears truncated after certain characters or fails, this indicates a delimiter conflict between the characters defined in your ISA header and the actual data content.

What This Error Means

Got it — this is a significant improvement to the article. Here's the full updated draft incorporating all of it:

EDI delimiter conflicts — data truncation and segment errors

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

Delimiter conflicts occur when characters used as EDI structural separators also appear inside free-text or descriptive data fields. Because characters like :, -, |, and / are common in plain English (addresses, URLs, notes, product descriptions), they frequently collide with the delimiters defined in the ISA header. When they do, the EDI parser misreads the file structure and produces different types of errors depending on which delimiter is affected.

Background: The Four Delimiters

Every X12 file defines four delimiter characters in its ISA header:

  • Element separator (The character immediately after ISA): Commonly asterisk (*)

  • Repetition separator (ISA11): Only used in version 004020 and later. Commonly caret (^) or pipe (|)

  • Composite element separator (ISA16): Commonly colon (:) or greater-than (>)

  • Segment terminator (also called the end-of-line character — the character immediately after ISA16): Commonly tilde (~)

Here's an example of a correctly formatted ISA segment showing where each delimiter lives:

ISA*00*          *00*          *ZZ*CDSHEEHY       *ZZ*1261055933     *260119*1205*^*00501*000025510*0*P*:~

  • Element separator: *

  • Repetition separator - ISA11: ^

  • Composite element separator - ISA16: :

  • Segment terminator: ~

When any of these delimiter characters appear within actual data values, the EDI parser treats them as structural elements rather than content, causing problems:

  • Transaction not created — The file fails X12 validation due to malformed segments and transactions can't get created

  • Data truncation — Only the portion before the delimiter character is processed

  • Invalid segment structure — The parser creates unexpected breaks in the data

  • Transaction rejection — The partner sends a rejected 997

This type of error usually happens on elements that free-text or descriptive data fields, because some EDI delimiters like :, -, |, and / are common in plain English (addresses, URLs, notes, product descriptions) and frequently collide with the delimiters defined in the ISA header.

How Each Conflict Behaves Differently

The type of error you see — and how the transaction is handled — depends on which delimiter appears in the data.

Segment terminator (end-of-line) conflict

What happens: The parser hits the segment terminator character inside a data field and treats that point as the end of the segment. Everything after it is read as the start of a new segment, and the parser tries to match free English text against known X12 segment identifiers.

Error message:

The EDI Job Failed: Could not post transaction(s) because the file could not be parsed as ANSI X12.  Parsing error: Unprocessed segment(s) existing, starting with a segment ID parsed as "3 TIMES PER MONTH".  Please check if the aforementioned segment ID exists in the intended type / version at the correct position.  If the parsed segment ID is unrecognizable, please check for any rogue separators.

The giveaway here is that the "segment ID" in the error is plain English text — the parser picked up a sentence fragment and tried to match it to a real segment name.

Transaction outcome: No transaction is created.

Composite element separator conflict

What happens: The parser encounters the composite separator (e.g., :) inside a data field and treats the text after it as a new composite component. For non-composite elements, this breaks the segment structure and causes the remainder of the segment to be misread as an unrecognizable segment ID.

Error message:

The EDI Job Failed: Could not post transaction(s) because the file could not be parsed as ANSI X12.  Parsing error: Unprocessed segment(s) existing, starting with a segment ID parsed as "THIS IS A PRODUCTION PO".  Please check if the aforementioned segment ID exists in the intended type / version at the correct position.  If the parsed segment ID is unrecognizable, please check for any rogue separators.

The garbled segment ID (like THIS IS A PRODUCTION PO) is the text that appeared after the rogue composite separator — the parser tried to interpret it as a segment name.

Transaction outcome: No transaction is created.

Element separator conflict

What happens: The parser encounters the element separator (e.g., *) inside a data field and treats that point as the boundary between two elements. No structural break occurs at the segment level, so the transaction is created — but all element values from that point forward are shifted one position. The data ends up mapped to the wrong fields or just not mapped at all.

Transaction outcome: Transaction is created, but may produce:

  • Validation errors — field values fail business rules because they're in the wrong position

  • Partner acknowledgment errors — trading partner's system rejects the transaction via 997 Functional Acknowledgment

  • Silent drops — transaction passes through without error but the partner silently discards or ignores it

This is the most dangerous conflict because it doesn't produce an obvious parsing failure — the file appears to process successfully.

How to Diagnose the Conflict

Unprocessed transaction error

  1. Open the email notification or go to your EDI Jobs in Orderful

  2. Open the failed EDI job and read the error message

  3. Go to the Content tab of the job to view the original transaction as submitted

  4. Search the raw X12 for the text fragment shown in the error message — that is where the rogue separator appears

Validation error

  1. Open the transaction in Orderful — it will show as Invalid

  2. Go to the Rules Editor and review the validation errors listed

  3. Open the transaction attachment labeled Original X12 and reconcile the element positions against the validation errors to identify where the shift occurred

ACK / 997 error

  1. Open the transaction in Orderful — it will show as Rejected

  2. Open the attachment labeled 997 Functional Acknowledgment

  3. Locate the AK3 (segment-level error) and AK4 (element-level error) loops

  4. Reconcile the segment and element positions identified in AK3/AK4 against the Original X12 attachment

Silent drop

  1. Open the transaction in Orderful and view the X12 in the editor

  2. Compare the element values in the editor against the Original X12 attachment

  3. Look for fields that are shifted — a value appearing one position later than expected confirms an element separator conflict

Fixes

For all delimiter conflicts, the sender must resolve the issue directly. There are two paths:

  • Change the delimiter — The sender updates their EDI system to use a delimiter character that does not appear anywhere in their data. Common replacements: : to > or ; for the composite separator; * to | or ! for the element separator; ~ to a hex value for the segment terminator.

  • Clean the data — The sender updates their source system to remove or replace the conflicting characters from descriptive fields before generating the EDI file.

After either fix, retransmit the affected transactions. If trading partner ACK errors were generated, notify the partner that corrected files are being resent.

What to Send Orderful Support

When contacting [email protected] about delimiter conflicts, include:

  • Transaction ID from the failed transaction in Orderful

  • Complete error message exactly as displayed

  • ISA header from your transaction showing current delimiter configuration

  • Sample data containing the problematic characters

  • Trading partner requirements if they've specified delimiter preferences

  • Affected transaction types (850, 810, 856, etc.)

Frequently Asked Questions

My trading partner says their file works fine in other EDI systems — why does Orderful reject it?
Orderful enforces strict X12 compliance. Other systems may silently accept files that technically violate the standard. The file needs to be corrected at the source, or the Orderful delimiter configuration updated to avoid the conflict.

Can I use delimiter characters that also appear in my data?
No. EDI delimiters must be characters that never appear in actual data content. If a character serves both roles, the parser cannot distinguish between structure and content.

Will changing delimiters affect my other trading partners?
No. Delimiter changes are configured per trading partner relationship. If multiple partners share the same account configuration, coordinate with Orderful Support to ensure compatibility.

What happens to transactions that were already rejected?
Previously rejected transactions cannot be automatically reprocessed. After the configuration is updated, retransmit them manually.

Why does Orderful change my delimiters when delivering files to me?
Orderful normalizes delimiters to standard characters (* for elements, > for composite elements, ~ for segments) when delivering to you. This ensures consistency regardless of what delimiters your trading partners use in their original files.

Did this answer your question?