Understand Transaction Validation

Validation is the check Orderful runs on a transaction against the guidelines published by the leader of the relationship. It determines whether the document you are sending meets the requirements the leader set — which fields they require, which codes they accept, how values must be formatted — and it happens before the transaction is delivered.

This article explains how leaders configure validation, which requirements it enforces, how to read validation results, and whether an invalid transaction is delivered.

Leaders configure validation

Every trading relationship has a leader and a follower.

The leader owns the guideline set — their EDI specification, digitized. It defines every requirement validation enforces. The follower is validated against it and cannot edit it on the relationship.

In practice the larger party is usually the leader: a retailer, a carrier, a 3PL. Their vendors and suppliers are followers, and their transactions are checked against the leader's spec.

Guideline requirements

Guideline validation runs on transactions. Structure and syntax are handled earlier, when Orderful parses the incoming file — a file that does not parse never becomes a transaction. See Unprocessed transactions for those checks.

Once a transaction exists, Orderful validates it against all the guideline requirements the leader defined. Leaders routinely require more than the X12 or EDIFACT standard does, and the guideline set is where those requirements live:

• Mandatory elements — fields the leader requires, including ones the standard marks optional. A leader may require REF*DP with a department number on every purchase order.
• Allowed values — code and qualifier lists restricted to what the leader accepts. A leader may accept only UP and VN in PO106; sending EN fails even though EN is valid X12.
• Field lengths — minimums and maximums, often stricter than the standard. A leader may cap N102 at 30 characters where X12 allows 60.
• Data types and formats — numeric, decimal, date and time formatting. Dates required as CCYYMMDD, or a price field required to carry an explicit decimal.
• Conditional requirements — a field required only in certain circumstances. If SAC01 is C for a charge, the leader may require an amount in SAC05.
• Cross-field and calculated rules — requirements spanning more than one element. CTT01 matching the number of PO1 loops, TDS01 matching the sum of the line item amounts, or HL parent pointers resolving to segments that exist.

Validation results

Every validated transaction carries a validation status:

Validation status is separate from delivery status. Validation says whether the document is compliant with the guideline requirements; delivery says whether it has been sent.

You can filter the transaction list by validation status to see everything currently failing.

To see the errors themselves, open the transaction and go to the Rules Editor tab. Each error names the field path and the specific violation — a length error reads Max length: 50. Actual length: 56, and a missing required field names the element. Orderful also emails a notification when a transaction fails validation, but the email does not list the individual errors.

See Fix an invalid transaction for how to resolve them.

Delivery of invalid transactions

What happens to a transaction that fails validation depends on how the relationship is configured. Validation itself is identical either way — the same checks run, the same errors appear on the transaction. Only delivery differs.

Blocking

By default, Orderful does not deliver a transaction that fails validation. The transaction is created and stored with status Invalid, and it stays in Orderful. The leader does not receive it. Once it revalidates as Valid it becomes eligible for delivery.

Blocking is the default because validation is real time. Holding the transaction gives you the chance to fix it with rules while it is still in Orderful — before the leader ever sees it, and before a non-compliant document becomes a rejection, a chargeback, or lost business.

Passthrough

Passthrough is limited to organizations sending EDI files, X12 and EDIFACT, because it exists for the migration case: your live traffic is already flowing through Orderful, but the JSON integration that would resolve your compliance issues is not finished yet. Blocking that traffic would stop your business. Passing it through keeps it moving while showing you where you stand.

That makes passthrough a preview of your compliance state. Every transaction is still validated, the transaction is still marked Invalid, and every error is still listed. The only difference from blocking is that the transaction is delivered anyway, and whether it is accepted is decided by the leader's system rather than by Orderful.

Skipping testing during an onboarding enrollment puts a relationship into passthrough.