Von der Stromrechnung zur verständlichen KI-Erklärung

Eine Strom- oder Gasrechnung enthält alles, was Kundinnen und Kunden wissen müssten, und doch kann sie kaum jemand lesen. Zählerstände, Tarifbestandteile, Grundpreise, Steuern, Abrechnungszeiträume und Fußnoten verteilen sich über Tabellenseiten, die für Regulierungsbehörden gemacht wurden, nicht für Menschen.

Also taucht in vielen Produkt-Backlogs die naheliegende Idee auf: Rechnung hochladen, KI erklären lassen. Die naheliegende Umsetzung liest die Stromrechnung per OCR und klebt den Rohtext ins Sprachmodell. Sie liefert in einer Woche eine Demo und in Produktion ein Haftungsrisiko.

Dieser Artikel beschreibt die Architektur, die wir stattdessen empfehlen: eine API-first Pipeline für Dokumentanalyse, in der die Rechnung zuerst in geprüfte, nachvollziehbare strukturierte Daten überführt wird, und das Sprachmodell nur Werte erklären darf, die bereits geprüft wurden. Das gilt für Strom, Gas, Wasser und Fernwärme, und für jedes Produkt, das Dokumente erklären statt sie nur anzuzeigen.

Warum niemand seine Stromrechnung liest

Selbst wenn jede Zahl technisch auf der Seite steht, bleiben ganz normale Fragen offen:

Klassische PDF-Portale zeigen die Rechnung nur an. Ein System zur Dokumentanalyse macht daraus etwas, das Menschen verstehen, hinterfragen und nutzen können. Diese Umwandlung ist ein Engineering-Problem, kein Prompt.

Produkterlebnis: Rechnung hochladen, geprüfte Erklärung erhalten

Aus Nutzersicht bleibt es bewusst einfach. Sie öffnen App oder Portal und laden ein PDF vom Anbieter, ein Foto einer Papierrechnung, einen Scan oder mehrere Smartphone-Seiten hoch. Das System arbeitet dann in neun Schritten:

Bei den Folgefragen entscheidet sich Vertrauen. „Warum ist meine Rechnung gestiegen, obwohl mein Verbrauch sank?“ „Wie viel könnte ich sparen, wenn ich den Verbrauch um 10 % senke?“ „Passt der Zählerstand zum Abrechnungszeitraum?“ Die KI muss aus den geprüften Daten genau dieses Dokuments antworten, nicht mit einer allgemeinen Phrase.

Architektur: OCR-zu-LLM-Pipeline mit spezialisierten Schichten

Die App oder das Portal bleibt schlank: Dokumente auswählen, hochladen, Ergebnisse anzeigen, Fragen senden. Alles andere liegt hinter der API, als Abfolge spezialisierter Schichten:

Dokument
├── Anbieter
├── Kunden- und Kontoreferenzen
├── Abrechnungszeitraum
├── Rechnungstyp
├── Zählerinformationen
├── Vorheriger und aktueller Stand
├── Verbrauch + Maßeinheit
├── Tarifbestandteile
├── Fixe / variable Kosten
├── Steuern, Gebühren, Rabatte, Gutschriften
├── Zahlungen
├── Gesamtbetrag
└── Fälligkeitsdatum

Validierung: die Vertrauensschicht zwischen OCR und LLM

OCR und KI-Extraktion machen Fehler. Ein Produktionssystem behandelt deshalb keinen extrahierten Wert als korrekt, bevor er geprüft wurde. Die Validierung fragt:

Jedes extrahierte Feld trägt Wert, Quellseite und Position, Extraktionsmethode, Konfidenzwert, Prüfergebnisse und ggf. Alternativen. Werte mit niedriger Konfidenz werden markiert. Nutzer bestätigen, statt dass das System still rät.

Zuerst deterministisch berechnen. Dann formuliert das LLM.

Mehrere Funktionen gehören in gewöhnliche, testbare Software, nie ins Modell: Verbrauchsunterschiede, Summenprüfung, Preis je Einheit, Periodenvergleiche, Fix- vs. variable Anteile, Schwellen für Auffälligkeiten, Mittelwerte, Daten für Diagramme und Was-wäre-wenn-Szenarien. Das Sprachmodell erhält diese geprüften Ergebnisse als Kontext und formuliert sie in Sprache.

Hier ist diese Idee als Arbeitsbeispiel: Das Szenario unten wird von deterministischem Code für einen typischen 2-Personen-Haushalt (2.550 kWh/Jahr zu 0,31 €/kWh plus typischem Grundpreis von 168 €/Jahr → 958,50 €) berechnet, genau so, wie das Berechnungsmodul es tun würde:

Fachwissen bei Bedarf mit RAG

Retrieval-Augmented Generation (RAG) liefert, was die Rechnung selbst nicht kann: Erklärungen zu Abrechnungsbegriffen, Tarifregeln, Einheiten, regionalen Vorgaben, Effizienzhinweisen und freigegebenen Empfehlungsvorlagen. Das Modell erhält nur, was zur aktuellen Frage passt. Ein faktenbasierter Antwortkontext kombiniert fünf Dinge:

Was Nutzerinnen und Nutzer zurückbekommen

Die Erklärungsschicht macht aus dem strukturierten Ergebnis verständliche Sprache: eine knappe Zusammenfassung (Zeitraum, Gesamtbetrag, Verbrauch, Änderungen, Frist), eine klare Aufschlüsselung jeder Position, auffällige Befunde wie ungewöhnlicher Verbrauch, höherer Einheitspreis, geschätzte Zählerstände oder doppelte Positionen sowie vorgeschlagene Anschlussfragen wie „Warum hat sich mein Einheitspreis geändert?“ oder „Zeig mir, welche Kosten ich beeinflussen kann.“

Entscheidend: Die API liefert Text und maschinenlesbare Daten für Visualisierungen. Das Sprachmodell zeichnet kein Diagramm; das Backend liefert strukturierte Chart-Definitionen (Kostenaufschlüsselung, Fix vs. variabel, Periodenvergleich, Zählerstandsverlauf, Einsparpotenzial), die jeder Client im eigenen Design System darstellt:

{
  "summary": {
    "billing_period": "2026-01-01 to 2026-03-31",
    "total_amount": 428.50,
    "currency": "EUR",
    "consumption": 1240,
    "unit": "kWh"
  },
  "explanation": {
    "headline": "Ihr Gesamtbetrag stieg vor allem
                 wegen eines höheren Einheitspreises.",
    "sections": []
  },
  "visualizations": [
    { "type": "cost_breakdown",
      "title": "So setzt sich Ihr Gesamtbetrag zusammen",
      "data": [] }
  ],
  "warnings": [],
  "suggested_questions": []
}

Folgefragen ohne erneutes Verarbeiten

Nach der ersten Analyse läuft das Gespräch gegen das bereits strukturierte Dokument. Das PDF wird nie zweimal gelesen. Eine Frage holt die geprüften Rechnungsdaten, die relevanten Berechnungsergebnisse und das passende Fachwissen und erzeugt eine faktenbasierte Antwort mit Quellen und Konfidenz.

Sparhinweise, die sich begründen lassen

Empfehlungen sind nur dann vertrauenswürdig, wenn sie an Belege gebunden sind. Das System unterscheidet drei Arten:

Jede Empfehlung nennt, warum sie kommt, welche Rechnungsinformationen sie stützen, ob die Ersparnis gemessen oder geschätzt ist und welche Annahmen gelten. Entscheidungshilfe, kein unsicherer Rat als Garantie.

API für Dokumentanalyse, kein einmaliges Feature

Das Backend ist ein wiederverwendbarer Service, kein Feature, das an eine App gebunden ist. Eine kleine, langweilige, versionierte Oberfläche:

POST    /v1/documents
GET     /v1/jobs/{job_id}
GET     /v1/documents/{document_id}
GET     /v1/documents/{document_id}/analysis
POST    /v1/documents/{document_id}/questions
DELETE  /v1/documents/{document_id}

Darum herum: versionierte Schemas, Idempotenzschlüssel, asynchrone Jobs, Webhooks, Mandantentrennung, Nutzungsstatistik, Audit-Logs, konfigurierbare Aufbewahrung, Löschanfragen, Sprachauswahl und anbieterspezifische Adapter. Genau das lässt eine Kernplattform viele Rechnungstypen und Märkte bedienen.

Datenschutz, Sicherheit und verantwortungsvolle KI

Strom- und Gasrechnungen enthalten Namen, Adressen, Kontonummern, Zählernummern, Zahlungsdaten und Verbrauchshistorien. Datenschutz gehört in die Architektur von Anfang an, nicht als Review am Ende.

Jede Stufe unabhängig testen

Eine Pipeline ist nur so vertrauenswürdig wie ihre schwächste Stufe, deshalb wird jede für sich bewertet:

Das Produkt ist die Pipeline

Das wertvolle Produkt ist weder die OCR-Engine noch der Chatbot. Es ist die vollständige, kontrollierte Pipeline dazwischen: eine sichere API, die ein unstrukturiertes Dokument in geprüfte Daten, zuverlässige Berechnungen, verständliche Erklärungen, nützliche Visualisierungen und begründete Empfehlungen verwandelt.

Genau diese Architektur erlaubt es Organisationen, Dokumentanalyse in bestehende Apps oder Portale zu bringen, ohne alles neu zu bauen. Das Frontend behält die Kundenerfahrung; das Backend liefert Intelligenz, Vertrauen, Sicherheit und Skalierbarkeit. Solche Backends zu entwerfen und umzusetzen, mit Mobile-Produkten, Cloud-Plattformen, strukturierten Daten und verantwortungsvoller KI als produktionsreifem Service, ist genau die Art System, die wir bauen.