KI-Rechnungsverarbeitung mit Azure, .NET und Business Central
Architektur: Eingang, Extraktion und Freigabe strikt trennen
Eine Rechnung ist kein gewöhnlicher Chat-Prompt. Sie kann mehrere Seiten, Positionszeilen, unterschiedliche Mehrwertsteuersätze und handschriftliche Notizen enthalten. Baue deshalb eine nachvollziehbare Pipeline: Eingang → unverändertes Original speichern → Dokument prüfen → Text/OCR → strukturierte Extraktion → deterministische Validierung → Freigabe → ERP-Übergabe. Jede Stufe erhält einen nachvollziehbaren Status und kann unabhängig wiederholt werden.
1. Eingang und Dublettenprüfung
Vergib beim Eingang eine Dokument-ID und speichere das Original unverändert im DMS oder in einem gesicherten Blob Storage. Prüfe Dateityp, Größe und gegebenenfalls Schadsoftware, bevor das Dokument in die Verarbeitung gelangt. Ein SHA-256-Hash erkennt identische Dateien; eine fachliche Dublettenprüfung muss zusätzlich Lieferant, Rechnungsnummer, Rechnungsdatum und gegebenenfalls Mandant berücksichtigen. Zwei PDF-Dateien können dieselbe Rechnung enthalten, obwohl sich ihre Binärdateien unterscheiden.
2. Textauslesung: PDF-Textebene oder OCR?
Extrahiere zunächst eingebetteten PDF-Text und prüfe, ob Reihenfolge, Spalten und Sonderzeichen brauchbar sind. Bei Scans ist OCR notwendig. Eine Texterkennung allein versteht noch keine fachliche Rechnung: Die Zuordnung von Rechnungsnummer, Lieferant, Lieferdatum, Positionen und Steuerbeträgen ist ein gesonderter Schritt. Bei Tabellen muss auch die Zuordnung einer Menge zu ihrem Einzelpreis erhalten bleiben. Speichere Seitenreferenzen oder Fundstellen, damit Prüfer die Werte im Original nachschlagen können.
3. Strukturierter Ausgabevertrag
Definiere vor der Modellauswahl das Schema, das die spätere Buchungslogik benötigt. Ein minimalistisches Beispiel:
{
"supplierName": "Example Supplier GmbH",
"invoiceNumber": "INV-2026-1042",
"invoiceDate": "2026-10-01",
"currency": "EUR",
"netAmount": 100.00,
"taxAmount": 19.00,
"grossAmount": 119.00,
"lineItems": [
{ "description": "Service", "quantity": 1,
"unitPrice": 100.00, "netAmount": 100.00 }
]
}
Das Beispiel ist eine Beispielausgabe, kein tatsächlich erkanntes Dokument. Validiere diese Struktur in .NET gegen feste Datentypen und Regeln. Ein syntaktisch gültiges JSON ist nicht automatisch inhaltlich richtig. Fehlende oder unleserliche Angaben sollten ausdrücklich als unbekannt markiert werden, statt sie zu erfinden. Ein Hinweis wie „verwende nur Informationen aus dem Dokument“ hilft, ersetzt aber keine externe Validierung.
4. Deterministische Prüfungen in .NET
Wichtige Prüfregeln gehören in C# oder einen Fachservice, nicht ausschließlich ins Sprachmodell. Die folgende vereinfachte Funktion prüft nur die arithmetische Beziehung; Steuerermittlung, Rundungsregeln und Steuergruppen müssen zum jeweiligen Beleg und Land passen.
public static bool TotalsMatch(
decimal net, decimal tax, decimal gross,
decimal tolerance = 0.02m)
{
return Math.Abs((net + tax) - gross) <= tolerance;
}
Verwende für Geldwerte decimal statt binärer Gleitkommatypen. Prüfe zusätzlich Währung, zulässige Datumswerte, Mehrfachvorkommen der Rechnungsnummer, Lieferantenstammdaten, Bankdaten und Rechnungspositionen. Bei grenzüberschreitenden Belegen oder unterschiedlichen Steuersätzen darf ein einziges pauschales Steuermodell nicht unterstellt werden.
5. Lieferantenabgleich mit Business Central
Eine KI darf einen Kreditor vorschlagen, aber nicht allein aufgrund eines ähnlichen Namens verbindlich zuordnen. Nutze mehrere Signale wie Umsatzsteuer-ID, bekannte Rechnungsadresse und eine bereits freigegebene IBAN. Stimmen Informationen nicht überein, wird der Vorgang in eine Prüfliste verschoben. Bankdatenänderungen benötigen einen besonders strengen Freigabeprozess. Erst nach bestätigter Zuordnung entstehen Entwurfsdaten in Business Central; eine automatische Buchung sollte nur in klar definierten risikoarmen Fällen erlaubt sein.
6. Menschliche Prüfung sinnvoll organisieren
Zeige in einer Freigabemaske links das Original und rechts erkannte Felder mit Fundstellen und Unsicherheiten. Der Sachbearbeiter muss Werte korrigieren können. Speichere wer, wann und welche Felder geändert oder freigegeben hat. Trenne die Rollen Erfassen, Prüfen und Buchen, soweit die Unternehmensrichtlinien dies erfordern. Eine vom KI-Modell gelieferte „Confidence“ ist kein verlässlicher, allgemeingültiger Prozentwert für Korrektheit; kalibriere Schwellen anhand realer Testbelege.
7. Sicherheit, Datenschutz und Kosten
Rechnungen enthalten häufig personenbezogene und vertrauliche Daten. Übermittle an externe KI-Dienste nur erforderliche Inhalte, prüfe Auftragsverarbeitung und Datenregion und schütze gespeicherte Dateien durch geeignete Zugriffskontrollen. Erfasse pro Dokument Modellname, Version, Tokenverbrauch, Kosten, Laufzeit und Prüfergebnis, aber protokolliere keine vollständigen Beleginhalte oder Zugangsdaten. Berücksichtige OCR-, Speicher-, Modell-, Suchindex- und Betriebsaufwand getrennt.
8. Betrieb und Wiederanlauf
Verarbeite Dokumente asynchron über eine Queue mit eindeutiger Job-ID. Bei einem Timeout darf dieselbe Rechnung nicht mehrfach in BC angelegt werden: Führe einen persistenten Idempotenzschlüssel aus Mandant, Quelle und Rechnungskennung. Unterscheide vorübergehende technische Fehler von fachlichen Validierungsfehlern. Nach einem Modellupdate sollten Regressionstests mit einer festgehaltenen Sammlung anonymisierter Belege laufen.
9. Praxistests vor dem Livegang
- Mehrseitige Rechnung mit Positionssummen und zwei Steuersätzen.
- Schlechte Scanqualität und verdrehte Seiten.
- Unbekannter Lieferant und geänderte Bankverbindung.
- Doppelte Rechnung mit abweichender PDF-Datei.
- Fremdwährung, Gutschrift und negatives Vorzeichen.
- Abbruch zwischen erfolgreicher Extraktion und BC-Übergabe.
- Unplausible Summen, fehlende Pflichtfelder und nicht lesbare Werte.
Fazit: Die Extraktion ist nur ein Baustein. Erst ein System aus Quellenbezug, nachvollziehbaren Prüfregeln, Freigabe und fehlertoleranter ERP-Übergabe macht die KI-Unterstützung produktiv nutzbar.
Kommentare (0)
Noch keine Kommentare. Schreibe den ersten Beitrag zur Diskussion.