Dokumentenverarbeitung mit KI: Extraktion, Prüfung und Übergabe

Das Wichtigste in Kürze:

• KI-Extraktion lohnt sich für Dokumente mit Stückzahl und klaren Zielfeldern.
• Produktionsreif wird sie erst mit Validierung auf 3 Ebenen: Konfidenz, Regeln, Stammdaten-Abgleich.
• Unsichere Fälle landen kontrolliert bei einem Menschen, nicht ungeprüft im ERP.
• E-Rechnungen (XRechnung, ZUGFeRD) liest du direkt als XML aus, ganz ohne KI.

Das Problem: Daten am falschen Ort

Fast jedes Unternehmen kennt diesen Alltag. Rechnungen kommen als PDF per E-Mail, Lieferscheine als Scan, Auftragsbestätigungen als Foto aus der Werkstatt. Die Information existiert, aber sie steht in einem Dokument statt in dem System, in dem sie gebraucht wird. Also tippt jemand ab: Rechnungsnummer, Betrag, Positionen, Lieferantendaten, jeden Tag, jede Woche.

Dieses Abtippen ist teuer, langweilig und fehleranfällig, und es ist genau die Art von Arbeit, die sich heute gut automatisieren lässt, wenn man es richtig angeht. Dieser Artikel richtet sich an Geschäftsführung, Operations und IT in kleinen und mittleren Unternehmen. Sie müssen entscheiden: Welche Dokumente lohnen sich, wie funktioniert die Technik, und wo braucht es weiterhin Menschen?

Meine Position vorweg: Dokumentenverarbeitung mit KI funktioniert produktiv, aber nicht als Blackbox nach dem Motto „alles rein, alles raus“. Sie funktioniert als Pipeline mit 3 messbaren Kernschritten: Extraktion, Prüfung, Übergabe; unsichere Fälle landen dabei kontrolliert bei einem Menschen. Wer die Prüf- und Freigabelogik weglässt, baut sich einen Fehlergenerator mit hoher Taktrate.

Drei Begriffe: OCR, IDP, Dokumenten-KI

Diese 3 Begriffe tauchen ständig auf und werden gern vermischt.

OCR (Optical Character Recognition) wandelt Bilder von Text in maschinenlesbaren Text um. OCR beantwortet die Frage „Was steht da und wo steht es?“, nicht, was es bedeutet.

IDP (Intelligent Document Processing) ist der Sammelbegriff für den Gesamtprozess: Dokumente empfangen, klassifizieren („Ist das eine Rechnung oder ein Lieferschein?“), Felder extrahieren, validieren und an Zielsysteme übergeben. Die großen Cloud-Anbieter haben dafür eigene Dienste. Azure AI Document Intelligence bringt vortrainierte Modelle unter anderem für Rechnungen, Belege, Ausweisdokumente und Verträge mit und erlaubt eigene Custom-Modelle für firmenspezifische Formulare. Google Document AI arbeitet analog mit Prozessoren zum Digitalisieren (OCR), Extrahieren und Klassifizieren beziehungsweise Aufteilen von Mehrfach-Dokumenten.

LLM-basierte Extraktion nutzt Sprachmodelle, um Inhalte zu interpretieren: Felder aus Fließtext ziehen, Klauseln zusammenfassen, Sonderfälle einordnen. Das ist mächtiger als klassisches Template-Matching, aber auch weniger deterministisch. Dazu gleich mehr.

Wichtig für die Einordnung: „Dokumentenverarbeitung mit KI“ ist kein einzelnes Tool, sondern ein Prozess, der diese Bausteine kombiniert. Die Extraktion ist dabei meist der kleinste Teil des Aufwands. Der größere Teil steckt in Validierung, Ausnahmebehandlung und der sauberen Übergabe an ERP, Buchhaltung oder DMS.

Welche Dokumente eignen sich?

Das lässt sich nicht pauschal pro Dokumenttyp beantworten. Die Eignung hängt an 3 Kriterien, die du für jeden Dokumentenstrom einzeln bewerten solltest.

Erstens: Wiederholung und Stückzahl. Automatisierung amortisiert sich über Menge. Ein Dokumententyp, der täglich oder wöchentlich in nennenswerter Zahl eintrifft, ist ein Kandidat; ein Dokument, das dreimal im Jahr kommt, kostet in der Einrichtung mehr, als es je spart.

Zweitens: Feldklarheit. Sind die Zielfelder eindeutig definierbar? „Rechnungsnummer, Nettobetrag, Steuersatz“ ist klar. „Die für uns relevanten Punkte aus dem Anschreiben“ ist es nicht. Hier wird die Validierung schwierig, weil eine objektive Richtig-oder-falsch-Referenz fehlt.

Drittens: Fehlerkosten. Was passiert, wenn ein Feld falsch übernommen wird? Eine falsch erfasste Bestellposition fällt beim Wareneingang auf. Eine falsche IBAN in einer Zahlung fällt erst auf, wenn das Geld weg ist. Je höher die Fehlerkosten, desto enger muss die menschliche Prüfschleife sein. Automatisieren kannst du trotzdem, nur eben die Vorarbeit, nicht die Entscheidung.

Entscheidungsmatrix: Dokumenttypen im Vergleich

Diese Übersicht ist meine eigene Arbeitshilfe aus Projekten. Sie ersetzt keine Einzelfallprüfung, sortiert aber die typischen Kandidaten:

• E-Rechnung (XRechnung/ZUGFeRD), strukturiertes XML: sehr hohe Eignung. Direktes Parsen ohne KI, menschliche Prüfung nur bei Regelverstößen.

• PDF-Rechnung und Beleg, semi-strukturiert: hohe Eignung. Vortrainiertes Modell (etwa das Invoice-Modell), Prüfung unterhalb der Konfidenzschwelle.

• Lieferschein und Bestellung, semi-strukturiert: hohe Eignung. Vortrainiertes oder Custom-Modell, Prüfung unter der Schwelle plus Mengenabgleich.

• Eigene Formulare wie Anträge und Protokolle: mittlere bis hohe Eignung. Custom-Modell mit eigenen Trainingsbeispielen; anfangs alles prüfen, dann stichprobenartig.

• Verträge und Standardklauseln, unstrukturiert: mittlere Eignung. LLM-Extraktion mit engem Feldschema, Prüfung immer im Vier-Augen-Prinzip.

• Freitext-E-Mails und Anschreiben: mittlere Eignung. LLM-Klassifizierung mit Routing, Prüfung sobald Aktionen ausgelöst werden.

• Handschriftliche Notizen und alte Faxe: niedrige Eignung. Erst die Eingangsqualität verbessern, der manuelle Anteil bleibt hoch.

• Einzelstücke ohne Wiederholung: ungeeignet, besser manuell erfassen.

Zwei Punkte daraus werden oft übersehen.

E-Rechnungen brauchen keine KI. Seit dem 1. Januar 2025 ist die elektronische Rechnung bei Umsätzen zwischen inländischen Unternehmern verpflichtend eingeführt. Eine XRechnung oder der XML-Teil einer ZUGFeRD-Rechnung ist bereits strukturierte Daten.

Die liest du deterministisch aus: ohne Modell, ohne Konfidenzwerte, ohne Restunsicherheit. KI brauchst du für den Bestand an Bild-PDFs, Scans und ausländischen Belegen, der daneben weiterläuft. Wer beides in einen Topf wirft, macht den einfachen Teil unnötig unsicher.

„Eignet sich“ heißt nicht „vollautomatisch“. Verträge eignen sich gut für KI-gestützte Extraktion, als Vorarbeit für einen Menschen, der das Ergebnis prüft. Die Frage ist nie nur „Kann das Modell das lesen?“. Sondern: „Welche Entscheidung darf daran hängen, ohne dass jemand draufgeschaut hat?“.

Die Pipeline: 6 Stufen im Überblick

Jede produktive Dokumenten-Pipeline hat dieselben 6 Stufen. Das gilt unabhängig davon, welche Tools dahinterliegen:

1. Eingang: E-Mail-Postfach, Scanner, Upload oder API nehmen Dokumente an.
2. Klassifizierung: Rechnung, Lieferschein oder Vertrag wird erkannt, mehrseitige Stapel werden gesplittet.
3. Extraktion: OCR, Dokument-KI oder LLM zieht definierte Felder als JSON.
4. Validierung: Konfidenz, Regeln und Stammdaten-Abgleich sortieren in OK, PRÜFEN oder ABLEHNEN.
5. Freigabe: Ein Mensch prüft alles unterhalb der Schwelle oder oberhalb der Betragsgrenze.
6. Übergabe: ERP, Buchhaltung, DMS und Archiv; das Original bleibt aufbewahrt.

Der Punkt dabei: Extraktion ist Stufe 3 von 6. Die Demos, die du von Anbietern siehst, zeigen fast immer nur diese eine Stufe. Produktionsreife entsteht in den Stufen 4 bis 6: Validierung, Freigabe, Übergabe. Dort entscheidet sich auch, ob die Buchhaltung dem System vertraut.

Für die Orchestrierung nutze ich je nach Umgebung unterschiedliche Werkzeuge. n8n verbindet als Workflow-Automatisierung KI-Fähigkeiten mit Prozessautomatisierung und lässt sich selbst hosten.

In Microsoft-Umgebungen bringt Power Automate Cloud-Flows und fertige Genehmigungsworkflows (Approvals) mit. Die Extraktion selbst übernimmt ein spezialisierter Dienst oder ein LLM; die Orchestrierung sorgt dafür, dass jedes Dokument den richtigen Weg nimmt.

OCR oder LLM: Was brauchst du?

Das ist die häufigste technische Frage in Erstgesprächen. Die kurze Antwort: Das sind keine Konkurrenten, sondern Werkzeuge für unterschiedliche Teilprobleme.

OCR und Dokument-KI-Dienste arbeiten positionsbasiert. Sie erkennen Text, Layout, Tabellen und Schlüssel-Wert-Paare und liefern zu jedem Ergebnis eine Position im Dokument und einen Konfidenzwert. Vortrainierte Modelle wie das Invoice-Modell von Azure Document Intelligence kennen die typischen Felder einer Rechnung bereits und normalisieren sie automatisch. Ein Rechnungsdatum kommt als Datumstyp zurück, ein Betrag als Währungstyp. Das ist deterministisch genug für Buchhaltungsprozesse: gleiche Eingabe, gleiches Ergebnis, nachvollziehbare Herkunft jedes Feldes.

LLMs arbeiten bedeutungsbasiert. Sie extrahieren Felder auch dann, wenn kein Template passt: die Kündigungsfrist aus einem Vertrag, die eigentliche Anfrage aus einer verschachtelten E-Mail. Auch die Zuordnung eines Belegs zu einer Kostenstelle anhand des Kontexts gelingt so. Dafür haben sie 2 strukturelle Schwächen. Sie liefern keine belastbare Positionsangabe im Dokument. Und sie können sich plausibel irren: Ein erfundener, aber format-korrekter Wert sieht genauso aus wie ein richtiger.

Meine Faustregel für die Praxis:

• Rechnungen, Lieferscheine, Formulare und andere Belege mit klaren Feldern: Dokument-KI-Dienst zuerst, denn Konfidenzwerte und Positionsangaben sind für die Validierung Gold wert.
• Verträge, Freitext und exotische Layouts: LLM mit eng definiertem Ausgabeschema, immer mit menschlicher Prüfung, wenn Entscheidungen daran hängen.
• Hybrid ist der Normalfall im Betrieb. Der Dokument-KI-Dienst verarbeitet die Masse, das LLM übernimmt die Fälle, an denen das Standardmodell scheitert. Ein Mensch übernimmt die Fälle, an denen beide scheitern.

Was ich nicht empfehle: alles ungefiltert durch ein LLM zu schicken, weil es „eh alles kann“. Du verlierst Konfidenzwerte und Positionsnachweise. Also genau die Signale, die eine automatische Validierung erst möglich machen.

Wie validierst du Felder?

Über 3 Ebenen, bevor irgendein Wert in dein ERP wandert. Ein extrahierter Wert ist zunächst nur eine Behauptung des Modells. Genau an dieser Stelle scheitern die meisten selbstgebauten Lösungen.

Ebene 1: Konfidenz, traut sich das Modell selbst? Dokument-KI-Dienste liefern pro Feld einen Konfidenzwert zwischen 0 und 1, eine geschätzte Wahrscheinlichkeit für die Korrektheit. Microsoft beschreibt das am Beispiel 0,95: Die Vorhersage ist voraussichtlich in 19 von 20 Fällen richtig. Microsoft empfiehlt ausdrücklich, über diesen Wert zu entscheiden, ob ein Ergebnis automatisch akzeptiert oder zur menschlichen Prüfung markiert wird. Wichtig: Es gibt mehrere Konfidenzen, etwa für Texterkennung, Feldzuordnung und bei Tabellen zusätzlich Zeile und Zelle. Für kritische Felder nimmst du die niedrigste relevante, nicht den Durchschnitt.

Ebene 2: Regeln, ist der Wert plausibel? Deterministische Prüfungen ohne KI: Stimmt Netto plus Steuer gleich Brutto, ist die IBAN formal gültig, liegt das Rechnungsdatum in einem sinnvollen Fenster? Sind USt-ID und Pflichtfelder in Ordnung? Diese Regeln fangen genau die Fehlerklasse, die Konfidenzwerte nicht sehen: ein selbstbewusst falsch gelesenes Feld.

Ebene 3: Passt der Wert zu deinen Daten? Der Abgleich mit Stammdaten und Vorgängen. Existiert der Lieferant, und stimmt die hinterlegte IBAN mit der auf der Rechnung überein? Gibt es die referenzierte Bestellnummer, und passen Menge und Preis dazu? Eine abweichende Bankverbindung ist kein Extraktionsfehler. Aber so ein Fall muss zwingend zu einem Menschen, schon aus Betrugsschutz-Gründen.

Aus den 3 Ebenen ergibt sich pro Dokument ein einfaches Routing:

• OK: Alle Ebenen bestanden, das Dokument läuft automatisch weiter.
• PRÜFEN: Mindestens eine Ebene unsicher; die Prüf-Queue zeigt Original und extrahierte Werte nebeneinander.
• ABLEHNEN: Unlesbar oder grob widersprüchlich; Rückweg an den Absender oder manuelle Erfassung.

Die Schwellenwerte legst du nicht einmalig fest, sondern kalibrierst sie. Am Anfang läuft ein größerer Teil durch die Prüf-Queue, und mit jedem Korrekturdatensatz lernst du, wo die Schwelle für deinen Dokumentenmix sitzt.

Ein Hinweis mit GoBD-Bezug, der oft überrascht. Reicherst du Dokumente im Erfassungsprozess per OCR an, etwa zu einer volltextdurchsuchbaren PDF, greift eine Pflicht: Die dadurch gewonnenen Informationen sind laut GoBD nach Verifikation und Korrektur ebenfalls aufzubewahren. Deine Korrekturschleife ist also nicht nur Qualitätssicherung, sondern Teil der ordnungsmäßigen Aufbewahrung.

Schlechte Scans sind der Alltag

In jedem realen Dokumentenstrom stecken schiefe Handy-Fotos und 150-dpi-Scans. Dazu kommen Durchschläge und Stempel über der Rechnungsnummer. Drei Dinge helfen, in dieser Reihenfolge.

1. Ursache vor Symptom. Der größte Hebel liegt vor der KI: Scanner-Profile prüfen, Lieferanten auf E-Mail-PDF statt Papier umstellen, ein Upload-Formular statt Foto per WhatsApp anbieten. Zu den Scanner-Profilen gehören Auflösung, Kontrast und Schwarz-Weiß-Schwellen. Jede Stunde hier spart Wochen an Sonderfallbehandlung.

2. Qualität messen statt raten. Moderne OCR-Dienste bewerten die Bildqualität selbst; Google Document AI bietet in der Enterprise-OCR eine Bildqualitätsanalyse als Zusatzfunktion. Ein Dokument mit schlechter Eingangsqualität routest du so schon vor der Extraktion in einen Sonderpfad, statt dich hinterher über unsichere Felder zu wundern. Auch niedrige Konfidenz der reinen Texterkennung ist ein Signal: Microsoft nennt als erste Maßnahme hier explizit bessere Eingangsdokumente.

3. Einen definierten Rückweg bauen. Was auch nach Vorverarbeitung (Begradigen, Kontrastanhebung, Entrauschen) unsicher bleibt, geht in die manuelle Erfassung. Schickt ein Absender wiederholt unlesbare Dokumente, braucht es eine freundliche, idealerweise automatische Rückmeldung: „Bitte als PDF-Anhang senden.“ Das ist unbequem, aber ehrlicher als eine Pipeline, die schlechte Eingaben stillschweigend in schlechte Daten verwandelt.

Was ich bewusst nicht verspreche: eine Automatisierungsquote. Wie viel Prozent deiner Dokumente ohne menschliches Zutun durchlaufen, hängt fast vollständig von Dokumentenmix und Eingangsqualität ab. Das lässt sich messen, sobald die Pipeline steht, aber nicht seriös vorher garantieren.

Welche Freigaben brauchst du?

Stand Juli 2026. Das Folgende ist Orientierung, keine Rechtsberatung. Für den konkreten Fall gehören Steuerberatung und gegebenenfalls Datenschutzbeauftragte an den Tisch.

Freigaben heißt hier zweierlei: einmalige Freigaben vor dem Produktivbetrieb und laufende Freigaben im Prozess. Vor dem Go-live brauchst du 3 Sichten.

Fachliche Freigabe. Wer verantwortet die Daten im Zielsystem: Buchhaltung, Einkauf, Operations? Diese Person definiert Pflichtfelder, Prüfregeln und Schwellen und nimmt die Pilotphase ab; ohne diesen Owner wird die Prüf-Queue zur Halde.

Steuerlich-rechtliche Sicht (GoBD). Die GoBD regeln, wie Bücher und aufbewahrungspflichtige Unterlagen in elektronischer Form zu führen sind. Konkret relevant: Eingehende elektronische Handels- und Geschäftsbriefe und Buchungsbelege müssen im Empfangsformat aufbewahrt werden; deine Pipeline extrahiert also Daten aus dem Original, sie ersetzt es nicht. Bei E-Rechnungen ist der strukturierte XML-Teil das Entscheidende; er darf nicht durch eine Formatumwandlung verloren gehen, etwa in ein Bildformat. Formatkonvertierungen sind nur unter definierten Voraussetzungen zulässig.

Kläre mit deiner Steuerberatung, wie Archivierung und Verfahrensbeschreibung bei euch aussehen müssen.

Datenschutz. Sobald personenbezogene Daten verarbeitet werden, braucht es die übliche DSGVO-Hausaufgabe: Rechtsgrundlage, Auftragsverarbeitungsvertrag mit dem Cloud-Anbieter, Klärung des Verarbeitungsorts. Betroffen sind etwa Bewerbungen, Personaldokumente und teils auch Rechnungen an Privatpersonen; bei besonders sensiblen Strömen kann eine selbst gehostete Verarbeitung die einfachere Antwort sein als ein Cloud-Dienst.

Im laufenden Betrieb kommen 3 Freigabearten dazu.

Betragsabhängige Freigaben. Auch ein perfekt extrahierter Beleg über einen hohen Betrag sollte eine menschliche Freigabe durchlaufen. Das ist keine Misstrauenserklärung an die KI, sondern normales internes Kontrollsystem. Genehmigungsworkflows musst du nicht selbst bauen: Power Automate bringt Approvals als fertigen Baustein mit, in n8n bildest du sie als Workflow-Schritt ab.

Vier-Augen-Fälle. Abweichende Bankverbindung, neuer Lieferant, Gutschriften, Verträge: Diese definierten Fallklassen landen unabhängig von Konfidenzwerten immer bei einem Menschen.

Änderungsfreigaben. Wer darf Schwellenwerte, Prüfregeln oder Feldzuordnungen ändern? Solche Änderungen gehören dokumentiert; das ist Teil der Nachvollziehbarkeit, die eine Betriebsprüfung erwartet.

Umsetzung: Vom Pilot zum Betrieb

So gehe ich in Projekten vor, bewusst klein geschnitten.

1. Einen Dokumentenstrom wählen, nicht fünf. Meist Eingangsrechnungen oder Lieferscheine: hohe Stückzahl, klare Felder, messbarer Nutzen. Die Entscheidungsmatrix oben hilft bei der Auswahl.

2. Referenzdatensatz bauen. 50-100 echte Dokumente aus den letzten Monaten sammeln, inklusive der hässlichen. Für jedes die Soll-Werte erfassen. Ohne diesen Goldstandard kannst du nicht beurteilen, ob die Extraktion gut genug ist.

3. Extraktion testen, bevor du baust. Vortrainiertes Modell gegen den Referenzdatensatz laufen lassen und Feldgenauigkeit messen. Reicht das Standardmodell nicht, ist ein Custom-Modell der nächste Schritt. Microsoft empfiehlt dabei, jede visuelle Variante mit mindestens fünf Beispielen im Training abzudecken. Erst wenn auch das nicht trägt, wird es ein LLM-Sonderweg.

4. Pipeline mit Prüf-Queue bauen. Orchestrierung über n8n oder Power Automate, Validierung über die 3 Ebenen. Dazu eine simple Prüfoberfläche: Original links, extrahierte Felder rechts, Korrektur mit zwei Klicks. Die Korrekturen werden gespeichert, sie sind später dein Trainings- und Kalibriermaterial.

5. Parallelbetrieb. Zwei bis vier Wochen läuft die Pipeline neben dem manuellen Prozess, ohne dass ihre Ergebnisse allein zählen; danach hast du echte Zahlen zu Durchlaufquote, Korrekturquote und Fehlerarten. Das ist eine belastbare Grundlage für die Go-live-Entscheidung.

6. Schrittweise scharf schalten. Erst die unkritischen Felder automatisch übernehmen, dann mit wachsendem Vertrauen die Schwellen senken. Die Prüf-Queue bleibt dauerhaft, sie wird nur leerer.

Zu Kosten und Aufwand nur so viel, wie sich ehrlich sagen lässt. Die reinen API-Kosten der Extraktion sind bei KMU-typischen Mengen selten der entscheidende Posten. Abgerechnet wird bei den Cloud-Diensten pro verarbeiteter Seite beziehungsweise pro Anfrage; die aktuellen Preise stehen in den Preislisten der Anbieter und ändern sich regelmäßig. Der eigentliche Aufwand ist die Einrichtung: Referenzdatensatz, Pipeline, Prüfoberfläche, Anbindung des Zielsystems.

Ob das ein überschaubares Wochenprojekt oder ein mehrmonatiges Vorhaben ist, hängt vor allem an 3 Faktoren. Wie viele Dokumentvarianten hast du, wie sauber ist deine Eingangsqualität, und wie gut ist dein Zielsystem per Schnittstelle erreichbar? Genau diese 3 Fragen kläre ich in einem Erstgespräch, bevor irgendjemand über Budgets redet. Pauschale Preisangaben ohne Blick auf den Dokumentenmix halte ich für unseriös.

Mehr zum Gesamtthema findest du auf der Übersichtsseite Backoffice-Automatisierung; wie ich bei solchen Projekten arbeite, steht unter KI-Beratung.

Risiken und Grenzen, ehrlich benannt

Diese 5 Punkte gehören auf den Tisch.

• Plausible Fehler sind das Kernrisiko. Anders als ein Mensch, der bei Unsicherheit nachfragt, liefert ein Modell auch bei Unsicherheit eine Antwort. Ohne Konfidenz-Routing und Regelprüfung wandern falsche Werte formatgerecht ins ERP und fallen dort später und teurer auf als beim Abtippen.

• Der Long Tail frisst die Euphorie. Die ersten 80 Prozent eines Dokumentenstroms sind schnell automatisiert. Die letzten 20 Prozent kosten überproportional: Sonderformate, Sammelrechnungen, Anhänge im Anhang; es ist völlig legitim, diesen Rest dauerhaft manuell zu erfassen. Eine Pipeline muss nicht vollständig sein, um sich zu lohnen.

• Verantwortung bleibt beim Unternehmen. Weder ein Cloud-Dienst noch ein Dienstleister nimmt dir die Ordnungsmäßigkeit deiner Buchführung ab. Die KI ist ein Erfassungswerkzeug; verantwortlich für die Daten bist du.

• Wartung ist eingepreist, oder sie fehlt. Lieferanten ändern Layouts, Modelle und APIs werden versioniert, Schwellen driften. Eine Dokumenten-Pipeline ist Betriebssoftware, kein abgeschlossenes Projekt. Plane einen kleinen, regelmäßigen Pflegeaufwand ein, sonst degradiert das System leise.

• Nicht jedes Problem ist ein KI-Problem. Wenn der eigentliche Engpass darin besteht, dass Freigaben wochenlang liegen bleiben, löst Extraktion nichts. Erst den Prozess anschauen, dann die Technik.

Checkliste: Bist du bereit?

Vier Blöcke mit 16 Punkten, ehrlich beantwortet.

Auswahl

• Dokumentenstrom mit relevanter, wiederkehrender Stückzahl identifiziert.
• Zielfelder eindeutig definiert, die Feldliste existiert schriftlich.
• Fehlerkosten pro Feld bewertet: Was passiert bei Falschübernahme?
• E-Rechnungs-Anteil separiert, das XML wird direkt geparst statt durch KI geschickt.

Vorbereitung

• Referenzdatensatz aus 50-100 echten Dokumenten mit Soll-Werten erstellt.
• Eingangsqualität geprüft: Scan-Profile, Foto-Eingänge, Fax-Altlasten.
• Zielsystem-Schnittstelle geklärt: API, Import oder DATEV-Übergabe?

Validierung und Freigaben

• Validierung auf 3 Ebenen definiert: Konfidenzschwellen, Regelprüfungen, Stammdaten-Abgleich.
• Routing festgelegt: OK, PRÜFEN und ABLEHNEN mit Prüf-Queue und Zuständigkeit.
• Vier-Augen-Fälle benannt: Bankverbindungswechsel, Neulieferanten, Betragsgrenzen.
• GoBD-Fragen mit der Steuerberatung geklärt, inklusive Aufbewahrung im Empfangsformat und Verfahrensbeschreibung.
• Datenschutz geprüft, falls personenbezogene Daten im Strom sind (AVV, Verarbeitungsort).

Betrieb

• Parallelbetrieb geplant, zwei bis vier Wochen gegen den manuellen Prozess.
• Kennzahlen definiert: Durchlaufquote, Korrekturquote, Zeit bis Übergabe.
• Fachlicher Owner benannt, der Schwellen und Regeln pflegt.
• Pflegeaufwand eingeplant für Layout-Änderungen, API-Versionen und Schwellen-Kalibrierung.

Wenn du bei den ersten 4 Punkten ins Stocken kommst, ist das kein schlechtes Zeichen. Es heißt nur: Die Auswahl des richtigen Stroms ist die eigentliche erste Aufgabe. Genau dabei hilft ein strukturierter Blick von außen mehr als jedes Tool.