Automatisiere nicht das Auslesen einer Rechnung, sondern den kontrollierten Weg vom Eingang bis zur Buchhaltung. Strukturierte E-Rechnungen werden geparst, PDF-Dateien und Scans extrahiert, beide Pfade laufen in ein gemeinsames Rechnungsmodell. Danach entscheiden deterministische Prüfungen gegen führende Stammdaten und verantwortliche Menschen, nicht ein Konfidenzwert.
OCR erledigt einen Teilschritt. Ein Modell kann Lieferant, Rechnungsnummer, Datum, Beträge und Positionen extrahieren. Ob der Lieferant bekannt ist, die Rechnung bereits vorliegt, eine Bestellung passt oder eine Freigabe fehlt, entscheidet es nicht. Genau diese Verbindung aus KI-gestützter Vorbereitung und betriebssicherer Workflow-Integration macht aus Dokumentenerkennung eine Rechnungsverarbeitung.
- Welchen fachlichen Zustand soll ein Beleg nach dem Eingang haben?
- Wo endet die Regel und beginnt die Verantwortung eines Menschen?
- Wer besitzt den Vorgang, wenn die Übergabe ins ERP in einen Timeout läuft?
Eine Rechnung ist ein Geschäftsvorgang, keine Bilddatei
Viele Projekte starten mit der Frage, welcher OCR-Dienst Felder am besten erkennt. Die wichtigere Frage lautet: Welcher fachliche Zustand soll nach dem Eingang entstehen? Eine Rechnung kann neu, unvollständig, doppelt, einer Bestellung zugeordnet, ungeklärt, freigegeben, abgelehnt, übertragen oder bereits gebucht sein. Solange diese Zustände, Übergänge und Verantwortlichkeiten nicht beschrieben sind, verschiebt eine bessere Extraktion das Problem nur in ein anderes System.
Der Zielprozess beginnt deshalb mit einer fachlichen Vorgangskennung und einer unveränderten Quelle. Jede Transformation erzeugt eine neue, nachvollziehbare Darstellung, ersetzt aber nicht heimlich das Original. Der Datensatz muss auf den empfangenen Beleg, seinen Eingangskanal, seine Verarbeitungsstände und die getroffenen Entscheidungen zurückführen. Das ist zugleich die Grundlage für Support, interne Kontrolle und eine spätere Prüfung.
| Schicht | Verbindliches Ergebnis | Typischer Fehler | Verantwortung |
|---|---|---|---|
| Eingang | Quelle, Format, Zeitpunkt und Vorgangskennung | Anhang fehlt oder wird doppelt abgeholt | Finance Operations |
| Extraktion | Felder, Positionen, Fundstelle und Konfidenz | Wert wird falsch gelesen oder falsch zugeordnet | Dokumenten-Pipeline |
| Validierung | Regelergebnisse gegen führende Daten | Lieferant, Betrag oder Bestellbezug widerspricht | Finance und System-Owner |
| Freigabe | Entscheidung, Rolle, Zeitpunkt und Begründung | Zuständigkeit fehlt oder Fall bleibt liegen | Benannte Freigeber |
| Übergabe | Belegter Zielstatus im ERP oder Accounting | Timeout erzeugt unklaren oder doppelten Zustand | Integration Owner |
| Betrieb | Monitoring, Warteschlange und Wiederanlauf | Fehler bleibt unsichtbar oder wird endlos wiederholt | Produkt- und Betriebsverantwortung |
Strukturierte E-Rechnung und OCR sind zwei verschiedene Eingangspfade
Seit dem 1. Januar 2025 ist nach der aktuellen BMF-Definition eine E-Rechnung im deutschen B2B-Kontext ein strukturiertes elektronisches Format, das eine elektronische Verarbeitung ermöglicht. Ein einfaches PDF ist danach eine sonstige Rechnung, auch wenn es per E-Mail ankommt. Für das Projekt heißt das: XML-basierte Daten und unstrukturierte Dokumente dürfen nicht unterschiedslos durch OCR geschickt werden.
Ein strukturierter Datensatz wird zunächst syntaktisch und fachlich validiert. Bei einem hybriden Format sind strukturierter Teil und menschenlesbare Darstellung gemeinsam zu behandeln, ohne die XML-Daten stillschweigend aus dem PDF zu überschreiben. Ein Scan braucht dagegen Texterkennung und semantische Feldextraktion. Beide Pfade laufen erst nach der Normalisierung in ein gemeinsames Modell zusammen.
Wichtig: E-Rechnungsfähigkeit ersetzt keine Rechnungsprüfung. Ein formal lesbarer Datensatz kann trotzdem einen unbekannten Lieferanten, eine unerwartete Bestellung, widersprüchliche Beträge oder eine erforderliche Freigabe enthalten.
Eingang, Extraktion und Normalisierung
Ein Postfach ist ein Empfangsweg, aber noch kein kontrollierter Eingang. Lege fest, welche Adressen, Portale, Uploads und Schnittstellen akzeptiert werden und welcher Kanal verbindlich gilt. Jede Quelle braucht Regeln für Dateityp, Größe, Malware-Prüfung, unlesbare Dateien und Mehrfachzustellung. Ein Dokument darf nicht verschwinden, nur weil ein Parser es nicht öffnen konnte. Beim ersten erfolgreichen Empfang entstehen eine unveränderliche Quellenreferenz und eine interne Vorgangskennung.
Die Klassifikation entscheidet danach, ob ein Eingang überhaupt eine Rechnung ist und welcher Parser zuständig wird. Bewahre für jedes relevante Feld Rohwert, normalisierten Wert, Fundstelle im Dokument, Parser-Version und Konfidenz auf. So kann ein Mensch sehen, warum das System einen Betrag angenommen hat, und eine Korrektur überschreibt den ursprünglichen Vorschlag nicht, sondern erzeugt eine nachvollziehbare Entscheidung.
Die Normalisierung übersetzt XML-Felder, Extraktionsausgabe und Portalmetadaten in ein gemeinsames internes Modell. Währungen, Datumswerte, Steuerangaben, Lieferantenkennungen und Positionsnummern brauchen eindeutige Typen, leere Werte bleiben leer und werden nicht aus Vermutungen ergänzt. Das Modell darf dabei nicht zum größten denkbaren Datenschema anwachsen: Ein Feld ohne fachliche Verwendung ist zusätzliche Wartungs- und Datenschutzlast.
Deterministische Prüfung und menschliche Freigabe
Eine Extraktion kann sehr sicher aussehen und trotzdem fachlich falsch sein. Der Lieferantenname kann korrekt gelesen, aber keinem aktiven Kreditor zugeordnet sein. Der Gesamtbetrag kann stimmen, während Steueranteile widersprechen. Eine Rechnungsnummer kann existieren und im Zielsystem bereits vorliegen. Nach der Extraktion folgen deshalb Regeln gegen führende Daten.
| Prüfart | Frage | Datenquelle | Mögliche Folge |
|---|---|---|---|
| Extraktionssignal | Wie sicher wurde dieser Wert erkannt? | Parser oder Dokumentenmodell | Wert anzeigen oder zur Korrektur markieren |
| Stammdatenprüfung | Ist der Lieferant eindeutig und aktiv? | Führendes ERP oder Accounting | Zuordnen oder als Ausnahme stoppen |
| Dublettenprüfung | Existiert derselbe fachliche Vorgang bereits? | Zielsystem und Prozessregister | Verknüpfen, prüfen oder ablehnen |
| Rechenprüfung | Passen Netto, Steuer und Brutto zusammen? | Normalisierte Rechnungsdaten | Bestehen oder Abweichung ausgeben |
| Bestellabgleich | Passen Bestellung, Leistung und Rechnung? | Bestellung, Wareneingang, Leistungsnachweis | Automatisch weiter oder fachlich klären |
| Freigaberegel | Wer darf diesen Fall verantworten? | Rollen- und Prozessmodell | Aufgabe erzeugen oder Übergabe sperren |
Human in the loop bedeutet nicht, dass jemand jedes Feld erneut abtippt. Eine gute Freigabe zeigt Quelle, vorgeschlagene Daten, bestandene Prüfungen, konkrete Abweichungen und die erwartete Entscheidung. Der Freigeber muss erkennen können, ob er fachliche Leistung, Kontierung, Zahlungsdaten oder nur eine technische Zuordnung bestätigt. Stellvertretung, Abwesenheit, Rückfrage und Ablehnung sind dabei echte Prozesszustände, und eine E-Mail-Benachrichtigung darf nicht selbst zum führenden Status werden.
Welche Fälle automatisch weiterlaufen dürfen, legt das Unternehmen mit Finance, Einkauf, Revision und Systemverantwortung fest. Unbekannte Lieferanten, geänderte Zahlungsinformationen, fehlende Bestellbezüge und widersprüchliche Steuerdaten sind typische Kandidaten für eine Prüfung, aber keine universelle Liste. Wo eine steuerliche Einzelfallbewertung nötig ist, gehört sie zu qualifizierten Verantwortlichen; ein Automatisierungsprojekt ersetzt keine Steuerberatung.
Übergabe, Idempotenz und Wiederanlauf
Die Übergabe ist nicht erfolgreich, weil ein HTTP-Aufruf abgesendet wurde, sondern erst, wenn das Zielsystem den Vorgang eindeutig angenommen hat und eine belastbare Referenz zurückliefert. Definiere vorab, ob das Ziel einen Entwurf, einen vorerfassten Beleg oder eine freigegebene Rechnung erhält. Buchungsperiode, Konten, Kostenstellen und Steuerkennzeichen bleiben unter der Hoheit des führenden Systems.
Bei einer unterbrochenen Verbindung ist oft unklar, ob das Ziel den Schreibvorgang verarbeitet hat, und ein blindes Retry legt denselben Beleg doppelt an. RFC 9110 beschreibt Idempotenz als dieselbe beabsichtigte Wirkung bei einer oder mehreren identischen Anfragen. Fachlich umgesetzt heißt das: stabile Vorgangskennung, Prüfung des Zielzustands vor der Wiederholung, dann begrenzte Retries mit Backoff. Permanente Validierungsfehler werden nicht wiederholt.
Anti-Pattern: Ein Job läuft jede Minute über alle offenen Rechnungen und sendet sie erneut, solange kein lokaler Erfolgsstatus gesetzt ist. Geht die Zielantwort einmal verloren, produziert dieses Muster Mehrfachwirkungen. Der Zielstatus muss vor der Wiederholung geklärt werden.
Ein Wiederanlauf wiederholt nur den notwendigen Teil. Nach einer korrigierten Lieferantenzuordnung kann erneut validiert werden, ohne das Original neu einzulesen; nach einer manuellen Freigabe kann die Übergabe fortgesetzt werden, ohne frühere Entscheidungen zu verlieren. Ausnahmen sind dabei kein Restposten, sondern ein eigener Produktpfad mit Ursache, betroffenen Feldern, bisherigen Entscheidungen und erlaubten nächsten Schritten.
Audit-Trail und Monitoring
Ein Audit-Trail beantwortet nicht nur, wer zuletzt auf Speichern geklickt hat. Er verbindet empfangenes Original, Parser-Ausgabe, normalisierte Werte, ausgeführte Regelversionen, menschliche Korrekturen, Freigaben, Übergabeversuche und Zielreferenz. Korrekturen bleiben als neue Ereignisse sichtbar, und Zugriffsrechte trennen Lesen, Ändern, Freigeben und administratives Eingreifen.
Die aktuelle BMF-FAQ und die 2025 angepassten GoBD behandeln die Aufbewahrung strukturierter E-Rechnungsdaten. Welche Unterlagen im konkreten Unternehmen steuerlich aufzubewahren sind, muss fachlich geprüft werden. Die technische Konsequenz ist klarer: Quellformat, relevante strukturierte Daten und Bearbeitungsnachweise dürfen nicht durch eine bequeme Arbeitskopie ersetzt werden.
Ein grüner Server sagt nichts darüber, ob Rechnungen im falschen Status warten. Beobachte Eingangsfehler, nicht klassifizierbare Dokumente, Validierungsausnahmen, das Alter offener Freigaben, Übergabefehler, Retry-Zähler und Fälle ohne Owner. Und jeder Alarm braucht eine Handlung: Wer klärt einen unbekannten Lieferanten, wer darf nach einem Timeout den Zielstatus prüfen und den Vorgang erneut anstoßen? Ohne diese Antworten bleibt Monitoring eine Sammlung roter Zahlen.
Standardprodukt, individuelle Integration oder Hybrid
Die Architektur folgt nicht der beeindruckendsten Demo. Ein Standardprodukt passt, wenn Eingangskanäle, Prüfungen, Freigaben und Zielsysteme weitgehend dem vorgesehenen Produktprozess folgen; eine individuelle Integration lohnt sich, wenn mehrere Systeme, eigene Geschäftsregeln oder anspruchsvolle Ausnahmen eine klar abgegrenzte Lücke erzeugen. Häufig trägt ein Hybrid am weitesten, aber nur mit bewusst begrenztem Datenmodell, definierten Fehlerfällen, einem Owner und einem in beide Richtungen geklärten Exit-Pfad. Unsere Software- und ERP-Entwicklung setzt deshalb an Prozess- und Systemgrenzen an, nicht an einem bevorzugten Produkt.
Einführung und Verantwortung
Starte nicht mit dem einfachsten Musterbeleg, wenn dieser die späteren Risiken nicht abbildet. Wähle einen begrenzten, aber repräsentativen Abschnitt mit echten Formaten, bekannten und unbekannten Lieferanten, Bestell- und Nicht-Bestellfällen, Gutschriften, Abweichungen und technischen Fehlern. Personenbezogene Testdaten gehören in eine kontrollierte Umgebung. Vor dem Pilot stehen Akzeptanzkriterien: Welche Formate müssen lesbar sein, welche Regeln stoppen den Vorgang, wann gilt eine ERP-Übergabe als bestätigt, wie wird zurückgerollt?
Eine Quote allein reicht als Abnahmekriterium nicht, weil ein einzelner falsch übergebener kritischer Fall schwerer wiegen kann als viele korrekt erkannte Standardbelege. Für jeden Teil braucht es danach einen benannten Owner: Eingangskanäle, Dokumentenmodell, Stammdaten, Prüfregeln, Freigabematrix, Zielintegration, Monitoring und Datenschutz. Die Projektübergabe umfasst die im vereinbarten Scope definierten Konfigurationen, Schnittstellenverträge, Prüfregeln und Runbooks; sie verspricht nicht pauschal jedes denkbare Artefakt. Wo KI-Agenten sinnvoll weiterhelfen und wo nicht, ordnet unser Beitrag zu KI-Agenten im Mittelstand ein; wie dieselbe Sorgfalt bei Firmenwissen aussieht, zeigt der Überblick zu RAG.
Was die entsorgo-Referenz belegt und was nicht
Im veröffentlichten Case zur KI-gestützten Belegverarbeitung bei entsorgo bereitet KI Dokumente vor, strukturierte Validierung unterstützt die Prüfung und das Team bestätigt kritische Schritte vor einer kontrollierten Übergabe. Diese Referenz belegt, dass DUNA Dokumenten-KI mit menschlicher Kontrolle und einem fachlichen Prozess verbinden kann.
Sie belegt keine universelle Genauigkeit, keinen bestimmten Anbieter, keine automatisch passende Architektur und keine garantierte Einsparung. Kundenspezifische Felder, Schwellenwerte, Routing, Volumen, Topologie, Preise, Margen und Wiederanlaufmechanismen bleiben unveröffentlicht. Dieser Artikel überträgt deshalb nur die allgemeine Entscheidungsmethode.
Häufige Fragen zur automatisierten Rechnungsverarbeitung
Braucht eine strukturierte E-Rechnung noch OCR?
Für den strukturierten Datenteil einer gültigen E-Rechnung ist OCR nicht der Weg, weil die relevanten Daten bereits maschinenlesbar vorliegen. Für einfache PDF-Dateien, Bilder und Scans bleibt Dokumentenextraktion notwendig. Ein belastbarer Eingang muss deshalb beide Formate erkennen und getrennt verarbeiten.
Darf ein hoher Konfidenzwert automatisch zur Buchung führen?
Nicht allein. Ein Konfidenzwert beschreibt die Sicherheit einer Extraktion, nicht die geschäftliche Richtigkeit der Rechnung. Lieferant, Rechnungsnummer, Beträge, Steuerlogik, Bestellung und Freigaberegeln brauchen deterministische Prüfungen gegen führende Daten. Welche Fälle danach automatisch weiterlaufen, muss fachlich entschieden, getestet und überwacht werden.
Wie verhindert man doppelte Rechnungen bei Wiederholungsversuchen?
Mit einer stabilen Vorgangskennung, den Dublettenregeln des führenden Systems und einer idempotenten Übergabe. Derselbe fachliche Vorgang muss bei einer Wiederholung auf dasselbe Ergebnis zeigen, statt einen zweiten Datensatz anzulegen. Bei einem Timeout wird zuerst der Zielstatus geprüft, erst danach folgt ein begrenzter Wiederholungsversuch.
Quellen und Stand
Die rechtlichen Hinweise sind eine technische Einordnung und keine Steuer- oder Rechtsberatung. Maßgeblich sind die aktuellen offiziellen Veröffentlichungen und der konkrete Einzelfall.
