PDF → XRechnung → PDF · EN 16931
E-Rechnung.
In beide Richtungen.
PDF rein, konforme XRechnung raus. Oder eine empfangene XRechnung rein, lesbares PDF raus. Beides im selben Schritt, direkt im Browser, ohne Konto und ohne dass deine Daten gespeichert werden.
Rechnung hier ablegen
oder Datei auswählen. PDF wird zur E-Rechnung, XRechnung-XML wird zum lesbaren PDF.
Die Datei verlässt deinen Rechner nur zur Texterkennung und wird nie gespeichert.
// Was drin ist
Vier Werkzeuge, ein Tab.
Nicht nur ein Konverter in eine Richtung. Erstellen, öffnen, prüfen und einbinden, alles an einem Ort, im Browser, ohne Speicherung.
erstellen
PDF zu XRechnung
Fertiges PDF hochladen, die Felder werden ausgelesen, du erhältst konforme XRechnung-XML.
öffnen
XRechnung zu PDF
Eine empfangene XRechnung als XML reinziehen, ein lesbares PDF mit allen Positionen kommt raus.
prüfen
Gegen EN 16931
Jede Rechnung wird feldweise gegen die EN-16931- und KoSIT-Regeln geprüft, bevor du sie nutzt.
integrieren
Als npm-Paket
Dieselbe Engine als pures TypeScript für deine eigene Software, in Node und im Browser.
// Zwei Richtungen
Ausstellen und Empfangen, beides hier.
Die E-Rechnungspflicht hat zwei Seiten: du musst E-Rechnungen ausstellen, und du musst empfangene lesen können. Beides erledigt dieses Werkzeug im selben Schritt, im Browser, ohne Speicherung.
Du stellst aus.
Lade dein fertiges PDF aus Word, Lexware oder dem Fremdsystem hoch. Die KI liest Rechnungsnummer, Beträge, Steuersätze und Adressen feldweise aus. Du prüfst im Formular, fehlende Pflichtfelder sind markiert, und lädst die konforme XRechnung als XML herunter.
Du hast empfangen.
Ein Lieferant schickt dir eine XRechnung als XML und du siehst nur kryptischen Code? Lade die Datei hier hoch. Wir setzen daraus ein sauberes, menschenlesbares PDF mit allen Positionen, Summen und Steuersätzen, so wie du eine Rechnung erwartest. Zum Prüfen, Ablegen oder Ausdrucken.
Das erzeugte PDF ist eine lesbare Darstellung. Die rechtlich führende Fassung bleibt die originale XML-Datei.
Beide Wege laufen im selben Konverter oben. Die Richtung wird automatisch erkannt.
// Ein Datensatz
Dieselbe Rechnung, zweimal erzählt.
Die Norm trennt, was früher eins war. Das Finanzamt liest die Felder, dein Kunde liest das Layout. Ein Datensatz nach EN 16931, zwei Darstellungen. Wir sorgen dafür, dass beide dasselbe sagen.
<Invoice> <cbc:ID>RE-2026-0042</cbc:ID>BT-1 <cac:AccountingSupplierParty> <cbc:RegistrationName>Mueller GmbH</cbc:RegistrationName>BT-27 </cac:AccountingSupplierParty> ... <cbc:TaxExclusiveAmount>1000.00</cbc:TaxExclusiveAmount>BT-109 <cbc:TaxAmount>190.00</cbc:TaxAmount>BT-110 <cbc:PayableAmount>1190.00</cbc:PayableAmount>BT-110</Invoice>Mueller GmbH
Rechnung RE-2026-0042
// 01 Eingang
XRechnung hochladen. Die XML aus Mail oder Portal, UBL oder CII. Keine Installation, kein Konto.
// 02 Verarbeitung
Felder lesen und prüfen. Wir parsen den EN-16931-Datensatz, ordnen jedes BT-/BG-Feld zu und prüfen gegen die Regeln.
// 03 Ausgabe
Lesbares PDF erhalten. Klar gesetzt mit Absender, Positionen und Summen. Im Browser erzeugt, nichts wird gespeichert.
Hin und zurück, derselbe Datensatz, kein Informationsverlust.
Aus Deutschland.
Für Deutschland.
Deutsche Rechnungen gehören nicht auf US-Server. Verarbeitung in der EU, Server in Deutschland, nichts wird gespeichert, Datensouveränität ist hier kein Häkchen, sondern die Architektur.
Verarbeitung in der EU
Die Texterkennung läuft über Mistral AI (Frankreich), europäische Rechenzentren, kein US-Modell, AVV verfügbar.
Server in Deutschland
Gehostet bei Hetzner in deutschen Rechenzentren (Falkenstein/Nürnberg). Deutsche Jurisdiktion, kein US-Konzern dazwischen.
Keine Speicherung
Deine Rechnung wird nur im Arbeitsspeicher verarbeitet und danach verworfen. Sowohl das XML als auch das lesbare PDF entstehen direkt in deinem Browser, nichts verlässt deinen Rechner.
DSGVO & kein US-Zugriff
Kein Datentransfer in die USA, kein CLOUD-Act-Zugriff. Konzipiert nach den Vorgaben der DSGVO.
// Grundlagen
Ein PDF ist keine E-Rechnung.
Seit dem 1. Januar 2025 ist eine E-Rechnung gesetzlich definiert (§ 14 UStG): eine Rechnung in einem strukturierten elektronischen Format nach EN 16931, die maschinell verarbeitet werden kann. Entscheidend ist nicht, wie sie aussieht, sondern ob eine Software ihre Felder auslesen kann.
sonstige Rechnung
PDF, Scan, Foto
Ein per Mail verschicktes PDF oder ein eingescannter Beleg enthält keine strukturierten Daten. Rechtlich keine E-Rechnung, nur ein Bild von einer Rechnung.
nicht konformE-Rechnung
XRechnung (XML)
Maschinenlesbares XML nach EN 16931 mit definierten Feldern: Rechnungsnummer, Netto, USt-Satz, feldweise auslesbar. Das ist eine echte E-Rechnung.
konformHybrid
ZUGFeRD / Factur-X
PDF/A-3, das für Menschen lesbar aussieht, aber den konformen XML-Datensatz eingebettet mitführt. Der XML-Teil ist rechtlich führend.
konform// Pflicht & Fristen
Die Uhr läuft bereits.
Empfangen müssen heute schon alle. Die Pflicht zum Ausstellen wird bis 2028 gestaffelt scharf, wer früh umstellt, ist auf der sicheren Seite.
- 01 / 2025in Kraft
Empfangspflicht
Jedes inländische Unternehmen muss E-Rechnungen empfangen und lesen können, ausnahmslos, ohne Übergangsfrist.
- 01 / 2027kommt
Ausstellung ab 800.000 €
Unternehmen mit über 800.000 € Vorjahresumsatz müssen E-Rechnungen ausstellen.
- 01 / 2028kommt
Ausstellung für alle
Die Ausstellungspflicht gilt für alle inländischen B2B-Umsätze. Ende aller Übergangsfristen.
Ausgenommen: B2C · Kleinbeträge ≤ 250 € · grenzüberschreitend · Kleinunternehmer (nur Empfang).
// Formate
Eine Norm, zwei Wege.
Alles basiert auf EN 16931, einem syntaxneutralen Datenmodell mit rund 170 Geschäftsfeldern. Daraus entstehen zwei zulässige XML-Syntaxen und die in Deutschland gängigen Formate. Wir erzeugen heute XRechnung (UBL) und rendern jede konforme XRechnung als lesbares PDF zurück. ZUGFeRD folgt.
| Eigenschaft | EN 16931 | XRechnungOutput | ZUGFeRD / Factur-X |
|---|---|---|---|
| Was es ist | EU-Norm: semantisches Datenmodell | Deutsche CIUS der EN 16931 (KoSIT) | Hybrid: PDF/A-3 + eingebettetes XML |
| Form | kein Dateiformat | reines XML | PDF (lesbar) + XML (maschinell) |
| Syntax | UBL oder CII | UBL oder CII | nur CII, eingebettet |
| In DE gültig | Basis aller Formate | ja, alle Versionen | ab 2.0.1 (außer MINIMUM / BASIC-WL) |
| Typischer Einsatz | — | B2G & reines B2B-XML | gemischte Empfänger |
// Konformität
Geprüft an der Primärquelle.
Wir validieren gegen die offiziellen Regeln der EN 16931 und die KoSIT-Vorgaben für XRechnung, nicht gegen unsere eigene Interpretation.
heute
Jede erzeugte Rechnung wird feldweise gegen die EN-16931-Geschäftsregeln und die KoSIT-Schematron-Regeln geprüft, bevor du sie herunterlädst. Die Regeln sind direkt aus den offiziellen Quellen entnommen: dem EU-Schematron und dem KoSIT-Repository.
Phase 2
Der vollständige Lauf gegen den offiziellen KoSIT-Validator ist in Arbeit. Bis dahin prüfen wir gegen dieselben Regeln, die dieser Validator anwendet, also gegen dasselbe Regelwerk, nur noch nicht durch das offizielle Tool selbst bestätigt.
// Für Entwickler
Dieselbe Engine als npm-Paket.
Was diese Website macht, kannst du direkt einbinden. Pures TypeScript, läuft in Node und im Browser, keine Server-Abhängigkeit, kein US-Cloud-Call.
import { toXRechnung, fromXRechnung, validateInvoice, renderInvoicePdf,} from "erechnung"; // Rechnungsdaten -> konforme XRechnung (UBL)const xml = toXRechnung(invoice); // empfangene XRechnung -> Objekt -> lesbares PDFconst pdf = await renderInvoicePdf(fromXRechnung(xml)); // gegen EN 16931 pruefenconst { valid, errors } = validateInvoice(invoice);toXRechnung(invoice)
Erzeugt konforme XRechnung-XML (UBL) aus deinen Rechnungsdaten.
fromXRechnung(xml)
Liest eine empfangene XRechnung in ein typisiertes Invoice-Objekt.
validateInvoice(data)
Prüft gegen die EN-16931- und KoSIT-Regeln, gibt Fehler feldgenau zurück.
renderInvoicePdf(data)
Setzt aus den Daten ein menschenlesbares PDF (Node und Browser).
Beta. fromXRechnung und renderInvoicePdf sind nutzbar, der vollständige Lauf gegen den offiziellen KoSIT-Validator folgt in Phase 2.
// FAQ