eu-einvoice brings XRechnung, Peppol and ZUGFeRD invoice generation to Python without Java

A developer has released eu-einvoice, an MIT-licensed Python package that builds and checks machine-readable EU invoices, with an optional wrapper that packages it as a "skill" for Claude. The project appeared in a dev.to post published on 24 October 2026, and it lands as a wave of e-invoicing mandates rolls across the bloc.

The compliance clock

According to the post, Germany will require machine-readable B2B invoices from 2027, France follows in September 2026, and Belgium has required Peppol-based invoicing since January 2026. Developers and small businesses that previously sent ordinary PDF invoices now need to emit XML that passes formal validation. The author's argument is that asking a language model to write that XML freehand is unreliable: the output can look plausible while a VAT breakdown lands a cent off, the Leitweg-ID that German public-sector buyers use is missing, or an identifier is tagged with the wrong scheme.

What the library does

eu-einvoice splits the job into two parts. A language model translates a plain-language description of an invoice into a JSON model, and a deterministic script takes over from there: it computes line totals, the VAT breakdown and the document totals, then generates the invoice in UBL or CII — the two XML syntaxes used for EN 16931, the EU's core e-invoicing standard — or as a Factur-X/ZUGFeRD hybrid PDF/A-3 file.

Generated files are then validated against the official rule sets: CEN EN 16931, the KoSIT rules Germany applies to XRechnung, and OpenPeppol's rules for the Peppol network. The post emphasises that these validators run through Saxon-HE driven from Python, so no separate Java runtime is needed. When validation fails, the tool reports which rule was broken and how to fix it. It also verifies check digits on identifiers the official rules leave unchecked, including the German Leitweg-ID, the French SIREN company number and Belgian enterprise numbers. The library handles incoming documents as well — for reading a received XRechnung file, the post gives the example of asking what the invoice says is owed.

Packaged as a Claude skill

Beyond the plain pip package, installed with pip install eu-einvoice, the tooling is distributed as a Claude Code plugin through the plugin marketplace, with Claude doing the JSON modelling and the script doing the arithmetic and validation. The author benchmarked identical tasks run with and without the skill and reports that both configurations usually complete the work, but the skill version runs roughly twice as fast. In one evaluation case the skill caught a mistyped Leitweg-ID that the baseline missed — exactly the class of error the deterministic checks are designed to intercept. These figures are the author's own; the evaluation cases are published in the project's GitHub repository, which was itself built with Claude Code.

Why it matters

EU e-invoicing mandates turn invoice generation from a formatting chore into a compliance task with machine-enforced rules. This project illustrates a pattern that is likely to become common: a language model handles the ambiguous front end — turning "invoice this client for three licences plus VAT" into structured data — while conventional code computes the totals and runs official validation, keeping hallucinated arithmetic and malformed identifiers out of documents that tax authorities and trading partners would otherwise bounce. For Python-based teams, an MIT-licensed package that validates without a Java toolchain lowers the barrier to testing compliance well before the German and French deadlines arrive.