E-invoicing software for developers: build or buy XRechnung, Factur-X, Peppol

Generating a valid EN 16931 XML file is the small part of e-invoicing, and a good library will do it for you in a week. The large part is everything around the file: keeping up with national rule sets that keep changing, validating against the buyer's country's Schematron, choosing the right profile and syntax per buyer, transporting the document over Peppol, an approved platform or KSeF, storing the invoice as issued for the retention period, and doing the same in reverse for what your suppliers send you. Build when e-invoicing is your product; buy — or integrate through an API — when it is your obligation.

What the standard actually asks of you

EN 16931 defines a semantic model of an invoice and two XML syntaxes that carry it; every national format in Western and Central Europe is either a constrained profile of that model or, in Poland's case, a separate schema. To implement it you need the model, the syntax binding, and the national rules layered on top.

The Commission's page on obtaining the standard lists the parts: "the semantic data model (EN 16931-1: 2017)" and "the two mandatory syntaxes that comply with the standard (CEN/TS 16931-2: 2017)" are available cost-free through national standardisation bodies, while "copies of the remaining parts (3-6) of the standard, consisting of syntax bindings, guidelines and methodologies are sold". The two syntaxes are UBL 2.1 (part 3-2) and UN/CEFACT CII D16B (part 3-3). On top of that:

• Germany — XRechnung, KoSIT's national specification, with its own Schematron and code-list restrictions; and ZUGFeRD, the hybrid PDF/A-3 with embedded CII. From 2027 businesses above EUR 800,000 turnover "will no longer be allowed to issue paper invoices or use unstructured electronic formats"; all businesses from 2028.
• France — Factur-X, "a Franco-German hybrid electronic invoice standard (PDF for users and XML data for automated processing)", technically "the same standard as ZUGFeRD 2.5", plus UBL and CII, exchanged through approved platforms that the ministry calls an "obligatory intermediary between businesses".
• Belgium — Peppol BIS Billing 3.0, a CIUS of EN 16931 in UBL 2.1; "any instance documents compliant to this specification will be compliant with the European Standard (EN 16931)".
• Poland — FA(3), a national XML schema submitted to KSeF, "mandatory for all entrepreneurs" from 1 April 2026 except the smallest, who follow on 1 January 2027.

The formats are compared in detail on the formats page; the model itself on EN 16931.

What a library gives you, and what it does not

A library turns your invoice object into XML (or a hybrid PDF) and, in the better ones, runs the Schematron. It does not know your buyer's country, your VAT verdict, your numbering sequence or the retention period, and it does not deliver anything anywhere.

A build decision is really a decision to own the middle rows of that table. For a company whose product is invoicing, that is the right call. For a SaaS or a services business that has to issue fifty valid invoices a month in three countries, it is a second product nobody asked for.

Validation: the rules move, and the buyer's validator wins

An invoice is valid when the receiver's validator says so, and receivers run the national rule sets. Validate against those, not against "well-formed XML", and re-validate when the rule set changes — both KoSIT and OpenPeppol publish updated rule bundles on regular release cycles.

The reference tool for Germany is the KoSIT validator, an open-source engine that will "identify actual XML format, validate the XML file (using schema and schematron rules), generate a custom report / extract custom data from the XML file, compute an acceptance status", driven by scenario configurations for XRechnung and EN 16931. It runs from the command line, embedded in Java, or as an HTTP daemon, under the Apache 2.0 licence — which makes it a good CI step whether you build or buy. Peppol BIS Billing 3.0 ships its Schematron in two sets, "Peppol transaction business rules" and "EN 16931 transaction business rules"; both must pass. For hybrid formats you validate twice: the embedded XML against the profile, and the container against PDF/A-3.

Whatever you choose, keep an independent validator in your pipeline. The free e-invoice checker validates a file against a country's rules without storing it, which is enough for a spot check; the KoSIT validator in CI is the stronger habit. The developer-level detail — business terms, rule identifiers, common failures — is on the EN 16931 developer guide.

Transport: three networks, three different problems

Producing the file is the same problem in every country; delivering it is not. Peppol is a four-corner network you join through an access point; France's system routes B2B invoices through approved platforms; Poland's KSeF is a central government platform that assigns the invoice its legal identity.

Peppol (Belgium, and cross-border)

You do not talk to the buyer; your access point talks to theirs after looking up the buyer's participant identifier. Building your own access point means accreditation with OpenPeppol and running SMP/AS4 infrastructure; almost every company instead contracts an access point provider and integrates with its API. See Peppol and the Peppol developer guide.

Approved platforms (France)

Only a plateforme agréée may transmit between businesses and to the tax authority. A software vendor either becomes one — a registration process with the administration — or integrates with one. See approved platforms.

KSeF (Poland)

You authenticate, open a session, submit FA(3) XML, and receive a KSeF number and an official receipt (UPO); the invoice is legally issued when KSeF accepts it, not when you generate it. The platform has separate test and production environments, and behaviour proven in one does not prove the other. See KSeF.

Germany

No mandated network: e-mail, download or Peppol are all acceptable channels for XRechnung and ZUGFeRD in B2B. The obligation is about the format, not the transport.

Archiving: the file you issued, unchanged, for years

The invoice you must keep is the structured file as issued — not a PDF rendering of it, and not a re-generated copy from today's data. EU rules leave the form of storage open ("businesses are generally free to store invoices where and how they like"), but each country sets a retention period and audit-access requirements, and where the invoice was issued as structured XML it is the XML — not a rendering of it — that counts as the invoice.

For a builder that means: store the exact bytes you sent, with a hash, alongside the validation report and — for Peppol or KSeF — the transport receipt; never regenerate; make the archive readable without your application. Retention periods and the acceptable storage location for your entity require professional confirmation.

How KRONENWERK handles this

KRONENWERK is an accounting system that generates and validates the e-invoice at issuance, with an API for the flows around it. It is the "buy / integrate" column of the table above, with the transport limitations stated. SUPPORTED WITH LIMITATIONS

• Generation and validation at issuance. Germany: XRechnung and ZUGFeRD, validated with the KoSIT Schematron rules and cross-checked with the Mustang library. France: Factur-X (PDF/A-3 with embedded CII). Belgium: Peppol BIS Billing 3.0 UBL. Poland: FA(3) XML for KSeF. The profile and syntax follow the buyer's country; the VAT verdict and the VIES check happen at the same step.
• Receiving. Incoming XRechnung, ZUGFeRD/Factur-X and UBL are read into bills.
• Transport. Peppol sending and receiving through an accredited access point provider (Storecove) once the company is connected in Settings → Delivery — KRONENWERK is not itself an access point. SUPPORTED WITH LIMITATIONS. French transmission is planned through Storecove's approved-platform capability and is not yet production-ready — KRONENWERK is not a plateforme agréée. NOT YET READY. The KSeF 2.0 module (token authentication, session, FA(3) submission, UPO retrieval, receiving) is built and environment-dependent, has not been used against the production KSeF, and KRONENWERK does not currently sell subscriptions to Polish companies. NOT YET READY for transmission.
• API. Your application creates customers and invoice drafts at https://kronenwerk.org/api/extern/v1 (POST /customers, POST /invoices/drafts, with Idempotency-Key); issuing — the step that assigns the number, generates the e-invoice and runs validation — happens in the product after validation. Webhooks report invoice.issued, invoice.paid and invoice.cancelled. Start at the quickstart; the e-invoicing angle is on the e-invoicing API page.