EDIFACT to JSON

Turn EDIFACT into clean JSON your applications can actually use.

CleanEDI translates trading-partner EDIFACT into business-oriented data without making EDIFACT syntax part of your application architecture.

Discuss your integrationTry the decoder

From segments to business data.

A generic parser can expose a message tree. The useful part is turning that message into data your application can work with.

EDIFACT
Business JSON
UNH+1+ORDERS:D:96A:UN'
BGM+220+PO-48291+9'
DTM+137:20260524:102'
NAD+BY+5412345000013::9++ACME Corp'
LIN+1++4012345678901:SRV'
QTY+21:100:PCE'
{
  "messageType": "ORDERS",
  "version": "D96A",
  "orderId": "PO-48291",
  "orderDate": "2026-05-24",
  "buyer": {
    "gln": "5412345000013",
    "name": "ACME Corp"
  },
  "lines": [
    {
      "lineNumber": 1,
      "gtin": "4012345678901",
      "quantity": 100,
      "unitOfMeasure": "PCE"
    }
  ]
}
01

Readable data

Developers should work with business objects such as orders, invoices and shipments, not decode segment syntax inside every service.

02

Stable contracts

The JSON contract used by your application can remain independent of a partner's external EDIFACT implementation.

03

Partner isolation

Different partners can use different versions, qualifiers and conventions without forcing those details into your internal models.

04

Production workflow

Conversion is only one step. Receiving, validating, deduplicating, retrying, auditing and delivering the message matter just as much.

JSON should describe the business, not just the EDI syntax.

There is an important difference between mechanically converting a segment tree to JSON and providing a stable application model. CleanEDI is designed around the second approach.

Generic parser

UNH → segment objects

Useful for inspection, but your application still has to understand segments, qualifiers and the meaning of each field.

Business model

ORDER → lines → buyer

Business-oriented data is easier for services, APIs, databases and downstream workflows to consume.

The application owns its contract.

Trading-partner syntax stays external.
Your internal model stays business-oriented.
A partner variation does not automatically change your API.
Outbound messages can be generated from the same business objects.

EDIFACT to JSON, explained.

Does EDIFACT to JSON mean every segment becomes a JSON property?

Not necessarily. A useful business representation maps message content into meaningful objects rather than simply turning each segment into a generic JSON structure. The right model depends on the message type and the business purpose.

Can JSON be sent back to a trading partner as EDIFACT?

Yes. An integration boundary can work in both directions: your application sends a business object, and the EDI layer generates the partner-specific EDIFACT message.

Why not parse EDIFACT directly in the application?

You can, but doing so couples application code to external message syntax and partner-specific behaviour. A separate boundary keeps that complexity contained and easier to change.

Need EDIFACT converted in production?

Show us your message types, partners and target systems. We can discuss the right business model, integration boundary and proof of concept.