Generate compliant invoice XML
generate_invoiceGenerate compliant e-invoice XML from a JSON invoice, in either EN 16931 syntax. Profiles: en16931, xrechnung-ubl, peppol-bis-3, xrechnung-cii, facturx-en16931 — the profile chooses the syntax, and xrechnung-cii and facturx-en16931 come back as CII. The invoice is validated first and generation is refused if it fails, because emitting XML for an invalid invoice produces a file that passes nothing. CREDIT NOTES GENERATE TOO, from the same object: invoiceTypeCode "381" emits a UBL CreditNote document under the UBL profiles and ram:TypeCode 381 under the CII ones, since CII has one document for both. XML ONLY, NEVER A PDF: Factur-X and ZUGFeRD files are CII XML inside a PDF/A-3 container, and this tool builds no container, so a facturx-en16931 result is the payload and not a Factur-X document — do not tell the user otherwise. If they need the PDF itself, no tool here returns one; the HTTP API does, on every plan: POST https://api.attestwire.com/v1/generate?format=pdf with the same invoice and profile facturx-en16931 returns a Factur-X / ZUGFeRD PDF (EN 16931 profile), with the CII XML inside as factur-x.xml, watermarked "not for sending" on the free plan and clean on a paid one. On xrechnung-cii the generator's own FIXTURE documents were run through the official KoSIT validator on release and accepted; on facturx-en16931 they were not, because that profile's BT-24 matches no XRechnung scenario for the validator to judge. Neither is a verdict on the document you just generated — nothing is sent to KoSIT at call time, so never call it "KoSIT-validated". REQUIRES AN API KEY and costs 1 document.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| invoice | Yes | The invoice to generate XML for, as an InvoiceInput object. Required: profile (one of en16931, xrechnung-ubl, xrechnung-cii, facturx-en16931, peppol-bis-3, or "auto" to have it chosen from the buyer: its Leitweg-ID, country and electronic address), invoiceNumber, issueDate ("YYYY-MM-DD"), currency (ISO 4217), seller {name, address{city, postalCode, countryCode}}, buyer {name, address{...}}, and lines[] of {id, description, quantity, unitCode, unitPrice, vatCategory, vatRate}. The XRechnung profiles additionally require buyerReference (BT-10), a seller contact {name, phone, email}, and payment instructions — see BR-DE-1/2/5/6/7/15 via the explain_rule tool. A CREDIT NOTE IS THE SAME OBJECT with invoiceTypeCode (BT-3) set to "381": there is no separate tool and no separate shape, the same rules run, and the amounts stay POSITIVE — the type code is what conveys the direction of the money, so negative amounts on a credit note reverse it back into an invoice. Full schema: https://api.attestwire.com/openapi.json |