11 Min. Lesezeit · KI · Juni 2026

Rechnungsverarbeitung mit KI automatisieren.

Eingangsrechnungen sind in fast jedem Unternehmen ein wiederkehrender, monotoner Aufwand: PDF öffnen, Beträge ablesen, Lieferant zuordnen, Kostenstelle vergeben, im ERP erfassen, zur Freigabe weiterleiten. KI kann den größten Teil dieser Tippt-und-Klickt-Arbeit übernehmen — aber nur, wenn man sie als Assistenzsystem mit klaren Prüfpunkten aufsetzt und nicht als Black Box, der man blind vertraut.

Wo der Aufwand wirklich steckt.

Der eigentliche Schmerz bei der Rechnungsverarbeitung ist selten das Verbuchen selbst — das ist im ERP schnell erledigt. Der Aufwand liegt davor: das manuelle Abtippen von Rechnungskopf, Positionen, Steuersätzen und IBAN, das Heraussuchen der richtigen Bestellung, das Erkennen von Doppel- oder Fehlbuchungen. Eine durchschnittliche Eingangsrechnung durchläuft mehrere Hände, bis sie bezahlt ist.

Genau hier setzt KI an. Sie löst nicht die Buchhaltung ab, sondern die stupide Datenerfassung dazwischen. Das Ziel ist nicht „die KI bucht alles allein“, sondern „die KI bereitet jeden Vorgang so weit vor, dass ein Mensch ihn in Sekunden prüft und freigibt statt ihn in Minuten zu tippen“.

Der Verarbeitungs-Pipeline in fünf Schritten.

Ein robustes System für die automatisierte Rechnungsverarbeitung besteht aus klar getrennten Stufen. Jede Stufe hat eine Aufgabe und einen definierten Ausgang:

Eingang & Klassifikation: Rechnungen kommen per E-Mail-Postfach, Upload oder Scan-Ordner. Ein erster Schritt entscheidet: Ist das überhaupt eine Rechnung? Eingangs- oder Ausgangsrechnung? Gutschrift? Mahnung?
Texterkennung (OCR): Bei reinen Bild-PDFs oder Scans wird der Text per OCR extrahiert. Native PDFs mit eingebettetem Text brauchen das nicht.
Datenextraktion: Aus dem Text werden die strukturierten Felder gezogen — Rechnungsnummer, Datum, Lieferant, Netto, Steuer, Brutto, Positionen, IBAN. Hier glänzen moderne LLMs.
Validierung & Abgleich: Stimmt Netto + Steuer = Brutto? Existiert der Lieferant im Stammdatensatz? Gibt es eine passende Bestellung? Ist die Rechnungsnummer schon einmal aufgetaucht (Dublettenprüfung)?
Übergabe & Freigabe: Die geprüften Daten gehen ins ERP/DMS, ein Mensch gibt frei. Bei Auffälligkeiten wird eskaliert statt automatisch gebucht.

Warum LLMs hier besser sind als klassische OCR-Templates.

Die klassische Rechnungserkennung der letzten zwei Jahrzehnte arbeitete mit Templates oder Zonen-OCR: „Die Rechnungsnummer steht immer oben rechts.“ Das funktioniert, solange jeder Lieferant ein festes Layout hat — und scheitert, sobald ein neuer Lieferant oder ein geändertes Format auftaucht. Jedes neue Layout musste angelernt werden.

Vision-fähige LLMs lesen eine Rechnung eher so, wie ein Mensch sie liest: Sie verstehen aus dem Kontext, was eine Rechnungsnummer ist, auch wenn sie an einer ungewohnten Stelle steht oder „Beleg-Nr.“ statt „Rechnungsnummer“ heißt. Das macht die Extraktion deutlich robuster gegenüber Layout-Vielfalt — der häufigste Grund, warum Template-Systeme in der Praxis so viel Nacharbeit verursachen.

Ehrlich bleiben muss man trotzdem: LLMs sind nicht fehlerfrei. Sie verlesen sich bei schlechten Scans, verwechseln gelegentlich Netto und Brutto bei ungewöhnlichen Darstellungen, oder erfinden im schlimmsten Fall ein plausibel aussehendes Feld, das gar nicht auf der Rechnung steht. Deshalb ist die Validierungsstufe nicht optional, sondern das Herzstück eines seriösen Systems.

Konkretes Extraktions-Setup.

Der Kern der Extraktion ist überschaubar: Man gibt dem Modell die Rechnung (als Bild oder Text) und ein klar definiertes Zielschema und verlangt strukturierte Ausgabe. Ein vereinfachtes Beispiel mit der Anthropic-API in Python:

import anthropic, base64, json

an = anthropic.Anthropic()

SCHEMA = """{
  "rechnungsnummer": str,
  "rechnungsdatum": "YYYY-MM-DD",
  "lieferant_name": str,
  "lieferant_iban": str | null,
  "netto": float,
  "steuersatz": float,
  "steuerbetrag": float,
  "brutto": float,
  "positionen": [{"text": str, "betrag": float}]
}"""

def extrahiere(pdf_seite_png: bytes) -> dict:
    img = base64.standard_b64encode(pdf_seite_png).decode()
    msg = an.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1500,
        system=("Du extrahierst Felder aus deutschen "
                "Rechnungen. Gib NUR valides JSON nach "
                "diesem Schema zurueck. Wenn ein Feld "
                "nicht eindeutig erkennbar ist: null. "
                "Erfinde KEINE Werte.\n" + SCHEMA),
        messages=[{"role": "user", "content": [
            {"type": "image", "source": {
                "type": "base64",
                "media_type": "image/png",
                "data": img}},
            {"type": "text",
             "text": "Extrahiere die Rechnungsdaten."}]}])
    return json.loads(msg.content[0].text)

def validiere(d: dict) -> list[str]:
    fehler = []
    # Rechnerische Plausibilitaet
    if abs(d["netto"] + d["steuerbetrag"]
           - d["brutto"]) > 0.02:
        fehler.append("Netto+Steuer != Brutto")
    # Steuerbetrag gegen Satz pruefen
    erwartet = round(d["netto"] * d["steuersatz"]
                     / 100, 2)
    if abs(erwartet - d["steuerbetrag"]) > 0.02:
        fehler.append("Steuerbetrag passt nicht zum Satz")
    return fehler

Entscheidend ist die validiere-Funktion: Sie nutzt deterministische Rechenregeln, um die KI-Ausgabe zu kontrollieren. Das LLM extrahiert, aber feste Mathematik prüft. Diese Trennung ist das Wichtigste am gesamten Aufbau. Wo immer eine Regel deterministisch formulierbar ist — Summenkontrolle, Dublettenprüfung, IBAN-Prüfziffer — gehört sie nicht ins LLM, sondern in normalen Code.

Validierung: das eigentliche Qualitätsmerkmal.

Ein gutes Rechnungssystem misst sich nicht daran, wie oft die KI alles richtig macht, sondern daran, wie zuverlässig es seine eigenen Unsicherheiten meldet. Folgende Prüfungen sollten automatisch laufen, bevor irgendetwas zur Freigabe geht:

Summenkontrolle: Netto + Steuer = Brutto, Positionen summieren sich zum Netto. Reiner Rechenschritt, kein KI-Schritt.
Stammdatenabgleich: Existiert der Lieferant? Stimmt die IBAN mit der hinterlegten überein? Eine geänderte IBAN ist ein klassisches Betrugsmuster und muss zwingend ein Mensch prüfen.
Dublettenprüfung: Rechnungsnummer + Lieferant schon einmal verbucht? Schützt vor versehentlicher Doppelzahlung.
Bestellabgleich (3-Way-Match): Rechnung gegen Bestellung gegen Wareneingang. Klassischer Kontrollmechanismus, den KI vorbereiten, aber nicht ersetzen kann.
Konfidenz-Schwelle: Bei unsicheren Feldern lieber als „unklar“ markieren und an einen Menschen geben, statt zu raten.

Wann ein Mensch entscheiden muss.

Vollautomatisches Buchen ohne menschliche Kontrolle ist bei Zahlungen die falsche Ambition. Sinnvoller ist ein abgestuftes Modell:

Fall	Behandlung
Bekannter Lieferant, alle Prüfungen grün, Betrag unter Schwelle	Vorerfasst, Mensch bestätigt per Klick
Neuer Lieferant oder geänderte IBAN	Manuelle Prüfung zwingend
Validierungsfehler (Summen passen nicht)	Zurück in die manuelle Bearbeitung
Betrag über Freigabegrenze	Regulärer Freigabe-Workflow, KI nur als Vorerfasser
Niedrige Extraktions-Konfidenz	Felder markiert, Mensch korrigiert

Mit diesem Modell verschiebt sich die menschliche Arbeit von „alles tippen“ zu „auf Auffälligkeiten reagieren“. Das ist der realistische Produktivitätsgewinn — nicht die Fantasie der menschenleeren Buchhaltung.

Rechtliches und Aufbewahrung nicht vergessen.

In Deutschland gelten für Rechnungen die Grundsätze ordnungsmäßiger Buchführung und die GoBD-Anforderungen an die Aufbewahrung. Ein KI-System ändert daran nichts: Originalbelege müssen unveränderbar archiviert werden, der Verarbeitungsweg sollte nachvollziehbar (revisionssicher) protokolliert sein. Wenn personenbezogene Daten oder Geschäftsgeheimnisse über eine Cloud-API laufen, ist ein Auftragsverarbeitungsvertrag und ein Blick auf den Datenstandort Pflicht. Für besonders sensible Umgebungen kann ein lokal betriebenes Modell die sauberere Wahl sein — auf Kosten von Setup-Aufwand und Modellqualität. Dies ist keine Rechtsberatung; die konkrete Ausgestaltung gehört mit Steuerberatung und ggf. Datenschutzbeauftragten abgestimmt.

Kosten — realistisch eingeordnet.

Die reinen API-Kosten für die Extraktion sind meist überraschend gering. Eine einzelne Rechnung verursacht typischerweise nur wenige Cent an Modellkosten, weil der Textumfang klein ist. Bei einigen tausend Rechnungen im Monat bleibt das im niedrigen zweistelligen Euro-Bereich. Der wahre Aufwand liegt nicht im Modell, sondern in der Integration: die Anbindung an ERP/DMS, die Stammdaten-Schnittstellen, das Berechtigungs- und Freigabekonzept, das Monitoring. Diese Einmal-Investition entscheidet über Erfolg oder Scheitern — nicht der Token-Preis.

Konkrete Zahlen hängen stark von Volumen, ERP-System und bestehender Infrastruktur ab. Wer mit belastbaren Zahlen plant, sollte ein kleines Pilot-Volumen real durchrechnen, statt sich auf Pauschalversprechen zu verlassen.

Einführung in Stufen — der bewährte Weg.

Der häufigste Fehler bei der Einführung ist, zu viel auf einmal zu wollen. Wer von Tag eins an alle Lieferanten, alle Belegarten und die vollautomatische Buchung anstrebt, baut sich ein unbeherrschbares System und verliert das Vertrauen der Buchhaltung beim ersten sichtbaren Fehler. Bewährt hat sich ein stufenweiser Weg:

Schattenbetrieb: Das System läuft mit, erfasst aber nichts verbindlich. Seine Vorschläge werden gegen die manuelle Erfassung gehalten. So lässt sich die Genauigkeit messen, bevor irgendein Risiko entsteht.
Assistenz für bekannte Lieferanten: Zuerst nur die immer gleichen, gut strukturierten Rechnungen weniger Stammlieferanten vorerfassen lassen. Hier ist die Trefferquote am höchsten und der Nutzen sofort spürbar.
Ausweitung mit Augenmaß: Schritt für Schritt weitere Lieferanten und Belegarten aufnehmen, jeweils begleitet von einer Stichprobenkontrolle.
Abgestufte Freigaben: Erst wenn die Quote über längere Zeit stabil hoch ist, lassen sich Routinefälle mit kleinem Betrag auf „Mensch bestätigt per Klick“ verkürzen — niemals auf „ganz ohne Mensch“.

Dieser Weg klingt langsamer, ist aber in der Praxis schneller, weil er das Vertrauen der Beteiligten aufbaut, statt es zu verspielen. Eine Buchhaltung, die dem System vertraut, arbeitet effizient damit. Eine, die ihm misstraut, prüft am Ende doch wieder alles doppelt — und dann hat man nichts gewonnen.

Typische Fehlerquellen, die man kennen sollte.

Aus der Praxis lassen sich die Stellen benennen, an denen automatisierte Rechnungsverarbeitung am häufigsten stolpert. Wer sie kennt, kann gezielt gegensteuern:

Sammel- und Mehrseitenrechnungen: Rechnungen mit vielen Positionen über mehrere Seiten oder mehrere Belege in einem PDF werden leicht falsch zusammengefasst. Hier hilft eine saubere Seitentrennung vorab.
Gutschriften und Stornos: Negative Beträge und Korrekturbelege werden manchmal als normale Rechnung interpretiert. Eine klare Klassifikation im ersten Schritt verhindert Folgefehler.
Fremdwährung und Skonto: Unterschiedliche Währungen, Skontobedingungen und Teilzahlungen erhöhen die Komplexität. Solche Fälle gehören eher in die manuelle Prüfung.
Uneinheitliche Steuersätze: Rechnungen mit mehreren Steuersätzen auf einem Beleg brauchen eine positionsgenaue Auswertung, sonst stimmt die Summenkontrolle scheinbar nicht.
Schlechte Scanqualität: Schiefe, blasse oder zerknitterte Scans sind die häufigste Ursache für Lesefehler. Oft löst eine bessere Erfassung am Eingang mehr als jede Modellverbesserung.

Was ich aus der Praxis mitgebe.

Klein anfangen. Ein Lieferanten-Segment oder ein Postfach automatisieren, Genauigkeit messen, dann ausweiten. Nicht das ganze Unternehmen auf einmal.
Validierung schlägt Extraktion. Die KI darf sich irren — das System darf es nicht ungeprüft durchwinken. Deterministische Prüfungen sind die Versicherung.
Mensch bleibt im Zahlungsfluss. Besonders bei IBAN-Änderungen und neuen Lieferanten. Betrugsprävention ist kein KI-Job.
Erfolg messen, nicht behaupten. Wie viele Rechnungen laufen wirklich ohne Nacharbeit durch? Diese Quote ehrlich erheben — sie ist der einzige relevante Maßstab.

Sie wollen Ihre Eingangsrechnungen mit KI vorerfassen lassen — sicher und nachvollziehbar? Unverbindlich anfragen — wir prüfen Belegvolumen, ERP-Anbindung, Datenschutz und einen sinnvollen Pilot-Bereich.