Auf dieser Seite
Dieser Artikel richtet sich an ERP-Verantwortliche, IT-Berater und Steuerberater, die verstehen wollen, wie ein System aus eingehenden XRechnungen und E-Mail-Signaturen Kreditorenstammdaten ohne manuelle Eingabe befüllen kann. Behandelt werden: das vollständige Feld-Mapping zwischen XRechnung Business Terms und Kreditorenstamm, die Parsing-Logik für strukturierte und unstrukturierte Signaturen sowie die Abgleichregeln bei IBAN-Abweichungen.
Dieser Artikel ist Teil der Lösungen im Überblick. Den Überblick ohne Technikjargon bietet die Lösungsseite für Buchhaltung und Entscheider. Wie XRechnung als Format aufgebaut ist, erklärt XRechnung erklärt.
Feld-Mapping: XRechnung Business Terms → Kreditorenstamm
XRechnung codiert alle Dokumentdaten als Business Terms (BT) nach der europäischen Norm EN 16931. Die Felder des Verkäufers – also des Lieferanten im Sinne des Kreditorenstamms – sind in der Gruppe Seller gebündelt. Folgende BT stehen für die Stammdatenbefüllung zur Verfügung:
| BT | Bezeichnung | Pflicht EN 16931 | Pflicht BR-DE | Kreditorenstamm-Feld |
|---|---|---|---|---|
| BT-27 | Name des Verkäufers | Ja | Ja | Kreditorname / Firmenbezeichnung |
| BT-31 | USt-IdNr. des Verkäufers | Nein | Ja (BR-DE-2) | USt-IdNr. |
| BT-32 | Lokale Steuernummer | Nein | Ja (BR-DE-2) | Steuernummer |
| BT-34 | Elektronische Adresse | Nein | Nein | Routing-Kennung (Peppol/Leitweg-ID) |
| BT-35 | Adresszeile 1 | Nein | Nein | Straße / Hausnummer |
| BT-36 | Adresszeile 2 | Nein | Nein | Adresszusatz |
| BT-37 | Stadt | Nein | Nein | Ort |
| BT-38 | Postleitzahl | Nein | Nein | PLZ |
| BT-39 | Region / Bundesland | Nein | Nein | Bundesland / Region |
| BT-40 | Land | Nein | Nein | Länderkennzeichen |
| BT-41 | Kontaktperson | Nein | Ja (BR-DE-5) | Ansprechpartner |
| BT-42 | Kontakttelefon | Nein | Ja (BR-DE-6) | Telefon |
| BT-43 | Kontakt-E-Mail | Nein | Ja (BR-DE-7) | |
| BT-84 | Zahlungskonto-Identifikator (IBAN) | Nein | Nein | IBAN (Bankkonto) |
| BT-86 | BIC | Nein | Nein | BIC |
Hinweis zu BR-DE-2: Die deutsche XRechnung-Erweiterung verlangt, dass entweder BT-31 (USt-IdNr.) oder BT-32 (lokale Steuernummer) vorhanden ist – nicht zwingend beides. Beide Felder sind je für sich optional, aber mindestens eines muss befüllt sein. Quellen: KoSIT – XRechnung-Spezifikation, eu-rechnung.de – BT-Referenz.
BT-34 – elektronische Adresse, nicht E-Mail-Adresse
Ein häufiger Irrtum: BT-34 wird gelegentlich als „E-Mail des Verkäufers" gelesen. Das ist falsch. BT-34 ist die elektronische Adresse im Sinne der Peppol-Routing-Infrastruktur – in Deutschland im B2B-Kontext häufig die Leitweg-ID (Format: DUNS-Nr.:0060:… oder GLN, OIN, Handelsregisternummer).
BT-34 ist als Identifikator gedacht, über den der Aussteller im Peppol-Netzwerk adressiert werden kann. Als eindeutige Lieferantenkennung eignet sie sich daher nur für Unternehmen, die am Peppol-Netzwerk aktiv teilnehmen – für alle anderen bleibt das Feld entweder leer oder enthält eine abweichend interpretierte Kennung. Wer BT-34 zur Deduplizierung von Kreditorenstämmen verwenden will, muss das Vorhandensein eines gültigen Peppol-Routing-Schemas (Schemakennung vor dem Doppelpunkt) prüfen; ansonsten ist BT-27 kombiniert mit BT-40 und BT-31 die tragfähigere Schlüsselkombination.
Datenqualität nach Herkunft
Nicht alle Datenquellen liefern dieselbe Strukturqualität. Für die automatische Stammdatenbefüllung ergibt sich eine klare Hierarchie:
Stufe 1 – XRechnung / ZUGFeRD XML (höchste Qualität)
Die Daten stecken im maschinenlesbaren XML-Kern. Jedes BT-Feld ist eindeutig kodiert, typisiert und per Schema validierbar. Zeichenketten, Ländercodes (ISO 3166-1 alpha-2), PLZ und IBAN liegen als diskrete Werte vor, ohne Parsing-Aufwand. ZUGFeRD-Dateien enthalten denselben XML-Kern im eingebetteten Anhang – als factur-x.xml (ZUGFeRD 2.1+ / Factur-X) in UN/CEFACT-Notation. Die Extraktion erfordert lediglich ein Standard-XML-Parsing (DOM oder SAX) plus Namespace-Auflösung. Details zum ZUGFeRD-Format: ZUGFeRD und Factur-X erklärt.
Stufe 2 – vCard-Signatur (RFC 6350)
Manche E-Mail-Clients hängen der ausgehenden Mail eine .vcf-Datei als Signatur-Anhang bei. Das vCard-Format (RFC 6350) ist zeilenbasiert und maschinenlesbar. Relevante Properties für die Stammdatenbefüllung:
BEGIN:VCARD
VERSION:3.0
FN:Anna Bauer → BT-41 / Ansprechpartner
ORG:Muster GmbH → BT-27 / Kreditorname
TEL;TYPE=WORK:+49 69 123 456 → BT-42 / Kontakttelefon
EMAIL:a.bauer@muster.de → BT-43 / Kontakt-E-Mail
ADR;TYPE=WORK:;;Musterstr. 1;Frankfurt;;60001;DE → BT-35/37/38/40
END:VCARD
Property-Erkennung: Das FN-Feld (Formatted Name) enthält den vollständigen Displaynamen der Person, ORG die Firmenbezeichnung. ADR ist nach RFC 6350 ein semikolon-separierter Verbund aus PO Box, Extended Address, Street, City, Region, Postal Code, Country – in dieser Reihenfolge. Parsen erfordert einen RFC-konformen vCard-Parser, da Continuation Lines (Leerzeichen am Zeilenanfang) und Base64-kodierte Felder (z. B. PHOTO) auftreten können.
Einschränkung: vCard-Signaturen enthalten keine IBAN. Bankverbindungen stecken im vCard-Standard nicht – das Feld X-IBAN existiert nicht als offizielle Property und wird von keinem gängigen Mail-Client befüllt.
Stufe 3 – Freitext-Signatur
Die Mehrheit der Signaturen in deutschen Unternehmens-E-Mails ist unstrukturiertes HTML oder Plain Text. Extraktion erfolgt hier per Named-Entity-Recognition (NER) und regulären Ausdrücken:
- Name: Zeile direkt nach/über der Berufsbezeichnung, Heuristik „Vorname Nachname" (zwei bis vier Worttoken, erste Buchstaben groß).
- Telefon:
\+?[0-9\s\-\/\(\)]{7,20}mit Präfix-Token wie „Tel", „Fon", „T:", „☎". - E-Mail: Standard-RFC-5322-Muster.
- Adresse: Mehrzeilige Erkennung: PLZ-Muster
[0-9]{5}als Anker, vorangehende Zeile als Straße, nachfolgende als Ort – kombiniert mit ISO-3166-Länderkennzeichen am Ende. - Firmenname: Erste Zeile nach dem Trennzeichen (oft
--oder horizontale Regel), bzw. Token mit GmbH/AG/GbR/UG-Suffix.
Freitext-Parsing hat eine inhärente Fehlerrate, die von der Signatur-Konvention des jeweiligen Unternehmens abhängt. Konfidenzwerte je Feld (z. B. 0,0–1,0 auf Basis von Musterkonsistenz und Tokenanzahl) ermöglichen es dem Benutzer, niedrig-konfidente Vorschläge vor der Übernahme zu prüfen.
Iban aus Freitext: Freitext-Signaturen enthalten gelegentlich IBAN-Angaben. Da diese nicht aus dem strukturierten Rechnungsfeld BT-84 stammen, gelten für sie dieselben erhöhten Prüfpflichten wie für jede manuell erfasste IBAN – dazu mehr im nächsten Abschnitt.
Dublettenerkennung beim Kreditorenanlegen
Bevor ein neuer Kreditorenstammsatz angelegt wird, prüft das System gegen den Bestand. Der Abgleich läuft mehrstufig:
Exakter Treffer – BT-27 (normalisiert: lowercase, Leerzeichen kollabiert) und BT-40 (Länderkennzeichen) und mindestens eines von {BT-31, BT-32} stimmen überein → kein neuer Satz, bestehenden Datensatz zur Anreicherung vorschlagen.
Unscharfer Treffer – Levenshtein-Distanz auf normalisiertem BT-27 ≤ 2 oder phonetischer Treffer (Kölner Phonetik / Soundex für deutschsprachige Firmennamen) → Treffer mit Konfidenz < 1,0 zur manuellen Entscheidung vorlegen.
IBAN-Treffer – BT-84 stimmt mit einem bestehenden Kreditorenkonto überein, aber Name weicht ab → gesonderte Warnung (mögliche Umbenennung oder Betrugsversuch, siehe unten).
Kein Treffer → Neuanlage mit Vorabdaten aus Rechnung oder Signatur, Status „zur Freigabe".
Der Neuanlage-Workflow legt noch keine buchhalterisch aktiven Felder (Zahlungskonto, Kontorahmen-Zuordnung) fest – diese erfordern eine explizite Freigabe durch die zuständige Person.
IBAN-Abgleich und Änderungs-Workflow
Die IBAN ist das sicherheitskritischste Feld im Kreditorenstamm. DATEV dokumentiert explizit, dass Angreifer ZUGFeRD/XRechnung-Dateien auf dem Transportweg abfangen und die IBAN im XML tauschen, bevor das Dokument den Empfänger erreicht – bei automatischer Verarbeitung ohne menschlichen Sichtkontakt ist dieser Angriff besonders effektiv (DATEV – E-Rechnung: wachsam sein).
Drei Konstellationen:
| Situation | Vorgehen |
|---|---|
| Neuer Kreditor, IBAN aus BT-84 vorhanden | IBAN als Vorschlag übernehmen; Freigabe durch Benutzer erforderlich; Empfehlung: Abgleich gegen Lieferanten-Website |
| Bestehender Kreditor, IBAN stimmt überein | Kein Handlungsbedarf; automatische Übernahme ohne Freigabe möglich |
| Bestehender Kreditor, IBAN weicht ab | Änderungsantrag mit Quellenangabe (BT-84 aus Rechnung-ID X); explizite Freigabe zwingend; Hinweis auf DATEV-Warnung; parallel telefonische Verifikation empfohlen |
Abgleich nach EU 2024/886 (Verification of Payee)
Seit dem 9. Oktober 2025 sind Zahlungsdienstleister in der Eurozone verpflichtet, bei Einzel-SEPA-Überweisungen den Namen des Zahlungsempfängers gegen die angegebene IBAN abzugleichen – der Überweisende erhält vor Ausführung ein Match/Close-Match/No-Match-Signal (EU-Verordnung 2024/886). Für Sammelzahlungen besteht derzeit noch eine Opt-out-Option mit voller Haftungsübernahme durch den Auftraggeber (Art. 5c; KPMG – Verification of Payee).
Praktische Konsequenz: Wer im Kreditorenstamm einen falschen Firmennamen oder eine veraltete IBAN führt, riskiert beim nächsten Zahllauf ein „No Match" der Bank – die Überweisung stockt, der Lieferant eskaliert, und der Fehler lässt sich auf den veralteten Stammsatz zurückverfolgen. Die automatische Befüllung aus BT-27 und BT-84 reduziert genau dieses Risiko: der Name kommt aus dem strukturierten XML des Lieferanten selbst, nicht aus einer manuellen Eingabe.
Verarbeitung über Schnittstelle
Der Dienst stellt Eingangsdaten über eine REST-Schnittstelle bereit. Der Ablauf im Überblick:
- Eingehende E-Mail-Rechnung wird empfangen (IMAP-Polling oder direkte API-Übergabe).
- Anhänge werden klassifiziert: XRechnung-XML, ZUGFeRD-PDF (XML-Extraktion aus
/XRechnungsdaten-Attachment), vCard-Anhang, sonstiger Anhang. - Erkannte Felder werden je Quelle mit Konfidenzwert normalisiert und zurückgegeben.
- Abgleich gegen bestehende Kreditoren-IDs erfolgt serverseitig; Ergebnis enthält Treffer-Status und Delta-Felder.
- Freigabe-Trigger (Neuanlage / IBAN-Änderung) werden als Event zurückgegeben; die Verarbeitung im ERP-System obliegt dem Aufrufer.
Die Schnittstelle gibt keine Kreditorenstammdaten direkt in ERP-Systeme zurück – sie liefert strukturierte Vorschläge mit Metadaten zur Herkunft (Feld source: bt-84 | vcard | freetext) und Konfidenz. Die Integration in die bestehende ERP-Datenhaltung liegt beim integrierenden System.
Für den Gesamtüberblick, was das für den Arbeitsalltag bedeutet – ohne Feldnummern und Parsing-Logik – geht es hier entlang: Stammdaten aus Signatur – Lösungsübersicht.