AI Orchestration in E-Invoicing and EDI Document Mapping

Every e-invoicing and EDI project depends on one unglamorous activity: translating documents from the format one trading partner sends into the format another can process. It is done in thousands of small, partner-specific maps, and it has traditionally been manual work that needs deep specialist knowledge.

At Comarch E-Invoicing, we have started to change this by building an agent-based AI orchestration around our mapping process. Dedicated chains of agents now support analysis, implementation, testing, and modification of maps, while people keep control over every decision that matters. Preliminary results from the first quarter show that a mapping task takes about 47% less time than it did a year earlier. This article describes how the solution works, where AI helps, and where humans deliberately stay in charge.

The document mapping problem

In EDI communication, an invoice in one input format must be converted into a different output format that the recipient's ERP system understands. Without this translation, the ERP systems of trading partners would not be able to communicate with each other.

For example, an incoming invoice in EDIFACT format (the INVOIC message) has to be mapped to the format required by the recipient – this may be the American X12 standard (transaction 810) or more modern XML-based formats such as Peppol BIS Billing or national schemas, for instance, the Polish National e-Invoicing System (KSeF).

The challenge is that every trading partner may use a different standard, and even within the same standard, apply its own variants and fields. As a result, every connection requires a separate, manually built map, which is time-consuming and error-prone.

What is more, a map not only transforms the format. It also takes care of:

• Validation – checking that the document has the correct structure and the required fields.
• Verification – confirming that the data complies with business rules and reference data.
• Data enrichment – supplementing the document with information missing from the input document: tax codes, counterparty data, product identifiers.

The mapping engine and the challenges before AI

Before AI tools were introduced, building maps involved problems that surfaced at every stage of the process.

• Analysis: Format specifications and partner requirements had to be studied manually, which took time and specialist knowledge.
• Implementation: Developers had to hand-code the mapping logic in C#, which was time-consuming and error-prone.
• Testing and verification: Every map had to be painstakingly checked for correct translation, validation, and data enrichment, further lengthening the process.

The AI-based approach

In the solution used in Comarch e-Invoicing, maps are built on a dedicated mapping engine developed in .NET using C#. We started by dividing the problem into types of use cases. The main ones are:

• problem analysis
• map implementation during rollouts
• testing and verification
• modifying existing maps (change requests)

Agent-based AI orchestration

For each of these use cases, we designed a dedicated chain of agents that guides the model through the successive steps needed to complete the task, whether analysis, implementation, testing, or modification. Each use case is handled by a separate group of agents. The agents communicate with Jira and internal systems via Comarch MCP servers. Heavier subtasks are delegated to sub-agents: specialized helper agents with their own context and a restricted set of tools.

*The agent and sub-agent names used here are technical names.

The use cases in practice

Problem analysis

Every task starts with establishing what it actually is – a new map, a change, a bug, or an analysis – and which specifications and maps it concerns. Done manually, this meant reading the ticket, comments, and attachments, and then searching the repository.

The verify-task agent does this in a single pass. It:

• retrieves the ticket, comments, linked issues, and attachments from Jira
• classifies the task and walks the decision tree documented on the wiki down to a specific scenario, for example, “similar map with the same specifications” or “bug in map logic”
• finds the specifications, similar maps, map chain, and component history in git within the repository – this part is performed by the map-analyzer sub-agent, which cannot modify files
• assesses complexity (XS–XL) and reads the estimate from tables built on historical data from more than 22,000 tickets (median, plus the p75 and p90 percentiles as a risk buffer)
• assesses task readiness and prepares a VERIFICATION comment following a fixed template: questions and blockers for the PM first, then information for the developer.

The comment is posted to Jira only after the mapper approves the preview, and it is marked as prepared with AI assistance. If the task is not ready, implementation does not start.

Example: In a ticket about a failed merge of an invoice visualization with the customer’s PDF, the agent confirmed the PM’s hypothesis in the code (the map works in PDF/A mode, while the customer’s PDF was PDF/UA), answered the questions raised in the ticket, and presented three fix options with estimates. The choice of option was left to the PM as a blocker.

The same agent handles purely analytical tasks such as requirements analysis, feasibility, change impact, regulatory compliance, or map audits. In that case, the output is the comment or report itself.

Map implementation during rollouts

Implementing a map is code development: every map is a C# project that has to be written, built, and tested. A new map is rarely created from scratch. Usually, it starts from a base (a generic, twin, or reverse map). Equally often, the starting point is an analysis of sample documents and specifications on both the input and output side, because the customer does not always provide ready mapping documentation. Setting up the project is tedious in itself and prone to errors in naming, project identifiers, versions, or packages.

The mapping-implementation agent:

• creates the project from the base map identified during verification, with a name that follows the convention, new GUIDs, a .NET Framework 4.8 target, and version 2.0.0.0
• copies the input and output specification XSDs and downloads the mapping specification (Excel) and sample input and output documents from Jira
• analyzes the specifications and sample documents on both sides, writes the mapping logic in C# on that basis (the map-implementer sub-agent), and builds the project

For non-trivial maps, built from scratch or with a large specification, the code is preceded by documentation stages: field tables extracted from the input and output XSDs, a region-by-region analysis of the base map, and mapping rules with a confidence level:

• HIGH – the rule comes from the customer’s documentation.
• MEDIUM – it follows a standard convention (for example, in EDIFACT the DTM+137 segment is the document date).
• LOW – it relies solely on similar field names.

Every LOW rule stops the process until the mapper accepts it or it is clarified with the PM. The agent does not guess business rules that nobody has written down; unclear items in the mapping specification go into the code as explicit TODOs.

According to the team’s preliminary estimates, a new map takes about 3 hours in this mode instead of the traditional 6–8 hours. The Implementation group also includes new partner relations and migrations, not only new maps.

Testing and verification

Every change has to be run on a real document, its output checked against the schema, and the code reviewed against team standards. The work is split between two agents.

• map-test runs a single map or an entire chain locally on a real document, validates the input and output against the XSD, and builds any missing libraries if needed. It returns a PASSED/FAILED verdict and a ready-made command the mapper uses to repeat the test after every fix.
• review-map (the map-reviewer sub-agent, with no edit rights) performs a mechanical code review: compliance with the map template, version number consistency in three places, namespace handling in line with the XSD, good practices (including safe number parsing, 24-hour date format, and changelog), and completeness of project files. The output is a PASS/FAIL table pointing to the relevant code lines.

In the full process, a failed test automatically sends the work back to the implementation stage (up to three times), and review findings once. When the limit is reached, a human decides.

The automated review is a “first pass”. Mapping logic, business rules, and regression risk are still assessed by a second mapper or a team lead.

Modifying existing maps

Change requests account for about 59% of mapping tasks (about 7,300 of 12,300 tickets in historical data). This is also the area of greatest risk: a single map may serve many partners, and an inconsistent version number can overwrite the previous registration on an environment.

The mapping-bugfix agent (with the map-analyzer and map-implementer sub-agents):

• starts from the verification findings; for bugs, it classifies the type (specification validation, map logic, namespace, number and date parsing, configuration) and chooses the diagnostic path;
• assesses the impact of the change: how many partners use the map and where in the XSD sequence the new field has to go;
• makes the change with a changelog entry, bumps the version consistently in three places, and builds the project.

Example: When fixing a map for KSeF correction invoices, the agent located the bug in two code branches, applied the fix and tested a chain of three maps on three customer documents. The test showed that a fix following the literal description in the ticket removed only one of the two errors, so the agent stopped and asked the mapper to decide whether to extend the scope. The AI session took about 30 minutes, followed by 15–30 minutes of the mapper’s work. Traditionally, the same bugfix took 3–4 hours.

The scope of the change is decided by the mapper. Verification can also be too optimistic: in another task, a map assessed as used by one partner turned out to be shared by 20 map groups. That is why a human confirms the actual use of the map before production rollout.

How the agent chains fit together

The mapping-pipeline agent is the orchestrator. It does no mapping itself, but calls the other agents in a set order and branches the path according to the task type.

The process state is saved in a state.md file, which acts as a contract between stages: each stage appends its findings, and an interrupted process can be resumed from the last unfinished step. The orchestrator has two gates of its own – the task not being ready, and low-confidence mapping rules – and runs only when the mapper explicitly starts it, because a single session means a dozen or so minutes of work and hundreds of tool calls.

What stays with the human

Automation covers almost every stage, but some decisions deliberately remain with a human, in line with the human-in-the-loop principle:

• Approving the artifacts of each stage (in Jira, commits, pushes, and merge requests);
• Business decisions and mappings not described in the customer’s documentation – the agent raises a request for the missing data to avoid hallucinations;
• Registering maps on the UAT and PROD environments – partly awaiting further agentisation, partly deliberately kept manual to retain full control over the environment;
• Substantive code review – largely supported by automation, but it underlines human accountability for the result.

Helper agents

Beyond the four main use cases, agents handle tasks that accompany mapping: specification preparation, PDF visualizations, documentation, Jira communication, and access to environment data. Some of them are separate procedures; others are tools of the comarch-edi-mcp server that the agent calls.

Specification preparation

When the customer has not provided a schema, the specification is created from a test file. The file (flat file, EDIFACT, or X12) is converted to XML, and the agent generates an XSD from that sample. It then assembles the specification project: it copies the nearest neighboring project, replaces the directory and file names, assembly name, GUIDs, and metadata, and builds a signed DLL. The agent performs this step on a regular instruction from the mapper, without a dedicated procedure.

When an existing specification changes, verify-task establishes the full list of dependent maps, and map-test runs each of them and validates the output against the new XSD. Tightening schema constraints could otherwise reject documents that previously passed validation.

The generated XSD is reviewed by the mapper (data types, cardinality, optional elements). Registering the specification in EDI Configurator, the spec list and tracked fields remain manual.

PDF visualisations

Visualizations are POST maps that generate a readable PDF version of a document. Changes to them are handled by the same agents as other maps. mapping-bugfix modifies the generator code (fields, layout, tables, labels, and translations), adds a changelog entry, bumps the version, builds the project, and map-test runs the map, which generates the PDF locally. Optionally, review-map checks the code against PDF library patterns.

This is the area with the most limited AI support. The agent cannot judge layout correctness, readability, or compliance with customer requirements, so the generated PDF is always verified by a human.

Map and specification documentation

Documentation is not written by hand. It is generated by the EcodMapTools portal tools available through the comarch-edi-mcp server. They have no dedicated agent – the session’s main agent calls them at the mapper’s request. The tools are:

• maptools_generate_map_doc – documentation of a single map,
• maptools_generate_map_group_doc – documentation of an entire map group,
• maptools_create_spec_doc – documentation of a specification.

The output is an Excel file, for example, describing the mapping rules for the customer.

Jira communication

Comments in tickets are prepared by specialized agents that enforce fixed templates:

• jira-verification-comment – the VERIFICATION comment with the analysis result (called by verify-task);
• jira-implementation-comment – a post-implementation summary: what was changed, on which environments the new version was registered, test results, and regression risk notes;
• jira-task-proposal-comment – handing over the conclusions of an analysis to a delivery task (change, new map, specification or bug).

Each of them shows a preview of the comment and publishes it only after the mapper approves. For regulatory compliance analyses (for example KSeF or Peppol), the deep-research agent finds and compiles official legal sources.

Access to environment data

The comarch-edi-mcp server gives agents visibility into two key platform systems:

• EDI Tracking – the content of input, intermediate, and output documents, processing history, errors, and suspended documents;
• EDI Configurator – partner relations, subscriptions, map group composition, and map versions registered on each environment.

This lets the agent fetch a real document for testing, diagnose at which stage of the chain a specific document stopped, or compare a partner’s configuration across environments before rollout. Ready-made agents built on this server include:

• einvoicing-pm-edi-tracking-document-details – a full diagnosis of how a single document was processed: mapping path, status, error code, timeline, and who should take action;
• einvoicing-pm-edi-tracking-document-list – a daily review of a selected partner’s documents, highlighting those that got stuck or failed;
• einvoicing-pm-relation-config-diff – a comparison of a partner’s configuration (relations, subscriptions, map versions in groups) across two or more environments.

Access is read-only by default. Write tools (for deploying and switching map versions) are available only in the DEV environment and require confirmation.

Gains and impact on productivity

To check whether agent orchestration translates into real productivity, we compared equivalent periods in 2025 (before AI agents were introduced) and 2026 (after they were introduced). The data is preliminary for now, as it covers one quarter, but a noticeable difference is already visible. The measure is the actual effort logged in Jira per task, not estimates. The 2025 side covers 246 tasks whose entire logged time falls within the period; the 2026 side covers 124 MAPP tasks closed between June 1 and August 24, 2026.

Overall result

• Average effort per task fell from 4.33 h to 2.30 h, a speed-up ratio of ×1.88 (95% confidence interval 1.47–2.41).
• The median fell from 2.50 h to 1.08 h.
• A ratio of ×1.88 means that a mapping task takes on average about 47% less time than a year earlier, and the same number of hours is enough for almost twice as many tasks.

Rather than replacing human expertise, this acceleration frees domain specialists to focus on complex edge cases. The time saved goes into onboarding more trading partners and responding faster to regulatory changes. In 2026 so far, we have launched about 500 go-lives, with KSeF and the French platform among them – a scale that relies on a high level of automation across the mapping process. We will continue extending the orchestration to further stages of the process, but the principle remains the same: the agents prepare, check, and document, and the mapper decides.

Results by task type

Effort fell across all four groups, from ×1.51 to ×1.78. The drop is most pronounced for bugs and change requests, exactly where agents take over the most work: locating the problem in the code, applying the change, bumping the version, and testing on real documents.

Looking Ahead

Faster, more consistent mapping means shorter onboarding of trading partners and quicker responses to changes in formats and regulations, with experienced mappers still accountable for every result. We will keep extending the orchestration to further stages of the process, but the principle stays the same: the agents prepare, check, and document, and the mapper decides.

Wojciech Nowak

Head of AI LAB at Comarch E-Invoicing