Rechnungsdatenextraktion: Deep Learning vs. Machine Learning vs. LLM (Leitfaden 2026)

Vor fünf Jahren bedeutete die Extraktion strukturierter Daten aus Rechnungen eine Deep-Learning-Pipeline: eine OCR-Stufe, ein layoutbewusstes Modell (LayoutLM, Donut), das auf Tausenden von Hand annotierten Dokumenten feinabgestimmt wurde, und ein Wartungsaufwand bei jeder Änderung einer Lieferantenvorlage. 2026 reduziert sich die gesamte Pipeline auf einen Vision-LLM-API-Aufruf: Bild hinein, schema-validiertes JSON heraus – keine Trainingsdaten, keine gehosteten Modelle und neue Layouts werden Zero-Shot verarbeitet. Dieser Leitfaden von Kunavo – einem unabhängigen, OpenAI-kompatiblen Gateway zu den Vision-Modellen, auf denen dieses Muster basiert – zeigt das vollständige Arbeitsmuster, die Kosten pro Rechnung anhand unserer veröffentlichten Preise und wie Sie die Genauigkeit produktionsreif halten.

Vergleich von Ansätzen zur Rechnungsextraktion: Regeln, Machine Learning, Deep Learning, LLM

Vier Generationen von Verfahren wurden eingesetzt, um strukturierte Daten aus einer Rechnung zu gewinnen. Ein Vergleich nebeneinander lohnt sich, denn der Kompromiss, der zwei Jahrzehnte lang zwischen ihnen entschied – Genauigkeit, die mit annotierten Daten erkauft wird –, ist nicht mehr maßgeblich.

Die ersten drei Verfahren haben eine Eigenschaft gemeinsam: Genauigkeit wird mit annotierten Daten erkauft. Jede Lieferantenvorlage, jedes CRF-Merkmal und jedes LayoutLM-Fine-Tuning ist ein Annotierungsprojekt. Ein Vision-LLM hat diese Kosten bereits während des Vortrainings getragen, daher sind die Grenzkosten eines neuen Layouts gleich null. Das ist die gesamte Veränderung – nicht, dass die älteren Methoden nicht mehr funktionieren, sondern dass das, wofür sie ihr Budget ausgaben, kostenlos geworden ist.

Feinabgestimmtes Deep Learning vs. Vision-LLM im Detail

Ein feinabgestimmter Extraktor kann bei einem einzigen unveränderten Layout mit hohem Volumen weiterhin gewinnen. Für die lange Reihe realer Rechnungen – unterschiedliche Lieferanten, Sprachen und Scanqualität – ist das Zero-Shot-Vision-LLM in der Praxis genauer und im Betrieb radikal günstiger. Weitere Muster für diese Art von Arbeitslast finden Sie im Anwendungsfall Datenextraktion.

Das vollständige Muster: Bild → schema-validiertes JSON

Alles Folgende läuft über Kunavos OpenAI-kompatiblen Endpunkt – verweisen Sie base_url auf https://api.kunavo.com/v1, und derselbe Code kann Claude oder GPT ansprechen, indem Sie eine Zeichenfolge ändern:

from openai import OpenAI
import base64, json

client = OpenAI(
    base_url="https://api.kunavo.com/v1",
    api_key="sk-kn-...",
)

SCHEMA = {
    "name": "invoice",
    "schema": {
        "type": "object",
        "properties": {
            "vendor_name":    {"type": "string"},
            "vendor_tax_id":  {"type": ["string", "null"]},
            "invoice_number": {"type": "string"},
            "invoice_date":   {"type": "string", "description": "ISO 8601"},
            "due_date":       {"type": ["string", "null"]},
            "currency":       {"type": "string", "description": "ISO 4217"},
            "line_items": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "description": {"type": "string"},
                        "quantity":    {"type": "number"},
                        "unit_price":  {"type": "number"},
                        "amount":      {"type": "number"},
                    },
                    "required": ["description", "amount"],
                },
            },
            "subtotal":  {"type": ["number", "null"]},
            "tax":       {"type": ["number", "null"]},
            "total":     {"type": "number"},
        },
        "required": ["vendor_name", "invoice_number", "invoice_date",
                     "currency", "line_items", "total"],
    },
}

def extract(path: str) -> dict:
    image_b64 = base64.b64encode(open(path, "rb").read()).decode()
    resp = client.chat.completions.create(
        model="claude-haiku-4-5",   # the cheapest capable model for clean invoices
        response_format={"type": "json_schema", "json_schema": SCHEMA},
        messages=[
            {"role": "system", "content":
                "Extract the invoice into the schema. Copy values exactly as "
                "printed; use null when a field is absent. Never invent data."},
            {"role": "user", "content": [
                {"type": "image_url",
                 "image_url": {"url": f"data:image/png;base64,{image_b64}"}},
            ]},
        ],
    )
    return json.loads(resp.choices[0].message.content)

inv = extract("invoice_0231.png")

# Cheap arithmetic guardrail: reject when the line items don't add up.
delta = abs(sum(li["amount"] for li in inv["line_items"])
            + (inv.get("tax") or 0) - inv["total"])
if delta > 0.02:
    raise ValueError(f"line items disagree with total by {delta:.2f}")

print(inv["vendor_name"], inv["total"], inv["currency"])

Drei Details leisten den größten Teil der Arbeit: das JSON-Schema in response_format (bei Claude kann das Modell nichts anderes ausgeben – siehe den Hinweis zu GPT in der unten verlinkten Referenz), die System-Prompt-Regel „Werte exakt kopieren; bei Fehlen null; niemals etwas erfinden“ (verhindert halluzinierte Steuer-IDs) und die Rechenprüfung – Einzelposten plus Steuer müssen der Gesamtsumme entsprechen, andernfalls wird das Dokument an ein stärkeres Modell oder einen Menschen weitergeleitet. Die Referenz zu Chat Completions beschreibt, was response_format bei jeder Modellfamilie erzwingt.

Dasselbe Schema als typisiertes Pydantic-Modell

Ein rohes JSON-Schema-Dictionary ist für einen Endpunkt in Ordnung und für zehn mühsam. In der Produktion definieren die meisten Teams das Schema einmal als Pydantic-Modell und leiten daraus sowohl die Einschränkung als auch das geparste Objekt ab, sodass Extraktor und restliche Codebasis niemals über die Struktur uneins sein können:

from pydantic import BaseModel, Field
from typing import Literal
from openai import OpenAI

client = OpenAI(base_url="https://api.kunavo.com/v1", api_key=KEY)

class LineItem(BaseModel):
    description: str
    quantity: float | None = None
    unit_price: float | None = None
    amount: float

class Invoice(BaseModel):
    vendor_name: str
    vendor_tax_id: str | None = None
    invoice_number: str
    invoice_date: str = Field(description="ISO 8601")
    currency: str = Field(description="ISO 4217")
    line_items: list[LineItem]
    tax: float | None = None
    total: float
    # A confidence field the model fills in itself is a cheap, surprisingly
    # reliable router: low self-reported confidence correlates well with the
    # documents a human should see.
    confidence: Literal["high", "medium", "low"]

resp = client.chat.completions.create(
    model="claude-haiku-4-5",
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "invoice", "schema": Invoice.model_json_schema()},
    },
    messages=[...],
)

invoice = Invoice.model_validate_json(resp.choices[0].message.content)

Hier lohnt es sich, zwei Dinge zu übernehmen. Felder vom Typ float | None statt float geben dem Modell eine zulässige Möglichkeit, „nicht vorhanden“ auszudrücken – ohne diese Möglichkeit zieht eine fehlende Steuerzeile stark dazu, eine Null zu erfinden. Und das selbst gemeldete Feld confidence kostet drei Ausgabetokens und routet überraschend gut; es ist nicht kalibriert, aber „niedrig“ ist ein zuverlässiges Signal dafür, dass ein Mensch prüfen sollte.

Zweistufiges Routing: Was tatsächlich in der Produktion läuft

Ein einziges Modell für jedes Dokument ist die falsche Struktur. Saubere gedruckte Rechnungen – die überwältigende Mehrheit – werden vom günstigsten verfügbaren Vision-Modell verarbeitet; die schwierigen Fälle (Handschrift, schlechte Scans, ungewöhnliche Layouts) rechtfertigen ein stärkeres Modell. Eskalieren Sie bei einem Validierungsfehler, nicht aufgrund einer Vermutung:

CHEAP, STRONG = "claude-haiku-4-5", "claude-sonnet-5"

def valid(inv: dict) -> bool:
    """Arithmetic is the guardrail no confidence score replaces."""
    items = sum(li["amount"] for li in inv["line_items"])
    return abs(items + (inv.get("tax") or 0) - inv["total"]) <= 0.02

def extract_routed(path: str) -> tuple[dict, str]:
    inv = extract(path, model=CHEAP)
    if valid(inv) and inv.get("confidence") != "low":
        return inv, CHEAP

    # Escalate: same prompt, same schema, stronger model. Only the failures
    # pay the higher rate, which is what keeps the blended cost near the
    # cheap tier's.
    inv = extract(path, model=STRONG)
    if not valid(inv):
        raise NeedsHumanReview(path, inv)
    return inv, STRONG

# Blended cost at a 90/10 split, per 10,000 invoices:
#   9,000 x $0.00248 + 1,000 x $0.00497
#   = $27.29

Die Rechenprüfung leistet die eigentliche Arbeit: Sie ist das einzige Signal, das unabhängig von der Selbsteinschätzung des Modells ist. Ein Dokument, dessen Einzelposten sich zur angegebenen Gesamtsumme addieren, ist fast nie in einer relevanten Weise falsch; eines, das die Prüfung nicht besteht, ist das stärkere Modell oder einen Menschen wert – unabhängig davon, was das Konfidenzfeld behauptet.

Kosten pro Rechnung nach Modell

Eine einseitige Rechnung entspricht etwa 1.800 Eingabetokens (als Bild gesendet) plus etwa 350 Ausgabetokens als JSON:

Die Preise stammen aktuell von der Preisseite (etwa 30 % unter den Listenpreisen der Anbieter), und fehlgeschlagene Anfragen werden nicht berechnet. Bei zweistufigem Routing – alles über Haiku, durch die Rechenprüfung erkannte Fehler werden an Sonnet eskaliert – liegen 10.000 Rechnungen pro Monat typischerweise unter $27.29.

Genauigkeit: Die Checkliste für den Produktionseinsatz

1. Schema zuerst. Kennzeichne wirklich erforderliche Felder als required und erlaube überall sonst null — ein erzwungener Wert führt zu Halluzinationen.
2. Sende das Bild, nicht den OCR-Text. Das Layout trägt Bedeutung (Spalten, Summenfelder); Vision-Modelle lesen es direkt. Weiche nur bei digital erzeugten PDFs auf Text aus, aus denen du eine saubere Textebene extrahieren kannst.
3. Validiere die Arithmetik im Code. Positionssummen + Steuer = Gesamtbetrag erkennt die meisten Extraktionsfehler kostenlos.
4. Eskalieren, nicht blind erneut versuchen. Fehler gehen mit dem enthaltenen Validierungsfehler im Prompt an Sonnet; anhaltende Fehler gehen in eine menschliche Warteschlange.
5. Die echten Grenzfälle per Few-Shot abdecken. Zwei oder drei Beispiele deiner schwierigsten Layouts (Gutschriften, mehrere Währungen) im System-Prompt sind besser als jede noch so umfangreiche Anweisungsoptimierung.

Über Rechnungen hinaus

Dasselbe schema-beschränkte Muster deckt Belege, Bestellungen, Lieferscheine, Zollformulare und Kontoauszüge ab — tausche das Schema aus, behalte die Leitplanken. Sieh dir den umfassenderen Anwendungsfall zur strukturierten Datenextraktion für RAG-nahe Muster oder den Leitfaden zur Kostenoptimierung für Routing-Strategien an, sobald das Volumen wächst. Ein Kunavo-Schlüssel deckt jede hier verwendete Modellstufe ab — kostenlos registrieren und einen Schlüssel erstellen, um das Snippet unverändert auszuführen.

Häufig gestellte Fragen