Write an EN 16931 invoice XML without learning the standard first
Fill in the boxes. You get an invoice XML — UBL or CII, whichever your buyer’s software expects — and the business-rule verdict on the file that was written, not on the intention behind it. The totals, the VAT breakdown and the document sums are computed by the generator, so the arithmetic cannot disagree with itself. The whole thing runs in this tab: nothing is uploaded.
The invoice
Each one is a real example from the engine’s own test suite: it passes the rule set it claims.
Lines
| Item | Qty | Unit | Unit price | VAT category | VAT % |
|---|
the engine starts on the first generation
The invoice as the engine sees it (JSON)
Every field of the standard is reachable here: allowances, charges, delivery, order references, buyer tax representatives, line attributes. The form writes the common ones; this box is the model itself, so anything you put in it survives editing the form.
The verdict, then the document
Nothing generated yet. The engine loads once, then every document is written locally.
What the generator writes, and what it refuses to guess
An EN 16931 invoice is a list of business terms with a lot of arithmetic attached. The form asks for the terms; the generator does the arithmetic, which is the part that breaks most hand-written documents.
| Field | How it is derived |
|---|---|
| line extension amounts (BT-131) | quantity × unit price, rounded once at the line to two decimals, then added — not added then rounded |
| VAT category totals and the VAT breakdown (BG-23) | grouped by tax category and rate, with the taxable amount and the tax amount per group |
| invoice total (BT-106, BT-109, BT-110, BT-111, BT-112) | line totals, document allowances and charges, then the tax; a total you cannot reproduce from the lines is the single most common reason a buyer rejects an invoice |
| line IDs (BT-126) | numbered in order, so removing a line cannot leave two lines answering to the same number |
| guideline declaration (BT-24) and syntax | named by the rule set you picked, because a rule set will not read a document that does not declare it |
| Field | What happens instead |
|---|---|
| VAT ID, IBAN, electronic address | the examples carry placeholder values. The report will tell you that a dummy VAT ID breaks the pattern checks — that is the tool doing its job, not a bug to work around |
| which syntax your buyer wants | you choose it. Both encodings are generated from one model, and the converter on the validator page moves documents between them |
| whether your invoice is legal | out of scope. Conformance to a rule set is not legal, tax or accounting advice, and a rule set is not a tax authority |
The engine is the same Go code as the command-line tool and the Go and TypeScript libraries, compiled to WebAssembly — so a document that passes here passes there. To put the XML inside a PDF invoice, use the Factur-X generator.
Frequently asked
Will the XML I download pass my buyer’s validator?
The page runs the same rule sets as the validator over the document it just generated and shows the verdict before you download anything. A document can still fail a buyer’s own checks: XRechnung and Peppol BIS are not the whole world, some buyers add their own CIUS rules, and placeholder VAT IDs, IBANs and electronic addresses in the examples deliberately fail the pattern checks. Fix what the report names.
Why does the form start full of a German invoice?
Because an empty form produces a report full of missing-field findings, which teaches you nothing about the tool. The examples are the same documents the engine’s test suite checks — the German one passes XRechnung, the Peppol one passes Peppol BIS Billing 3.0, and neither is a photograph of someone’s real invoice. Replace every value before sending.
Where are allowances, charges, delivery and order references?
In the JSON box. They are common enough to matter and varied enough that a form for them would be a wall of inputs, so the form writes the fields it can explain in one line and the model carries the rest. Load an example to see what a complete model looks like, edit it there, and press “Use this JSON”.
Are the numbers I type sent anywhere?
No. The generator is a WebAssembly binary — the same Go code as the command-line tool — running in your tab. There is no backend to receive the invoice, no analytics on its contents, and the download comes out of local memory. After the page has loaded it works with the network unplugged.
Which syntax should I pick: UBL or CII?
Peppol and most buyers outside France and Germany want UBL 2.1. Factur-X is CII, and German tools accept either as long as they declare the same profile. Pick the one your buyer’s software reads; the document you build is the same model underneath, and the validator page converts an existing file between the two.
Can it also make the PDF the invoice is printed on?
No, and that is deliberate: the human-readable pages are the legal record and should come from your own system, with your layout and your fonts. The Factur-X generator writes the other half — it puts the XML you made here inside a PDF as a PDF/A-3 attachment and audits the file that comes back.
Is the tool really free?
Yes, with no account. The engine is MIT licensed and embeds the European Commission’s EN 16931 Schematron artefacts (EUPL 1.2) and the German XRechnung rules (KoSIT, Apache 2.0) unmodified. Conformance help only — not legal, tax or accounting advice.