Zurück zum Changelog

XRechnung 3.0.2 Konformität

7. Mai 2026

100% KoSIT-Konformität: alle 86 offiziellen Referenznachrichten validieren grün. Plus XRechnung Extension, Bauwirtschaft (§13b/§48 EStG), Cross-Country-Helper-Rollout und 8 neue Request-Felder + 3 neue Endpoints in der REST-API.

100% KoSIT-Konformität

Alle 86 offiziellen KoSIT-Referenznachrichten validieren grün gegen Schematron 3.0.2.

XRechnung Extension

Sub-Invoice-Lines (BG-DEX-01) und Drittzahlungen (BG-DEX-09) — Switch via profile: xrechnung-extension.

Bauwirtschaft §13b/§48

§13b UStG Reverse Charge (norm-unterstützt) und §48 EStG Bauabzugsteuer als strukturierte Note.

REST-API-Schema-Sync

8 neue optionale Felder und 3 neue Endpoints, alle in /openapi-1-3.json dokumentiert.

Vollständige KoSIT-Konformität

Vorher: ~70% norm-konform — einzelne BTs waren im Interface, aber nicht im XML. Jetzt: alle 86 offiziellen KoSIT-Referenznachrichten aus dem xrechnung-testsuite-Repository validieren grün via xmllint-wasm + Schematron 3.0.2 in der Test-Suite.

Ein Corpus-getriebener Round-Trip-Test parsed → regeneriert → re-parsed jede Fixture und vergleicht die kanonische Shape (Typ, Rechnungsnummer, Währung, Item-Count, Tax-Rates, Line-Totals, Seller/Buyer-Präsenz, Sub-Item-Tiefe, Drittzahlungs-Count).

XRechnung Extension

Aktiviert über invoice.profile = "xrechnung-extension". Die CustomizationID schaltet auf die Extension-URN und folgende Strukturen werden verfügbar:

Sub-Invoice-Lines (BG-DEX-01)

items[].subItems[] rendert als nested cac:SubInvoiceLine innerhalb der Parent-cac:InvoiceLine in UBL. Beliebige Tiefe (KoSIT-Korpus nutzt 2-3 Ebenen). Jede Sub-Line hat exakt eine cac:ClassifiedTaxCategory (BR-DEX-03). Summen-Prüfung BR-DEX-02 (Σ Child BT-131 = Parent BT-131) wird vom Schematron erzwungen.

Drittzahlungen (BG-DEX-09)

thirdPartyPayments[] mit type, paidAmount, description emittiert als cac:PrepaidPayment mit ID + PaidAmount + InstructionID. Erfüllt BR-DEX-10..14 (Pflichtfeld-Kombinationen, max 2 Dezimalstellen, Currency = BT-5).

Beispiel: Extension-Request mit Sub-Items + Drittzahlung

json
1{
2  "invoice": {
3    "invoiceNumber": "BAU-2026-042",
4    "type": "invoice",
5    "issueDate": "2026-05-07",
6    "currency": "EUR",
7    "profile": "xrechnung-extension",
8    "serviceCategory": "construction",
9    "constructionTax": {
10      "exemptionCertificateNumber": "FNR-2026-12345",
11      "recipientTaxOffice": "Finanzamt Berlin Nord"
12    },
13    "seller": { "name": "Bau Acme GmbH", "countryCode": "DE", "vatId": "DE123456789" },
14    "buyer":  { "name": "Großbau AG",    "countryCode": "DE", "vatId": "DE987654321" },
15    "items": [
16      {
17        "position": 1,
18        "description": "Bauabschnitt A — Rohbau",
19        "quantity": 1,
20        "unitPrice": 50000.00,
21        "taxRate": 19,
22        "subItems": [
23          { "type": "DETAIL", "description": "Fundament", "netAmount": 20000.00 },
24          { "type": "DETAIL", "description": "Mauerwerk", "netAmount": 30000.00 }
25        ]
26      }
27    ],
28    "thirdPartyPayments": [
29      { "type": "advance", "paidAmount": 10000.00, "description": "Bauherren-Vorauszahlung" }
30    ],
31    "subtotal": 50000.00,
32    "total": 59500.00
33  }
34}

Bauwirtschaft: §13b + §48 EStG

§13b UStG

Reverse Charge (norm-unterstützt)

Setze serviceCategory: "construction" und verwende die AE-Tax-Category. Der Standard-Vermerk „Steuerschuldnerschaft des Leistungsempfängers gemäß §13b UStG“ wird in UBL und CII emittiert.

§48 EStG

Bauabzugsteuer (Norm-Lücke)

XRechnung hat kein Feld für Freistellungsbescheinigung oder 15%-Abzug. Lösung: strukturierte Note in BT-22 nach KoSIT-#SKONTO#-Konvention. Nutze constructionTax mit exemptionCertificateNumber / withholdingPercent / recipientTaxOffice — emittiert als #FREISTELLUNG#NR=...#PROZENT=15.00#FA=...#-Note in UBL und CII.

Cross-Country Helper-Rollout

Drei wiederverwendbare Helper schließen strukturelle Lücken in mehreren Ländern auf einmal. Vorher: nur DE hatte sie. Jetzt auf 12 Länder ausgerollt:

  • BG-24Anhänge (BT-122..125) — eingebettete Dokumente in UBL und CII, 200 MiB Cap pro Anhang (KoSIT-aligned). Ausgerollt auf DE, BE, NL, PT, FR.
  • BR-CL-01UBL CreditNote-Root-Switch — TypeCode 381 lebt unter ubl:CreditNote-Root (nicht ubl:Invoice). Ausgerollt auf DE, BE, NL, PT.
  • BG-20/21Document-Level Allowance/Charge — BT-95/96 + BT-102/103 mit ReasonCode und TaxCategory. Ausgerollt auf DE, BE, NL, PT, FR.

Zusätzlich: neuer GR-myDATA-Strukturvalidator (lib-invoice-validator-gr) und ein CH-ZUGFeRD-Wrapper (DE-CII-Generator mit CHF + CHE-VAT-ID-Propagation) — ermöglicht EN-16931-konformes XML neben der QR-Bill-PDF.

REST-API: 8 neue Felder + 3 neue Endpoints

Das OpenAPI/Zod-Schema war zwei Sprints hinter dem invoice-backend-Interface. Jetzt ist alles explizit typisiert, dokumentiert und mit Beispiel-Payloads versehen. Alle Felder sind optional und .passthrough() bleibt erhalten — keine Breaking Changes für bestehende Clients.

Neue optionale Felder in invoiceSchema

  • profile— xrechnung | xrechnung-extension — schaltet den Extension-Modus ein
  • items[].subItems— Rekursive Sub-Invoice-Lines (BG-DEX-01), beliebige Tiefe
  • thirdPartyPayments— Drittzahlungen (BG-DEX-09)
  • attachments— Eingebettete Dokumente (BG-24, BT-122..125)
  • referencedInvoiceNumber + Date— Vorgänger-Rechnung (BG-3, BT-25/26) für Gutschriften
  • deliveryNote— Lieferschein-Referenz (BT-16/17)
  • serviceCategory— construction | general — schaltet §13b-Reverse-Charge frei
  • constructionTax— §48 EStG Bauabzugsteuer (Freistellungsbescheinigung, Abzug, Finanzamt)

Neue Endpoints

POST

/api/v1/invoice/es/verifactu-qr

Spanischer VeriFactu QR-Code nach Real Decreto 1007/2023 Annex II — URL, PNG, SVG.

POST

/api/v1/invoice/ch/zugferd/generate

CH wraapt den DE-CII-Generator mit CHF + CHE-VAT-ID. Use Case: CH-Lieferant rechnet DE/AT-Empfänger ab und braucht EN-16931-konformes XML neben der QR-Bill-PDF.

Schema

validationErrorSchema.code

Von freier string-Form auf eine discriminated Union geschärft: 50+ explizite DE_* / GR_*-Codes plus Fallback-String für dynamische Schematron-Rule-IDs.

Beispiel: VeriFactu-QR-Request

bash
1POST /api/v1/invoice/es/verifactu-qr
2 
3{
4  "sellerNif": "B12345674",
5  "invoiceSeries": "2026/A",
6  "invoiceNumber": "0001",
7  "invoiceDate": "07-05-2026",
8  "total": 1234.56,
9  "verifactuMode": false
10}
11 
12# Response
13{
14  "url": "https://prewww2.aeat.es/wlpl/TIKE-CONT/ValidarQR?nif=B12345674&numserie=2026%2FA-0001&fecha=07-05-2026&importe=1234.56",
15  "png": "<base64 PNG>",
16  "svg": "<svg ...>"
17}
Alle Changelog-EinträgeAPI-Dokumentation