X12 parse & build
Read inbound X12 interchanges into structured data and build compliant outbound ones — ISA/GS/ST envelopes, any transaction set (850, 810, 856, 837, 835, 834, 270/271, 204…).
EDI integration
Parse X12. Map it. Move on.
X12 and EDIFACT — parsed and generated on the same engine that runs your ETL, CDC, and API integrations. Map EDI to any database, warehouse, or API, and exchange with trading partners over AS2, SFTP, FTP, cloud storage, or HTTP. Predictable monthly pricing instead of per-document VAN fees.
- X12
- + EDIFACT, in & out
- Any
- target: DB, API, warehouse
- 10s MB
- Per message, handled
- No
- Per-document fees
The problem
EDI is a format, not a separate product.
Most shops run EDI in a silo — a dedicated translator, a VAN that bills per kilocharacter, and a separate team that maps each trading partner by hand. The data still has to land in a database, a warehouse, or an API, so you end up bridging two stacks that never agree.
Where EDI budgets go to die
Per-document pricing punishes the partners you want most.
VAN and translator pricing scales with document volume and trading-partner count — exactly the growth you're trying to enable. Etlworks treats X12 and EDIFACT as formats on the same engine as everything else: parse an inbound interchange, map it, enrich it from a database or API, and load it wherever it needs to go — in one flow, on one per-tier subscription.
Capabilities
EDI, end to end.
EDIFACT parse & build
Full EDIFACT support — UNB/UNG/UNH envelopes and message types like ORDERS, INVOIC, and DESADV, in both directions.
Map EDI to anything
Transform between EDI and databases, warehouses, APIs, and file formats — JSON, Parquet, CSV, XML. The same visual-or-code mapping you use for every other flow.
AS2 & trading-partner exchange
Send and receive over AS2 — with signing, encryption, and MDN receipts — plus SFTP, FTP/FTPS, cloud storage (S3, Azure Blob, GCS), HTTP/S, and email/IMAP. Connect point-to-point with a partner or via your VAN's file endpoint.
Validation & acknowledgments
Structural validation of envelopes and segments, with functional acknowledgments (997/999) generated for inbound interchanges.
One engine, every format
EDI sits alongside CDC, ETL, reverse ETL, files, and APIs. A single flow can receive an 850, enrich it, call an API, and load a warehouse — no separate translator to license.
Patterns
Inbound, outbound, at scale.
Every EDI pattern configured the same way — no separate translator for inbound, no separate gateway for outbound, no bespoke code for the big documents.
Partner SFTP
X12 parse
Database
Receive & load
Pick up interchanges from a partner, parse the transaction set, map it, and land structured data in your database or warehouse. Return a 997 ack.
Database
Build X12
Partner
Build & send
Read source records, map to X12 or EDIFACT segments, build a compliant interchange, and deliver it to the partner over AS2, SFTP, FTP, cloud, or HTTP.
Large X12
JSON / Parquet
Warehouse
High-volume conversion
Stream multi-megabyte X12 messages, convert to JSON or Parquet, and load to Redshift, Snowflake, or any warehouse. The XSOLIS pattern, in production.
Pricing transparency
An EDI program, three ways.
The same workload — a few dozen trading partners exchanging a steady stream of documents — priced under three common EDI models. Numbers are approximate, based on typical public pricing as of 2026.
VAN (per-kilocharacter)
~$5,000/mo
Scales with document size and volume. Surcharges per partner and per interconnect.
EDI translator + VAN
~$2,500/mo
License plus transport, plus a separate stack to map, monitor, and reconcile against your data platform.
Etlworks (fixed tier)
$1,000/mo
Standard tier, all formats, all partners, all documents — on the same engine as the rest of your integrations.
Specifications
EDI depth.
Every part of an EDI program you'd actually run — standards, transport, mapping targets, and validation — supported and documented.
Standards
X12
All versions · any transaction set · ISA/GS/ST envelope handling
EDIFACT
UN/EDIFACT message types · UNB/UNG/UNH envelope handling
Acknowledgments
Functional acks (997 / 999) · structural validation of envelopes and segments
Transport
AS2
Send and receive · signing & encryption · synchronous and asynchronous MDN receipts
File transfer
SFTP, FTP / FTPS · connect to partners or VAN file endpoints
Cloud & web
S3, Azure Blob, Google Cloud Storage · HTTP/S · email / IMAP
Scale
Streamed parsing · multi-megabyte interchanges · hundreds of thousands of messages
Targets & mapping
Databases & warehouses
Postgres, MySQL, SQL Server, Oracle · Snowflake, Redshift, BigQuery, Databricks
APIs & files
REST / SOAP targets · JSON, Parquet, CSV, XML · transforms in SQL, JavaScript, Python
Orchestration
Schedule, trigger on file arrival, chain with CDC / ETL / API steps in one flow
Running EDI in healthcare? See HL7, FHIR, and X12 on one platform
Proof
X12 in production, at real scale.
XSOLIS processes hundreds of thousands of massive X12 messages — each tens of megabytes — converting them to JSON and Parquet and loading them into Amazon Redshift, while Etlworks also streamlines their Salesforce integration.
XS
Read the case study
XSOLIS
Large X12 at scale · X12 → JSON / Parquet → Redshift
FAQ
Common questions.
Which EDI standards does Etlworks support?
ANSI X12 and EDIFACT, in both directions. Etlworks parses inbound interchanges into structured data and builds compliant outbound interchanges — envelopes (ISA/GS/ST for X12, UNB/UNG/UNH for EDIFACT), segments, and elements. Any transaction set or message type can be mapped, including common ones like X12 850/810/856/834/837/835/270/271/204/997 and EDIFACT ORDERS/INVOIC/DESADV.
Do I need a VAN to exchange EDI with Etlworks?
No. Etlworks supports AS2 send and receive — with signing, encryption, and MDN receipts — so you can connect point-to-point with partners that require it, no VAN in the middle. It also exchanges files over SFTP, FTP/FTPS, cloud storage (S3, Azure Blob, GCS), HTTP/S, and email/IMAP. If a partner only reaches you through a VAN, Etlworks connects to the VAN's SFTP or FTP endpoint like any other partner — you don't need a separate EDI gateway product.
Can Etlworks handle very large X12 messages?
Yes. Etlworks streams EDI rather than loading whole documents into memory, so multi-megabyte interchanges are processed efficiently. XSOLIS uses Etlworks to process hundreds of thousands of X12 messages — each tens of megabytes — converting them to JSON and Parquet and loading them into Amazon Redshift.
Can I generate outbound EDI, not just parse it?
Yes. The same mapping engine works both ways. Read from a database, warehouse, API, or file, map the fields to X12 or EDIFACT segments, and write a compliant interchange to a partner over SFTP, FTP, cloud storage, or HTTP. Functional acknowledgments (997/999) and structural validation are supported.
How is EDI priced at Etlworks?
Per platform tier — not per document, per kilocharacter, or per trading partner. Replicate one partner or two hundred; process a thousand documents a month or a million; the monthly cost is the same. Predictable for budgets, painless for the team that runs the integrations.
Can EDI run alongside my other integrations?
Yes — that's the point. EDI is one format on the same engine that runs your ETL, real-time CDC, reverse ETL, and API integrations. A single flow can receive an X12 850, enrich it from a database, call an API, and load the result into a warehouse — no separate EDI translator to license, run, and reconcile. Talk to us about your trading-partner setup.
Start your trial
14 days. No card. Real documents.
Spin up a free trial, point it at a partner's SFTP folder, and parse a real X12 interchange into your database. See what unified EDI actually feels like.