Eingangsrechnungen automatisch erfassen: Praxis-Workflow

Eingangsrechnungen automatisch erfassen heißt, eingehende Rechnungen — PDFs, Scans, XRechnung-XML und ZUGFeRD-Dokumente — über Software einzulesen, Kopf- und Positionsdaten zu extrahieren und strukturiert an die Buchhaltung zu übergeben. Der Workflow trennt vier Schritte: zentraler Eingang, Datenextraktion, Validierung und Übergabe. Ein Mensch greift nur dort ein, wo eine Ausnahme das verlangt. Seit dem 1. Januar 2025 müssen inländische B2B-Empfänger zusätzlich strukturierte E-Rechnungen nach EN 16931 verarbeiten können, weshalb die Erfassungsschicht heute zwei Welten gleichzeitig bedienen muss: das strukturierte Format und die weiterhin große Restmenge an PDFs, Scans und Foto-Eingängen.

Dieser Artikel beschreibt die Erfassung als eigene Schicht. Erfassung ist hier nicht der Sammelbegriff für alles, was vom Posteingang bis zur Buchung passiert, sondern genau der Schritt, der ein eingehendes Dokument in strukturierte Felder verwandelt, die ein nachgelagertes System konsumieren kann. Die meisten ranking-starken Vendor-Seiten zum Thema „Rechnungserfassung automatisieren" verschmelzen Eingang, Extraktion, Validierung, Freigabe, Buchung und Archivierung in einer einzigen Folie und geben Ihnen am Ende ein Tool, das angeblich alles davon übernimmt. Diese Verschmelzung ist der Hauptgrund, warum Finanzteams nach der Tool-Auswahl überrascht sind, wo der Übergang in DATEV, Addison oder lexoffice noch immer manuell läuft. Eingangsrechnungen digital erfassen ist ein klar abgegrenzter Datenextraktions-Job — nicht die ganze Kreditorenbuchhaltung.

Die folgenden Abschnitte arbeiten den Erfassungs-Workflow entlang seiner vier Grenzen ab. Grenze 1 ist der zentrale Eingang als gemeinsamer Anlaufpunkt für alle Rechnungsformate. Grenze 2 ist die automatische Datenextraktion selbst — der Schwerpunkt dieses Artikels. Grenze 3 ist die Validierung und der Review der extrahierten Daten. Grenze 4 ist die Übergabe an die Buchhaltung, an DATEV, BMD oder den Steuerberater. Jede Grenze bekommt ihren eigenen Abschnitt, weil genau diese Trennung die Information ist, die in der SERP-Konkurrenz fehlt.

Was 2026 wirklich im Posteingang ankommt — und warum die Erfassung beide Welten bedienen muss

Ein realistischer Posteingang in einem deutschen Mittelstand sieht 2026 nicht aus wie auf den Vendor-Folien. Er enthält XRechnung-XML-Dateien aus Behörden- und Konzernverkehr, ZUGFeRD-PDFs mit eingebettetem strukturierten XML, klassisch eingescannte PDFs ohne jede strukturierte Datenschicht, mit dem Mobiltelefon abfotografierte Belege aus dem Außendienst, Rechnungen, die als E-Mail-Body ohne Anhang ankommen, und Lieferantenportal-Exports, die je nach Quelle als CSV, XLSX oder PDF herausfallen. Diese sechs Eingangsformate erscheinen parallel, oft in derselben Stunde.

Den Anlass für die strukturierte Welt gibt die deutsche Gesetzgebung. Wie die offizielle Übersicht zur B2B-E-Rechnungspflicht ab 1. Januar 2025 festhält, müssen seit dem 1. Januar 2025 Umsätze zwischen inländischen Unternehmen verpflichtend mit einer E-Rechnung in einem strukturierten Format gemäß EN 16931 abgerechnet werden, wobei XRechnung und ZUGFeRD als zulässige Formate gelten. Das verändert die Eingangsseite spürbar: Empfänger müssen strukturierte Formate technisch annehmen und verarbeiten können, sonst bricht der gesetzlich vorgesehene Vorsteuerabzug aus formalen Gründen.

Die Pflicht eliminiert den unstrukturierten Anteil aber nicht. Mehrere Gründe halten ihn dauerhaft im Posteingang. Erstens gelten Übergangsfristen, in denen deutsche Aussteller weiterhin nicht-strukturierte Rechnungen versenden dürfen. Zweitens haben internationale Lieferanten keinerlei Veranlassung, sich an EN 16931 zu halten — eine Rechnung aus Italien, den USA oder Indien kommt als PDF mit einem dortigen Layout. Drittens fallen Kleinbetragsrechnungen unterhalb der gesetzlichen Schwelle aus der Pflicht heraus. Viertens treffen B2C-Eingänge die Vorschrift ohnehin nicht. Fünftens existieren weiterhin Bestandsdokumente, nachträglich nachgereichte Rechnungen, Korrekturbelege und Archivablagen aus älteren Jahren, die immer wieder ins aktuelle Verarbeitungsfenster zurückgespielt werden. Eingangsrechnungen aus PDF erfassen bleibt damit mindestens das ganze Jahrzehnt eine Pflichtdisziplin neben der XML-Verarbeitung.

Das hat eine direkte Konsequenz für die Architektur der Erfassungsschicht. Sie muss zwei technisch unterschiedliche Routen parallel bedienen: ein deterministisches Mapping aus strukturierter XML, das die Felder an festen Positionen liest, sobald das Dokument normkonform ist; und eine probabilistische Datenextraktion aus PDFs, Scans und Fotos, die mit Konfidenzwerten pro Feld arbeitet und Layoutvariationen aushält. Eine Erfassungs-Lösung, die nur eine der beiden Routen sauber löst, deckt 2026 die Hälfte des realen Posteingangs nicht ab.

Grenze 1 — zentraler Eingang als gemeinsamer Anlaufpunkt

Bevor irgendetwas extrahiert werden kann, muss alles am selben Ort ankommen. Der zentrale Eingang ist die Schicht, deren einzige Aufgabe es ist, alle Rechnungsformate aus allen Kanälen an einer einheitlichen Übergabestelle zu sammeln, sodass die Datenextraktion einen vorhersagbaren Stapel bekommt. In der Praxis besteht diese Schicht aus einer kleinen Handvoll konkreter Bestandteile: einer zentralen Sammeladresse — meist eine dedizierte E-Mail-Adresse wie [email protected] — für PDF- und Scan-Anhänge; einem PEPPOL- oder E-Rechnungs-Empfangsendpunkt für strukturierte XRechnung- und ZUGFeRD-Eingänge; einer Upload-Möglichkeit oder API-Anbindung für Lieferantenportale, aus denen Rechnungen aktiv abgeholt werden müssen; und einem einfachen Trennregelsatz, der Cover-Mails, Lieferscheine und beigemischte Anhänge auseinanderhält.

Die Triage-Logik bleibt überschaubar, wenn sie konsequent angewendet wird. Anhänge werden vom E-Mail-Body getrennt, Lieferscheine und Werbe-PDFs werden vor der Extraktion aussortiert, und ein Sammel-PDF mit mehreren Belegen wird als solches erkannt und in seine Einzelrechnungen zerlegt, statt als ein einziges Dokument verarbeitet zu werden. Wer diese Trennung erst in der Extraktionsschicht macht, verschwendet Verarbeitungskapazität auf Dokumente, die nie hätten extrahiert werden müssen.

Den Rechnungseingang zu automatisieren heißt für diese Schicht also nicht, ein eigenes ERP-Modul aufzusetzen, sondern die Eingangskanäle zu konsolidieren und die offensichtlichen Nicht-Rechnungen abzufangen, bevor die rechenintensive Extraktionsarbeit beginnt. Wer dabei tief in die technischen Details der E-Rechnungs-Empfangsseite einsteigen möchte — PEPPOL-Zugangspunkte, Übermittlungswege, Empfangsbestätigungen, Format-Konformitätsprüfung beim Eintreffen — findet die ausführliche Anleitung im Companion-Artikel zum Thema den E-Rechnung-Empfangsprozess vorab einrichten. Dieser Artikel hier nimmt den zentralen Eingang als gegeben an und konzentriert sich auf das, was danach passiert.

Grenze 2 — automatische Datenextraktion aus jedem Format

Die Datenextraktion ist der Schritt, an dem aus einem eingegangenen Dokument strukturierte Felder werden. Auf der Header-Ebene liefert eine ernsthafte Erfassung pro Rechnung mindestens diese Werte: Rechnungsnummer, Rechnungsdatum, Lieferant mit Name und Anschrift, Leistungszeitraum, Nettobetrag, MwSt-Satz und MwSt-Betrag, Bruttobetrag, IBAN sowie USt-IdNr. Jedes dieser Felder trägt einen konkreten Folgeprozess: die Rechnungsnummer ordnet die Buchung dem Ausgangsbeleg zu, das Datum bestimmt das Buchungsperioden-Mapping, IBAN und USt-IdNr. fließen in die Stammdatenpflege und in die Doublettenerkennung, Netto- und MwSt-Werte sind die Basis der Vorsteuerermittlung. Wenn eines dieser Felder fehlt, fällt der nachgelagerte Prozess in einen manuellen Pass zurück.

Auf der Positions-Ebene liest die Extraktion pro Rechnungszeile die Beschreibung der Leistung oder Ware, Menge, Einzelpreis, Zeilensumme und den MwSt-Satz pro Position. Positionsdaten sind nicht für jeden Workflow nötig — eine reine Vorsteuer-Verbuchung kommt mit Header-Werten aus — aber sobald Vorkontierung, Kostenstellenzuordnung oder eine Spend-Analyse über Lieferanten hinweg im Spiel sind, wird die Positions-Schicht zur Pflicht. Eine Erfassung, die nur Header liefert, schließt diese Auswertungen aus.

Die Extraktionsschicht erkennt zusätzlich den Dokumenttyp und behandelt ihn entsprechend. Eine Rechnung, eine Gutschrift, eine Mahnung und ein Lieferschein sehen sich auf den ersten Blick ähnlich, gehören aber in völlig unterschiedliche Buchungsflüsse. Bei Gutschriften kehrt sich die Vorzeichenlogik um; Mahnungen werden aus dem Buchungsfluss ausgeschlossen, weil sie keine eigene Verbindlichkeit erzeugen, sondern auf eine bestehende verweisen; Lieferscheine gehören in den Wareneingang, nicht in die Kreditorenbuchhaltung. Die Dokumenttyp-Erkennung ist deshalb keine Zusatzfunktion, sondern ein eigenständiger Bestandteil der Erfassungsschicht in ihrer modernen Form.

Die zwei Extraktionsrouten unterscheiden sich technisch grundlegend. Aus strukturierter XML — XRechnung als reine Norm-Datei, ZUGFeRD als PDF mit eingebettetem XML — ist die Extraktion ein deterministisches Feldmapping. Die EN 16931 schreibt fest, an welcher Stelle im XML-Baum die Rechnungsnummer steht und welcher Datentyp sie ist; sobald das Dokument normkonform ist, liest die Software den Wert verlässlich, ohne Layout-Interpretation. Aus PDF, Scan und Foto ist die Extraktion ein probabilistisches Verfahren: die Engine analysiert das Dokument räumlich und semantisch, identifiziert Felder anhand von Beschriftungen, Position und Kontext und gibt zu jedem extrahierten Wert einen Konfidenzwert aus. Der Konfidenzwert ist die Brücke zur Validierungsschicht in Grenze 3 — er sagt nicht, ob der Wert richtig ist, sondern wie sicher die Engine ist, dass sie ihn korrekt gelesen hat.

Klassisches OCR ist die ältere, schwächere Vorstufe dieser zweiten Route. Eingangsrechnung-OCR im engeren Sinne konvertiert ein Bild in Zeichen, ohne den semantischen Kontext einer Rechnung zu kennen — sie weiß nicht, dass „14,90" im Briefkopf eher eine Telefondurchwahl als ein Bruttobetrag ist, und sie kann nicht zwischen Rechnungs- und Auftragsdatum unterscheiden. Wer Rechnungen mit reinem OCR auslesen will, bekommt am Ende einen Zeichenstrom, der einen Menschen zur Nachklassifikation zwingt. Die moderne Extraktionsschicht ist OCR plus eine Verstehens-Schicht, die Felder, ihre Bedeutung und ihre Beziehungen zueinander interpretiert.

Die zweite Verschiebung in der Erfassungsschicht der vergangenen Jahre betrifft die Konfiguration. Die alte Welt arbeitete mit Layout-Templates pro Lieferant: für jeden neuen Rechnungsschreiber wurde eine Vorlage hinterlegt, in der die Feldpositionen geometrisch markiert waren. Das funktionierte für Lieferanten mit konstantem Layout und brach bei jeder kleinen Änderung — neuer Briefkopf, anderes Logo, geändertes Datumsformat. Die moderne Welt arbeitet mit natürlichsprachlichen Extraktionsanweisungen: die Anwenderin beschreibt in einem Prompt, was sie braucht — etwa „Extrahiere Rechnungsnummer, Rechnungsdatum, Lieferant, Nettobetrag, MwSt-Satz, MwSt-Betrag, Bruttobetrag und IBAN; erkenne Gutschriften und kennzeichne Beträge dort negativ; eine Zeile pro Rechnung" — und die Engine bewältigt Layoutvariationen, ohne dass pro Lieferant etwas konfiguriert werden müsste.

Genau in dieser Konfigurations-Logik liegt der Kern eines modernen Tooling-Ansatzes. Unsere Plattform setzt diese Schicht so um, dass Sie Eingangsrechnungen mit KI-gestützter Datenextraktion erfassen können, ohne pro Lieferant ein Layout-Template zu pflegen: Sie laden die Dokumente hoch — einzeln oder im Stapel von bis zu 6.000 Dateien pro Job — beschreiben in einem natürlichsprachlichen Prompt, welche Felder Sie in welcher Struktur brauchen, und erhalten eine strukturierte Excel-, CSV- oder JSON-Datei, die direkt in den nachgelagerten Workflow geht. Mehrseitige PDFs mit bis zu 5.000 Seiten verarbeitet derselbe Prozess in einem Lauf, sodass auch Sammel-PDFs aus Lieferantenportalen ohne Vorzerlegung durchlaufen. Zwei Eigenschaften sind dabei für die Erfassungsschicht funktional entscheidend. Erstens lösen die natürlichsprachlichen Extraktionsanweisungen die Template-pro-Lieferant-Pflege ab — wer den Prompt einmal sauber formuliert, deckt einen Großteil der Layoutvarianten ab und kann den Prompt für die Wiederverwendung speichern. Zweitens trägt jede Zeile in der Output-Datei eine Verweisspur zur Quelldatei und zur Seitenzahl, aus der sie stammt — eine direkte Brücke zwischen extrahiertem Wert und Originaldokument, ohne Zwischenrecherche.

Grenze 3 — Validierung und Review der extrahierten Daten

Die Validierungsschicht ist die Übergabestelle zwischen Maschine und Mensch. Aufgabe dieser Schicht ist es, aus einem extrahierten Datensatz einen freigabefähigen Buchungsentwurf zu machen — also alle Prüfungen durchzuführen, die nötig sind, bevor ein Datenstrom in die Kreditorenbuchhaltung übergeben werden kann. Ein guter Teil dieser Prüfungen ist automatisierbar, ein kleiner Teil bleibt zwingend menschlich.

Automatisch laufen mindestens diese Schritte: das Konfidenz-Scoring pro Feld, das aus Grenze 2 mitgeliefert wird und einzelne Werte unterhalb einer organisations-eigenen Schwelle zur Nachprüfung markiert; die UStG-§14-Pflichtfeldprüfung, die kontrolliert, ob alle gesetzlich erforderlichen Angaben einer Rechnung vorhanden sind; die USt-IdNr.-Plausibilitätsprüfung, die innerhalb der EU gegen das MIAS-System abgefragt werden kann; die IBAN-Format- und Prüfsummen-Kontrolle, die syntaktisch falsche oder per Tippfehler veränderte Bankverbindungen abfängt; der Doublettencheck gegen die offenen Posten, der eine bereits eingegangene oder bezahlte Rechnung erkennt; der Stammdatenabgleich mit der Lieferantenliste, der eine bekannte IBAN gegen den gespeicherten Lieferanten validiert; und die einfache Konsistenzprüfung Netto plus MwSt gleich Brutto, die rein arithmetisch falsche Extraktionen sofort sichtbar macht. Was diese Prüfungen gemeinsam haben: sie betreffen alle die Datenqualität auf Feldebene.

Genau hier vermischt die SERP-Konkurrenz regelmäßig zwei Schritte, die getrennt gehören. Ein Validierungs-Review fragt: „Stimmen die extrahierten Daten?" — er betrifft die Datenextraktion und ihre Korrektheit. Ein Freigabe-Review fragt: „Wollen wir diese Rechnung tatsächlich bezahlen?" — er ist eine Geschäftsentscheidung über Vertrag, Leistungserbringung und Zahlungsfreigabe und gehört in den Workflow eines Fachverantwortlichen oder einer Vier-Augen-Prüfung. Die beiden Schritte haben unterschiedliche Verantwortliche, unterschiedliche Eskalationswege und unterschiedliche Servicezeiten. Wer sie in einer Maske vermengt, mischt Datenqualitätsfragen mit kaufmännischen Entscheidungen — und produziert sowohl ineffiziente Reviews als auch unklare Zuständigkeiten.

Ein Validierungs-Review wird in der Regel dann zwingend menschlich, wenn die automatischen Prüfungen ein klares Signal nicht selbst auflösen können: niedrige Konfidenz auf einem Pflichtfeld wie Rechnungsnummer oder Bruttobetrag; fehlende USt-IdNr. bei einer innergemeinschaftlichen Leistung, die ohne diese Angabe nicht steuerfrei verbucht werden kann; eine IBAN, die im Stammdaten-Abgleich nicht zur erwarteten Lieferantenkennung passt und damit auf einen möglichen Betrugsfall hindeutet; ein Bruttobetrag oberhalb einer organisationsspezifischen Schwelle, bei der ein Mensch ohnehin gegenlesen soll. Eine gut eingerichtete Validierungsschicht reicht den Großteil der Eingänge ohne menschliches Zutun an Grenze 4 weiter und eskaliert nur diesen Ausnahmeanteil — das ist der Punkt, der die Wirtschaftlichkeit der ganzen Erfassung trägt.

Eine zweite, oft mit Datenqualitäts-Validierung verwechselte Aufgabe ist die format-spezifische Validierung von strukturierten E-Rechnungen: ist eine eingegangene XRechnung-Datei syntaktisch korrekt nach der EN-16931-Norm? Ist ein ZUGFeRD-PDF schemavalide? Diese Prüfung gehört in dieselbe Schicht, hat aber eine andere Kompetenz und andere Werkzeuge. Wer sie im Detail aufsetzen will, findet die format-spezifische Anleitung im Companion zum Thema XRechnung und ZUGFeRD vor der Buchung validieren.

Grenze 4 — Übergabe an Buchhaltung, DATEV oder Steuerberater

Am Ende der Erfassungspipeline steht die Übergabe — die Schnittstelle zwischen den extrahierten, validierten Daten und allem, was nachgelagert ist: der Buchhaltungssoftware, dem ERP, dem externen Steuerberater oder einem Spreadsheet-getriebenen Monatsabschluss. Diese Schicht ersetzt das Buchhaltungssystem nicht; sie speist es.

In der Praxis brauchen deutsche Finanzteams je nach Setup unterschiedliche Übergabeformate. CSV- und XLSX-Exporte tragen den Großteil der Steuerberater-Übergaben, Quartalspakete und Spreadsheet-Workflows in Eigenregie — sie sind das gemeinsame Format, mit dem fast jedes nachgelagerte System umgehen kann. JSON-Exporte fließen in eigene Verarbeitungs-Pipelines, in Skripte, die Datensätze vor dem Import noch transformieren, oder in API-Integrationen mit Drittsystemen. Strukturierte Importdateien beziehungsweise Payloads sind das richtige Format für DATEV Unternehmen Online, BMD, Addison, lexoffice und sevdesk; jedes dieser Systeme bringt seine eigenen Importmechaniken und Vorlagen mit, in die die extrahierten Daten geladen werden. Größere ERPs wie SAP, Sage 100 oder weclapp nehmen die Daten typischerweise über ihre vorhandenen Importschnittstellen oder über Middleware entgegen, die zwischen dem Extraktions-Output und der ERP-Importtabelle vermittelt.

Was die Erfassungsschicht in dieser Grenze liefert, sind strukturierte Daten. Was sie ausdrücklich nicht liefert, ist die kaufmännische Buchung selbst. Eine saubere Erfassung leistet keine DATEV-native Buchung, keine GoBD-konforme Archivierung, keinen Freigabeworkflow als Engine, keine Zahlungslauf-Steuerung und kein reines XML-Parsing als Kernfunktion. Wer eine dieser Funktionen braucht, sollte sie an der dafür vorgesehenen Stelle im AP-Workflow ansiedeln — bei der Buchhaltungssoftware, beim DMS, beim Workflow-Tool — und die Erfassung als das einsetzen, was sie ist: die datenliefernde Mittelschicht.

Auf der DATEV-Seite hat die Übergabe eigene Konventionen, eigene Importformate und eigene Konsistenzanforderungen, die für eine reine Erfassungsbeschreibung den Rahmen sprengen. Die ausführliche Anleitung dazu, wie Rechnungsdaten in den DATEV-Workflow übergeben werden — von der Datei-Vorbereitung über DATEV Unternehmen Online bis zum klassischen Postversand — liegt im verlinkten Companion. Aus Sicht der Erfassung gilt: liefere saubere strukturierte Daten in dem Format, das das nachgelagerte System erwartet, und überlasse den eigentlichen Buchungs-Anstoß dem System, das schon dafür eingerichtet ist.

---

Was beim automatischen Erfassen weiterhin manuell bleibt — und wie der Review-Schritt billig wird

Vendor-Pages werben gern mit 96 bis 99 Prozent Extraktionsgenauigkeit und 85 bis 95 Prozent Dunkelverarbeitung. Was diese Zahlen meist verschweigen: wer beschreibt die verbleibenden 5 bis 15 Prozent? Ein erwachsener Erfassungs-Workflow geht von einem Ausnahmeanteil aus. Die Designfrage ist nicht, ob es ihn gibt, sondern wie billig der menschliche Pass auf diesen Anteil ist.

Die Ausnahmen lassen sich konkret benennen. Ausländische Lieferantenrechnungen mit ungewohntem Layout und nicht-deutschsprachigen Feldbezeichnern bringen die Extraktion zuverlässig an Konfidenzgrenzen, weil der semantische Kontext fehlt, an dem deutsche Rechnungen erkennbar sind. Sammelrechnungen und Statement-of-Account-Dokumente, die mehrere Einzelrechnungen in einem Dokument bündeln, brauchen eine eigene Aufbruchlogik, die nicht jede Engine sauber trifft. Mehrseitige Rechnungen mit Positions-Umbruch über Seitenwechsel hinweg erzeugen Zuordnungsprobleme zwischen Header und Positionen. Gutschriften und Stornorechnungen kehren die Vorzeichenlogik um und werden bei oberflächlicher Klassifikation als reguläre Rechnungen verbucht — mit den entsprechenden Folgen im Soll und Haben. Eine fehlende USt-IdNr. bei einer innergemeinschaftlichen Leistung blockiert die steuerfreie Verbuchung, bis das Feld nachgeholt ist. Schlecht gescannte Belege mit niedriger DPI, Schräglage oder Schattenwurf — vor allem mit dem Mobiltelefon abfotografierte Rechnungen aus dem Außendienst — überschreiten regelmäßig die Konfidenzschwelle, ab der eine menschliche Sichtprüfung sicherer ist als die Extraktion.

Was diese Ausnahmen ökonomisch tragbar macht, ist nicht eine höhere Extraktionsgenauigkeit, sondern ein anderer Hebel: Source-Referenzen pro extrahiertem Datensatz. Wenn jeder Wert in der Output-Datei eine Verweisspur zur Quelldatei und zur Seitenzahl trägt, aus der er stammt, ist die Verifikation eines auffälligen Feldes eine Zwei-Klick-Operation. Der Reviewer öffnet die Quelle, sieht die Stelle, vergleicht den extrahierten Wert mit dem Original und korrigiert oder bestätigt — ohne Suche im Dateisystem, ohne PDF-Wühlerei, ohne Datenbank-Recherche. Genau diese Verweisspur liefert unsere Plattform pro Zeile in der Output-Datei: jede extrahierte Zeile referenziert das Quelldokument und die Seitenzahl, sodass der Reviewer den Originalbeleg ohne Umweg aufrufen kann. Das Feature steht funktional zwischen Extraktion und menschlichem Pass — es macht den Pass auf den Ausnahmeanteil wirtschaftlich tragbar, statt ihn als unbezahlten Zusatzaufwand auf den AP-Schreibtisch zu kippen.

Ein kurzer Hinweis zur Einordnung: Diese Source-Referenzen sind ein Effizienz-Mechanismus für den Review-Schritt, nicht ein Ersatz für die GoBD-konforme Archivierung. Die rechtssichere Aufbewahrung der Originalbelege bleibt Aufgabe des nachgelagerten DMS oder Buchhaltungssystems. Was die Verweisspur leistet, ist eine andere Frage — nämlich die, wie schnell ein Mensch eine Auffälligkeit prüfen kann, ohne den Workflow zu unterbrechen.

Wo die Erfassungsschicht in den bestehenden AP-Workflow passt

Die vier Grenzen — zentraler Eingang, automatische Datenextraktion, Validierung und Review, Übergabe an die Buchhaltung — sind keine vier Tools, sondern vier voneinander abgrenzbare Schritte in einem AP-Workflow. Die meisten deutschen Finanzteams haben für Eingang, Freigabe und Buchung längst funktionierende Schichten: ein Postfach, das schon heute alle Rechnungen einsammelt, eine etablierte Freigabepraxis und ein Buchhaltungssystem, das die Buchungen verarbeitet. Was häufig fehlt, ist die datenextrahierende Mittelschicht — die Schicht, die ein PDF oder eine XML-Datei in strukturierte Felder überführt, ohne dass jemand sie abtippen muss.

Drei Fragen helfen, die Erfassungs-Lücke im eigenen Setup zu verorten:

• Wo werden Rechnungsdaten heute manuell abgetippt oder per Sichtprüfung in Felder übertragen — sei es in eine DATEV-Maske, in ein ERP, in eine Excel-Liste oder in eine Steuerberater-Vorlage?
• Wo gehen Lieferantenformate verloren, weil pro Lieferant ein anderes Layout, eine andere Position des Bruttobetrags oder eine andere Datumsschreibweise eintrifft — und niemand die Energie hat, alle Varianten konsistent zu erfassen?
• Wo bleibt die Verifikation einer auffälligen Rechnung teuer, weil eine direkte Verweisspur vom extrahierten Wert zum Originalbeleg fehlt und der Prüfende erst im Dateisystem suchen muss?

Wer auch nur eine dieser Fragen mit „bei uns" beantwortet, hat die Erfassungs-Lücke benannt. Der nächste sinnvolle Schritt ist nicht, das ganze AP-Setup zu ersetzen. Er ist enger gefasst: die Erfassungsschicht so an den bestehenden Eingang und die bestehende Buchhaltung andocken, dass die manuellen Felder verschwinden.