Audience: EDI developers, B2B integration teams, trading partner technical contacts
EDI transactions fail when they contain characters that are either not allowed by the trading partner's character set restrictions, conflict with X12 separators, or contain invalid Unicode/encoding. This article covers how to identify and fix these character-related validation failures.
What These Errors Mean
Character validation failures occur when your EDI transaction data contains characters that violate one of these rules:
X12 separator conflicts — X12 uses specific characters to parse the file structure: the segment terminator, element separator, and component element separator. If any of these characters appear inside element data, the parser cannot distinguish data from structure. Newline characters cause the same issue. These characters cannot be used in any element value.
Trading partner character restrictions — Your receiving partner has configured their account to only allow specific characters (often alphanumeric only). They may not accept special characters such as
?,",Â,@,&, ...
Note: invalid characters are not always visible. Some may be non-printable or hex-encoded characters that look normal in your source system but cause failures when transmitted.
The most common symptoms are validation errors on free-text, human-readable fields like product descriptions (PID05), address lines (N301/N302), and notes (NTE).
Common Invalid Character Error Messages
X12 separator conflict - Transaction cannot be created:
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 "TERMS". 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.
Partner character restriction (validation error on transaction):
Element PID05 (Description) contains characters not listed in the allowed character set The element contains an invalid character: ''. The receiver EDI account does not allow the '' character to be used Must be alphanumeric (only letters, numbers, spaces and special characters are allowed) The '?' is the invalid character
Partner character restriction (997 error):
In this example, AK403 is 6, which means "Invalid character in data element."
ISA*00* *00* *08*SENDER *12*RCEIVER *250506*1421*:*00501*327268368*0*P*>~GS*FA*SENDER*RECEIVER*20250506*1421*327249987*X*005010~ST*997*0001~AK1*QM*0091~AK2*214*0001~AK3*MS1*7**8~AK4*5*1655*6*0385960~AK5*R*5~AK9*R*1*1*0~SE*8*327251613~GE*1*327249987~IEA*1*327268368~
How to Diagnose Which Characters Are Causing Issues
Step 1 — Identify the error type
Unprocessed transaction — Transaction not created
When an X12 separator character or newline appears in element data, Orderful cannot create the transaction at all. You will receive a parsing error (see example above) with a link to the EDI job. The error message on the EDI job will highlight the segment where the invalid character was detected.Transaction validation error
If the transaction was created but failed validation, there are two possible causes:X12 separator conflict in a rule — if a transformation rule contains an X12 separator character, Orderful can return a validation error pinpointing the exact location in the rule
Partner character restriction — if your partner guidelines have semantic rules enforcing strict alphanumeric requirements, the validation error will identify the element that failed
Transaction acknowledgment error (997)
If your trading partner returns a 997 with a rejected acknowledgment status, open the 997 in Orderful and check the rejection details. The 997 will specify the segment and element position where the invalid character was found.
Step 2 — Locate the segment and element
Once you know the error type, locate the impacted data:
Unprocessed transaction — download the original payload from the EDI job and find the segment identified in the parsing error. The invalid character is usually before the highlighted text in the error message
Transaction validation error — open the Invalid transaction in Orderful; the error will reference the specific element with an invalid character
997 rejection — retrieve the original X12 transaction and navigate to the segment and element position identified in the 997 rejection details in the AK3 and AK4 segments
Examine the data for obvious special characters like @, &, :, *, /, quotes, apostrophes.
Step 3 — Check for non-printable characters
If the data looks normal but still fails, you may have non-printable characters or hex-encoded sequences that aren't visible in your source system. Common signs:
Characters rendering as
Âor?in the payloadSmart quotes or typographic punctuation that visually look like standard ASCII but have different character codes
Newline or carriage return characters embedded in field values
Contact Orderful Support to identify the specific hex values.
Step 4 — Verify your ISA header separators
If you suspect an X12 separator conflict, check the three delimiter characters defined in your ISA header:
Segment terminator — marks the end of each segment (typically
~)Element separator — separates elements within a segment (typically
*) - The first one will be after the first 2 letter of an X12 transactionISAComponent element separator — separates sub-elements within a composite (ISA16, typically
:or>)
Confirm none of these characters appear anywhere in the element data flagged by the error.
Fix 1: Characters Restricted by Trading Partner Settings
What's happening: Your trading partner has configured their account to only allow certain characters (typically alphanumeric), and your data contains restricted characters.
Common restricted characters: @, &, :, *, /, quotes, apostrophes
How to fix it - Choose one of the following:
Add a rule that removes the invalid characters
Example:REPLACE($transactionSets.*.IT1_loop.*.PID_loop.*.productItemDescription.*.description, "#", "")
Fix the source data in your ERP system to prevent sending restricted characters in future transactions
Request character set expansion from your trading partner if the restricted characters are business-critical.
Fix 2: Component Element Separator Conflicts
What's happening: Your data contains the same character being used as a structural delimiter (segment terminator, element separator, or component element separator), causing the parser to misread your data as X12 structure.
Symptoms: Transaction cannot be created; Orderful returns a parsing error referencing an unrecognizable segment ID.
How to fix it - Choose one of the following:
The sender (you or your partner) can remove the conflicting character from your source data — rules cannot fix this because the transaction fails at parsing and can't be created and rules executed
The sender can change their ISA delimiters to characters that don't appear in the data (e.g.,
^or>instead of:)
Fix 3: Invalid Unicode or Hex Characters
What's happening: Your data contains corrupted encoding, invalid hex sequences, or Unicode characters that appear normal but aren't valid ASCII.
Symptoms: Characters like Â, ?, or smart quotes that look identical to regular quotes but cause validation failures.
How to fix it:
Review your data source for encoding issues — often caused by copying data from Word documents or web forms
Implement data cleansing in your source system to convert smart quotes to regular quotes and remove non-ASCII characters
What to Send Orderful Support
When contacting [email protected] about invalid character issues, include:
Transaction ID from the failed transaction in Orderful
Full error message as displayed in the validation details
The specific segment and element position that's failing (PID05, N301, NTE02, etc.)
Sample of the problematic data showing the characters being rejected
Trading partner name and ISA IDs (sender and receiver)
Permission to add rules if you want Orderful to automatically clean the data
Frequently Asked Questions
My data looks normal but keeps failing validation. What's wrong?
You likely have invisible Unicode characters that look identical to ASCII but have different character codes. Contact support to identify the specific hex values causing issues — they can create rules to convert these to valid ASCII characters.
Can I get a complete list of characters that aren't allowed?
Character restrictions vary by trading partner and their account configuration. Some partners only allow alphanumeric characters, while others allow most special characters. The restriction is set by your receiving partner, not by Orderful globally.
Will adding transformation rules affect all my transactions to this partner?
Yes, transformation rules apply to all transactions sent to that specific trading partner relationship. The rules only modify the data as it's transmitted — your source data remains unchanged.
My trading partner says the data is valid. Why is Orderful rejecting it?
Orderful validates against the character set restrictions configured in your trading partner's account settings. Even if the data meets X12 standards, it may violate partner-specific restrictions. Contact support to review the partner's character set configuration.
Can newline characters be automatically removed with rules?
No, newline characters cannot be handled by transformation rules. You must remove them from the source data in your ERP system and regenerate the transaction. This is because newline characters break the fundamental X12 parsing structure.