8 Stunden pro Woche zurück: LLM-Beleg-Klassifikation für eine süddeutsche Steuerkanzlei
Anonymisiert: Mandant- und Standortdetails sind geändert, Zahlen-Bandbreiten sind real und in der NLA-Datenbasis dokumentiert.
Das Problem
Eine süddeutsche Steuerkanzlei mit 12 Mitarbeitenden hatte ein konkretes Skalierungsproblem: 8 Stunden pro Woche manuelle Beleg-Klassifikation. Eingehende PDFs aus den verschiedenen Mandanten — Rechnungen, Spesenbelege, Mahnungen, Quittungen, Steuerbescheide — wurden von der Sekretariats-Position einzeln geprüft und der jeweils richtigen Kategorie zugeordnet.
Der jährliche Personalaufwand allein für diese Tätigkeit lag bei etwa 27.000 €. Mit jedem neu hinzugewonnenen Mandanten wuchs das Volumen, ohne dass die Sekretariats-Kapazität mitwuchs. Steuerbescheid-Phasen mit erhöhtem Aufkommen brachten regelmäßig Überstunden — und Frustration.
Die Hypothese
Ein LLM mit klar definierten Klassen und Few-Shot-Beispielen sollte den Großteil der Routine-Klassifikation übernehmen können. Die Frage war:
- Wie hoch ist die Treffergenauigkeit auf realen Kanzlei-Daten?
- Wie sieht ein realistischer Validation-Layer aus, damit das System keine falschen Auto-Aktionen produziert?
- Welcher DSGVO-Pfad ist für Mandantendaten angemessen?
POC-Setup (6 Arbeitstage)
- LLM: Anthropic Claude (Sonnet 4) mit Structured Output (JSON-Schema mit klaren Klassen-Enums)
- Few-Shot-Anker: 50 Beispiel-Belege mit korrekter Klassifikation aus dem Kanzlei-Archiv
- DSGVO-Pfad: EU-Region (AWS Frankfurt) plus AVV-Vertrag mit Anthropic
- Test-Set: 200 separate Belege, die nicht im Few-Shot-Training waren
- Confidence-Capture: jeder LLM-Output enthielt einen Selbst-Bewertungs-Score
Die ersten 3 Arbeitstage gingen in Setup und Datenanalyse, die nächsten 2 Tage in Iteration der Klassen-Definitionen und der Few-Shot-Auswahl, der letzte Tag in Live-Demo plus Architektur-Diskussion mit dem Kanzleiinhaber.
POC-Ergebnis
Wichtig: das Resultat war besser als die initiale Hypothese, weil die Kanzlei-Belege relativ standardisierte Layouts hatten. Bei einem anderen Mandanten mit unstrukturierteren Eingangsdokumenten wären niedrigere Treffergenauigkeiten realistisch — und würden im POC ehrlich gemessen.
Implementation (4 Wochen)
Auf Basis der POC-Ergebnisse wurde die Vollintegration entschieden:
- Integration ins bestehende DMS via REST-API mit Webhook-Trigger
- Confidence-Threshold-Routing: Score > 0,85 = Auto-Klassifikation, < 0,85 = Human-Review
- Review-Dashboard für die 13 Prozent Edge-Cases mit Ein-Klick-Korrektur
- Logging und Audit-Trail pro Beleg für 10-Jahres-DSGVO-Anforderungen (Eingangs-Hash, LLM-Antwort, Confidence, finale Klasse, eventuelle menschliche Korrektur)
- Wochen-Reporting mit Treffergenauigkeit-Metriken zur kontinuierlichen Prüfung
Investment: 7.000 € POC plus 18.000 € Implementation einmalig, plus etwa 30–50 € pro Monat laufende API-Kosten.
Architektur (vereinfacht)
Eingang DMS
↓
Webhook
↓
Klassifikations-Service
↓
Pre-Processing (PDF → Text + Bild-Extract)
↓
Anthropic Claude API (EU-Region) + Structured Output
↓
Confidence-Validation (Schema-Check + Score)
↓
— Score > 0,85 → Auto-Klassifikation → DMS
— Score < 0,85 → Human-Review-Queue
↓
Audit-Log (Eingangs-Hash, LLM-Antwort, Confidence, Output, ggf. Korrektur)Was wir gelernt haben
Drei IP-Bausteine aus diesem Mandat sind in unsere Default-Architektur eingeflossen:
Werkzeug ungleich Handwerk
Das Klassifikations-Werkzeug ist Claude. Das Handwerk — wann eine Mahnung wichtig ist, wann ein Spesenbeleg nachgefragt werden muss, welche Klasse ein neuer Mandant verlangt — bleibt bei der Steuerberaterin. Der Agent verschiebt den Engpass von Routine-Klassifikation zu echter Beratungsarbeit. Das ist der Punkt.
Validation-Layer ist nicht optional
87 Prozent Treffer klingen gut, aber 13 Prozent Fehler bei 200 Belegen pro Woche sind 26 falsche Klassifikationen pro Woche. Ein Confidence-Threshold mit menschlicher Review ist kein Add-on, sondern der eigentliche Sicherheits-Mechanismus, der das System produktiv-tauglich macht. Wir bauen Validation-Layer als Pflicht, nicht als Option.
DSGVO-Pattern: EU-Region plus AVV als Default
Für diesen Use-Case (interne Beleg-Klassifikation, keine Mandanten-Identifikatoren in den Prompts) war EU-Region mit AVV ausreichend. Für Use-Cases mit identifizierenden Mandanten-Daten in den Prompts hätten wir zu einem On-Premise-Setup oder einer Anonymisierungs-Schicht gewechselt — die Wahl ist immer Use-Case-spezifisch.
Weitere LLM-Anwendungen in Steuerkanzleien
Beleg-Klassifikation ist der naheliegendste Einstiegs-Use-Case für LLMs in Steuerkanzleien, weil die Datenstruktur sauber und der Workflow klar abgegrenzt ist. Aus der Beratungspraxis sehen wir aber fünf weitere Anwendungsfelder, in denen Steuerkanzleien LLM-gestützte Automatisierung mit hohem ROI einsetzen:
- E-Mail-Triage: Eingehende Mandanten-E-Mails werden klassifiziert (Anfrage / Frist / Dokument-Lieferung / Beschwerde) und automatisch dem zuständigen Sachbearbeiter zugewiesen. Spart 3–5 Stunden pro Woche im Sekretariat. Setup ähnlich wie Beleg-Klassifikation, mit anderen Klassen.
- Mandanten-Onboarding-Vorbereitung: Aus eingereichten Unterlagen extrahiert der LLM strukturiert die nötigen Stammdaten (Rechtsform, USt-Pflicht, Branche, Vorjahres-Bandbreiten). Die Kanzleistunde mit der neuen Mandantin startet damit nicht bei null, sondern bei einer vorbereiteten Akte.
- Recherche-Assistenz fuer Steuerberater: Konkrete Frage zu BFH-Rechtsprechung, einer §-Verschiebung im neuen JStG oder einer DBA-Auslegung. Ein RAG-System mit aktuellen Steuer-Quellen (NWB-Datenbank, Bundesfinanzministerium-Schreiben) liefert eine Erstauskunft mit Quellen-Citation, die der Berater dann fachlich prüft. Achtung: nie als Letztinstanz, immer als Zuarbeit.
- Mandanten-Reporting-Generierung: Quartalsberichte, GuV-Kommentare, Liquiditäts-Hinweise — aus den Buchungsdaten und einem Sprach-Template generiert der LLM Erstentwürfe, die der Berater überarbeitet. Spart bei einer Kanzlei mit 40 GmbH-Mandaten ~12 Stunden pro Quartal.
- Fristüberwachung mit semantischer Prüfung: Klassische Frist-Tools triggern auf Datums-Felder. Ein LLM-gestützter Layer erkennt zusätzlich Frist-Hinweise, die im Fließtext einer Behörden-E-Mail oder eines Mandanten-Schreibens stehen („bis zum Monatsende…“). Reduziert das Risiko verpasster Fristen.
Das gemeinsame Muster: LLMs in der Steuerkanzlei ersetzen nicht die Beratung — sie reduzieren die Routine-Last, die der Beratung im Weg steht. Die Beraterin macht weniger Klassifikation, mehr Mandanten-Gespräch. Der Engpass verschiebt sich von Sekretariat-Stunden auf Beratungs-Verfügbarkeit, was die richtige Richtung ist.
Die DSGVO-Anforderungen sind in allen fünf Fällen vergleichbar: EU-Region-Hosting, AVV mit dem LLM-Anbieter, Anonymisierung wo möglich, Audit-Trail für 10 Jahre. Die [Detail-Pfade für DSGVO-konforme KI-Integration](/blog/dsgvo-konforme-ki-integration-2026/) sind im separaten Artikel beschrieben — sie gelten generisch für alle LLM-Anwendungen in der Kanzlei, nicht nur für diesen Klassifikations-Case.
Der konkrete Reifegrad pro Kanzlei ist hochgradig unterschiedlich. Manche Mandanten haben bereits ein modernes DMS und brauchen nur den Klassifikations-Layer. Andere arbeiten noch teilweise papierbasiert — dort beginnt die LLM-Roadmap mit dem Schritt davor (Eingangs-Digitalisierung). Die Reihenfolge ist immer: erst stabiler Datenfluss, dann KI-Layer obendrauf.
Häufige Fragen
Wie lange dauert ein LLM-POC realistisch?
Ein klar abgegrenzter LLM-POC dauert bei New Life Digital 5 bis 10 Arbeitstage. In dieser Zeit werden Datenproben analysiert, Prompt-Engineering und Few-Shot-Anker erstellt, das System mit Structured Output gebaut, und die Ergebnisse mit echten Daten validiert. Am Ende steht eine Live-Demo, kein Mockup. Der konkrete Steuerkanzlei-Case lief 6 Arbeitstage — schneller als die Range-Obergrenze, weil die Datenlage außergewöhnlich sauber war.
Was kostet ein LLM-Klassifikations-Setup im Mittelstand?
Der POC liegt bei 7.000–10.000 € als Festpreis (5–10 Arbeitstage). Die volle Implementation mit Audit-Trail, Confidence-basiertem Routing und DMS-Integration bewegt sich bei 18.000–25.000 € einmalig. Laufende Kosten sind primär die LLM-API-Kosten — bei dem Steuerkanzlei-Case 0,003–0,005 € pro klassifiziertem Beleg über Anthropic Claude. Bei 200 Belegen pro Woche sind das etwa 30–50 € API-Kosten pro Monat.
Wie hoch ist die Treffergenauigkeit von Claude bei Beleg-Klassifikation?
Im konkreten Case 87 Prozent korrekte Klassifikation auf einem Test-Set von 200 Belegen. Die übrigen 13 Prozent waren Edge-Cases: handschriftliche Quittungen, fremdsprachige Belege, ungewöhnliche Layouts. Diese werden über einen Confidence-Threshold (Score < 0,85) automatisch in eine menschliche Review-Queue geroutet. Wichtig: 87 Prozent ist nicht „die Genauigkeit von Claude" — sondern die Genauigkeit dieses Setups bei diesem Kanzlei-Datenmix. Andere Kanzleien mit anderem Beleg-Mix können höher oder niedriger landen, was wir im POC ehrlich messen.
Verwandte Themen
- KI-Integration Mannheim — lokale Vor-Ort-Discovery
- ChatGPT-Integration für Unternehmen — Multi-Vendor-Strategie und DSGVO-Decision-Matrix
- AI-Agenten für den Mittelstand — n8n vs. Custom-Builds
- Pillar: KI im Mittelstand
- DSGVO-konforme KI-Integration im Detail
Ähnliches Problem? POC in 5–10 Tagen.
Wenn Sie einen klar abgegrenzten Klassifikations- oder Routine-Schmerzpunkt haben und wissen wollen, ob ein POC sich lohnt: 30-Min-Strategiegespräch ist der Einstieg.