My first job involving Java was to write libraries to handle ANSI EDI
transactions involving health-insurance claims.  The EDI standards are
hopelessly complex and poorly organized, or were then.  The largest part of
the effort was simply analyzing what constituted a valid EDI message.
Translation to and from XML, and to and from various JDBC stores, was very
straightforward after that.  Just to support about 6 EDI formats involved
roughly two-and-a-half man years, of which maybe three quarters was analysis
and documentation of the structures in a programmer-friendly format (also
XML).  Before that I was involved in other EDI formats using C.  The effort
there was huge also.

There weren't any EDI validation tools available to us back then (this was
back in the 20th century).

Each EDI format is sufficiently different from any other that they require
independent analysis.

The point is that there is a huge amount of effort to create EDI libraries
that actually work.  EDI is a very commercial format, not used by the general
public.  You will likely find that all good EDI libs require license fees.

Maybe in the 21st century EDI formats are easier to analyze, making it perhaps
feasible to write your own EDI library.

As for using XML as an intermediate format for EDI, that's one of the things
we did in our health-insurance-claim project.  The tools to go XML to Java and
back are free and standard.  XML could be a very viable solution for your project.