You’re essentially looking at parsing EDI into JSON so that it’s easier to work with programmatically before you transform it into XML or another EDI format. The key thing to keep in mind is that EDI messages (like X12 or EDIFACT) are segment-based and hierarchical, whereas JSON is naturally key-value and nested.
To achieve what you want, the typical flow looks like this:
Parse the EDI file – Break down the EDI message into segments, elements, and sub-elements. This requires an EDI parser or library, because EDI isn’t a flat text file—it has delimiters and compliance rules.
Convert parsed EDI to JSON – Once parsed, you can serialize the EDI structure into JSON. Each segment becomes an object, and elements/sub-elements become fields within it. For example, an EDI ISA segment might become a JSON object with properties like ISA01, ISA02, etc.
Apply transformations – After you have JSON, it’s straightforward to map it into user-defined XML or even back to another EDI standard by applying rules. At this stage, you don’t need “mapping tools” if you just want to restructure—it can be done with normal JSON processing libraries in your programming language.
So in short:
Step 1 is the hardest (properly parsing EDI).
Steps 2 and 3 are straightforward once you’ve got the parsed values.
If you don’t want to build the parsing logic from scratch, look into existing EDI parsers for your language (for example, Python has bots and pyx12, Java has Smooks, .NET has EdiFabric, etc.). These tools already understand segment delimiters and compliance rules.
👉 For a deeper dive into how EDI structures work and why formats like JSON and XML are often used as “intermediaries,” you may find this guide helpful: https://www.commport.com/edi-to-json/?highlight=json