Rechnungsdaten aus PDF extrahieren: Felder, Excel, Tools

Rechnungsdaten aus PDF extrahieren bedeutet, die Kopf- und Positionsfelder einer Rechnung in eine strukturierte Tabelle zu überführen — als Excel, CSV oder JSON. Moderne KI-Extraktion liest sowohl native PDFs als auch Scans, ordnet die Felder anhand einer Prompt-Beschreibung zu und liefert wahlweise eine Zeile pro Rechnung oder eine Zeile pro Position. Jede Ausgabezeile sollte einen Verweis auf Quelldatei und Seitennummer tragen, damit ein Mensch den Wert vor der Verbuchung prüfen kann.

Wer in deutschen Suchergebnissen nach diesem Thema sucht, bekommt drei verschiedene Aufgaben in einem Brei serviert. Dieser Beitrag behandelt nur die erste, weil die anderen beiden andere Werkzeuge brauchen:

• PDF- und Scan-Extraktion ist das, was deutsche AP-Teams im Alltag meinen: ein Stapel deutschsprachiger Lieferantenbelege — native PDFs, eingescannte Papierrechnungen, Handy-Fotos — wird in eine prüf- und importtaugliche Tabelle überführt. Der Inhalt der Rechnung wird interpretiert, nicht nur das Layout abgebildet.
• ZUGFeRD- und XRechnung-XML-Extraktion ist eine andere Aufgabe: bei strukturierten E-Rechnungen wird die eigenständige oder eingebettete XML gelesen. Wer einen relevanten Anteil solcher Dateien im Eingang hat und nur die XML-Schiene bedienen möchte, ist mit einem Ansatz besser bedient, der speziell XRechnung-XML-Dateien öffnen und visualisieren kann.
• Generischer PDF-zu-Excel-Konverter (Adobe Acrobat, Smallpdf und ähnliche): wer eine Rechnung PDF in Excel umwandeln möchte, ohne dass das Werkzeug Rechnungen semantisch versteht, bekommt die abgebildete Tabelle gespiegelt — aber keine sortenrein zugeordneten Felder, keine Lieferanten-übergreifende Spaltenkonsistenz, keinen passenden Datentyp pro Spalte.

Im realen AP-Posteingang treffen Mischformen aufeinander: eine PDF aus dem Lieferantenportal, eine eingescannte Papierrechnung mit verzogenem Logo, ein Handy-Foto vom Außendienst, eine ZUGFeRD-Hybrid-Datei mit lesbarem PDF und mitgelieferter XML, mitunter ein Sammel-PDF mit mehreren Rechnungen hintereinander. Die Frage, um die der Rest dieses Beitrags kreist, ist die operative: wie wird aus einem solchen Stapel eine Tabelle, mit der die Sachbearbeitung und die Buchhaltung tatsächlich arbeiten können?

Pflichtangaben und operative Zusatzfelder deutscher Rechnungen

Bevor ein Tool auf den Stapel losgelassen wird, lohnt sich der Blick auf den Feldkatalog: was muss eine deutsche Lieferantenrechnung enthalten, und welche zusätzlichen Felder braucht das eigene AP-Team, damit die extrahierte Tabelle nicht direkt am ersten Buchungstag scheitert.

Den gesetzlichen Rahmen geben die zehn Pflichtangaben nach § 14 Abs. 4 UStG vor: vollständiger Name und Anschrift des Lieferanten und des Empfängers, Steuernummer oder USt-IdNr. des Lieferanten, das Ausstellungsdatum, eine fortlaufende Rechnungsnummer, Menge und Art der Lieferung oder Umfang und Art der sonstigen Leistung, der Zeitpunkt der Lieferung oder sonstigen Leistung, das nach Steuersätzen und einzelnen Steuerbefreiungen aufgeschlüsselte Entgelt, der anzuwendende Steuersatz, der auf das Entgelt entfallende Steuerbetrag oder ein Hinweis auf eine Steuerbefreiung, sowie im Voraus vereinbarte Minderungen des Entgelts. Diese zehn Angaben sind die Mindestbasis dafür, dass aus der Rechnung der Vorsteuerabzug gezogen werden darf — und damit auch das, was in der späteren Tabelle nicht fehlen sollte.

Übersetzt in die Spalten der Ausgabetabelle ergeben sich aus den Pflichtangaben die üblichen Identifier-Felder (Rechnungsnummer, Rechnungsdatum), die Stammdaten des Lieferanten (Firma, Anschrift, Steuernummer oder USt-IdNr.), das Leistungsdatum als eigenes Datumsfeld neben dem Rechnungsdatum, sowie die steuerliche Aufschlüsselung. Die Aufschlüsselung ist der unangenehme Teil: weil eine Rechnung mehrere Steuersätze enthalten kann (typisch 19 % und 7 %, in Sonderfällen 0 % oder steuerfrei), reicht eine einzelne Spalte für Netto und USt nicht. In der Praxis landen entweder mehrere parallele Spalten (Netto 19, USt 19, Netto 7, USt 7) oder ein wiederholtes Tripel aus Steuersatz, Netto und Steuerbetrag, das bei Bedarf in eine Pivot-Tabelle wandert.

Daneben gibt es die operativ wichtigen Zusatzfelder, die das UStG nicht verlangt, ein AP-Team aber für seine Arbeit braucht: das Zahlungsziel und die Skonto-Bedingungen für den Zahlungslauf, IBAN und BIC für die Überweisung, eine Bestellnummer oder Lieferscheinnummer für den Abgleich gegen den Wareneingang, der Reverse-Charge-Hinweis bei Drittlandsleistungen oder innergemeinschaftlichen Leistungen, ein Hinweis auf eine eingebettete ZUGFeRD-Datei, gegebenenfalls Felder für Kostenstelle oder Kostenträger. Welche dieser Zusatzfelder relevant sind, ist von Unternehmen zu Unternehmen verschieden — und genau dieser Unterschied ist der Grund, einen eigenen Feldkatalog zu definieren statt einen Vendor-Standard zu übernehmen.

Nicht jede Rechnung trägt jedes Feld. Kleinbetragsrechnungen unter 250 € haben reduzierte Anforderungen, ausländische Lieferanten tragen häufig nur eine USt-IdNr. statt einer deutschen Steuernummer, B2C-Rechnungen aus Online-Shops sind oft minimaler ausgestattet, und bei Reverse-Charge-Konstellationen fällt der Steuerbetrag bewusst weg. Diese Variabilität ist der Punkt, an dem ein starres Template pro Lieferant in der Praxis scheitert: bei zehn oder zwanzig Lieferantenformaten lohnt sich der Setup-Aufwand nicht, bei mehreren hundert ist er nicht zu leisten. Ein Prompt-basierter Ansatz, der "extrahiere folgende Felder, wenn vorhanden, sonst lass die Zelle leer" als Anweisung kennt, geht mit dieser Variabilität anders um.

Eine Zeile pro Rechnung oder eine Zeile pro Position: die Spaltenform entscheidet

Die erste Entscheidung über das Ergebnis fällt nicht beim Tool, sondern bei der Spaltenform: braucht das Team eine Kopfdaten-Tabelle mit einer Zeile pro Rechnung, oder eine Positions-Tabelle mit einer Zeile pro Position? Beide Modelle kommen aus derselben Datei, dienen aber unterschiedlichen Aufgaben — und wer das vor der Extraktion festlegt, spart sich die nachträgliche Bastelei in Excel.

Die Kopfdaten-Tabelle trägt eine Zeile pro Rechnung mit den Identifier- und Stammspalten: Rechnungsnummer, Rechnungsdatum, Lieferant, USt-IdNr., Netto und USt nach Steuersatz, Brutto, Zahlungsziel, IBAN. Das ist die Form, in der ein Zahlungslauf vorbereitet wird, ein Buchungsstapel für die Buchhaltung erzeugt wird, eine monatliche Liquiditätsübersicht entsteht oder ein Geschäftsführungs-Reporting Eingangsrechnungen pro Lieferant aggregiert. Aus dieser Tabelle führt der Weg in den AP-Workflow zur automatischen Erfassung von Eingangsrechnungen — die Spaltenform passt direkt in den Importpfad der gängigen Buchhaltungssysteme.

Die Positions-Tabelle ist granularer: eine Zeile pro Rechnungsposition, mit den Kopf-Feldern auf jeder Zeile wiederholt (mindestens Rechnungsnummer und Lieferant), zusätzlich Beschreibung, Menge, Stückpreis, Positions-USt und Positions-Gesamtbetrag, je nach Bedarf auch Artikel- oder SKU-Nummer und Bezug zur Bestellposition. Wer Rechnungspositionen aus PDF auslesen will, will sie meist genau so haben: für eine Spend-Analyse über Lieferanten und Warengruppen, für den Wareneingangsabgleich gegen Bestellung und Lieferschein, für die Aufteilung pro Kostenstelle oder Kostenträger, oder für eine detaillierte Vorsteueraufteilung über Sammelrechnungen.

Die Wiederholung der Kopf-Felder auf jeder Positionszeile sieht redundant aus, ist aber bewusste Konstruktion: erst dadurch lassen sich Positionen direkt in Excel sortieren, filtern und in Pivot-Tabellen ziehen, ohne dass der Bezug zur Rechnung verloren geht. Bei einem CSV-Import in ein ERP- oder Buchhaltungssystem gilt dasselbe — eine Positionszeile ohne Identifier ist im Datensatz wertlos.

Praktisch wird der Unterschied vor allem bei den lästigen Layouts. Eine mehrseitige Rechnung mit Positionen, die über einen Seitenwechsel laufen, verliert in einer reinen Kopfdaten-Sicht jede Spur der einzelnen Positionen; in einer Positions-Tabelle steht jede Zeile mit ihrem eigenen Quellverweis. Bei Statement-of-Account-Layouts, in denen ein Lieferant mehrere offene Rechnungen in einem Dokument zusammenfasst, ist die Positions- oder Listenform ohnehin die einzige saubere Repräsentation: jeder Eintrag aus der Sammelübersicht wird zu einer eigenen Zeile.

Granularität und Dateiformat sind unabhängig voneinander. Beide Tabellenformen lassen sich ausgeben, wie es der nachgelagerte Schritt verlangt: als Excel, wenn die Sachbearbeitung die Datei selbst öffnet und prüft (Rechnung in Excel exportieren ist hier der Standardweg), als CSV, wenn die Tabelle in ein Buchhaltungs- oder ERP-System importiert wird (eine PDF-Rechnung in CSV umwandeln ist eigentlich nichts anderes als die Kopf- oder Positionsdaten als CSV abzulegen), oder als JSON, wenn ein nachgelagerter Automatisierungsschritt die Daten programmatisch weiterverarbeitet.

Native PDF, Scan und der Unterschied zwischen OCR und KI-Extraktion

Im Stapel liegen zwei Dateitypen nebeneinander, die technisch unterschiedlich behandelt werden müssen. Eine native PDF — die Rechnung kommt direkt aus der Buchhaltungs- oder ERP-Software des Lieferanten und wird per E-Mail oder Lieferantenportal verschickt — trägt einen Text-Layer. Wer in dieser Datei Text markiert, kopiert echte Zeichen, keine Bildpunkte. Eine eingescannte Papierrechnung oder ein Handy-Foto ist demgegenüber ein reines Pixelbild; der Text ist nur als Bild vorhanden und muss erst über Bilderkennung lesbar gemacht werden. Daneben existiert eine täuschende Mischform: ein scheinbar natives PDF, das aus einem Scan zusammengebaut wurde — die Datei trägt die PDF-Endung, hat aber keinen brauchbaren Text-Layer. Ein gemischter Lieferantenstapel enthält in der Praxis fast immer beide Typen, und ein brauchbares Tool erkennt den Unterschied selbst, ohne Sondermodus pro Datei.

Reine OCR-Texterkennung löst die erste Hälfte der Aufgabe: Pixelbilder werden in Text mit Positionsangaben verwandelt. Was OCR nicht löst, ist die zweite Hälfte. OCR weiß nicht, was eine Rechnung ist, kennt nicht den Begriff USt-IdNr., ordnet "USt 19 %" nicht dem Steuerbetrag zwei Spalten weiter rechts zu, und verliert die Zuordnung zwischen Feldname und Wert, sobald sich das Layout zwischen zwei Lieferanten unterscheidet. Im Ergebnis bekommt die Sachbearbeiterin eine Textkopie der Rechnung — nicht eine Tabelle.

Der eigentliche Hebel der KI-Extraktion liegt in vier Punkten, die sich konkret beschreiben lassen, ohne in Vendor-Vokabular zu kippen:

1. Prompt-gesteuerte Feldauswahl. Die Sachbearbeiterin schreibt in natürlicher Sprache auf, welche Felder sie braucht und in welcher Form, und das Modell folgt der Beschreibung. Statt für jeden Lieferanten ein Template zu pflegen, beschreibt der Prompt einmal den Feldkatalog und gilt für den ganzen Stapel — exakt der Mechanismus, den unser eigenes Werkzeug verwendet, wenn Anwender Rechnungsdaten direkt nach Excel extrahieren möchten.
2. Dokumentverständnis. Das Modell weiß, dass eine Rechnung Kopfdaten und Positionen kennt, dass Steuernummer und USt-IdNr. unterschiedliche Felder sind, dass das Leistungsdatum nicht zwingend mit dem Rechnungsdatum identisch ist, und dass bei einer Reverse-Charge-Konstellation kein deutscher Steuerbetrag ausgewiesen wird, sondern ein Hinweis auf die Steuerschuldumkehr. Diese Semantik trägt das Modell ins unbekannte Layout hinein, statt sich an einer trainierten Vorlage zu orientieren.
3. Excel-getypte Ausgabe. Datumsfelder werden als Datum geschrieben, Beträge als Zahl, Steuersätze als Prozent. Die Tabelle ist direkt formel- und pivot-fähig, ohne dass jemand die Spalten in Excel nachformatiert oder Tausenderpunkte manuell auseinanderbaut.
4. Konsistenz über den ganzen Stapel. Derselbe Prompt liefert dieselbe Spaltenstruktur, ob im Stapel zehn Rechnungen liegen oder mehrere tausend. Genau hier laufen reine OCR-Werkzeuge und auch generische Chat-Tools wie ChatGPT auf — sie können einzelne Rechnungen erstaunlich gut, verlieren aber bei wachsendem Volumen die Spaltenkonsistenz, sodass die Tabelle hinten anders aussieht als vorne.

Wer Rechnungen automatisch auslesen will, sucht in der Praxis genau diese Kombination: Felder werden über einen Prompt beschrieben, das Dokument wird semantisch verstanden, der Output ist getypt und über den ganzen Stapel hinweg gleich strukturiert. Ein konkretes Beispiel für diese Bauweise ist unsere eigene Plattform: ein einzelnes Prompt-Feld neben dem Datei-Upload, kein Template-Setup, kein Wizard, dieselbe Bedienlogik bei zehn Rechnungen wie bei einem Stapel von 6.000 Dateien pro Job. Native PDFs, Scans und Handy-Fotos werden im selben Lauf verarbeitet, deutsche Belege ohne Sprachumschaltung, die Ausgabe wahlweise als Excel, CSV oder JSON — kein OCR-Wrapper und kein generischer Chat-Bot.

Quell- und Seitenverweis: jede Zeile zurück zum Original

Eine extrahierte Tabelle ist nur so brauchbar, wie sie sich prüfen lässt. Stellen Sie sich vor, in der Excel-Liste fällt der Sachbearbeiterin auf, dass bei einem Lieferanten ein Brutto-Wert nicht zur Summe der Positionen passt, oder dass ein Steuersatz von 19 % statt 7 % ausgewiesen wird, obwohl die Position offensichtlich Lebensmittel betrifft. Sie muss den Wert gegen das Original prüfen, bevor sie ihn freigibt. Ohne Quellverweis sucht sie händisch im Eingangs-Stapel oder Mailpostfach: Lieferantenname filtern, Rechnungsdatum suchen, PDF öffnen, zur richtigen Seite blättern. Mit einem Quellverweis pro Zeile ist es ein Klick.

Ein brauchbarer Quellverweis trägt mindestens drei Informationen: den Dateinamen oder eine eindeutige Datei-ID des Originaldokuments, die Seitennummer innerhalb dieser Datei, und idealerweise einen direkten Link, der die Datei genau auf dieser Seite öffnet. Bei einzelnen Rechnungen reichen Dateiname und Seite 1; bei einem Sammel-PDF, in dem mehrere Lieferantenbelege hintereinander liegen, ist die Seitennummer der entscheidende Anker, weil ein Dateiname ohne sie auf jede der enthaltenen Rechnungen zeigen könnte. Bei einer Positions-Tabelle, in der eine Rechnung über mehrere Seiten geht, gehört im Zweifel zu jeder Positionszeile auch die konkrete Seite, auf der die Position erscheint.

Diese Funktion fehlt vielen reinen OCR-Werkzeugen oder bleibt oberflächlich. OCR liefert Text mit Position auf der Seite, aber keinen semantischen Bezug zwischen einer Tabellenzeile im Output und der Stelle in der Originaldatei, aus der die Werte kommen — es gibt schlicht keinen Schlüssel, der "diese Zeile in Excel = diese Rechnung auf dieser Seite" eindeutig herstellt. KI-Extraktion kann diesen Bezug pro Feld speichern und mit jeder Ausgabezeile mitliefern, weil sie die Zuordnung im Moment der Extraktion ohnehin treffen muss.

Praktisch bedeutet ein konsequenter Quellverweis, dass die menschliche Prüfung als Schritt zwischen Extraktion und Buchung tatsächlich machbar wird. Ohne Verweis kostet jede strittige Zelle so viel Zeit, dass die Prüfung in der Praxis schleift; mit Verweis dauert ein Abgleich Sekunden, und die Validierung extrahierter Rechnungsdaten vor der Buchung kann konsequent in den Workflow eingebaut werden, statt nur als Vorsatz auf einer Folie zu stehen. Datenqualität in der Buchhaltung steht und fällt mit dieser Stufe.

Im eigenen Werkzeug haben wir den Quellverweis als Standardausgabe verankert: jede Zeile in der Excel-, CSV- oder JSON-Datei trägt eine Referenz auf Quelldatei und Seitennummer. Ergänzend liefert die KI auf Wunsch Extraktionsnotizen, in denen sie erklärt, wie sie mit einer mehrdeutigen Stelle umgegangen ist — etwa bei einer Gutschrift, einer Sammelrechnung oder einem Beleg, dessen Dokumenttyp uneindeutig war. Beides zusammen heißt für die Sachbearbeitung: Entscheidung der KI sichtbar, Originalbeleg einen Klick entfernt, Korrektur in Sekunden statt Minuten.

Tool-Test auf den eigenen Rechnungen: ein praxistaugliches Vorgehen

Die Vendor-Seiten der deutschen Anbieter versprechen alle dasselbe — KI-Erkennung, hohe Genauigkeit, deutsche Belege, Stapelverarbeitung. Der einzige Weg, eine begründete Aussage über ein bestimmtes Werkzeug zu bekommen, ist es auf den eigenen Belegen zu prüfen. Das folgende Vorgehen lässt sich in einem Nachmittag durchziehen und liefert am Ende eine Trefferquote, die belastbar ist, weil sie auf dem realen Lieferantenmix beruht — nicht auf der Demo-Auswahl des Anbieters. Ein Blick auf einen Vergleich von Rechnungs-OCR-Software für deutsche Belege hilft bei der Vorauswahl, damit die Stichprobe nicht ergebnislos auf einem ungeeigneten Tool landet.

Schritt 1: Stichprobe zusammenstellen. 20 bis 50 Rechnungen aus dem letzten Monat, die das eigene Lieferanten-Spektrum repräsentieren. Die Mischung soll die Realität des Posteingangs widerspiegeln, nicht den Best-Case:

• native PDFs aus Lieferantenportalen oder Buchhaltungssoftware,
• mindestens fünf Scans aus eingegangenen Papierrechnungen, idealerweise mit unterschiedlicher Scan-Qualität,
• mindestens ein Handy-Foto vom Außendienst (schief, gegebenenfalls mit Schattenwurf),
• mindestens eine Rechnungskorrektur oder Gutschrift,
• mindestens eine Reverse-Charge-Rechnung mit ausländischem Lieferanten,
• mindestens eine mehrseitige Rechnung mit Positionen, die über einen Seitenwechsel laufen,
• mindestens eine Rechnung mit Skonto-Bedingungen und mehreren Steuersätzen auf einem Beleg.

Wer den Test ohne diese Edge Cases fährt, prüft nicht das Tool, sondern die Hochglanz-Vorlage des Anbieters.

Schritt 2: Feldkatalog als Prompt formulieren. Schreiben Sie auf Deutsch auf, welche Felder die spätere Tabelle tragen muss und in welcher Granularität. Ein Beispiel-Prompt für einen Kopfdaten-Test könnte lauten: "Extrahiere Rechnungsnummer, Rechnungsdatum, Leistungsdatum, Lieferant, USt-IdNr., Netto je Steuersatz, USt-Satz, USt-Betrag, Brutto, Zahlungsziel und IBAN. Eine Zeile pro Rechnung. Bei Gutschriften die Rechnungsnummer mit 'GS-' präfixieren und alle Beträge negativ darstellen. Bei Reverse-Charge das USt-Feld auf 0 setzen und einen Hinweis 'Reverse-Charge' in einer Zusatzspalte führen." Ein zielorientierter Zusatz — etwa "Ich bereite die Daten für die Vorerfassung in unserer Buchhaltung vor" — hilft dem Modell bei Sonderfällen, ersetzt aber die explizite Feldliste nicht.

Schritt 3: Extraktion durchführen und Feld für Feld prüfen. Hier werden die echten Tool-Unterschiede sichtbar. Die folgenden Punkte sind die typischen Bruchstellen:

• Lieferantenname. Werden Lieferanten mit ähnlichem Namensanfang (etwa "Müller GmbH" gegen "Müller & Söhne KG") sauber getrennt, oder wird ein Treffer auf den anderen umgebogen?
• Steuersätze. Bei mehreren Steuersätzen auf einem Beleg — wird Netto und USt-Betrag pro Satz korrekt aufgeschlüsselt, oder wird zusammengefasst und damit die Aufteilung der Vorsteuer verloren?
• Skonto. Werden Skonto-Bedingungen erkannt und in eigenen Spalten ausgewiesen, oder versteckt im Beschreibungstext?
• Reverse-Charge. Wird der Hinweis erkannt und das USt-Feld korrekt mit 0 oder einem Hinweis befüllt, oder erfindet das Modell einen Wert, weil das Feld semantisch erwartet wird?
• Mehrseitige Rechnungen. Werden Positionen über einen Seitenwechsel hinweg vollständig erfasst, oder bricht die Erkennung an der Seitengrenze ab?
• Handy-Foto. Werden auch schiefe oder schlecht beleuchtete Aufnahmen brauchbar erkannt, oder gehen sie still in die Fehlerquote?

Schritt 4: Quellverweis nutzen. Bei jeder Zelle, die unstimmig aussieht, den Verweis auf Quelldatei und Seite öffnen und gegen das Original abgleichen, statt im Stapel zu suchen. Dieser Schritt ist auch ein indirekter Test des Tools: liefert es einen brauchbaren Verweis pro Zeile, oder muss die Prüfung an dieser Stelle scheitern?

Schritt 5: eigene Trefferquote berechnen. Anzahl korrekt extrahierter Felder geteilt durch Anzahl geprüfter Felder, getrennt nach Pflicht- und Zusatzfeldern, wenn Sie die Aussage präzise machen wollen. Diese Zahl ist belastbarer als jede Anbieter-Angabe, weil sie auf dem eigenen Lieferantenmix beruht. Pauschalsätze wie "99 % Genauigkeit" sagen nichts darüber aus, wie das Tool auf den eigenen Belegen läuft — sie beziehen sich oft auf eine Auswahl glatter Standardrechnungen, die mit dem realen Posteingang wenig zu tun haben.

Die meisten ernstzunehmenden Anbieter halten einen kostenlosen Einstieg vor, der für 20 bis 50 Test-Rechnungen reicht — eine Vorabbindung ist nicht nötig, um diesen Test durchzuziehen. Am Ende des Nachmittags steht eine Zahl, mit der das Gespräch mit der Geschäftsführung geführt werden kann.

PDF-Extraktion neben der E-Rechnung: gemischte Eingänge bleiben Standard

Seit dem 1. Januar 2025 müssen B2B-Rechnungen in Deutschland in strukturierten Formaten — XRechnung oder ZUGFeRD ab dem Profil EN 16931 — empfangen werden können. Die verpflichtende Ausstellung wird gestaffelt eingeführt mit Übergangsfristen bis 2027 und 2028, abhängig vom Jahresumsatz des Ausstellers. In der Berichterstattung wird daraus oft die Botschaft, dass das Thema PDF-Extraktion damit erledigt sei. Im realen Posteingang sieht es anders aus.

Mehrere Effekte sorgen dafür, dass gemischte Eingänge auf Jahre Standard bleiben:

• Bestandsbelege aus laufenden Vorgängen werden weiterhin als PDF nachgereicht — Korrekturen, Mahnungen, ergänzende Lieferantenrechnungen zu früheren Aufträgen.
• Ausländische Lieferanten innerhalb und außerhalb der EU sind nicht an die deutschen Format-Anforderungen gebunden und stellen weiter PDFs aus.
• Kleinunternehmer- und Kleinbetragsrechnungen unter 250 € sowie B2C-Rechnungen sind ausgenommen oder weniger reguliert.
• Während der Übergangsfristen dürfen viele Lieferanten weiter PDF ausstellen, weil ihr eigener Stichtag noch nicht erreicht ist.
• Hybrid-Formate wie ZUGFeRD enthalten zugleich ein lesbares PDF und eine eingebettete XML. Wer die XML-Schiene fährt, bekommt das PDF gratis dazu; wer ohne XML-Verarbeitung arbeitet, behandelt die Datei genau wie eine PDF-Rechnung.

Praktisch bedeutet das: ein AP-Posteingang, der diese Realität sauber bedient, hat zwei nebeneinanderliegende Spuren. Die strukturierten E-Rechnungen werden direkt aus der XML in die Buchhaltung übernommen — der Empfangsweg dafür sitzt im Detail bei den E-Rechnung-Empfangsprozess für XRechnung und ZUGFeRD. Die PDFs, Scans und Handy-Fotos laufen über die KI-Extraktion in dieselbe Tabelle bzw. dasselbe Buchungsformat, das die strukturierte Spur produziert. Die Felder werden einmal definiert; beide Spuren bedienen denselben Zielzustand.