The whole X12 stack on one engine
A translator, an AS2 gateway, and a mapper are usually three products and three invoices. Version 9.6.4 put all three on the engine that already runs your pipelines.
A normal EDI program is assembled from three purchases. A translator that understands X12. A VAN subscription or an AS2 gateway to move documents to partners. A mapping tool to get the data into something your systems can read. Three vendors, three renewal dates, and a reconciliation problem every time a partner changes something.
Version 9.6.4 closed the last gaps in doing all of it in one place.
AS2, both directions
The piece customers asked for most. Full AS2 support arrived as a dedicated AS2 connector for outbound traffic and an AS2 listener for inbound.
Signing uses SHA-256 by default, with SHA-1, SHA-384, SHA-512, and MD5 available for partners who require them. Encryption covers 3DES, AES-128-CBC, and AES-256-CBC. Synchronous MDN receipts are supported. Certificates can be supplied as inline PEM, a file path, or a PKCS12 or JKS keystore, which matters because every partner onboarding pack seems to use a different one.
AS2 is what lets you connect point to point with a partner and skip the VAN. If a partner only reaches you through a VAN, that still works, since Etlworks connects to the VAN's SFTP or FTP endpoint like any other partner. The VAN becomes a choice.
Building outbound documents
Building an outbound X12 document used to mean nested mapping and a fair amount of scripting for repeating loops.
The Message Designer, our schema-driven editor for EDI messages, changes the shape of that work. You pick the segments you need, mark loops as repeating, and bind each leaf element to a source field or a lookup query. Repeating loops and segments are populated with DataSet lookups from the Lookup Builder, our point-and-click expression builder, so one source row drives many segments with no JavaScript.
It is now the primary path for X12 creation. Nested mapping remains available for the cases that need it.
Inbound, flattened
Parsing is the other half. Inbound X12 flattens automatically into CSV, JSON, or XML, so the document lands in a shape your database or warehouse already understands and nobody writes a parser for the ISA/GS/ST envelope structure.
That flattening is what makes the volume story work. XSOLIS processes hundreds of thousands of X12 messages, each tens of megabytes, converting them into JSON and Parquet and loading them into Amazon Redshift. That scale had exceeded the tools they tried before. At the other end, Cox Transfer automates EDI 204 load tenders into their internal systems. Same engine, different order of magnitude.
The rest of the family
X12 gets the attention, but the same engine handles HL7 2.x, FHIR, EDIFACT, NCPDP, and VDA, each with a full format reference. In healthcare you are probably dealing with X12 837 claims and HL7 messages in the same week, and running both through one platform means one set of connections, one scheduler, and one audit trail.
Where this saves real money
Check the pricing model against your current invoices. EDI is billed per platform tier here. Not per document, not per kilocharacter, not per trading partner.
Under per-document pricing, onboarding a partner is a budget conversation and a high-volume partner is a line item someone reviews. Under per-tier pricing, it is configuration work. The difference compounds in exactly the direction you want your business to grow.
We have seen enough competitive quotes to know the gap is large, and we are not going to put a multiplier in a blog post with no math behind it. Send us what you pay now and we will do the comparison against a published tier.
One thing stays manual: certificate and AS2 ID exchange with each partner is still an onboarding step, and it is usually the slowest part. That is the protocol, not the tooling. Budget for it.
Standards, transports, and mapping targets are on the EDI integration page.