EDIFACT Message Validator

Validates bounded UN/EDIFACT interchanges and emits stable syntax, envelope, count, narrow message-structure, partner-rule, and optional CONTRL evidence. It is built for EDI integration teams, ERP mapping developers, supplier onboarding and transaction-operations teams. The main result is structured, deterministic evidence that can be consumed from the default dataset or an Apify automation.

When to use this Actor

• Validate ORDERS, INVOIC, DESADV, or CONTRL messages before partner transmission.
• Regression-test an EDI mapping against a pinned directory and deterministic finding fingerprints.
• Generate a CONTRL acknowledgement for delivery through an existing EDI transport.

How it works

• Tokenize UNA-defined delimiters and release characters, then validate UNB/UNZ and UNH/UNT nesting, references, and counts.
• Apply the selected D96A, D01B, or D20B compatibility pin and the Actor's narrow original message profiles.
• Apply optional require/forbid segment overlays and persist transaction, finding, canonical, and optional acknowledgement output before charging.

The Actor validates only the declared product contract. It does not infer facts outside the supplied data or claim outcomes that the source material cannot prove.

Quick start

1. Open the Actor's Input tab or create a Task from one of the public examples.
2. Paste or adapt this bounded example.
3. Click Start and inspect the default dataset plus the output links shown on the run page.

{
  "interchanges": [
    {
      "sourceId": "po-1001",
      "content": "UNB+UNOC:3+SENDER:14+RECEIVER:14+260916:1200+IREF'UNH+1+ORDERS:D:01B:UN'BGM+220+PO-1001+9'DTM+137:20260916:102'NAD+BY+BUYER::9'LIN+1++SKU-1:EN'QTY+21:5'UNT+7+1'UNZ+1+IREF'"
    }
  ],
  "directory": "D01B",
  "mode": "strict",
  "generateContrl": true,
  "partnerRules": []
}

Expected result: a transaction result with any deterministic findings, canonical JSON, and a CONTRL acknowledgement artifact.

Input

The quick-start example is intentionally small. These are the material controls; the Input tab remains authoritative for the complete current schema.

Field	Purpose and format	Default	Important bounds or interaction
interchanges	Independent inline UN/EDIFACT interchange strings with stable source IDs.	No implicit default	minimum items 1; maximum items 100
directory	Supported UN/EDIFACT directory used to validate message structures and segment rules.	No implicit default	one of D96A, D01B, D20B
mode	Selects the declared strict or compatible validation behavior without guessing partner conventions.	"strict"	one of strict, tolerant
generateContrl	Requests a CONTRL acknowledgement only for supported message outcomes; disabling it leaves validation evidence unchanged.	false	See the Input tab for the current schema bound.
partnerRules	Explicit bounded partner-specific qualifiers layered on the base directory rules; no conventions are inferred.	No implicit default	maximum items 100
maxInterchangeBytes	Maximum UTF-8 size accepted for each interchange before parsing.	2000000	minimum 128; maximum 10000000
maxSegmentsPerInterchange	Maximum segment count accepted from one interchange.	20000	minimum 4; maximum 100000
maxMessagesPerInterchange	Maximum UNH/UNT message envelopes accepted from one interchange.	1000	minimum 1; maximum 10000

Unknown top-level fields and invalid field combinations fail validation rather than being guessed.

Output

The default dataset contains typed records. The run's Output tab links the dataset and any key-value-store reports declared by the current output schema.

Field	Meaning
recordType	Identifies transaction, finding, or failed interchange rows.
sourceId	Current dataset field.
status	PASS, WARN, or FAIL transaction result under the selected mode and overlays.
messageType	Current dataset field.
directory	Current dataset field.
interchangeReference	Current dataset field.
messageReference	Current dataset field.
documentNumber	Current dataset field.
findingCode	Current dataset field.
severity	Current dataset field.
segmentIndex	Current dataset field.
message	Current dataset field.
fingerprint	Stable identity for deterministic regression comparison.
engineVersion	Current dataset field.

Representative current-schema dataset item:

{
  "recordType": "transaction",
  "sourceId": "po-1001",
  "status": "PASS",
  "messageType": "ORDERS",
  "directory": "D01B",
  "interchangeReference": "IREF",
  "messageReference": "1",
  "documentNumber": "PO-1001",
  "engineVersion": "1.0.0"
}

An interchange with no transaction message is not converted into a successful transaction; its envelope/structure outcome remains explicit.

Pricing and billing

This Actor uses PAY_PER_EVENT; platform usage is included in event prices. A charge is eligible only after the billable unit described below is durably completed. Validation failures and the non-billable failure classes in the product contract do not emit the custom completion event. Higher Store tiers use the complete tier matrix below; Platinum and Diamond match Gold under the current policy. The Apify Pricing tab is authoritative if a later approved pricing change takes effect.

Event	What triggers it	FREE	BRONZE	SILVER	GOLD	PLATINUM	DIAMOND
transaction-validated	Charged once after one supported EDIFACT message reaches a final validation result and durable evidence is written.	$0.01000000	$0.00950000	$0.00900000	$0.00850000	$0.00850000	$0.00850000
apify-actor-start	Platform-managed Actor start event.	$0.00005000	$0.00005000	$0.00005000	$0.00005000	$0.00005000	$0.00005000

The Actor does not have Task-specific prices: public Tasks use this same live Actor pricing. Third-party costs are not implied; see the data and security section for external services actually contacted.

Limits and bounds

• At most 100 interchanges per run, 10 MiB per interchange, 100,000 segments per interchange, and 10,000 messages per interchange; current schema defaults are lower.
• Supported syntax identifiers are UNOA, UNOB, UNOC, and UNOY with the documented D96A, D01B, and D20B pins.
• The profiles are a bounded original subset, not complete official UNECE directory conformance.

These are product-facing limits, not targets. Use smaller inputs when you need faster feedback or simpler evidence.

Failure and edge-case behavior

• Invalid top-level configuration fails before work; malformed individual interchanges are isolated so other inputs can continue.
• Unsafe syntax, missing terminators, broken nesting, unsupported message/directory, and resource-limit breaches fail closed.
• Envelope and count mismatches remain visible findings on parsed transactions rather than being silently corrected.

Operationally:

• Pin directory and sourceId in repeatable tests and retain finding fingerprints across mapping releases.
• If generateContrl is enabled, the Actor creates an acknowledgement artifact but never transmits it.

Use with Tasks and automation

Public Tasks provide reusable saved inputs for distinct supported workflows. Start with the closest Example Task, review its visible fields and scope caveat, then save your own Task for schedules or repeated runs. Do not treat an Example Task as evidence that unsupported behavior exists.

• Validate a D01B ORDERS transaction: Validate a safe synthetic EDIFACT order, inspect stable quality evidence, and generate a deterministic CONTRL acknowledgement.
• Generate a deterministic CONTRL acknowledgement: Validate a synthetic D96A INVOIC and generate a deterministic CONTRL:D:96A:UN acknowledgement. No transport, certification, or full directory conformance.
• Validate a mixed EDIFACT batch and isolate failed interchanges: Process submitted interchanges independently, preserve successful evidence, and isolate failed interchanges. Isolation is not per message within one interchange.
• The Actor page contains 3 additional public Example Task workflow(s).

Integration and API usage

Every saved Task can be started manually, through the Apify API, or from an Apify schedule. Run-completion webhooks can notify a downstream system after output is durable. Actor-to-Actor calls should consume the typed dataset/output links instead of scraping the Store page.

• Route transaction status and stable finding codes into an ERP/EDI release gate.
• Deliver CONTRL_ACKNOWLEDGEMENTS through your separately managed EDI transport.

No third-party integration is claimed unless it is named above and supported by the current product contract.

Data, privacy, and security

• EDI content and findings remain in Apify run storage under account retention settings.
• The Actor sends no EDI content to third parties and requires no partner transport credentials.

Set Apify storage retention and access according to the sensitivity of your inputs and outputs. This documentation does not create legal, privacy, compliance, or security certification.

Support and known limitations

• The Actor does not provide X12, AS2/SFTP transport, partner onboarding, custom mapping, ERP connectivity, or compliance certification.
• It does not bundle or redistribute official UNECE directory files.

For support, use the Actor Issues page. Include the run ID, a minimal reproducible input with sensitive values removed, the failing record or error code, and what you expected. Do not post credentials, private source files, customer data, or full confidential payloads.