Klassische Texterkennung (OCR) verwandelt ein gescanntes Blatt in einen Zeichenstrom. Sie weiß aber nicht, dass „4.250,00 EUR“ der Bruttobetrag einer Rechnung ist und „2026-06-15“ das Fälligkeitsdatum. Genau diese semantische Lücke schließt Document AI: Der Dienst kombiniert hochwertige OCR mit trainierten Modellen, die Felder als Entitäten erkennen – also als benannte, weiterverarbeitbare Datenpunkte. Aus einem Stapel Papier wird so ein strukturierter Datensatz, der direkt in eine Buchhaltung, ein ERP-System oder eine Datenbank fließen kann.
Drei Eigenschaften definieren Google Document AI:
Document AI lohnt sich vor allem dort, wo große Mengen gleichartiger Dokumente manuell erfasst werden: Eingangsrechnungen in der Buchhaltung, Lieferscheine in der Logistik, Antragsformulare im Versicherungs- und Behördenumfeld, Ausweisdokumente im Onboarding. Faustregel aus unserer Projektpraxis: Sobald ein Team mehrere hundert Belege oder Formulare pro Monat per Hand abtippt, rechnet sich eine Prüfung der Automatisierung in den meisten Fällen.
Weniger geeignet ist Document AI für kleine, sehr heterogene Dokumentmengen ohne wiederkehrende Struktur – etwa gelegentliche Einzeldokumente in stark unterschiedlichen Layouts. Hier übersteigt der Einrichtungs- und Trainingsaufwand oft den Nutzen. Auch wer ausschließlich reinen Volltext für eine Suche braucht, kommt manchmal mit einfacherer Texterkennung aus.
Ein häufiges Missverständnis: Document AI ersetzt keine Buchhaltungssoftware, kein DMS und kein ERP. Es ist eine Extraktions- und Verstehensschicht, die strukturierte Daten liefert. Was mit diesen Daten geschieht – Buchung, Freigabe, Archivierung, Zahlung – passiert in den nachgelagerten Systemen. Document AI ist der Baustein, der die Lücke zwischen Papier respektive PDF und dem digitalen Prozess schließt.
Der Sprung von „Text erkennen“ zu „Inhalt verstehen“ klingt klein, ist im Geschäftsalltag aber der entscheidende. Solange ein Dokument nur als Zeichenstrom vorliegt, muss am Ende doch ein Mensch lesen, interpretieren und abtippen. Erst wenn die Felder als benannte Datenpunkte vorliegen, kann ein System automatisch weiterarbeiten: prüfen, abgleichen, buchen, weiterleiten. Document AI adressiert damit nicht ein technisches Nischenproblem, sondern einen der größten verbliebenen manuellen Aufwände in vielen Verwaltungs- und Buchhaltungsprozessen.
Gleichzeitig ist Realismus angebracht: Kein Dienst versteht ein Dokument so vollständig wie ein erfahrener Sachbearbeiter, der den Kontext kennt. Document AI liefert eine sehr gute, aber nicht fehlerfreie Vorerfassung. Der Gewinn entsteht dort, wo die Vorerfassung die Masse der Routinefälle abräumt und der Mensch sich auf die Ausnahmen und die fachliche Bewertung konzentrieren kann. Genau dieses Zusammenspiel zieht sich als roter Faden durch diesen Artikel.
Am Anfang steht die optische Zeichenerkennung (OCR). Document AI nutzt Googles OCR-Technologie, um aus einem Bild oder PDF die Zeichen, Wörter, Zeilen und ihre Positionen auf der Seite zu ermitteln. Das Ergebnis ist nicht nur reiner Text, sondern eine Layout-bewusste Repräsentation: Jedes Wort hat Koordinaten, jede Zeile eine Zuordnung. Diese Positionsinformationen sind entscheidend, weil die spätere Feldzuordnung oft vom Layout abhängt – etwa der Betrag, der rechts neben dem Wort „Gesamt“ steht.
Die OCR von Document AI bewältigt auch anspruchsvolle Eingaben: gedrehte Scans, mäßige Bildqualität, mehrspaltige Layouts und über 200 Sprachen. Handschrift wird teilweise erkannt, ist aber generell die schwierigste Disziplin und sollte immer mit besonderer Vorsicht und zusätzlicher Prüfung behandelt werden.
Auf der OCR-Ebene setzt das eigentliche Verstehen auf. Sogenannte Parser erkennen Strukturen im Dokument: Absätze, Tabellen mit Zeilen und Spalten, Formularfelder als Schlüssel-Wert-Paare („Rechnungsnummer: 2026-0815“), Kontrollkästchen und Unterschriftsfelder. Ein Tabellen-Parser etwa rekonstruiert eine Rechnungsposition mit Menge, Artikel, Einzelpreis und Gesamtpreis als zusammenhängende Datenzeile – nicht als losen Text.
Die höchste Stufe ist die Entitäten-Extraktion. Hier identifiziert ein trainiertes Modell konkrete, benannte Datenpunkte – die Entitäten. Bei einer Rechnung sind das beispielsweise Lieferantenname, USt-IdNr., Rechnungsdatum, Nettobetrag, Steuerbetrag, Bruttobetrag und IBAN. Jede Entität wird mit einem Wert und einem Konfidenzwert (Confidence Score) zurückgegeben – einer Wahrscheinlichkeit, wie sicher das Modell bei dieser Erkennung ist. Dieser Konfidenzwert ist später der Schlüssel für die Validierung: Felder unterhalb einer Schwelle gehen in die manuelle Prüfung.
Das Ergebnis einer Document-AI-Verarbeitung ist ein strukturiertes Dokument-Objekt (meist als JSON), das Text, Layout, erkannte Tabellen und Entitäten mitsamt Positionen und Konfidenzwerten enthält. Dieses Objekt ist der Übergabepunkt an alle nachgelagerten Systeme.
Für die meisten Standard-Dokumente sind vortrainierte, spezialisierte Prozessoren der pragmatischste Einstieg. Ein Rechnungs-Parser erkennt typische Rechnungsfelder über viele Lieferantenlayouts hinweg, ohne dass Sie ein einziges Beispiel annotieren müssen. Das senkt die Einstiegshürde erheblich – binnen Stunden lässt sich ein erster Durchstich testen. Wir empfehlen praktisch immer, zuerst mit einem vortrainierten Prozessor zu prüfen, wie weit man damit kommt, bevor über ein eigenes Training nachgedacht wird.
Reicht ein vortrainierter Prozessor nicht aus – etwa bei firmenspezifischen Formularen oder Branchendokumenten mit eigenen Feldern –, kommt ein Custom-Prozessor ins Spiel. Dafür müssen Beispieldokumente annotiert werden: Ein Mensch markiert in einer Trainingsoberfläche, welcher Text welche Entität ist. Aus diesen Beispielen lernt das Modell. Je nach Komplexität und gewünschter Genauigkeit sind hierfür je Dokumenttyp typischerweise mehrere Dutzend bis einige hundert annotierte Beispiele sinnvoll.
Dieser Annotationsaufwand ist real und wird in Projekten oft unterschätzt. Er ist gleichzeitig der Hebel für hohe Genauigkeit bei schwierigen Dokumenten. Eine generative Variante ergänzt das klassische Training inzwischen: Über große Sprachmodelle lassen sich Felder teils auch ohne umfangreiches Training per Anweisung extrahieren. Welcher Weg sinnvoller ist, hängt vom Dokumenttyp, vom Volumen und von den Genauigkeitsanforderungen ab und sollte fallweise bewertet werden.
So nützlich die Beispiele sind, sie unterscheiden sich stark in Schwierigkeit und Risiko. Eingangsrechnungen und Lieferscheine sind vergleichsweise gutmütig: hohes Volumen, wiederkehrende Felder, klare Plausibilitätsregeln. Formulare liegen im Mittelfeld – sie sind strukturiert, variieren aber je nach Herkunft. Verträge und Ausweise sind die anspruchsvollsten Fälle, weil sie entweder sprachlich komplex oder hochsensibel sind. Eine sinnvolle Einführungsreihenfolge orientiert sich an dieser Schwierigkeit: erst die gutmütigen, volumenstarken Fälle, dann die anspruchsvolleren.
So unterschiedlich die Fälle wirken – das Muster ist immer gleich: Ein Dokument in einem festen oder halbfesten Layout enthält Daten, die ein nachgelagertes System braucht. Document AI verwandelt diese Daten in ein maschinenlesbares Format. Je gleichförmiger der Dokumenttyp und je höher das Volumen, desto deutlicher der Nutzen. Bei stark wechselnden Layouts oder geringen Mengen sinkt der Mehrwert, weil Einrichtungs- und Prüfaufwand stärker ins Gewicht fallen.
Klassisches OCR – ob als Open-Source-Bibliothek oder einfacher Scanner-Dienst – beantwortet eine Frage: „Welche Zeichen stehen auf dem Blatt?“. Es liefert Text, manchmal mit grober Layout-Information. Es weiß aber nicht, was die Zeichen bedeuten. Wer aus einer Rechnung den Bruttobetrag braucht, müsste den OCR-Text mit eigenen Regeln und Mustern weiterverarbeiten – aufwendig, fehleranfällig und bei jedem neuen Lieferantenlayout brüchig.
Document AI geht den entscheidenden Schritt weiter: Es liefert nicht nur Text, sondern erkannte Felder mit Bedeutung und Konfidenzwert. Der Aufwand verschiebt sich vom Programmieren eigener Erkennungsregeln hin zum Auswählen oder Trainieren eines Prozessors und zur Validierung der Ergebnisse. Für gleichförmige Dokumente in Menge ist das fast immer der robustere Weg. Für reine Volltext-Anforderungen ohne Feldverständnis kann einfaches OCR dagegen genügen und günstiger sein.
Die direkten Wettbewerber stammen ebenfalls aus der Cloud-Welt: Azure Document Intelligence von Microsoft (früher „Form Recognizer“) und AWS Textract von Amazon. Alle drei verfolgen denselben Grundansatz – OCR plus trainierte Modelle zur Feld- und Tabellenerkennung, vortrainierte Modelle für Standarddokumente und die Möglichkeit, eigene Modelle zu trainieren. Die Unterschiede liegen weniger im Prinzip als im Detail und im Ökosystem.
Gegenüber klassischem OCR verursacht Document AI höhere laufende Kosten pro Seite und etwas mehr Einrichtungsaufwand. Diese Investition lohnt sich, sobald aus den erkannten Feldern echter Prozesswert entsteht – wenn also nachgelagert tatsächlich automatisch gebucht, abgeglichen oder weitergeleitet wird. Wird die Ausgabe ohnehin von einem Menschen vollständig nachbearbeitet, schrumpft der Vorteil. Die Leitfrage lautet daher nicht „Welcher Dienst erkennt am besten?“, sondern „Wie viel manuelle Arbeit ersetzt die Erkennung im konkreten Prozess wirklich?“. Erst diese Frage macht den Vergleich betriebswirtschaftlich belastbar.
Die ehrliche Antwort aus unserer Praxis: Die Wahl folgt meist der bestehenden Cloud-Strategie, nicht einem knappen Funktionsvergleich. Wer ohnehin in der Google Cloud arbeitet und Daten in BigQuery auswertet, fährt mit Document AI am rundesten. Wer eine Microsoft-Azure-Landschaft betreibt, wird Azure Document Intelligence bevorzugen; in einer AWS-Welt liegt Textract nahe. Die Erkennungsqualität ist bei allen dreien hoch und für die meisten Standarddokumente vergleichbar – entscheidend sind Integration, vorhandenes Know-how und der konkrete Dokumenttyp.
Sinnvoll ist daher fast immer ein Pilot mit echten Dokumenten: Geben Sie einen repräsentativen Stapel Ihrer realen Belege in den jeweils naheliegenden Dienst und messen Sie die Trefferquote auf den für Sie wichtigen Feldern. Diese empirische Prüfung ersetzt jede Marketingaussage und ist binnen weniger Tage machbar.
Ein produktiver Document-AI-Workflow folgt fast immer demselben Muster. Dokumente landen über einen Eingangskanal – etwa ein E-Mail-Postfach, ein Upload-Portal oder einen Cloud-Speicher (Cloud Storage) – in einem definierten Ablageort. Ein Auslöser startet die Verarbeitung durch den passenden Prozessor. Das Ergebnis, das strukturierte Dokument-Objekt, wird auf Konfidenz geprüft: Sichere Felder laufen automatisch durch, unsichere gehen in eine Prüfoberfläche. Die finalen Daten werden anschließend an das Zielsystem übergeben – Buchhaltung, ERP, DMS oder Datenbank.
Für die Orchestrierung dieser Kette nutzt man in der Google Cloud typischerweise serverlose Bausteine wie Cloud Functions oder Workflows, die auf neue Dateien reagieren und die Schritte verketten. Genauso lässt sich Document AI per API aber aus bestehenden Anwendungen, iPaaS-Plattformen oder Workflow-Tools ansprechen – die API ist der universelle Anschlusspunkt.
Ein großer Vorteil im Google-Ökosystem ist die nahtlose Brücke zu BigQuery, Googles Data-Warehouse. Extrahierte Entitäten lassen sich strukturiert in BigQuery laden und dort mit gewohnten Analysewerkzeugen auswerten: Wie verteilen sich Eingangsrechnungen über Lieferanten? Welche Vertragslaufzeiten enden im nächsten Quartal? Welche Belege fielen durch die automatische Prüfung? So wird aus einem Stapel Dokumente eine auswertbare Datenbasis, die mit Reporting- und BI-Werkzeugen visualisiert werden kann.
Die zweite Brücke führt zu Vertex AI, Googles Plattform für generative KI und Machine Learning. Während Document AI die Daten extrahiert, können generative Modelle sie weiterverarbeiten: einen Vertrag zusammenfassen, eine Rechnung gegen eine Bestellung plausibilisieren, eine Frage in natürlicher Sprache gegen die extrahierten Inhalte beantworten. Diese Kombination – präzise Extraktion plus sprachliche Weiterverarbeitung – ist der eigentliche Reiz des integrierten Ansatzes und hebt die reine Datenextraktion auf eine semantische Ebene.
Der letzte Schritt der Kette ist die Übergabe der geprüften Daten an das System, in dem die eigentliche Geschäftslogik liegt. Bei Eingangsrechnungen ist das typischerweise die Buchhaltungs- oder ERP-Software, bei Verträgen ein Vertragsmanagement oder DMS, bei Anträgen ein Fachverfahren. Document AI liefert die Daten in einem maschinenlesbaren Format; die Anbindung an das Zielsystem erfolgt über dessen Schnittstellen oder über eine Integrationsschicht. In der Praxis ist genau diese Anbindung der Punkt, an dem viele Projekte ihre Komplexität entfalten – nicht weil die Daten fehlen, sondern weil das Zielsystem bestimmte Pflichtfelder, Formate oder Freigabeschritte verlangt.
Ein bewährtes Vorgehen ist, die Schnittstelle zum Zielsystem früh zu klären, bevor die Erkennung im Detail optimiert wird. Welche Felder braucht das ERP zwingend? Wie werden Stammdaten wie Lieferanten oder Kostenstellen zugeordnet? Wie sieht der Freigabeworkflow aus? Diese Fragen entscheiden darüber, welche Entitäten Document AI überhaupt liefern muss – und verhindern, dass mit hohem Aufwand Felder extrahiert werden, die das Zielsystem gar nicht verwendet.
Genauigkeit ist kein einzelner Wert. Sie hängt vom Dokumenttyp, von der Bildqualität, vom Layout und vom konkreten Feld ab. Ein klar gedruckter Rechnungsbetrag wird nahezu fehlerfrei erkannt, eine handschriftliche Notiz am Rand deutlich schlechter. Statt einer pauschalen Prozentzahl zählt deshalb die feldbezogene Trefferquote auf Ihren echten Dokumenten – gemessen im Pilot, nicht aus dem Datenblatt übernommen. Seriöse Aussagen entstehen nur empirisch an realen Belegen.
Wichtig ist außerdem die Unterscheidung zweier Fehlertypen: Ein Feld, das gar nicht erkannt wird, ist meist unkritisch – es fällt auf und wandert in die Prüfung. Gefährlicher ist ein Feld, das falsch, aber mit hoher Konfidenz erkannt wird, weil es unbemerkt ins Zielsystem gelangen könnte. Genau gegen diesen Fall richten sich Validierungsregeln und Plausibilitätsprüfungen.
Das tragende Prinzip heißt Human-in-the-Loop (HITL): Die KI erledigt die Masse, der Mensch prüft die Ausnahmen. Konkret heißt das: Felder oberhalb einer Konfidenzschwelle laufen automatisch durch; Felder darunter oder Dokumente, die definierte Plausibilitätsregeln verletzen, landen in einer Prüfoberfläche, in der ein Mensch den vorgeschlagenen Wert bestätigt oder korrigiert. So bleibt die Kontrolle erhalten, ohne dass jedes Dokument vollständig manuell bearbeitet werden muss.
Plausibilitätsregeln sind dabei ein einfacher, wirkungsvoller Hebel. Beispiele: Netto plus Steuer muss Brutto ergeben; ein Rechnungsdatum darf nicht in der Zukunft liegen; eine IBAN muss formal gültig sein. Solche Regeln fangen viele Erkennungsfehler ab, bevor ein Mensch überhaupt prüfen muss – und sie erhöhen das Vertrauen in die automatisch durchgelaufenen Fälle.
Korrekturen aus der Prüfoberfläche sind kein verlorener Aufwand – sie sind wertvolle Trainingsdaten. Bei Custom-Prozessoren lassen sich korrigierte Beispiele in einen kontinuierlichen Verbesserungszyklus einspeisen, sodass die Erkennung über die Zeit besser wird und die Prüfquote sinkt. Dieser Kreislauf aus Erkennen, Prüfen, Korrigieren und Nachlernen ist das Herz eines reifen Dokumentenautomatisierungsprozesses.
Die GoBD verlangen unter anderem, dass steuerlich relevante Belege nachvollziehbar, vollständig, richtig, zeitgerecht, geordnet und unveränderbar erfasst und aufbewahrt werden. Für die Belegverarbeitung sind dabei mehrere Aspekte zentral: die revisionssichere Archivierung des Originalbelegs, die Nachvollziehbarkeit jedes Verarbeitungsschritts und eine Verfahrensdokumentation, die beschreibt, wie Belege erfasst, geprüft und verbucht werden.
Wichtig zur Einordnung: Document AI ist ein Extraktionsdienst. Es ist kein revisionssicheres Archiv und keine Buchhaltung. Die GoBD-Pflichten erfüllen sich nicht im Erkennungsschritt, sondern in den umgebenden Systemen und Prozessen – im DMS, im Buchhaltungssystem und in der dokumentierten Verfahrensweise.
Richtig eingebettet kann Document AI einen ordnungsgemäßen Belegprozess sogar stützen. Der eingehende Originalbeleg wird unverändert revisionssicher archiviert. Document AI liest die buchungsrelevanten Daten aus und liefert sie als strukturierten Vorschlag. Im Buchhaltungssystem werden diese Daten geprüft, freigegeben und gebucht – mit nachvollziehbarem Protokoll, wer wann was bestätigt oder korrigiert hat. Die KI-Extraktion ist damit ein vorbereitender Schritt, der die menschliche Prüfung unterstützt, sie aber nicht ersetzt.
Entscheidend ist die lückenlose Protokollierung: Die Verfahrensdokumentation sollte beschreiben, dass Daten maschinell vorerfasst, durch definierte Plausibilitäts- und Konfidenzregeln gefiltert und vor der Buchung durch berechtigte Personen geprüft werden. So bleibt die Nachvollziehbarkeit gewahrt – ein Prüfer kann jeden Schritt vom Originalbeleg bis zur Buchung zurückverfolgen.
Aus unserer Projekterfahrung gibt es wiederkehrende Risiken, die unbedingt mit fachlicher Begleitung adressiert werden sollten:
Google Cloud ist ein US-Anbieter. Auch bei Wahl einer EU-Region bleibt die Drittland-Thematik ein Punkt, der sorgfältig bewertet werden muss – Stichwort Datentransfer und Zugriff durch ein US-Mutterunternehmen. Die EU-Region reduziert das Risiko deutlich, hebt die rechtliche Bewertung aber nicht auf. Für besonders sensible Dokumente – Ausweise, Gesundheitsdaten, Personalunterlagen – sind zusätzlich strenge organisatorische Maßnahmen geboten: minimale Datenhaltung, kurze Löschfristen, enger Personenkreis mit Zugriff, klare Zweckbindung.
Für Unternehmen mit höchsten Souveränitätsanforderungen – KRITIS, Berufsgeheimnisträger – kann es sinnvoll sein, alternative Ansätze zu prüfen, etwa europäische Anbieter oder stärker abgeschottete Betriebsmodelle. Diese Abwägung gehört früh in die Planung, nicht ans Ende.
Eine erfolgreiche Einführung folgt einem bewährten Muster, das technische, organisatorische und rechtliche Schritte verbindet:
