Converter ist live: XRechnung, ZUGFeRD und Factur-X in einem Aufruf umwandeln
POST /api/v1/invoice/convert nimmt eine bestehende E-Rechnung als XML oder PDF entgegen, erkennt das Quellformat und liefert das Zielformat zugferd, facturx oder xrechnung zurück. Felder, die das Ziel nicht führt, stehen in conversionWarnings, statt still zu verschwinden. Der Rückweg von ZUGFeRD nach XRechnung scheitert nachvollziehbar mit den XRechnung-Regelcodes, wenn Pflichtangaben wie BT-10 oder die Kontaktdaten des Verkäufers fehlen. Abgerechnet wird wie ein Erzeugen: eine Einheit auf das Zielformat.
Länder und Formate kommen aus dem laufenden Dienst, nicht mehr von Hand
Die Landing wurde am 15.09. auf die OpenAPI-Spezifikation 1.4.0 gezogen. Die Tabellen auf den Seiten Creator, Formats, Validator und OpenAPI werden seither aus der Antwort von GET /api/v1/invoice/formats erzeugt — damals 37 Länder mit den Formaten, die der Dienst je Land tatsächlich anbietet. Vorher standen dort 28 handgeschriebene Einträge, von denen mehrere nicht stimmten: Österreich mit ZUGFeRD statt UBL, Spanien mit VeriFactu als Format, Portugal mit SAF-T beim Erzeugen.
Neue Doku: So funktioniert's, Attachments, VeriFactu-QR, Rezept Konvertieren
Die Übersichtsseite „So funktioniert's“ zeigt alle Bausteine in einem Bild: Eingang, Rechnungsdaten, Erzeugen, Anreichern, Umwandeln, Versand. Neu dokumentiert sind die Endpunkte /api/v1/invoice/attachments und /api/v1/pdf/attachments (Dateien in ein bestehendes PDF/A-3 einbetten) und /api/v1/invoice/es/verifactu-qr. Das Rezept „XRechnung zu ZUGFeRD umwandeln“ läuft gegen die echte API. Auf /docs/errors wurden sieben Regelbeschreibungen gegen die XRechnung-Spezifikation korrigiert: BR-DE-1, BR-DE-15, BR-DE-17, BR-16, BR-CO-13, BR-S-8 und BR-CL-10 beschrieben vorher jeweils eine andere Regel.
Neu: Wir melden uns, bevor Kontingent, Testzeitraum oder API-Schlüssel auslaufen
Bisher haben Sie von einer Grenze erst erfahren, als Sie an ihr standen. Das ist vorbei: Nähert sich Ihre Organisation dem Monatskontingent, geht eine Warnung an die Eigentümerin oder den Eigentümer — je Schwelle eine eigene Mail. Dasselbe gilt für einen endenden Testzeitraum und für einen API-Schlüssel, der abläuft. Auch eine fehlgeschlagene Zahlung erreicht jetzt Sie und nicht nur uns; vorher endete sie in unserem Betriebs-Log. Dahinter stehen fünf tägliche Läufe, die Fristen überwachen und aufräumen — einer davon, der Abgleich der Zahlungsanbieter-Konfiguration, war zwei Wochen lang gar nicht aufrufbar. Alle Konto-Mails kommen deutsch und gebrandet, und jede Marketing-Mail trägt einen Abmelde-Link, der ohne Anmeldung funktioniert. Was Sie davon bekommen möchten, entscheiden Sie unter Einstellungen → E-Mail: ein Schalter, Opt-in, jederzeit widerrufbar.
Sicherheit
Konto-Löschung: es bleibt nichts zurück — und Rechte werden serverseitig geprüft
Der Löschweg nach DSGVO ist vollständig und nachweisbar. Ein Löschantrag wird per Mail bestätigt, die Frist läuft tatsächlich ab, und drei Mails begleiten den Weg: angefordert, abgebrochen, erledigt. Drei Datenbestände, die die Löschung bisher überlebt haben, verschwinden jetzt mit — das Geheimnis der Zwei-Faktor-Anmeldung, die hinterlegten Finanzamt-Zugangsdaten und die Antworten aus dem Onboarding. Damit das so bleibt, zählt ein Wächter den Tabellenbestand ab, statt eine von Hand gepflegte Liste abzuarbeiten: Kommt eine neue Tabelle mit Personenbezug dazu, fällt sie auf. Zweitens haben wir eine Annahme korrigiert, die keine Zugriffskontrolle war: Ein ausgeblendeter Knopf hat nie geschützt. Jede Route prüft ihre Berechtigung jetzt serverseitig, Einstellungen und Abfragen gehören dem angemeldeten Benutzer statt einem gemeinsamen Zwischenspeicher, und Anmeldungen über Google werden wieder im Login-Protokoll aufgezeichnet.
Bugfix
Korrigiert: Validierung braucht einen API-Key und ist an Ihr Kontingent gebunden — und unsere Beispiele waren unvollständig
An mehreren Stellen stand bei uns, die Validierung sei frei nutzbar und ohne Bezug zum Kontingent. Das war unvollständig: Validierung und Format-Abruf brauchen einen gültigen Bearer-Key — ohne einen solchen antwortet der Endpoint mit 401 —, und sie sind an Ihr Monatskontingent gebunden: Ist es aufgebraucht, werden auch sie mit 429 abgewiesen. Der Aufruf selbst wird dem Kontingent allerdings nicht angerechnet. Korrigiert ist das auf der Validator- und der Formats-Seite, in Bannern, Badges und Feature-Karten sowie in den OpenAPI-Spezifikationen. Zweitens waren die Beispiele im Quickstart und auf der Creator-Seite nicht lauffähig — es fehlten Pflichtfelder (countrySpecific.countryCode, subtotal, total, taxSummary sowie seller.bankAccount, das EN 16931 über BR-61 verlangt, sobald eine Überweisung als Zahlungsart angegeben ist). Wer sie kopiert hat, bekam Fehler zurück, und die Ursache lag bei uns. Beide Beispiele sind repariert und gegen die OpenAPI-Spezifikation geprüft. Wenn Sie Ihre Integration auf der alten Aussage aufgebaut haben oder an unseren Beispielen gescheitert sind: melden Sie sich, wir sehen uns Ihren Fall an.
Ankündigung
Premium enthält 7.500 API-Calls — Preis unverändert, Bestandskonten bis 31.12.2026
Premium enthält ab sofort 7.500 API-Calls im Monat statt 20.000. Der Preis bleibt unverändert, und der Free-Tier bleibt vollständig unverändert. Bestehende bezahlte Konten behalten ihr bisheriges Kontingent bis zum 31.12.2026; ein bereits bezahlter Zeitraum wird nie mitten in der Laufzeit geändert. Über dem Kontingent wird nichts abgeschaltet — Calls darüber werden mit 0,01 € netto je Call nachberechnet. Der Grund: Premium ist ein Tarif von der Stange, und ab einer gewissen Größe ist das die falsche Antwort — dann geht es um planbares Volumen, eigene Rate Limits und je nach Haus um den Betrieb in der eigenen Infrastruktur. Dafür gibt es Enterprise. Diese Stufe war bisher mit einer Schwelle ausgeschildert, die praktisch niemanden gemeint hat; sie beginnt jetzt bei rund 7.500 Calls im Monat, und der Rechner auf der Preisseite reicht über Premium hinaus.
Feature
PDF-Editor: Kopf- und Fußzeilen als Bänder, Gruppensummen und maßstabsgetreue Ränder
Der Template-Editor (V2) bekommt Bänder: Kopf- und Fußzeile liegen als eigene Bereiche auf dem Blatt, ihre Höhe ziehen Sie am Trenner. Für wiederholte Bereiche gibt es jetzt Gruppenfuß und Gruppensummen im Eigenschaften-Panel, die zugehörigen Kennzahlen stehen im Variablen-Picker, und Summenspalten lassen sich mehrfach wählen statt genau einer. Dazu eine Reihe von Korrekturen am Maßstab, die zusammen den Unterschied machen: Blockinhalt zeichnet im Papier-Maßstab statt 1 pt = 1 px, Ziehgriffe rechnen den Zoom heraus, und Ränder werden in ihrer eigenen Einheit gelesen und angezeigt — pt bleibt pt. Die Vorschau kann serverseitig rendern und zeigt damit, was das PDF wirklich erzeugt, samt Kopf-/Fußzeilen-Wiederholung und Übertrag über den Seitenumbruch. Neue Vorlagen erben Maßsystem und Papierformat vom Betrieb. Und die Oberfläche springt nicht mehr zwischen Deutsch und Englisch: 42 Sprach-Lecks sind geschlossen, der Editor schreibt auch keine deutschen Seitennamen mehr in Ihre Daten.
Juli 2026
Feature
Console-Update: neues Dashboard, aufgeräumte Navigation + Changelog in der Console
Die Console bekommt ein echtes Dashboard: drei Widgets zeigen die heutigen API-Calls als Ring, die Nutzung pro Tag nach Call-Typ (Heute/7/30/90 Tage) und die System-Aktivität aus dem Audit-Log. Dazu: einklappbare Seitenleiste mit eigener Einstellungen-Gruppe, Settings-Seite mit innerer Navigation (inkl. Cookie-Einstellungen und Rechtlichem), Profilbild-Upload und Schnellaktionen per Cmd+K. Der Konverter ist jetzt ein Live-Playground — jede Konvertierung zeigt den echten REST-Call samt Copy-&-Paste-curl — und das komplette Änderungsprotokoll ist direkt in der Console lesbar, mit Release-Sprungliste.
VeriFactu (Spanien): Registro-Kern, Aktivierung pro Organisation, Druckpflichten im PDF
Spanische Organisationen finden VeriFactu jetzt in der Console: eine eigene Seite unter Einstellungen, sichtbar nur dort, wo sie hingehört, mit einsehbarer declaración responsable. Aktiviert wird pro Organisation statt global — wer mehrere Mandanten betreibt, schaltet gezielt den, der es braucht. Der Registro-Kern liegt im Rechnungs-Backend, und das spanische Rechnungs-PDF erfüllt die Druckpflichten nach VERI*FACTU.
Feature
Factur-X als Zielformat der Konvertierung — und die Anzahlung im API-Schema (BT-113)
Der Endpunkt /convert nimmt jetzt facturx als targetFormat entgegen, neben zugferd und xrechnung. Das Zielformat löst weiterhin auf den Generator des jeweiligen Landes auf, Sie müssen also nicht wissen, welcher das ist. Außerdem steht die Anzahlung (prepaidAmount, BT-113) im OpenAPI-Schema und ist damit dokumentiert und typisiert — bisher ließ sie sich übergeben, aber nicht nachschlagen.
Feature
Großes PDF-Editor-Update: Beispieldaten live im Editor, Inline-Bearbeitung + echtes WYSIWYG
Der Template-Editor (V2) zeigt jetzt beim Gestalten echte Beispieldaten statt roher Platzhalter, Texte lassen sich direkt auf der Seite bearbeiten, und eine neue Schnittlinie warnt, bevor Kopf- oder Fußzeile im PDF abgeschnitten würden. Dazu: Felder-Übersicht aus den Beispieldaten, Seiten umbenennen/duplizieren/löschen, Block-Kontextmenü, dokumentweite Schriftgrößen und exakt maßhaltige Bilder — der Editor zeigt, was das PDF wirklich rendert.
Neue Flows zum Ändern der Konto-E-Mail-Adresse und zum Übertragen des Konto-Eigentums an eine andere Person. Rollen und Finanzamt-Zugänge (Gov Credentials) sind jetzt eigene Bereiche in der Seitenleiste statt Tabs – mit voller Breite. Und: Sprach-Updates erscheinen nach einem Deploy sofort, ohne dass der Browser-Cache manuell geleert werden muss.
Feature
ZUGFeRD 2.5 / Factur-X 1.09 + Länder & Formate automatisch aus dem Katalog
Die Generate-Endpoints erzeugen jetzt auch ZUGFeRD 2.5 und Factur-X 1.09; die gewünschte Version lässt sich gezielt anfordern. Die Konvertierungs-Ansicht in der Console zieht Länder- und Format-Auswahl außerdem dynamisch aus dem API-Katalog – damals 28 Länder, und neue erscheinen automatisch, sobald die API sie unterstützt, ohne auf ein Update zu warten.
v1.4.0Feature
PDF per API: beliebige Templates rendern + neuer Editor V2
Neuer Endpoint POST /api/v1/pdf/generate rendert jedes in der Console gespeicherte (oder inline mitgeschickte) PDF-Template mit euren Daten – nicht nur Rechnungen, sondern auch Verträge, Lieferscheine, Reports und mehr. Dazu gibt es in der Console einen neuen block-nativen Template-Editor (V2) parallel zum bisherigen, mit frei wählbaren Dokumenttypen und einem v1/v2-Badge pro Template.
Mai 2026
v1.3.0Feature
Team-Verwaltung + öffentliche API-Doku unter /docs-full
Console-Erweiterung: Owner/Admins laden in /users weitere Nutzer per E-Mail in die Organisation ein und pflegen Rollen/Berechtigungen in /settings/roles (Console-Routen, keine REST-API-Endpoints). Neu außerdem die öffentliche Doku unter /docs-full (Scalar-UI) und die rohe Spec unter /openapi-full.json – kein Login, direkt verlinkbar.
PDF-Anhänge einbetten (PDF/A-3-konform für E-Rechnungen)
Neues Feld invoice.attachments[] im Request-Body aller Generate-Endpoints bettet beliebige Dateien (Leistungsnachweise, Prüfberichte, AGB) als Anhänge ein – pro Eintrag filename, mimeType, content (Base64) und optionale description. ZUGFeRD/Factur-X-Rechnungen behalten dabei ihre PDF/A-3-Konformität (normgerechte /AF-Array- und AFRelationship-Verdrahtung). ~200 MiB Limit pro Anhang (KoSIT-aligned).
Bugfix
ZUGFeRD/Factur-X: CII-Element-Reihenfolge gefixt
Strikte XSD-Validierung deckte mehrere Reihenfolge-Bugs in der CII-XML-Generierung auf: DefinedTradeContact vor PostalTradeAddress, ExemptionReasonCode nach CategoryCode, SEPA-Lastschrift-Struktur und Factur-X-Line-Items vor Settlement. Die Test-Suite validiert generiertes XML jetzt strikt gegen die offiziellen CII/UBL-XSDs.
Feature
28 Länder vollständig unterstützt + neue Format-Slots qr-bill und peppol-ubl
14 zusätzliche Länder (CY/DK/EE/FI/GB/GR/IE/LT/LU/LV/MT/NO/SE/SI) bekommen eigene Adapter – /api/v1/invoice/{cc}/ubl/generate antwortet jetzt direkt mit Peppol BIS 3.0 UBL. Neu außerdem: qr-bill für CH (32-Zeilen-SPC-Payload), peppol-ubl für PL/PT/RO neben dem nationalen CIUS, und Peppol-BIS UBL auf AT/CZ/ES/FR. Mehrere optionale Felder im Request-Body relaxed.
Der Account-Lösch-Dialog versteckt das Passwort-Feld für OAuth-only-User (Google/GitHub/Apple) – die aktive Session dient als Identitätsnachweis. Zusätzlich: Preview-Sackgasse aufgelöst (Org-Checkbox wurde stillschweigend versteckt), Pending-Banner zeigt das Löschdatum jetzt in der UI-Sprache (12.06.2026 statt 06/12/2026).
Feature
6 System-PDF-Templates pro Land + echter Swiss QR-Bill
Statt einer einzigen Standard-Rechnung gibt es jetzt System-Templates für DE/AT/CH/NL/CZ/BG – pro Land angepasste Labels, Locale und VAT-ID-Format. Das CH-Template rendert einen scannbaren Swiss-QR-Bill-Block am Body-Ende. „Beispiel einfügen“ in der Konvertierungs-UI lädt jetzt landesspezifische Sample-Rechnungen in der jeweiligen Sprache.
Verbesserung
NL-Validator-Coverage + BT-25 BillingReference im Inbound-Parser
Fünf NL-R-Regeln (NL-R-001/002/004/007/008) laufen jetzt auf JSON-Validator-Ebene, nicht mehr nur im KoSIT-Schematron – Aufrufer bekommen Findings sofort, ohne XML-Roundtrip. Außerdem heben die NL-UBL- und DE-CII-Parser die Vorgänger-Rechnungs-Referenz (BT-25) korrekt nach referencedInvoiceNumber.
Vollständige Schließung der DE-Konformitäts-Lücken: alle 86 offiziellen KoSIT-Referenznachrichten validieren grün, plus Support für XRechnung-Extension (Sub-Lines + Drittzahlungen via thirdPartyPayments[]) und Bauwirtschaft (§13b/§48 EStG mit #FREISTELLUNG#-Note). Cross-Country-Sweep mit Helper-Rollout (Anhänge, CreditNote-Root, Document-Allowance/Charge) für 12 Länder, neuer GR-myDATA-Validator und CH-ZUGFeRD-Wrapper. REST-API-Schema um 8 Felder und 3 Endpoints erweitert.
PDF-Editor: Logo + Trennlinien-Bug + DACH-Pflichtangaben
Drei PDF-Bugs aus einem Pilot-Kunden-Report behoben: Logos mit Inline-Base64-Quelle wurden nicht gerendert, Trennlinien überlappten Nachbarspalten, und EN-16931-Pflichtfelder blockierten den reinen PDF-Render. Neue Felder im Field-Picker: HRB-Nummer, Registergericht, Geschäftsführer und Rechtsform fließen jetzt end-to-end von Org-Settings ins PDF.
Verbesserung
Strikte Schematron-Compliance für alle 13 Outbound-Generatoren
Jeder Country-Generator (AT/BE/BG/CZ/DE/ES/FR/HU/IT/NL/PL/PT/RO) wird im Test jetzt strikt gegen den Country-Validator geprüft – validation.errors muss leer sein. Aktivierung deckte echte Generator-Bugs in BG (schemeID), CZ (Duplicate-Identifier), IT (PIVA-Präfix), PT und RO auf, die alle mit dieser Auslieferung gefixt sind.
Bugfix
PDF-Template-ID-Bug + XRechnung UBL-SR-16 Fix
POST /api/v1/invoice/de/zugferd/generate warf HTTP 500 sobald eine templateId in der Request war – Schema-Qualifizierung im SQL und Result-Shape gefixt. Außerdem: XRechnung-Generator emittierte zwei cac:PartyIdentification am AccountingCustomerParty (UBL-SR-16-Verletzung), die VAT-ID gehört ausschließlich in cac:PartyTaxScheme.
Verbesserung
Roundtrip-Fidelity: Parser + Generatoren für alle Länder erweitert
Alle 12 Parser und 12 Generatoren ergänzt, sodass jedes Feld aus der jeweiligen Format-Spezifikation korrekt generiert und zurückgeparst wird. Vorher wurden ~21 Felder pro Format ignoriert, jetzt nur noch 3–7 (alle als format-spezifische Limits dokumentiert). E-Mail, Artikelnummer, GTIN, servicePeriod, BankAccount und mehr fließen jetzt durch den Roundtrip.
Verbesserung
Roundtrip-Tests für alle 13 unterstützten Länder
Systematische Roundtrip-Tests (Generate → Validate → Parse) für alle 13 Länder, insgesamt 998 Tests über Äquivalenzklassen-basierte Fixture-Generierung aus Excel-Entscheidungstabellen. Behobene Validierungsprobleme in IT/HU/RO/BG/PT/CH/NL. Das countrySpecific-Schema akzeptiert jetzt landesspezifische Daten für jedes Land, nicht nur DE.
Feature
ZUGFeRD 2.4 und Factur-X 1.08 Support + Sub-Line-Items
Neue Ausgabeformate ZUGFeRD 2.4 (DE) und Factur-X 1.08 (FR), wählbar im Finalisierungs-Dialog neben den bestehenden Versionen 2.3 / 1.07. Neue UI für Sub-Positionen pro Rechnungs-Item mit Typ-Auswahl (items[].lineSubtype: DETAIL/INFORMATION/GROUP) und Expand/Collapse. Alle 12 Sprachen aktualisiert.
Neue optionale Felder für vollständige E-Rechnungen: orderNumber, customerNumber, contractNumber, servicePeriod (Leistungszeitraum), paymentMethods (SEPA, Lastschrift, Kreditkarte) und countrySpecific (DE: buyerReference, leitwegId, isKleinunternehmer). Seller/Buyer um bankAccount, tradingName, additionalStreet, state und website erweitert.
Neben dem Auto-Detect-Endpoint (/api/v1/invoice/parse) gibt es jetzt 19 explizite Endpoints pro Land und Format – z.B. /de/xrechnung/parse, /at/ebinterface/parse, /ro/efactura/parse. Neue Parse-Formate: PT (SAF-T), PL (KSeF), RO (eFactura + UBL), BG (UBL).
Der Auto-Detect-Parser liefert jetzt ein detailliertes detection-Objekt: Format, Version, Ländercode, Confidence-Score (0–100), Erkennungsmethode (NAMESPACE, ROOT_ELEMENT, CUSTOMIZATION_ID, PROFILE_ID, HEURISTIC) und Ambiguitäts-Info mit alternativen Ländern.
invoice.xhub.io – E-Rechnungen ohne eine Zeile Code
Ab sofort gibt es invoice.xhub.io – eine vollständige SaaS-Anwendung zum Erstellen, Versenden und Verwalten von E-Rechnungen. Kein Code, kein Setup. Gebaut auf der bewährten invoice-api.xhub.io Plattform.