A report from practice
As of 8 September 2026
Background
A DataFlex ERP system that has been in production for many years generates invoices through text-controlled forms and the existing F2P print processor. The visible PDF invoice already worked.
The new requirement was a structured electronic invoice conforming to EN 16931, embedded as factur-x.xml in a ZUGFeRD/Factur-X PDF.
The extension had to fit into the existing architecture.
Roles
- Frigyes contributed his knowledge of the DataFlex system, customer variants, forms and production workflows. He also ran tests on the actual customer system through TeamViewer.
- Codex for DataFlex examined the existing programs and forms, implemented the XML side, compiled the local programs and checked the generated files.
- The Claude/F2P agent handled the PDF side in a separate development environment: PDF/A-3, XML embedding, XMP metadata and error handling.
The work combined domain knowledge, several specialised AI workstreams and real tests.
The first development stream: XML from DataFlex
Selected correspondence
Frigyes
We want to use RNDXDE to create an XML file that can be embedded in a PDF.
We are only working with the FELD version in C:\DEV.
We have already built an entry point into AUSLSN for generating XML:
If the form starts with X, we jump to xrechtest; take a look there.
Codex
The existing printing architecture will be preserved. A dedicated XML form and a separate invoice template will be created for testing. Once XML and PDF output are stable, the workflow will be integrated into the existing form selection.
Frigyes
go
Codex
The entry point for the production workflow is in place. The key task was now to extend RNDXDE and the X form while ensuring that normal invoices continued to run through RNDD and the R form.
The second development stream: F2P and PDF/A-3
The PDF extension was assigned to a separate F2P agent. A reproducible handover package was prepared, containing:
- Precise technical requirements
- The complete invoice form
- An EN16931 test XML file generated by the actual program
- Clear acceptance criteria
The F2P agent implemented and checked:
- PDF/A-3b
- The attachment name
factur-x.xml - The MIME type
text/xml - The PDF name tree
EmbeddedFiles - The
/AFentry in the PDF catalogue /AFRelationship /Alternative- Factur-X XMP metadata with the
EN 16931profile
The feedback from this workstream was particularly valuable: the PDF side was ready, but the profile identifier in the DataFlex XML was still incorrect for EN 16931.
Validation tools
Frigyes had not specified the two validation tools. The F2P agent independently searched for suitable, established tools, set them up in its development environment and used them for reproducible checks:
- veraPDF is an independent, open-source PDF/A validator. It checks the technical rules of the archival standard in addition to whether a PDF can be opened. In this project, it was used specifically to validate PDF/A-3b, the variant that permits the invoice XML to be embedded in the PDF.
- Mustangproject, or Mustang-CLI, is an open-source tool for generating and validating electronic invoices. For a Factur-X/ZUGFeRD file, it checks both the PDF container and the embedded XML against the schema, profile and business rules of EN 16931.
Using both tools together was important. Their results enabled targeted corrections on the DataFlex side.
Integration at the customer’s premises
The customer’s current invoice form was located at \df\forms\r.1. Codex used it to create renr.all for the production workflow.
Archive, dispatch and PDF outputs were redirected to neutral directories for testing:
C:\dev\umi\pdf
C:\dev\umi\archiv
C:\dev\umi\versand
Frigyes handled data exchange and the creation of files and folders on the actual customer system.
The AI agents never had direct access to the customer system.
Units of measure: from ST and M to UNECE codes
The visible form uses units such as ST, KG, M and L. EN 16931 requires standardised UNECE codes in the unitCode attribute.
Analysis of the existing DataFlex code showed that:
ARTIKEL.VERKEINH contains the stable internal key. MEINHEITM is translated into the displayed text through the customer-specific MYERRS.DAT.
| Display | UNECE code |
|---|---|
| ST / pieces | C62 |
| KG | KGM |
| M | MTR |
| L | LTR |
| cm | CMT |
| mm | MMT |
The XML output uses XUNITCODE for this purpose. Unknown units or units without an unambiguous mapping initially fall back to C62.
The abbreviation P needs clarification from someone familiar with the business before a final mapping can be made. It could mean, for example, “pair” or “pack”.
After Codex reported that its work was complete
Selected correspondence
Frigyes
I am working on the real system through TeamViewer. But let's try locally in
dev first. I started a test run myself with invoice 47R6428/01; the results
are in \dev\umi.
Codex
The local test succeeded: 14 line items were generated as well-formed XML, all quantities were numeric, and every unit representing pieces used C62. The XML embedded in the archive, dispatch and end-customer PDFs was byte-for-byte identical.
Frigyes
I have now installed the programs and forms at the customer's premises and
started a test there.
Can you test the real 66r8879_08.pdf?
Codex
The new real output, 66R8879_08.pdf, contained well-formed XML with eleven line items. Quantities and C62 were correct. The embedded factur-x.xml was byte-for-byte identical to the separate XML file; PDF/A-3b, Factur-X and /AFRelationship metadata were present.
Important files in the current solution
C:\dev\feld\auslsn.FRM— switches to the XML workflowC:\dev\feld\rndXde.FRM— the XML program actually executedC:\dev\feld\drincf2X.fri— form and XML outputC:\dev\pkgold\DOCf2x.FRI— preparation of invoice line itemsC:\dev\forms\xenr.all— EN16931 XML formC:\dev\forms\renr.all— visible invoice form and F2P control
Why the use of AI is interesting here
This project shows AI assistance extending well beyond generating new code:
- An old, barely documented system was reconstructed from source code, forms and actual output files.
- The developer’s domain knowledge was connected directly with technical findings.
- Changes were traced across DataFlex, the form language, F2P, PDF structure and external validators.
- A second AI agent used a handover package to work independently on the F2P component and provide structured feedback.
- Real test invoices provided verifiable results.
The developer’s experience remained essential. System knowledge, targeted code analysis, separate agent tasks and tests within the actual workflow together produced a reliable result.
Every step was documented and stored on GitHub with a traceable version history, so future developers can get up to speed quickly. I am now convinced, however, that AI agents will carry out most future development of this code.
The quality of the work was very good. The enormous time saving compared with a similar implementation without AI assistance was particularly impressive.
We have previously implemented XML invoices for both Italy and Poland. The effort involved then was approximately 10 to 100 times greater.
I was especially impressed that Claude independently found and used suitable tools for validating PDF and XML files.
Codex, in turn, continued analysing and changing the forms and programs until the generated output was actually correct.