Dokumentenanalyse mit KI: Rechnungen und Verträge richtig auslesen

Rechnungen lesen, Verträge durchsuchen, Berichte verdichten: Kaum ein Büroprozess passt so gut zu Sprachmodellen wie die Dokumentenanalyse. Der Grund ist strukturell: Modelle sind darauf trainiert, Text zu verstehen und umzuformen - und genau das ist der Schritt vom Beleg zum Buchungssatz. Dieser Beitrag zeigt, wie eine belastbare Pipeline aussieht, was die E-Rechnung verändert und wo die Prüfpflichten der GoBD liegen.

Der Kontext: Die E-Rechnung wird zum Datenlieferanten

Seit dem 1. Januar 2025 gilt in Deutschland für Umsätze zwischen inländischen Unternehmern die E-Rechnung: Empfangen können müssen sie alle, ausstellen dürfen viele noch nach alten Formaten - Übergangsregelungen erlauben sonstige Rechnungen bis Ende 2026, bei einem Vorjahresumsatz bis 800.000 Euro sogar bis Ende 2027, und EDI-Verfahren laufen ebenfalls bis Ende 2027 aus ^[2]. Die GoBD wurden 2025 entsprechend angepasst: Entscheidend ist der strukturierte Datenteil (etwa die XML-Datei einer ZUGFeRD-Rechnung); der menschenlesbare PDF-Teil muss nur aufbewahrt werden, wenn er zusätzliche steuerlich relevante Informationen enthält ^[1].

Für die Dokumentenanalyse ist das eine Zeitenwende: Der strukturierte Teil liefert die Felder frei Haus - die KI verschiebt sich vom Erkennen auf das Verstehen. Was bleibt, sind die schwierigen Fälle: Scans, Fotos, E-Mail-Text, Verträge, Mahnungen, alles ohne XML.

Wie eine belastbare Pipeline aussieht

1. Erfassen: Beleg eingehend als Datei - E-Rechnung mit XML, Scan als PDF, Foto vom Handy.
2. Parsen: Datei in Text und Layout übersetzen; bei E-Rechnungen zuerst den strukturierten Teil lesen.
3. Extrahieren: Das Modell zieht Felder - Nummer, Datum, Beträge, Positionen - als strukturierte Ausgabe, idealerweise mit JSON-Schema.
4. Validieren: Regeln prüfen, was das Modell liefert: Summen stimmen, USt-IdNr. hat das richtige Format, Datum liegt im Geschäftsjahr.
5. Verbuchen und Ablegen: Erst nach bestandener Prüfung geht es ins System; Original und Extraktion werden zusammen abgelegt.

Die Arbeitsteilung ist der Punkt: Die KI liest, die Regeln rechnen, der Mensch entscheidet im Zweifel. Ein Beispiel für den Extraktionsschritt mit Schema:

{
  "rechnungsnummer": "2026-1187",
  "datum": "2026-10-14",
  "lieferant": "Muster GmbH",
  "netto": 1000.00,
  "mwst": 190.00,
  "brutto": 1190.00,
  "positionen": [
    {"text": "Beratung Oktober", "betrag": 1000.00}
  ],
  "konfidenz": 0.93
}

Warum jede Extraktion eine Prüfstufe braucht

Die Forschung ist eindeutig: Auch die besten Dokumenten-Lesesysteme scheitern regelmäßig an echten Dateien. Der Benchmark DocBench wurde 2024 genau dafür gebaut, weil es für Systeme, die rohe Dateien samt Fragen verarbeiten, keinen Maßstab gab - Dateiparsing, Metadaten, multimodale Inhalte und lange Kontexte sind eigene Fehlerquellen ^[3]. Hinzu kommt die bekannte Grundeigenschaft von Sprachmodellen: Sie ergänzen Plausibles statt „weiß nicht“ zu sagen - die Anatomie dieser Halluzinationen steht im eigenen Beitrag.

Typische Fehler in der Praxis: vertauschte Ziffern bei Beträgen, ein Datum aus dem Falzjahr, eine erfundene Position, ein Betrag in der falschen Währung. Alle vier fängt keine Plausibilitätsprüfung von allein - aber drei von vier fängt eine einfache Regel: Positionen aufsummieren und mit dem Gesamtbetrag vergleichen; das kostet zwei Zeilen Code und filtert den Großteil der teuren Fehler. Mehr zur Rechenschwäche der Modelle selbst im Beitrag Rechnen mit LLMs.

Was die GoBD dazu sagen

Die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern (GoBD) verlangen Nachvollziehbarkeit und Unveränderbarkeit: Belege bleiben in ihrer ursprünglichen Form aufbewahrt, Verfahren werden dokumentiert, jede Buchung muss sich bis zum Beleg zurückverfolgen lassen. Mit der Änderung von Juli 2025 ist klargestellt: Bei E-Rechnungen genügt die Aufbewahrung des strukturierten Teils, sofern keine zusätzlichen steuerlich relevanten Angaben im Bildteil stecken, und der strukturierte Datensatz darf nicht durch Formatumwandlung gelöscht werden ^[1].

Übersetzt auf die KI-Pipeline heißt das: Das Original ist der Beleg, nie die Extraktion. Die KI-Ausgabe ist ein Arbeitsergebnis mit Zeitstempel und Versionsbezug - was korrigiert wurde, wird als Korrektur geführt. Eine kurze Verfahrensdokumentation (welches Modell, welche Regeln, welche Stichproben) macht aus dem Bauchgefühl „das läuft schon“ einen prüfbaren Prozess.

Einordnung

Dokumentenanalyse mit KI ist fertig für den Alltag - unter einer Bedingung: Die Prüfstufe ist Teil des Systems, nicht ein Versprechen im Prospekt. Mit E-Rechnung, Schema-Extraktion und Regelwerk sinkt der Restaufwand auf die Ausreißer, die ohnehin ein Mensch sehen will. Wer danach die Zahlen weiter auswertet, liest im nächsten Schritt, warum Sprachmodelle beim Rechnen stolpern und welche Compliance-Pflichten in Finanzprozessen gelten.

Methode

Der Beitrag stützt sich auf das BMF-Schreiben zur zweiten GoBD-Änderung vom 14. Juli 2025, die BMF-FAQ zur E-Rechnung (Stand März 2026) und den DocBench-Benchmark aus der Forschung. Alle Quellen wurden am 20. Oktober 2026 geöffnet. Die beschriebene Pipeline und das Fehlerbild-Tableau sind redaktionelle Modelle aus der Praxis, keine behördliche Vorgabe.

Grenzen

• Konkrete Genauigkeitswerte hängen von Modell, Belegart und Layout ab - der Beitrag nennt bewusst keine Prozentzahlen ohne eigene Messung.
• Steuerliche Detailfragen (Verfahrensdokumentation im Einzelfall, Aufbewahrungsfristen je Belegart) gehören in die Beratung.
• Keine Rechts- oder Steuerberatung.

Quellen

1. GoBD; 2. Änderung aufgrund verschiedener gesetzlicher Änderungen (BMF-Schreiben vom 14. Juli 2025), Bundesministerium der Finanzen (abgerufen 2026-10-20) ↩1 ↩2 ↩3 ↩4
2. Fragen und Antworten zur Einführung der obligatorischen E-Rechnung zum 1. Januar 2025 (Stand: März 2026), Bundesministerium der Finanzen (abgerufen 2026-10-20) ↩1 ↩2
3. DocBench: A Benchmark for Evaluating LLM-based Document Reading Systems, arXiv (Shanghai Jiao Tong University / Tencent AI Lab) (abgerufen 2026-10-20) ↩1 ↩2