In vielen Buchhaltungen läuft seit Jahren eine Strecke, die niemand mehr anfasst: Rechnungen kommen als PDF per E-Mail an, ein Werkzeug holt Betrag, Datum, Rechnungsnummer und Steuersatz heraus, daraus entsteht ein Buchungsstapel. Sie funktioniert zuverlässig — bis ein Lieferant seine Vorlage umstellt, das Logo zwei Zentimeter tiefer rückt und die Positionstabelle eine Spalte mehr bekommt. Am nächsten Morgen stimmt die Summe nicht mehr, oder schlimmer: Sie stimmt scheinbar, weil der Ausleser das Skonto als Nettobetrag gelesen hat.

Dieser Ablauf ist kein Betriebsunfall, sondern die Regel. Er folgt direkt aus der Bauart des Formats. Ein PDF beschreibt, wie eine Seite aussieht — nicht, was auf ihr bedeutet wird. Jede Auslesung, die auf dieser Beschreibung aufsetzt, ist deshalb eine Wette darauf, dass das Aussehen konstant bleibt. Diese Wette verliert man nicht, wenn ein Programm versagt, sondern wenn ein Lieferant sein Rechnungsprogramm aktualisiert.

Was in einer PDF-Datei tatsächlich steht

Das Portable Document Format ist als ISO 32000 genormt; ISO 32000-1:2008 beschreibt PDF 1.7, ISO 32000-2 aus dem Jahr 2017 die Version PDF 2.0. Beide beschreiben in erster Linie eine Seitenbeschreibungssprache. Der Inhalt einer Seite liegt als Anweisungsfolge vor: Setze diese Glyphe aus dieser Schrift an diese Position, ziehe dort eine Linie, fülle jenes Rechteck. Es gibt kein Feld „Rechnungsbetrag”, keinen Datensatz und keine Tabelle im Sinne von Zeilen und Spalten.

Was ein Ausleser als Tabelle sieht, rekonstruiert er aus Abständen. Der Zwischenraum zwischen zwei Spalten ist oft überhaupt kein Leerzeichen, sondern ein Koordinatensprung. Die Reihenfolge der Textfragmente in der Datei muss nicht die Lesereihenfolge sein. Und die Fragmente selbst sind unzuverlässig: Wo ein Satzprogramm Fettung durch mehrfach versetztes Übereinanderlegen desselben Textes erzeugt, extrahieren einfache Werkzeuge laut PDFlib „Inttrroduccttiion” statt „Introduction”; Ligaturen gehen als „e rst photographs” statt „The first photographs” heraus, Akzente als „Midi-Pyr´en´ees”. Diese Fehler entstehen nicht durch schlechte Dateien, sondern durch korrekt erzeugte.

Warum Tabellen der teuerste Sonderfall sind

Wie weit die Qualität auseinandergeht, hat eine Untersuchung von Pius Horn und Janis Keuper gemessen (arXiv 2603.18652, Fassung vom 1. Juni 2026, eingereicht zur BMVC 2026). Sie ließ 21 aktuelle PDF-Ausleser — spezialisierte OCR-Modelle, allgemeine multimodale Modelle und regelbasierte Werkzeuge — auf 100 Seiten mit 451 Tabellen laufen und bewertete das Ergebnis auf einer Skala von 0 bis 10. Die Gesamtwerte reichen von 2,10 bis 9,55. Die Wahl des Werkzeugs entscheidet damit weitgehend darüber, ob die ausgelesenen Tabellen überhaupt brauchbar sind.

Aufschlussreicher als der Bestenwert ist das Gefälle innerhalb einzelner Werkzeuge. Von einfachen zu komplexen Tabellen — also solchen mit verbundenen Zellen über mehrere Zeilen und Spalten — verlieren einzelne Ausleser bis zu 2,19 Punkte, während andere kaum nachgeben. Komplexität heißt hier nichts anderes als Layout. Die Autoren halten fest, dass selbst die bestplatzierten Modelle bei manueller Durchsicht Fehler zeigen: verschobene verbundene Zellen, veränderte Werte, falsch zugeordnete Kopfzeilen. Ihr Fazit lautet, dass die genaue Tabellenextraktion aus PDF weiterhin ungelöst ist.

Tagged PDF und PDF/A: wo doch Struktur vorhanden ist

Struktur ist im Format durchaus vorgesehen. Tagged PDF hinterlegt eine logische Baumstruktur — Überschrift, Absatz, Tabelle, Zelle — parallel zum sichtbaren Inhalt. Der Barrierefreiheitsstandard PDF/UA (ISO 14289) baut darauf auf, und auch die Archivnorm PDF/A kennt sie: Nach der Darstellung von PDFlib verlangt die Konformitätsstufe A Strukturinformationen und verlässliche Textsemantik, während die Stufe B nur die eindeutige visuelle Reproduzierbarkeit sichert. PDF/A-2 führte zusätzlich die Stufe U ein, die zuverlässige Unicode-Semantik ohne Strukturinformationen verlangt.

Im Alltag hilft das selten. Erstens ist die Auszeichnung optional: PDF/A-4 aus dem Jahr 2020 stellt es ausdrücklich frei, ob ein Dokument Tags enthält. Zweitens sagt ein vorhandener Tag-Baum nichts über seine Richtigkeit — automatisch erzeugte Auszeichnungen bilden Layouttabellen als Datentabellen ab und umgekehrt. Drittens hat, wer eingehende Fremddokumente verarbeitet, keinen Einfluss darauf, wie der Absender exportiert. Eine Auslesestrecke, die eine korrekte Auszeichnung voraussetzt, verlagert das Problem nur nach außen.

Die Wette auf das Layout — und was sie kostet

Der entscheidende Unterschied zwischen den Verfahren ist nicht die Trefferquote am ersten Tag, sondern das Verhalten am Tag der Vorlagenänderung. Positionsregeln brechen dann sichtbar oder, weitaus teurer, unsichtbar: Sie liefern weiterhin einen Wert, nur eben den falschen. Modellgestützte Auslesung ist gegen Layoutwechsel deutlich robuster, dafür nicht deterministisch — zwei Läufe über dieselbe Datei können abweichen, und die Untersuchung von 2026 zeigt bei mehreren Modellen ein zweigipfliges Verhalten: Sie lassen Tabellen entweder ganz aus oder extrahieren sie nahezu fehlerfrei.

Der Rechtsrahmen räumt die Wette bei Rechnungen ab

Für den häufigsten Anwendungsfall — die Eingangsrechnung — hat der Gesetzgeber die Frage entschieden. § 14 Abs. 1 UStG definiert seit dem 1. Januar 2025: „Eine elektronische Rechnung ist eine Rechnung, die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht.” Und im Satz darauf: „Eine sonstige Rechnung ist eine Rechnung, die in einem anderen elektronischen Format oder auf Papier übermittelt wird.” Ein normales PDF ist damit ausdrücklich keine E-Rechnung, sondern eine sonstige Rechnung.

Die Übergangsregelung in § 27 Abs. 38 UStG betrifft ausschließlich das Ausstellen und Übermitteln, nicht den Empfang. Für Umsätze bis Ende 2026 dürfen Papier und andere elektronische Formate mit Zustimmung des Empfängers weiterverwendet werden. Für Umsätze des Jahres 2027 gilt diese Möglichkeit nur noch, wenn der Gesamtumsatz des Ausstellers im Vorjahr höchstens 800.000 Euro betrug; parallel läuft eine gesonderte Frist für EDI bis Ende 2027. Ab dem 1. Januar 2028 ist die Ausnahme vollständig ausgelaufen. Empfangen und verarbeiten können muss eine E-Rechnung dagegen jedes inländische Unternehmen bereits seit Anfang 2025.

ZUGFeRD und Factur-X: das PDF, das seine Daten mitbringt

Das hybride Format des Forums elektronische Rechnung Deutschland löst den Konflikt zwischen Lesbarkeit und Auswertbarkeit, indem es beides in einer Datei transportiert. Technisch ist eine ZUGFeRD-Rechnung ein PDF/A-3-Dokument nach ISO 19005-3:2012, in das eine XML-Datei nach UN/CEFACT CII eingebettet ist; inhaltlich richtet sie sich nach der europäischen Norm EN 16931 und der Richtlinie 2014/55/EU. Die aktuelle Fassung ist ZUGFeRD 2.5.2 vom 4. August 2026. Das PDF bleibt die Sichtkomponente, das XML ist das inhaltlich identische Mehrstück derselben Rechnung — und der Teil, den ein System liest.

Damit verschwindet die Layoutwette nicht ganz, sie wechselt nur die Seite. Weichen Bildteil und strukturierter Teil voneinander ab, ist nach dem BMF-Schreiben vom 15. Oktober 2024 der XML-Teil führend; das zweite Schreiben vom 15. Oktober 2025 hat die Rechtsfolgen solcher Abweichungen im Umsatzsteuer-Anwendungserlass eigens geregelt. Wer ein hybrides PDF erzeugt, haftet also für die Übereinstimmung zweier Darstellungen, die aus derselben Quelle stammen sollten, es aber nicht immer tun.

In sieben Schritten zu einer Auslesung, die man verantworten kann

Der Aufbau ist in allen Fällen ähnlich, in denen Unternehmen Daten aus PDF auslesen — ob es um Rechnungen, Frachtpapiere, Preislisten oder Prüfberichte geht. Beschreibungen aus der Praxis, wie sich PDF-Dokumente als Datenquelle erschließen lassen, folgen derselben Aufgabenteilung: Das Entgegennehmen und Ablegen erledigt eine Regel, das Erkennen der Felder ein Modell, die Zuordnung wird gegen Stammdaten geprüft, gerechnet wird wieder in Code. Entscheidend ist nicht das Erkennungsverfahren, sondern was danach passiert.

1. Herkunft klären, bevor gelesen wird Enthält die Datei eine Textebene, ist sie ein Scan, bringt sie eingebettetes XML mit? Diese drei Fälle brauchen drei verschiedene Wege und dürfen nicht in einem Ausleser zusammenlaufen.
2. Strukturierte Daten immer bevorzugen Liegt ein eingebettetes XML vor, wird ausschließlich dieses verarbeitet. Das Layout wird dann gar nicht erst befragt.
3. Je Absender messen, nicht im Mittel Eine Gesamttrefferquote verdeckt, dass ein einzelner Lieferant seit drei Wochen falsch gelesen wird. Auswertungen gehören nach Absender getrennt.
4. Rechnen außerhalb des Modells Positionssummen, Steuerbetrag und Endbetrag werden nachgerechnet, nicht übernommen. Geht die Probe nicht auf, ist das Ergebnis unbrauchbar, egal wie plausibel es aussieht.
5. Gegen die eigenen Stammdaten abgleichen Lieferant, Bankverbindung, Bestellnummer und Konditionen kommen aus dem führenden System, nicht aus dem Dokument. Das Dokument liefert nur den Anlass.
6. Unsicherheit sichtbar machen Jedes Feld bekommt einen Zustand: bestätigt, zu prüfen, abgelehnt. Eine Strecke, die nie etwas zur Prüfung meldet, prüft in der Regel nicht, sondern schweigt.
7. Herkunft mitschreiben Zu jedem übernommenen Wert gehören Datei, Seite, Fundstelle und Zeitpunkt. Ohne diesen Pfad ist eine Korrektur Monate später nicht mehr nachvollziehbar — die Aufbewahrungsfrist beträgt acht Jahre.

Was eine Auslesung nicht leistet

Zwischen „liest die Felder meistens richtig” und „darf ohne Rückfrage buchen” liegt der gesamte Aufwand eines solchen Vorhabens. Die folgende Gegenüberstellung trennt, was eine Dokumentenauslesung übernimmt, von dem, was sie auch bei sehr guter Erkennung nicht leistet.

Ein Rechenbeispiel: was der Prüfschritt wirklich kostet

Ein Betrieb erhält 1.200 Eingangsrechnungen im Monat. Bei einer Feldtrefferquote von 97 Prozent über sechs geprüfte Felder je Beleg ist statistisch jeder sechste Beleg an mindestens einer Stelle falsch — rund 200 Belege monatlich. Ohne Summenprobe fallen davon nur jene auf, die jemandem später inhaltlich auffallen. Mit rechnerischer Gegenprobe und Stammdatenabgleich bleiben typischerweise die Fälle übrig, in denen ein Wert falsch ist, ohne die Summe zu verletzen: falsche Bestellnummer, falsches Leistungsdatum, falscher Steuerschlüssel.

Diese Rechnung ist der Grund, warum die Erkennungsquote allein ein schlechter Maßstab ist. Entscheidend ist der Anteil der Fehler, die eine automatische Prüfung selbst findet. Eine Strecke mit 92 Prozent Erkennung und vollständiger Summenprobe verursacht weniger Nacharbeit als eine mit 97 Prozent und ohne — weil im ersten Fall die Fehler gemeldet werden und im zweiten in den Zahlen stehen bleiben.

Wann sich der Aufwand nicht lohnt

Nicht jede Dokumentenstrecke gehört automatisiert. Vorlagen, die ein paarmal im Jahr vorkommen, rechtfertigen den Prüfaufbau nicht; hier ist die manuelle Erfassung billiger und nachvollziehbarer. Dasselbe gilt, wenn niemand im Haus den Ablauf vollständig beschreiben kann, wenn jede Position einzeln begründet wird oder wenn ein Fehler monatelang unbemerkt bliebe — dann fehlt die Rückkopplung, die eine Automatisierung überhaupt erst kontrollierbar macht.

Und für Rechnungen gilt eine einfachere Regel: Bevor Aufwand in bessere Auslesung fließt, lohnt der Blick auf die Absender. Jeder Lieferant, der ab 2027 ohnehin strukturiert liefern muss, ist ein Fall weniger für die Layoutwette. Die verbleibenden Dokumentenarten — Frachtpapiere, Lieferscheine, technische Nachweise — sind dann der eigentliche Anwendungsfall, und für sie lohnt sich der beschriebene Prüfaufbau.

Häufige Fragen

Ist ein PDF per E-Mail ab 2027 noch eine zulässige Rechnung?

Als sonstige Rechnung im Sinne von § 14 Abs. 1 UStG bleibt sie zivilrechtlich gültig, erfüllt aber die Pflicht zur E-Rechnung nicht mehr. Für Umsätze ab dem 1. Januar 2027 dürfen nach § 27 Abs. 38 Nr. 2 UStG nur noch Aussteller mit höchstens 800.000 Euro Vorjahresumsatz auf andere Formate ausweichen, und auch das nur mit Zustimmung des Empfängers. Ab 2028 entfällt diese Möglichkeit.

Woran erkennt man, ob ein PDF strukturierte Rechnungsdaten enthält?

An einem eingebetteten Dateianhang. ZUGFeRD und Factur-X nutzen PDF/A-3 nach ISO 19005-3, das beliebige Dateitypen als Anlage erlaubt und für jeden Anhang die Beziehung zum Dokument über den Schlüssel AFRelationship angibt. Übliche Anzeigeprogramme listen solche Anhänge; Prüfwerkzeuge validieren die enthaltene XML-Datei zusätzlich gegen die Norm EN 16931.

Was gilt, wenn PDF-Ansicht und eingebettetes XML verschiedene Beträge zeigen?

Nach dem BMF-Schreiben vom 15. Oktober 2024 bilden die XML-Daten den führenden Teil einer hybriden Rechnung. Das zweite BMF-Schreiben vom 15. Oktober 2025 regelt die Rechtsfolgen von Abweichungen zwischen strukturiertem und Bildteil im Umsatzsteuer-Anwendungserlass gesondert. Das FeRD empfiehlt deshalb, eigene Prüfmechanismen für die inhaltliche Identität beider Teile einzuführen.

Hilft PDF/A dabei, Daten aus einem Dokument auszulesen?

Nur mittelbar. PDF/A sichert vor allem die langfristige Reproduzierbarkeit. Strukturinformationen verlangt erst die Konformitätsstufe A; die Stufe B beschränkt sich auf das Aussehen, die bei PDF/A-2 eingeführte Stufe U auf verlässliche Unicode-Semantik. PDF/A-4 stellt Tags ausdrücklich frei. Ein PDF/A-Dokument ist deshalb nicht automatisch besser auswertbar als ein gewöhnliches.

Wie viel Prüfung braucht eine automatische Auslesung?

So viel, dass jeder übernommene Wert gegen etwas außerhalb des Dokuments geprüft werden kann: Summen rechnerisch, Zuordnungen gegen Stammdaten, Beträge gegen Bestellung oder Vertrag. Der Maßstab ist nicht die Erkennungsquote, sondern der Anteil der Fehler, den die Strecke selbst meldet. Automatisierungen, die nie eine Ausnahme melden, prüfen meist gar nicht.