Rechnungen automatisch auslesen: Felder, Prüfung und Übergabe

Prüfen Sie zuerst, ob strukturierte Rechnungsdaten vorhanden sind. Bei einer passenden E-Rechnung kann ein Parser Werte direkt übernehmen. Ein digitales PDF mit zugänglichem Text benötigt einen anderen Weg als ein Foto oder Bildscan. Die deutsche BMF-FAQ erläutert die Abgrenzung einfacher PDFs zu strukturierten E-Rechnungen. BMF: E-Rechnung, geprüft am 26. September 2026.

Speichern Sie das unveränderte Original und eine stabile Vorgangskennung. Wenn eine Datei mehrere Rechnungen enthält, muss die Aufteilung geprüft werden. Wenn eine Rechnung mehrere Seiten besitzt, dürfen ihre Positionen und Summen nicht auf verschiedene Vorgänge verteilt werden. Diese Zuordnung ist eine Voraussetzung für jede spätere Feldbewertung.

Ein reiner Dateitypfilter ist keine ausreichende Eingangskontrolle. Beschädigte PDFs, geschützte Dateien, leere Seiten und unvollständige Fotos brauchen einen sichtbaren Fehlerstatus. Verlorene Eingänge dürfen nicht aus der späteren Erfolgsrechnung verschwinden.

Lesen Sie nur Felder aus, die für den vereinbarten Prozess benötigt werden. Ein Rechnungsmodell kann viele Angaben liefern; nicht jede davon muss in ein weiteres System kopiert werden. Microsoft dokumentiert beim Invoice-Modell beispielsweise Kopf- und Positionsdaten als strukturierte Ausgabe. Microsoft: Invoice extraction.

Das folgende Beispielschema gliedert Rechnungsfelder in sechs Feldgruppen, jeweils mit einer Regel bei Unsicherheit:

Definieren Sie für jedes Feld Format, Pflichtstatus und fachlichen Eigentümer. Eine fehlende Bestellnummer kann bei einem Lieferanten normal und bei einem anderen ein Sperrgrund sein. Solche Unterschiede gehören in Regeln, die die Buchhaltung nachvollziehen und ändern kann.

Lieferant. Der gelesene Lieferantenname ist zunächst ein Textwert. Die Auswahl eines Kreditors ist eine zusätzliche Entscheidung. Verwenden Sie geprüfte Referenzen und zeigen Sie Mehrdeutigkeit an. Ein ähnlicher Name allein darf nicht automatisch die falsche Gesellschaft auswählen.

Konten, Kostenstellen und Projekte. Das Gleiche gilt für Konten, Kostenstellen und Projekte. Die KI kann einen Vorschlag machen, aber gültige Werte stammen aus dem Zielsystem beziehungsweise einer freigegebenen Zuordnung. Neue Bankdaten sollten nicht allein aufgrund einer überzeugenden Extraktion in Stammdaten übernommen werden. Für solche Änderungen ist ein eigener betrieblicher Kontrollweg erforderlich.

Rohwert, normalisierter und bestätigter Wert. Bewahren Sie Rohwert, normalisierten Wert und bestätigten Zielwert getrennt, soweit diese Unterscheidung für die Prüfung relevant ist. Dadurch lässt sich später erklären, ob ein Fehler beim Lesen, beim Umformen oder beim fachlichen Zuordnen entstanden ist.

Korrekturen wiederverwenden. Legen Sie fest, wie Korrekturen wiederverwendet werden. Wer eine einzelne Rechnung korrigiert, gibt damit nicht automatisch eine dauerhafte Regel für alle künftigen Belege dieses Lieferanten frei. Trennen Sie die Korrektur im Einzelfall von einer freigegebenen Änderung der Zuordnung.

Kontrollieren Sie erforderliche Felder, zulässige Formate und rechnerische Zusammenhänge. Prüfen Sie Dubletten im richtigen Gesellschafts- und Lieferantenkontext. Vergleichen Sie bei Bedarf Bestellung und Wareneingang. Ein korrekt erkannter Gesamtbetrag belegt noch keine berechtigte Lieferung.

Wie wirken Konfidenzwerte auf die Prüfung?

Konfidenzwerte können helfen, schwierige Felder zur Prüfung zu geben. Sie sind jedoch kein Ersatz für feste Regeln. Ein hoher Modellwert kann auch bei einer fachlich falschen Zuordnung auftreten. Legen Sie Schwellen anhand eigener Testdaten und der Folgen eines Fehlers fest.

Welche Ausnahmen brauchen eine fachliche Entscheidung?

Eine fachliche Ausnahme muss von einem technischen Fehler unterscheidbar sein. „Lieferant unbekannt“ braucht eine Zuordnungsentscheidung, „Zielsystem nicht erreichbar“ eine Betriebsreaktion. Unterschiedliche Ursachen sollten nicht in einer gemeinsamen endlosen Wiederholungsschleife landen.

Die Rechnung. Eine erfundene Rechnung enthält mehrere Positionen, zwei Steuersätze und einen gesonderten Rabatt. Das Erkennungsmodell liefert den Gesamtbetrag richtig, ordnet aber eine Position der falschen Steuergruppe zu. Wer nur den Bruttobetrag kontrolliert, würde den Fehler übersehen.

Geplanter Ablauf. Der geplante Ablauf übernimmt die Positionen mit Quellenbezug und prüft die Summen nach den fachlich vereinbarten Regeln. Die Abweichung führt zur Prüfansicht. Dort sieht die Buchhaltung Original, erkannten Wert und betroffene Summengruppe. Nach Korrektur wird die Prüfung erneut ausgeführt und die freigegebene Version festgehalten.

Übergabe. Die Übergabe verwendet genau diese Version. Trifft später eine korrigierte Lieferantenrechnung ein, wird sie mit dem bestehenden Vorgang verbunden und erneut bewertet. Die frühere Freigabe gilt nicht stillschweigend für einen veränderten Inhalt. Dieses Beispiel ist eine entworfene Testaufgabe, kein Nachweis einer ausgeführten Integration.

Zweiter Test. Ergänzen Sie einen zweiten Test, in dem das Modell eine Position auslässt, die Summe im Rechnungskopf aber plausibel bleibt. Wenn Positionsdaten benötigt werden, muss dieser Fall an der Vollständigkeitsprüfung scheitern. So unterscheiden Sie ein optisch überzeugendes Ergebnis von einer Ausgabe, die für den vorgesehenen Ablauf taugt.

Ein Export ist erst dann abgeschlossen, wenn die vorgesehene Verarbeitung im Ziel bestätigt ist. Speichern Sie Zielkennung, Zeitpunkt und Status. Bei einem verlorenen Rückkanal klären Sie zuerst, ob der Datensatz schon existiert. Eine blinde Wiederholung kann aus einem technischen Problem eine doppelte Rechnung machen.

Prüfen Sie im Ziel nicht nur die Werte, sondern auch den Belegbezug. Die spätere Bearbeitung muss vom Datensatz zum Original gelangen können. Ein vollständig gefüllter Import ohne erreichbare Quelle verursacht zusätzliche Sucharbeit und erschwert Korrekturen.

Weisen Sie ungeklärten Übergaben eine zuständige Person zu und halten Sie ihr Alter fest. Ein erfolgreich ausgelesener Beleg, der unbegrenzt auf den Import wartet, ist weiterhin unerledigte Arbeit. Die betriebliche Auswertung sollte diesen Unterschied sichtbar machen.

Nehmen Sie eine synthetische Rechnung mit der Lieferantenreferenz EXAMPLE-SUPPLIER-7, der Rechnungsnummer INV-104, der Währung EUR und einem Bruttobetrag von 240 €. Das sind erfundene Testwerte und keine Buchhaltungs- oder Steuerberatung. Die Originaldatei und jeder ausgelesene Wert bleiben mit dem Vorgang TEST-104 verknüpft.

Jede Stufe der synthetischen Übergabe erzeugt einen Nachweis und hat eine Bedingung, die den automatischen Fortgang anhält:

Eine erneut zugesandte E-Mail sollte auf den bestehenden Vorgang verweisen. Ändert eine prüfende Person den Lieferanten, wird die frühere Freigabe ungültig, statt stillschweigend weiterverwendet zu werden. Könnte das Buchhaltungssystem den Schreibvorgang bereits angenommen haben, untersuchen Sie zuerst den vorhandenen Datensatz, bevor Sie eine weitere Anlage versuchen. Das erwartete Ergebnis ist ein einziger, korrekt zugeordneter Datensatz und nicht bloß eine grün markierte Workflow-Ausführung.

Dokumentierte Konnektor-Operationen. n8n dokumentiert Rechnungs- und Kontaktoperationen für Xero sowie getrennte Ressourcen Bill, Vendor und Invoice für QuickBooks Online. Diese Quellen wurden am 27. September 2026 geprüft. Sie belegen verfügbare Konnektor-Operationen, keine fertige Integration von modernagents.

Verbindlichkeitsobjekt und Zuordnung. Vergewissern Sie sich bei eingehenden Lieferantenrechnungen, dass das vorgesehene Verbindlichkeitsobjekt angelegt wird und nicht versehentlich eine Ausgangsrechnung an einen Kunden. Halten Sie Gesellschaft oder Organisation, Lieferantenkennung, Währung, Steuerzuordnung und erforderlichen Status fest. Vorgeschlagene Werte bleiben in einer Warteschlange zur Prüfung, bis die in der Buchhaltung zuständige Person den Schreibvorgang freigibt. Gehen Sie nicht davon aus, dass ein Status namens „Entwurf“ in beiden Produkten und in jeder Edition existiert oder sich gleich verhält.

Erster Test. Der erste Test sollte eine falsch gewählte Gesellschaft, einen unbekannten Lieferanten, eine Dublette und eine verlorene Bestätigung enthalten. Das Anlegen eines Datensatzes berechtigt weder zu einer Zahlung noch zu einer E-Mail an Kunden. Das Integrationsverzeichnis beschreibt die dokumentierten Wege und Voraussetzungen; bevor einer der beiden Wege als funktionierende Umsetzung dargestellt wird, ist ein Test mit einem echten Konto erforderlich.

Wählen Sie normale und schwierige Rechnungen: wechselnde Layouts, schlechte Fotos, mehrseitige Belege, Gutschriften, Fremdwährungen, fehlende Referenzen und erneute Zusendungen. Lassen Sie die Sollwerte unabhängig bestimmen. Vergleichen Sie Felder und vollständige Vorgänge getrennt.

Messen Sie falsche, fehlende und zusätzlich erzeugte Angaben sowie verbleibende Korrekturzeit. Berücksichtigen Sie auch Fälle, die das Modell gar nicht verarbeiten konnte. Eine Quote nur aus erfolgreichen Antworten überschätzt die praktische Leistung.

Starten Sie mit einem Belegtyp und einer bestätigten Übergabe. Erweitern Sie erst, wenn das Team Quellen, Ausnahmen und Zuständigkeiten versteht. So wird Rechnungserkennung zu einem beherrschbaren Arbeitsprozess, dessen Qualität anhand Ihrer Belege und nicht anhand eines allgemeinen Produktversprechens beurteilt wird.

Diese Leitfäden und Leistungsseiten behandeln die Entscheidungen rund um das automatische Auslesen von Rechnungen:

• KI-Dokumentenverarbeitung: vom Eingang bis zur Freigabe
• OCR, IDP oder Sprachmodell: was Dokumentenverarbeitung braucht
• Digitale Rechnungsfreigabe: Regeln, Vertretung und Ausnahmen
• Doppelte Rechnungen erkennen: Regeln vor KI

Für eine konkrete Ablaufprüfung reichen zunächst eine Prozessbeschreibung, die beteiligten Systeme und typische Ausnahmen. Mit modernagents besprechen.