Auf dieser Seite
- BCC-Workflow: Wie eine Mail den Prozess startet
- Drei Eingangsformate: Erkennung und Parser-Hierarchie
- XRechnung – reines XML in zwei Syntaxen
- ZUGFeRD / Factur-X – hybrides PDF/A-3
- PDF ohne strukturierten Kern
- Feld-Extraktion: was aus dem Dokument gezogen wird
- Fallback-Logik: wenn BT-9 fehlt
- Dublettenschutz und Statusführung
- Datenfluss in den Forecast
- Migrationspfad: vom Postfach zur API- oder ERP-Schnittstelle
- Was der Dienst nicht übernimmt
Dieser Artikel richtet sich an ERP-Verantwortliche, IT-Berater und Steuerberater, die genau verstehen wollen, wie der BCC-Mechanismus technisch arbeitet: Welche Formate werden erkannt, welche Felder werden extrahiert, wie greift die Fallback-Logik bei fehlenden Pflichtfeldern, wie ist Dublettenschutz implementiert, und wie sieht der Migrationspfad von der Postfach-Lösung zu einer direkten API- oder ERP-Schnittstelle aus.
Den Überblick ohne Technikjargon – für Buchhalter und kaufmännische Leitung – gibt es unter Ausgangsrechnungen per BCC erfassen. Die Funktionsweise des BCC-Einstiegs und der direkte Weg in die Liquiditätsvorschau sind auf der Angebots-Übersicht zusammengefasst.
BCC-Workflow: Wie eine Mail den Prozess startet
Jeder Mandant erhält beim Onboarding eine individuelle SMTP-Eingangsadresse. Sobald eine Ausgangsrechnung an diese Adresse als BCC (oder Forward) gesendet wird, nimmt der Dienst die Nachricht entgegen und startet die Verarbeitungspipeline. Das Konzept ist von der Empfängerseite her betrachtet identisch mit dem, was das BMF für den Empfang von E-Rechnungen per E-Mail-Postfach als regelkonform bestätigt – nur dass hier der Aussteller die Kopie schickt, nicht der Empfänger eine Rechnung erhält.
Der Dienst verarbeitet eingehende Nachrichten als MIME-Multipart-Dokument und geht dabei systematisch vor:
- Anhang-Inventur: Alle Anhänge werden nach MIME-Typ und Dateiendung klassifiziert.
- Format-Priorisierung: Liegt ein strukturierter XML-Anhang vor (Typ
application/xml,text/xmloder Dateiendung.xml), wird er vorrangig verarbeitet. Liegt ein PDF-Anhang vor, wird der PDF-Kern auf ein eingebettetes XML-Attachment geprüft (ZUGFeRD/Factur-X). Erst wenn kein strukturierter Kern gefunden wird, greift OCR auf dem PDF. - Body wird ignoriert: Der Mailtext-Body enthält keine strukturierten Rechnungsdaten und wird nicht in den Forecast-Datenfluss eingespeist.
Drei Eingangsformate: Erkennung und Parser-Hierarchie
XRechnung – reines XML in zwei Syntaxen
XRechnung ist die deutsche CIUS (Core Invoice Usage Specification) zur europäischen Norm EN 16931 und implementiert die EU-Richtlinie 2014/55/EU. Die Norm schreibt zwei gleichwertige XML-Syntaxen vor:
- UBL 2.1 (ISO/IEC 19845): Wurzelelement
<ubl:Invoice>, Namespaceurn:oasis:names:specification:ubl:schema:xsd:Invoice-2. Zahlungsfelder liegen untercac:PaymentTerms(BT-20) undcac:PaymentMeans/cbc:PaymentDueDate(BT-9). - UN/CEFACT Cross Industry Invoice (CII): Wurzelelement
<rsm:CrossIndustryInvoice>. BT-9 steckt unterram:SpecifiedTradePaymentTerms/ram:DueDateDateTime, BT-20 unterram:SpecifiedTradePaymentTerms/ram:Description.
Der Dienst erkennt die verwendete Syntax am Namespace-Deklaration im Wurzelelement und wählt den entsprechenden Parser-Pfad. Beide Pfade liefern dasselbe normalisierte Datenmodell für den Forecast-Datenfluss.
Aktuelle XRechnung-Version ist 3.0.2 (Bundle 2025-03-21, basierend auf der seit 1. Februar 2024 gültigen CIUS 3.0). Die technische Dokumentation und Validierungsartefakte stellt die KoSIT bereit.
ZUGFeRD / Factur-X – hybrides PDF/A-3
ZUGFeRD (aktuelle Version 2.4, in Kraft seit 15. Januar 2026, harmonisiert mit Factur-X 1.08) bettet eine UN/CEFACT-CII-XML-Datei direkt in einen PDF/A-3-Container ein. Der Standard nutzt die Attachment-Fähigkeit von PDF/A-3 (ISO 19005-3): Das XML-Attachment trägt den Dateinamen factur-x.xml und ist per XMP-Metadaten deklariert (fx:DocumentType, fx:ConformanceLevel, fx:Version).
ZUGFeRD kennt sechs Profile mit steigendem Datenreichtum:
| Profil | Positionsdaten | BT-9 / BT-20 enthalten | Typischer Einsatz |
|---|---|---|---|
| MINIMUM | Nein | Nein | Gut-/Bestätigungsbelege |
| BASIC WL | Nein | Bedingt | Einfache Rechnungen ohne Positionsdetail |
| BASIC | Ja | Bedingt | Standard B2B-Rechnung |
| EN 16931 | Ja | Bedingt | Volle EN-16931-Konformität |
| EXTENDED | Ja | Bedingt | Branchenspezifische Erweiterungen |
| XRECHNUNG | Ja | Bedingt | Identisch mit XRechnung CIUS |
Der Dienst liest das fx:ConformanceLevel aus den XMP-Metadaten, wählt das entsprechende Parsing-Schema und extrahiert die CII-XML-Payload. Die visuelle PDF-Darstellung wird dabei nicht verarbeitet.
PDF ohne strukturierten Kern
Liegt ein PDF-Anhang ohne eingebettetes XML vor – also eine klassische, nicht strukturierte Rechnung –, greift eine OCR-gestützte Extraktion. Erkannt werden Fälligkeitsdatum, Rechnungsdatum, Rechnungsnummer und Bruttobetrag. Die Felderkennungsqualität ist formatabhängig und grundsätzlich geringer als bei maschinenlesbaren Formaten. Fehlende oder unlesbare Felder werden mit dem konfigurierten Fallback aufgefüllt (siehe unten).
Feld-Extraktion: was aus dem Dokument gezogen wird
| BT-Feld | Bezeichnung (EN 16931) | Pflicht laut Norm | Verwendung im Dienst |
|---|---|---|---|
| BT-1 | Rechnungsnummer | Ja | Primärschlüssel für Dublettenerkennung |
| BT-2 | Ausstellungsdatum | Ja | Fallback-Basis für Fälligkeitsberechnung |
| BT-5 | Währung | Ja | Betragsnormalisierung |
| BT-9 | Fälligkeitsdatum | Bedingt | Direktes Signal für Forecast; s. Fallback unten |
| BT-20 | Zahlungsbedingungen | Bedingt | Freitextfeld, ggf. Zahlungsziel ableitbar |
| BT-41 | Name des Verkäufers | Ja | Debitor-Identifikation (Aussteller = eigenes Unternehmen) |
| BT-44 | Name des Käufers | Ja | Debitor-Stammdaten-Abgleich |
| BT-106 | Rechnungsbetrag netto | Ja | Forecast-Betrag |
| BT-112 | Gesamtbetrag brutto | Ja | Forecast-Betrag (alternativ) |
Wichtiger Hinweis zur Norm: BT-9 und BT-20 sind laut EN 16931 bedingt verpflichtend – nicht absolut. Die Business Rules der Norm verlangen, dass eine Rechnung mit zu zahlendem Betrag entweder ein Fälligkeitsdatum (BT-9) oder Zahlungsbedingungen (BT-20) enthalten muss, aus denen das Datum ableitbar ist. In der Praxis fehlen beide Felder dennoch regelmäßig – insbesondere bei PDFs und bei ZUGFeRD-Rechnungen im MINIMUM-Profil.
Fallback-Logik: wenn BT-9 fehlt
Enthält ein Dokument kein auswertbares Fälligkeitsdatum, greift der Dienst auf eine zweistufige Fallback-Kette zurück:
Stufe 1 – BT-20 auswerten: Enthält das Freitextfeld BT-20 eine parsbare Zahlungszielangabe (z. B. „Zahlbar innerhalb von 30 Tagen"), wird das Fälligkeitsdatum aus BT-2 (Ausstellungsdatum) plus dem extrahierten Zahlungsziel berechnet.
Stufe 2 – Standard-Zahlungsziel aus dem Debitor-Stamm: Lässt sich aus BT-20 kein Zahlungsziel ableiten – oder fehlt auch BT-20 –, wird das im Dienst pro Debitor konfigurierbare Standard-Zahlungsziel herangezogen. Dieses Zahlungsziel kann mandantenweit oder je Kunde individuell hinterlegt werden. Das Ergebnis ist BT-2 + Standard-Zahlungsziel = berechnetes Fälligkeitsdatum.
Das auf diesem Weg berechnete Datum wird im Forecast als „geschätzt" markiert und kann vom Nutzer nachträglich korrigiert werden. Eine Markierung in der Benutzeroberfläche macht transparent, welche Positionen auf echten BT-9-Werten basieren und welche auf dem Fallback.
Dublettenschutz und Statusführung
Eine Ausgangsrechnung, die zweimal per BCC eingeht – etwa weil die Rechnung an mehrere Empfänger versendet wurde –, darf nicht doppelt im Forecast landen. Der Dienst identifiziert Dubletten über den kombinierten Schlüssel aus:
- BT-1 (Rechnungsnummer) – normalisiert auf Groß-/Kleinschreibung und führende Nullen
- BT-41 (Name des Ausstellers) – eigene Mandanten-ID (da der Aussteller immer das eigene Unternehmen ist, ist dieser Schlüssel konstant)
- BT-2 (Ausstellungsdatum) – als Disambiguierungsfeld bei identischen Rechnungsnummern über mehrere Perioden
Wird eine Rechnung als Dublett erkannt, wird der zweite Eingang protokolliert, aber nicht in den Datenfluss eingespeist. Der erste Eintrag behält seinen Status.
Für die Statusführung unterscheidet der Dienst:
- Offen – Fälligkeit liegt in der Zukunft, keine Zahlung erfasst
- Überfällig – Fälligkeit überschritten, keine Zahlung erfasst
- Bezahlt – Zahlungseingang wurde manuell bestätigt oder aus einem Bankfeed zugeordnet
- Storniert – manuell markiert oder durch eine Gegenbuchung neutralisiert
Datenfluss in den Forecast
Jede erfasste Ausgangsrechnung – ob über BCC, API oder ERP-Schnittstelle eingespeist – landet im selben normalisierten Datenmodell. Der Datenfluss ist einstufig:
BCC-Mail (MIME)
→ Anhang-Identifikation
→ Format-Parser (XRechnung UBL | XRechnung CII | ZUGFeRD CII | PDF/OCR)
→ Feld-Extraktion (BT-Mapping)
→ Fälligkeitsdatum (BT-9 | Fallback BT-20 | Fallback Standard-Zahlungsziel)
→ Dublett-Check (BT-1 + Mandanten-ID + BT-2)
→ Forecast-Position (Betrag + Datum + Debitor + Status)
→ 13-Wochen-Liquiditätsvorschau
Das Signal steht damit früher bereit als jeder Bankfeed: Der Forderungseintrag erscheint in dem Moment, in dem die Rechnung rausgeht – nicht erst, wenn die Zahlung gebucht ist. Bei einer durchschnittlichen Forderungslaufzeit von 39,63 Tagen (Zahlungsziel 32,13 Tage plus 7,50 Tage Verzug laut Creditreform Zahlungsindikator Winter 2025/26) bedeutet das einen Informationsvorsprung von vier bis sechs Wochen gegenüber der Bankbuchung.
Wie eingehende Belege denselben Forecast füllen, erklärt Cashflow aus Belegen.
Migrationspfad: vom Postfach zur API- oder ERP-Schnittstelle
Der BCC-Mechanismus ist als Einstieg konzipiert – er setzt keinen Eingriff ins bestehende ERP voraus und ist ohne Abtippen einsatzbereit. Der Prozess dahinter – Parsing, Feld-Extraktion, Fallback, Dublett-Check, Forecast-Einspeisung – ist formatagnostisch und von der Eingangsquelle entkoppelt.
Das macht den Migrationspfad zu einer direkten Schnittstelle verlustfrei:
- Postfach → REST-API: Wer das ERP oder die Faktura-Software um einen API-Call erweitern kann oder will, ersetzt die BCC-Mail durch einen strukturierten POST-Request. Das Downstream-Datenmodell ändert sich nicht.
- Postfach → ERP-Schnittstelle: Bietet das ERP eine native Ausgangsrechnungs-Exportschnittstelle (z. B. DATEV-Export, SAP-IDOc, Peppol AS4), kann diese als alternativer Eingangskanal konfiguriert werden. Auch hier bleibt der Forecast-Datenfluss identisch.
- Parallelbetrieb: Postfach und API-Kanal können gleichzeitig aktiv sein. Der Dublett-Check verhindert Doppelerfassungen, wenn dieselbe Rechnung über beide Wege eingeht.
Die Entscheidung für den Einstieg per Postfach schließt keine spätere Integration aus – sie öffnet sie, weil der Prozess schon läuft und die Datenstruktur bekannt ist.
Was der Dienst nicht übernimmt
Archivierung: Die BCC-Kopie im Dienst ist eine Arbeitskopie für die Liquiditätsplanung – kein steuerrechtlich gültiges Archivdokument. Das Original verbleibt beim Aussteller im sendenden System. Laut BMF muss der strukturierte Teil einer E-Rechnung unversehrt in Originalform aufbewahrt werden; die Aufbewahrungsfrist für Ausgangsrechnungen beträgt im Regelfall acht Jahre. Diese Pflicht erfüllt das sendende System oder der Steuerberater – nicht der Dienst.
Zahlungsauslösung: Der Dienst hat ausschließlich Lesezugriff auf die eingehenden Dokumente. Er löst keine Überweisungen aus und greift nicht in Zahlungsprozesse ein.
XRechnung-Validierung: Der Dienst prüft nicht, ob eine eingehende XRechnung normkonform ist. Für Validierungszwecke empfiehlt sich der offizielle KoSIT-Validator. Die Frage, wie E-Rechnungsformate sich im Detail unterscheiden, beantwortet ZUGFeRD oder XRechnung – was passt?.
Zurück zur Übersicht: Ausgangsrechnungen per BCC erfassen – der schlanke Einstieg
Forderungen im Forecast, nicht im Rückblick
Wer Ausgangsrechnungen direkt beim Versand im Liquiditätsplan sieht, hat den Vorsprung vor dem Bankfeed – und was das wirklich bedeutet: Entscheidungen über Mahnläufe, Kreditlinien und Zahlungsziele fallen auf Basis belegter Forderungsdaten, nicht auf Basis von Buchungen, die schon Geschichte sind.
Gebaut von Leuten, die denselben Engpass aus der Praxis kennen.
