Builds a German XRechnung 3.x electronic invoice (EN 16931, CII syntax) from invoice
details and returns the XML as text. This is the format German public-sector buyers
are legally required to receive, and that many private B2B buyers now ask for.
The EN 16931 business rules are checked before anything is built, and a rejected call
comes back naming the rules that failed and the business term (BT-xx) each concerns.
The ones worth getting right up front: tax category S requires a rate above 0 %,
categories Z, E and AE require exactly 0 %, E and AE additionally require a stated
exemption reason (BT-120), and both parties need an email address because XRechnung
makes the electronic address (BT-34, BT-49) mandatory. For a public-sector buyer, put
their Leitweg-ID in buyerReference (BT-10) — check_leitweg_id will verify it first.
What this does NOT do:
- It does not validate against the KoSIT Prüftool. It applies our reading of EN 16931,
which is not the same thing as the Schematron suite a receiving portal runs. Use
validate_einvoice for a second look, and the official validator before a deadline.
- It does not produce ZUGFeRD or Factur-X. There is no PDF and no embedded XML — this
is a bare XML file. Use create_zugferd for the hybrid a private-sector B2B buyer
usually wants.
- It handles ONE tax rate and one tax category for the whole invoice. A document
mixing 19 % and 7 % lines is not expressible here.
- It does not send the invoice anywhere, and there is no Peppol.
Nothing is stored: no account, no invoice record, no retained personal data.
