Zurück zum Blog
Datenautomatisierung· Henrik Lippke

PDFs auslesen mit Claude: Rechnungen, Lieferscheine und Verträge als strukturierte Daten

Warum OCR-Vorlagen bei wechselnden Layouts scheitern und wie Claude Rechnungen, Lieferscheine und Verträge als geprüftes JSON in ERP, CRM oder Tabelle schreibt.

Rechnungen, Lieferscheine, Verträge: Die meisten davon kommen als PDF, ein guter Teil als Scan oder als Handyfoto aus dem Lager. Irgendjemand tippt die Werte ab. Das ist langsam, fehleranfällig und für die Leute, die es tun müssen, zermürbend. Mit Claude als Leser und n8n als Taktgeber lässt sich das zuverlässig automatisieren. Wir zeigen, worauf es dabei ankommt.

Warum klassische OCR-Vorlagen scheitern

Klassische Belegerkennung arbeitet mit Vorlagen: Für jeden Lieferanten wird festgelegt, an welcher Stelle Rechnungsnummer, Datum und Summe stehen. Das funktioniert, solange sich nichts ändert. Dann wechselt ein Lieferant sein Rechnungslayout, der nächste schickt eine zweite Seite mit Zusatzpositionen, der dritte ein schief eingescanntes Dokument. Jede Abweichung bedeutet eine neue Vorlage oder einen falschen Wert, der erst in der Buchhaltung auffällt.

Claude liest Dokumente anders. Das Modell versteht, was eine Rechnung ist, wo üblicherweise die Summe steht und dass "Gesamtbetrag", "Total" und "zu zahlen" dasselbe meinen. Es kommt mit Scans, Fotos und mehrseitigen PDFs zurecht und braucht keine Vorlage pro Lieferant. Der Preis dafür: Man muss dem Modell sehr genau sagen, was man zurückhaben will.

Erst das Schema, dann der Prompt

Der wichtigste Schritt passiert vor dem ersten Aufruf. Wir definieren ein JSON-Schema für das Ergebnis. Es legt fest, welche Felder es gibt, welchen Typ sie haben und was Pflicht ist. Claude bekommt dieses Schema mit und liefert ausschließlich Daten in dieser Form zurück.

{
  "document_type": "invoice",
  "supplier_name": "string",
  "supplier_vat_id": "string | null",
  "invoice_number": "string",
  "invoice_date": "YYYY-MM-DD",
  "po_number": "string | null",
  "net_total": "number",
  "vat_total": "number",
  "gross_total": "number",
  "currency": "EUR",
  "line_items": [
    { "description": "string", "quantity": "number", "unit_price": "number", "amount": "number" }
  ],
  "confidence": "number zwischen 0 und 1"
}

Das Schema zwingt zu Klarheit. Soll das Lieferdatum erfasst werden? Zahlungsziel? Skonto? Jedes Feld, das drinsteht, wird befüllt, jedes, das fehlt, geht verloren. Für Lieferscheine und Verträge gibt es eigene Schemata, oft mit einem Klassifikationsschritt davor, der zuerst entscheidet, um welchen Dokumenttyp es sich handelt.

Validierung: dem Modell nicht blind vertrauen

Ein Sprachmodell liest gut, aber es rechnet nicht zuverlässig und es kennt Ihre Stammdaten nicht. Deshalb prüft n8n jedes Ergebnis mit festen Regeln, bevor etwas weitergeht:

  • Netto plus Steuer ergibt brutto, auf den Cent. Die Summe der Positionen ergibt netto.
  • Die USt-IdNr. hat das richtige Format für das Land und stimmt mit dem Lieferantenstamm überein.
  • Die Bestellnummer existiert im ERP und gehört zu diesem Lieferanten.
  • Das Rechnungsdatum liegt nicht in der Zukunft und nicht Jahre zurück.
  • Die Rechnungsnummer ist für diesen Lieferanten noch nicht erfasst.

Diese Prüfungen sind deterministisch, kosten nichts und fangen die meisten Lesefehler ab. Rechnet eine Summe nicht auf, hat das Modell meist eine Zeile übersehen oder einen Punkt als Komma gelesen. Genau diese Fälle wollen Sie sehen, bevor sie im ERP landen.

Confidence und Prüfschlange

Claude gibt zu jeder Extraktion eine Einschätzung ab, wie sicher es sich ist, auf Wunsch auch pro Feld. Zusammen mit den Validierungsregeln ergibt das drei Wege:

  • Alle Prüfungen bestanden, hohe Confidence: Direkt weiter ins Zielsystem.
  • Prüfungen bestanden, aber niedrige Confidence oder ein unklares Feld: Ab in die Prüfschlange. Ein Mensch sieht das Dokument neben den extrahierten Werten, korrigiert und gibt frei.
  • Prüfung fehlgeschlagen: Ebenfalls Prüfschlange, mit dem konkreten Fehler als Hinweis.

Die Prüfschlange ist kein Zeichen, dass die Automatisierung nicht funktioniert. Sie ist der Ort, an dem die Fälle landen, die auch vorher jemand genau anschauen musste. Nur eben jetzt mit Vorarbeit.

Ins Zielsystem schreiben

Nach der Freigabe schreibt n8n die Daten dorthin, wo sie gebraucht werden. Rechnungen gehen als Eingangsbeleg ins ERP oder zu DATEV, Lieferscheine gleichen Wareneingänge gegen Bestellungen ab, Vertragsdaten wie Laufzeit, Kündigungsfrist und Konditionen landen im CRM oder in einer Vertragsdatenbank. Für den Anfang reicht oft eine Tabelle, die jemand im Blick hat.

Die Originaldatei wird mit abgelegt und mit der Extraktion verknüpft. Wer später eine Zahl anzweifelt, soll mit einem Klick den Beleg sehen.

Kosten, Datenschutz und Fehlerquote

Drei Fragen kommen in jedem Gespräch zu diesem Thema.

Was kostet das? Abgerechnet wird nach verarbeiteten Seiten, genauer gesagt nach Tokens. Eine einseitige Rechnung ist günstig, ein vierzigseitiger Vertrag nicht. Wir steuern das über die Modellwahl: Für Standardbelege reicht ein kleineres, schnelleres Modell, für komplexe Verträge nehmen wir das stärkste. Außerdem prüft der Workflow vorab Seitenzahl und Dateigröße und schickt nicht jeden Anhang ungesehen durch.

Welche Daten verlassen das Haus? Das Dokument selbst wird an die API übertragen. Das muss in der Auftragsverarbeitungsvereinbarung stehen und mit dem Datenschutzbeauftragten abgestimmt sein. Claude ist direkt über Anthropic sowie über Amazon Bedrock und Google Cloud verfügbar, beide bieten Regionen innerhalb der EU. Nach den kommerziellen API-Bedingungen werden Eingaben nicht zum Training verwendet. Lassen Sie den aktuellen Stand trotzdem von Ihrem Datenschutzbeauftragten prüfen. Wer zusätzlich Namen oder Kontonummern vor der Übertragung maskieren will, kann das in n8n tun, verliert damit aber oft die Information, die das Modell für die Zuordnung braucht.

Wie hoch ist die Fehlerquote? Ehrliche Antwort: Das hängt von Ihren Dokumenten ab. Saubere digitale PDFs von bekannten Lieferanten werden fast immer korrekt gelesen. Schlechte Scans, handschriftliche Ergänzungen und ungewöhnliche Layouts erzeugen mehr Fälle für die Prüfschlange. Was wir sagen können: Die Validierungsregeln fangen den Großteil der Lesefehler ab, bevor sie Schaden anrichten, und die verbleibende Fehlerquote liegt nach unserer Erfahrung unter der von manueller Erfassung. Messen Sie es an Ihren eigenen Belegen. Ein Testlauf mit einigen hundert Dokumenten aus dem letzten Quartal zeigt in wenigen Tagen, wo Sie stehen.

Fazit

PDF-Extraktion mit Claude funktioniert, wenn drei Dinge zusammenkommen: ein klares Schema, harte Validierungsregeln und eine Prüfschlange für den Rest. Dann wird aus dem Abtippen ein Kontrollieren, und das nur noch für die Fälle, die es brauchen.

Wenn Sie wissen wollen, wie das mit Ihren Belegen aussieht: Buchen Sie ein kostenloses 30-minütiges Erstgespräch unter /#kontakt.

  • Datenautomatisierung
  • Claude
  • PDF

Weitere Artikel

Welchen Prozess würden Sie als Erstes automatisieren?

30 Minuten, kein Pitch. Wir schauen gemeinsam, was sich lohnt, was ein Pilot kostet und wie schnell er laufen kann. Suchen Sie sich direkt einen Termin aus.

Lieber schriftlich?

E-Mail schreiben

Erstgespräch buchen · 30 Minuten

Kalender wird nicht angezeigt? Direkt öffnen: calendar.app.google