PDF zu ZUGFeRD: Was bei der Konvertierung funktioniert – und wo es knifflig wird
Viele Unternehmen erzeugen ihre Rechnungen heute als PDF – aus Altsystemen, Branchensoftware oder Word-Vorlagen. Die E-Rechnungspflicht verlangt aber ein strukturiertes Format nach EN 16931: ZUGFeRD oder XRechnung. Der schnellste Weg dorthin ist oft die Konvertierung des bestehenden PDFs.
Das funktioniert gut. Bei rund 90 % aller PDFs, die wir verarbeiten, erzielen wir bereits ohne Anpassung sehr gute Ergebnisse. Die restlichen Fälle setzen wir in Zusammenarbeit mit dem Kunden um – bislang nahezu vollständig. Dieser Beitrag zeigt, was dabei zu beachten ist, welche Rechnungen problemlos durchlaufen und wo wir genauer hinschauen.
Vorweg: Strukturiert schlägt Konvertierung
Eine klare Empfehlung zuerst: Wenn Ihr System strukturierte Daten liefern kann (JSON, CSV, ERP-Export), ist das immer der bessere Weg.
- Strukturierte Daten sind eindeutig. Es gibt nichts zu interpretieren.
- Layout-Änderungen an der Rechnungsvorlage haben keinen Einfluss.
- Unerwartete Sonderfälle führen nicht zu Fehlinterpretationen.
Die PDF-Konvertierung ist die richtige Lösung, wenn das Quellsystem keine strukturierten Daten hergibt, ein Systemwechsel nicht ansteht oder Rechnungen aus mehreren Quellen zusammenlaufen. Für diese Fälle haben wir sie gebaut – und sie funktioniert zuverlässig. Warum der JSON-Weg Entwicklern so viel Arbeit abnimmt, erklärt unser Beitrag JSON statt direktem XML-Editing.
Woher unsere Erfahrung kommt
Wir kommen aus der Einkaufsfinanzierung. Dort verarbeiten wir seit Jahren große Mengen eingehender Lieferantenrechnungen – aus allen Branchen, in allen denkbaren Layouts. Unser Extraktionssystem ist auf genau diese Vielfalt trainiert: Rechnungen von Großhändlern, Logistikern, Handwerksbetrieben, Industriezulieferern.
Diese Erfahrung ist der Grund, warum die Standardfälle sofort funktionieren. Was darüber hinausgeht, lösen wir individuell mit dem Kunden.
So läuft die Konvertierung ab
- 1
Eingang: PDF per REST API oder über ein überwachtes Verzeichnis (Hot Folder), das neue Rechnungen automatisch abholt.
- 2
Extraktion: Self-hosted auf unseren eigenen Servern in Deutschland. Nur wenn ein Dokument an Grenzen stößt, geht die Verarbeitung an Mistral in Paris – ebenfalls in der EU. Alles DSGVO-konform, keine Datenübermittlung in Drittländer.
- 3
Mapping: Zuordnung der Inhalte auf die Business Terms der EN 16931 (BT-/BG-Felder).
- 4
Plausibilitätsprüfung: Rechnerische und inhaltliche Checks (siehe unten).
- 5
Erzeugung: ZUGFeRD (PDF/A-3 mit eingebettetem XML) oder reine XRechnung (XML).
- 6
Validierung: Prüfung gegen Schema und Schematron-Regeln (EN 16931, XRechnung CIUS).
Für schwierige oder umfangreiche Dokumente gibt es einen asynchronen Aufruf: Die API nimmt das Dokument an und gibt sofort einen Link zurück, über den das Ergebnis abgeholt wird, sobald die Verarbeitung abgeschlossen ist. Kein Timeout, kein Blockieren Ihres Prozesses.
POST /invoice/analyze/async → 202 Accepted + Status-Link
GET <Status-Link> → Ergebnis, sobald fertigWelche PDFs gut funktionieren
| Eigenschaft | Bewertung |
|---|---|
| Digital erzeugtes PDF (Text auswählbar) | Sehr gut |
| Eine Rechnung pro Datei | Sehr gut |
| Klare Positionstabelle mit Menge, Einheit, Einzelpreis, Gesamt | Sehr gut |
| Ein oder zwei Steuersätze, sauber ausgewiesen | Sehr gut |
| Mehrseitige Rechnungen mit durchlaufender Tabelle | Gut |
| Gescannte Rechnungen in guter Qualität (≥ 300 dpi, gerade) | Gut |
| Gutschriften und Stornorechnungen mit klarer Kennzeichnung | Gut |
| Mehrere Rechnungen in einem PDF | Vorher trennen |
| Rechnung plus Anhänge (Lieferscheine, AGB, Leistungsnachweise) | Anhänge zunächst entfernen |
| Schlechte Scans, Handnotizen, Stempel über Beträgen | Individuell prüfen |
Wo es knifflig wird
1. Zuschläge und Abzüge
Das ist der häufigste Problembereich – nicht weil die Werte schwer zu lesen wären, sondern weil sie in der EN 16931 präzise eingeordnet werden müssen.
Ebene richtig zuordnen:
| Fall | EN 16931 | Typische Beispiele |
|---|---|---|
| Abschlag auf Belegebene | BG-20 (Document level allowances) | Gesamtrabatt, Bonus, Treuerabatt |
| Zuschlag auf Belegebene | BG-21 (Document level charges) | Fracht, Verpackung, Mindermengenzuschlag |
| Abschlag auf Positionsebene | BG-27 (Invoice line allowances) | Positionsrabatt |
| Zuschlag auf Positionsebene | BG-28 (Invoice line charges) | Energie-, Maut-, Materialteuerungszuschlag je Position |
| Rabatt im Preis | BT-147 / BT-148 (Preisnachlass / Bruttopreis) | „Listenpreis 100,00 €, abzgl. 15 %“ |
Typische Stolperstellen:
- Steuerkategorie fehlt: Jeder Zu- und Abschlag auf Belegebene braucht einen eigenen Steuersatz. Eine Frachtpauschale bei einer Rechnung mit 7 % und 19 % muss eindeutig zugeordnet oder aufgeteilt werden.
- Prozent vs. Betrag: „3 % Rabatt“ auf dem PDF – auf welche Basis? Brutto, netto, nur bestimmte Positionen? Die Basis (BT-93/BT-100) muss stimmen, sonst passt die Summe nicht.
- Skonto ist kein Abzug: Skonto ist eine Zahlungsbedingung (BT-20), keine Allowance. Wird es als Abzug gemappt, stimmt der Rechnungsbetrag nicht mehr. Mehr dazu: Skonto in der E-Rechnung.
- Versteckte Zuschläge: Diesel-, Maut- oder Energiezuschläge stehen oft als eigene „Position“ ohne Menge oder im Fußbereich der Rechnung. Hier entscheiden wir mit dem Kunden einmalig, ob das eine Position oder ein Zuschlag ist – danach läuft es automatisch.
- Rundungsdifferenzen: Positionsweise gerundete Werte ergeben nicht immer die ausgewiesene Summe. Die EN 16931 prüft hier streng (BR-CO-Regeln).
2. Informationen, die nicht rechnungsbezogen sind
Gerade in Logistik, Industrie und Handel enthalten Rechnungen viele Angaben, die für den Empfänger wichtig sind, aber keine steuerliche Relevanz haben:
- Containergrößen und -typen (20′, 40′ HC, Reefer)
- Beschaffenheit, Material, Güteklasse, Chargennummern
- Gewichte, Volumen, Palettenanzahl
- Lieferbedingungen, Fahrzeugkennzeichen, Ladestellen
Diese Informationen haben in der EN 16931 keine eigenen Pflichtfelder. Wir legen gemeinsam mit dem Kunden fest, wohin sie gehören:
| Information | Ziel im Datensatz |
|---|---|
| Merkmal einer Position (z. B. Containertyp, Material) | BG-32 Artikelattribute (BT-160 Name / BT-161 Wert) |
| Freitext zur Position | BT-127 Positionsnotiz |
| Hinweis zur gesamten Rechnung | BG-1 Rechnungsnotiz |
| Für den Empfänger irrelevant | Bewusst weglassen |
Wichtig: Nicht alles, was auf dem PDF steht, muss ins XML. Ein schlanker, korrekter Datensatz ist besser verarbeitbar als ein überladener.
3. Unterteilungen und Zwischensummen
Viele Rechnungen gliedern ihre Positionen – nach Lieferscheinen, Aufträgen, Projekten, Kostenstellen, Standorten oder Leistungszeiträumen – oft mit Zwischensummen je Block.
Die EN 16931 kennt keine Gruppierungen und keine Zwischensummen. Die Rechnung ist eine flache Liste von Positionen. Das heißt:
- Zwischensummen werden nicht übernommen – sie ergeben sich beim Empfänger aus den Positionen.
- Die Gruppierungsinformation wird an jede einzelne Position gehängt:
- Bestellposition → BT-132
- Kostenstelle / Buchungsreferenz des Käufers → BT-133
- Objektkennung (z. B. Projekt, Container, Sendung) → BT-128
- Positionsbezogener Leistungszeitraum → BG-26
- Lieferscheinbezug auf Positionsebene ist in der EN 16931 nicht vorgesehen. Wer das zwingend braucht, nutzt das ZUGFeRD-Profil EXTENDED – dort sind Positionsreferenzen und Unterpositionen abbildbar.
4. Anhänge: erst einmal weglassen
Eine klare Empfehlung aus der Praxis: Schicken Sie zunächst nur die reine Rechnung. Lieferscheine, Leistungsnachweise, Stundenzettel oder AGB im selben PDF verwirren die Extraktion – Tabellen aus dem Lieferschein sehen aus wie Rechnungspositionen. Nach der Konvertierung fügen wir die Anhänge wieder hinzu: als eingebettete Dateien im ZUGFeRD-PDF oder als Anlagen in der XRechnung (BG-24).
Unsere Prüfungen
Eine Extraktion ist nur so gut wie ihre Kontrolle. Jede konvertierte Rechnung durchläuft automatische Checks, bevor sie ausgeliefert wird:
- Positionsrechnung: Menge × Einzelpreis ± Positionszu- und -abschläge = Positionsbetrag. Abweichungen werden erkannt und gemeldet.
- Summenprüfung: Positionssummen, Beleg-Zu-/Abschläge, Steuerbeträge je Kategorie und Gesamtbetrag müssen exakt aufgehen.
- IBAN-Prüfung: Formale Korrektheit inklusive Prüfziffer. Ein Zahlendreher wird erkannt, bevor er zu einer Fehlüberweisung führt.
- USt-IdNr.-Prüfung: Format und Gültigkeit der Umsatzsteuer-Identifikationsnummer.
- Validierung: Schema- und Schematron-Prüfung gegen EN 16931 und XRechnung.
Ergebnis: Fehler fallen bei uns auf – nicht erst in der Buchhaltung Ihres Kunden. Welche Fehler in der Praxis am häufigsten auftreten, zeigt unser Beitrag Häufigste Fehler bei der E-Rechnungs-Validierung.
Zwei Wege zur Integration
| Variante | Für wen |
|---|---|
| REST API (synchron + asynchron) | IT-Teams, die die Konvertierung direkt in ERP, Faktura oder Workflow einbinden – zur API-Dokumentation |
| Verzeichnisversion (Hot Folder) | Unternehmen ohne Entwicklungsressourcen: PDF in den Ordner legen, E-Rechnung kommt zurück |
Beide Varianten nutzen dieselbe Extraktion, dieselben Prüfungen und dieselbe Validierung.
Vor dem Produktivstart: alle Geschäftsvorfälle durchgehen
Bevor die Konvertierung produktiv geht, gehen wir mit jedem Kunden alle Geschäftsvorfälle durch:
- Standardrechnung, Teil- und Abschlagsrechnung, Schlussrechnung
- Gutschrift, Storno, Rechnungskorrektur
- Rechnungen mit Zu- und Abschlägen, mehreren Steuersätzen, Reverse Charge, innergemeinschaftlichen Lieferungen
- Rechnungen mit Gruppierungen und Zusatzinformationen
- Sonderlayouts einzelner Geschäftsbereiche oder Standorte
Für jeden Fall verarbeiten wir echte Beispielrechnungen und prüfen das Ergebnis gemeinsam. Erst wenn alle Vorfälle sauber durchlaufen, geht das System live. So ist eine erfolgreiche Verarbeitung im Tagesgeschäft sichergestellt – nicht nur im Demo-Fall. Eine vollständige Liste der Vorfälle finden Sie in unserer Checkliste der Rechnungs-Geschäftsvorfälle.
Checkliste für Ihre PDF-Konvertierung
- Prüfen: Liefert Ihr System strukturierte Daten? Dann diese nutzen.
- Eine Rechnung pro PDF, digital erzeugt statt gescannt.
- Anhänge vorerst entfernen.
- Liste aller Geschäftsvorfälle erstellen (inkl. Gutschriften, Storno, Sonderfälle).
- Pro Vorfall 2–3 echte Beispielrechnungen bereitstellen.
- Zu- und Abschläge klären: Positions- oder Belegebene? Welcher Steuersatz?
- Festlegen, welche Zusatzinformationen ins XML gehören – und welche nicht.
- Gruppierungen (Kostenstelle, Projekt, Lieferschein) auf Positionsreferenzen abbilden.
- Integrationsweg wählen: API oder Verzeichnis.
Häufige Fragen
Kann man jede PDF-Rechnung automatisch in ZUGFeRD umwandeln?
Bei rund 90 % der PDFs erzielen wir ohne Anpassung sehr gute Ergebnisse. Die übrigen Fälle – etwa versteckte Zuschläge, Gruppierungen oder Zusatzinformationen – klären wir einmalig mit dem Kunden, danach läuft die Verarbeitung automatisch.
Ist PDF-Konvertierung besser als strukturierte Daten?
Nein. Wenn Ihr System strukturierte Daten liefern kann (JSON, CSV, ERP-Export), ist das immer der bessere Weg: eindeutig, unabhängig vom Layout und ohne Interpretationsspielraum. Die PDF-Konvertierung ist die richtige Lösung, wenn das Quellsystem keine strukturierten Daten hergibt.
Wo werden die PDF-Rechnungen verarbeitet?
Self-hosted auf unseren eigenen Servern in Deutschland. Nur wenn ein Dokument an Grenzen stößt, geht die Verarbeitung an Mistral in Paris – ebenfalls in der EU. Keine Datenübermittlung in Drittländer.
Ist Skonto ein Abzug in der E-Rechnung?
Nein. Skonto ist eine Zahlungsbedingung (BT-20), keine Allowance. Wird es als Abzug gemappt, stimmt der Rechnungsbetrag nicht mehr.
Was passiert mit Zwischensummen und Gruppierungen aus dem PDF?
Die EN 16931 kennt keine Gruppierungen und keine Zwischensummen. Zwischensummen werden nicht übernommen; die Gruppierungsinformation wird an jede Position gehängt, etwa als Bestellposition (BT-132), Kostenstelle (BT-133), Objektkennung (BT-128) oder Leistungszeitraum (BG-26).
Sollte ich Lieferscheine und Anhänge mitschicken?
Zunächst nicht. Lieferscheine, Stundenzettel oder AGB im selben PDF verwirren die Extraktion. Nach der Konvertierung fügen wir die Anhänge wieder hinzu – als eingebettete Dateien im ZUGFeRD-PDF oder als Anlagen in der XRechnung (BG-24).
Fazit
Die Konvertierung von PDF zu ZUGFeRD ist kein Experiment mehr. Für die große Mehrheit der Rechnungen funktioniert sie sofort und zuverlässig. Die Herausforderungen liegen in den fachlichen Details – Zu- und Abschläge, Zusatzinformationen, Gruppierungen. Genau diese klären wir einmalig mit Ihnen, danach läuft die Verarbeitung automatisch.
Self-hosted in Deutschland, EU-Fallback in Paris, DSGVO-konform. Mit Prüfung jeder Rechnung, bevor sie Ihr Haus verlässt.
Wie gut konvertieren Ihre Rechnungen?
Schicken Sie uns zwei, drei Beispiel-PDFs – wir zeigen Ihnen das Ergebnis.