Zielgruppe & Rolle

Rolle: Technik / Entwickler & Support | Schritt: 2 von 5 der Verarbeitungspipeline

Extraktion

Nach Schritt 1 liegen E-Mail und Anhänge in S3 (mail/pending/). In diesem Schritt werden die Anhänge aus S3 geladen und in ein gemeinsames Zielformat (IncomingInvoice) überführt.

Vor der eigentlichen Extraktion wird je Anhang geprüft, ob eine strukturierte E-Rechnung vorliegt. Wenn das nicht klappt, greift der PDF-/OCR-Pfad.

Ziel des Schritts

Eine möglichst stabile Datenbasis für Belegprüfung und ERP-Anlage erzeugen.

Start aus S3 und Typentscheidung

• Für jeden Mail-Anhang wird der Inhalt aus S3 geladen.
• Zuerst wird eine E-Rechnungs-Extraktion (kosit-go) versucht.
• Nur wenn dieser Schritt nicht erfolgreich ist oder nicht zum Dateityp passt, wird auf PDF-Verarbeitung gewechselt.
• Nicht-PDF-Dateien ohne verwertbare E-Rechnungsstruktur werden als nicht verarbeitbar behandelt.

Damit werden strukturierte Quellen bevorzugt und klassische PDF/Scan-Fälle trotzdem verarbeitet.

E-Rechnung (XML)

• Die Extraktion erfolgt direkt über kosit-go (z. B. UBL, CII/ZUGFeRD).
• Belegtyp und Fachdaten stammen aus der strukturierten XML-Quelle (CDM).
• Die technische Regelprüfung (Schematron) liefert den Status für die E-Rechnungsvalidierung.
• Zusätzlich wird ein Sichtbeleg (Visualisierung als PDF) erzeugt und im S3-Kontext gespeichert.
• Falls die E-Rechnungs-Verarbeitung bei einem PDF fehlschlägt, wird automatisch auf den PDF-Pfad zurückgefallen.

Feldzuordnung

Für eine vollständige Übersicht der Zuordnung von E-Rechnungsfeldern zu microtech-Feldern siehe Feldzuordnung E-Rechnung zu microtech.

PDF/Scan (KI-gestützt)

• Digitale PDFs werden zuerst per Tika ausgelesen (ExtractText).
• Falls kein verwertbarer Text vorliegt, übernimmt ein Vision/OCR-Ansatz (ExtractInvoiceFromVision) die Erkennung direkt aus dem Dokument.
• Bei vorhandenem Text klassifiziert die KI den Beleg und extrahiert anschließend strukturierte Kopf- und Positionsdaten (ExtractInvoiceFromText).
• Die Klassifizierung erfolgt ausschließlich über UN/EDIFACT 1001 Codes (380, 381, 384, 389 etc.). Details siehe Dokumentenklassifizierung.
• Belege vom Typ 999 (Other / Nicht-relevant) werden nicht als Rechnung weiterverarbeitet.

Ergebnisartefakte je Verarbeitung

Für jeden verarbeiteten Anhang werden Artefakte in S3 abgelegt. Sie dokumentieren das Ergebnis der Extraktion und dienen als Übergabe an die Folgeschritte.

Wenn eine E-Mail mehrere Dokumente enthält und mindestens ein Dokument als Rechnung erkannt wird, werden alle zugehörigen Dokumente gemeinsam im Rechnungskontext abgelegt.

Wenn in der E-Mail keine Rechnung erkannt wird, wird die E-Mail sowohl in S3 als auch im E-Mail-Postfach in den Bereich Other bzw. Rejected verschoben.

Immer angelegt

IncomingInvoice (JSON)

Enthält das normalisierte Extraktionsergebnis (Kopf, Positionen, Beträge, Belegtyp) und ist die zentrale Eingabe für Enrichment, Prüfung und ERP-Anlage.

E-Rechnung (XML)

Artefakt	Beispielname (Eingangsbeleg rechnung20250101)	Zweck
Schematron-Status	rechnung20250101-schematron-status.json	Technischer Validierungsstatus der E-Rechnung
Sichtbeleg (PDF)	rechnung20250101-visualisierung.pdf	Lesbare Darstellung der strukturierten Rechnung

PDF/Scan

Artefakt	Beispielname (Eingangsbeleg rechnung20250101)	Zweck
Volltext (Tika)	rechnung20250101-volltext.txt	Grundlage für textbasierte Extraktion
OCR/Vision-Ergebnis	rechnung20250101-ocr.json	Ersatz, wenn kein verwertbarer Volltext vorliegt

---

Nächster technischer Schritt

Nach der Extraktion der Rohdaten folgt die Währungsumrechnung und Stammdaten-Anreicherung: Schritt 3: Währung und Enrichment | Siehe auch: Feldzuordnung E-Rechnung