Welche Felder die IDR auf einer PDF-Rechnung erkennt: Standard, Professional und konfigurierbare Referenzen.
Die IDR (Intelligent Document Recogniser) erkennt automatisch die wichtigsten Daten auf einer PDF-Rechnung und wandelt sie in strukturierte Felder in der E-Rechnung um. Welche Felder erkannt werden, hängt von Ihrem Abonnement und der Konfiguration ab.
Bei jeder PDF-Konvertierung werden folgende Felder automatisch erkannt:
Bei einigen Lieferantenformaten kann die IDR ein anderes Feld als die Rechnungsnummer übernehmen, zum Beispiel eine Transaktions-ID anstelle der eigentlichen Rechnungsnummer. Ein bekanntes Beispiel sind Meta (Facebook) Rechnungen, bei denen die Rechnungsnummer am unteren Ende einer späteren Seite der PDF steht und die Transaktions-ID prominenter erkannt wird. Weitere Fehlzuordnungen: die Handelsregisternummer des Lieferanten, eine Bestellnummer/PO oder eine Bank-/Zahlungsreferenz (zum Beispiel eine Bankreferenz, die IBAN oder ein Teil der IBAN/Kontonummer) statt der echten Rechnungsnummer, was zu einer falschen Rechnungsnummer in Coda oder im ERP-System führen kann. Letzteres kann auch dazu führen, dass eine Gutschrift fälschlich als Duplikat blockiert wird (siehe Doppelte Rechnung). Dies ist ein Feldauswahlfehler der Erkennung und unterscheidet sich von der korrekten Erkennung einer Zahlungsreferenz als separates PaymentID-Feld (siehe Lastschrift & G-Konto): dort überschreibt die Zahlungsreferenz die Rechnungsnummer nicht, hier wird sie versehentlich an ihrer Stelle erkannt.
Dies ist für das betreffende Lieferantenformat verbesserbar. Die Erkennung der Rechnungsnummer ist vom Kunden nicht konfigurierbar, wird aber intern durch einen Support-Mitarbeiter über Outlier Detection, Regex und Hinweise pro Lieferant oder Format optimiert. Es ist keine Roadmap-Änderung erforderlich; es handelt sich um eine gezielte Optimierung der bestehenden Funktionalität. Melden Sie solch einen Fall dem Support — auf Basis der Meldung fügt das Team einen lieferantenspezifischen Hinweis hinzu, sodass zukünftige Rechnungen dieses Formats die richtige Rechnungsnummer erhalten.
Wie funktioniert die Erkennung im Hintergrund (SampleStore)? Die IDR verwendet dafür den SampleStore: eine Datenbank mit Erkennungsmustern pro Lieferant. Der Prozess läuft in drei Schritten ab: (1) Suche nach Nummern, die einem RegEx-Muster im SampleStore entsprechen, (2) Vergleich mit früheren Beispielen desselben Lieferanten (Länge, Aufbau, Bindestriche, Punkte, Unterstriche, Konsistenz), (3) selbstlernende Anpassung auf Basis neuer Rechnungen. Support ergänzt den SampleStore nach einer Meldung mit Beispielen und ggf. einem RegEx.
Kurze oder andere Nummer anstelle eines längeren Präfix-Musters. Wenn die Rechnungen eines Lieferanten normalerweise ein festes Präfix und eine feste Länge haben, erkennt die IDR manchmal eine kürzere oder andere Nummer ohne dieses Präfix. Ist das Muster (Präfix, Länge, Aufbau) aus der Meldung bereits klar, ist der erste Schritt, den SampleStore oder die RegEx für diesen Lieferanten direkt anzupassen; ein PDF- oder XML-Beispiel ist dann Beweismaterial, kein verpflichtender erster Schritt. Hat die Erkennung früher bereits gut funktioniert und ist im Laufe der Zeit wieder fehlerhaft geworden, gilt derselbe Ansatz: den SampleStore für diesen Lieferanten erneut prüfen und anpassen, kein Hinweis auf einen Produktfehler.
Für die Untersuchung ist die Plattform-XML aus dem Posteingang die nützliche Datei: Sie enthält den IDR-Erkennungspfad. Eine XML, die Sie selbst aus Ihrem ERP-System (z. B. AFAS) exportieren, nachdem die Rechnungsnummer bereits manuell korrigiert wurde, enthält in der Regel diesen IDR-Block nicht und zeigt nur die bereits korrigierte Nummer — diese Datei ist dann nicht geeignet, um den Erkennungsfehler zu analysieren.
Versteckter oder transparenter Text in der PDF (Vorlagenwiederverwendung). Einige Lieferanten verwenden eine alte Rechnungs-PDF als Vorlage für neue Rechnungen. Dabei können alte Daten oder Rechnungsnummern als unsichtbarer oder transparenter Resttext in der PDF-Textschicht verbleiben. Die IDR verwendet hybrides OCR: Neben dem sichtbaren Bild wird auch die Textschicht der PDF gelesen. Auf einem Screenshot oder auf dem Bildschirm sehen Sie nur die sichtbaren Zeilen, aber die Erkennung sieht die vollständige Textschicht einschließlich verstecktem Resttext. Dies kann die Ursache sein, wenn eine alte und eine neue Rechnungsnummer oder ein Datum in der Erkennung durcheinander geraten. Vermuten Sie dieses Muster, fordern Sie immer die Original-PDF an: Ein Screenshot reicht nicht aus, da die Textschicht darin fehlt. Kopieren Sie dann den Text aus der Datei in einen Nur-Text-Editor, um die Abweichung gegenüber der sichtbaren Darstellung zu prüfen.
Sekundäres Symptom: fälschlich als Duplikat markierte Rechnung. Eine nachfolgende Rechnung kann dadurch fälschlicherweise als Duplikat markiert werden, weil die IDR eine falsche (verborgene) Rechnungsnummer erneut verwendet oder abgleicht. Dies ist eine Folge des zugrunde liegenden Erkennungsfehlers, kein separates Problem: Korrigieren Sie zuerst die Textschichterkennung wie oben beschrieben, anstatt die Duplikaterkennung isoliert zu behandeln (siehe Wie wird eine doppelte Rechnung erkannt?).
Suchvarianten: „andere Handelsregisternummer in der XML", „Handelsregisternummer Rechnung vs. XML", „Absender-Handelsregisternummer weicht ab", „Lieferanten-Handelsregisternummer falsch in XML", „Lieferanten-Handelsregisternummer XML anders als Rechnung", „Partei-ID Absender XML PDF", „AccountingSupplierParty Handelsregisternummer".
Manchmal weicht die Handelsregisternummer des Lieferanten (oder eine andere Partei-ID, wie eine Umsatzsteuer-ID) im Absenderblock der XML von der Original-PDF ab, oder die Erkennung ordnet die Rechnung dem falschen Lieferanten zu. Dies ist ein Felderkennungsfehler am Lieferanten-Identifikator, genau wie bei Beträgen, Währung oder Rechnungsnummer.
Achtung — nicht dasselbe wie „Handelsregisternummer als Rechnungsnummer gelesen". Bei diesem anderen Fall (siehe oben) wird die Handelsregisternummer versehentlich im Rechnungsnummer-Feld erkannt. Hier geht es um die Partei-ID im Absenderblock selbst, die nicht mit der PDF übereinstimmt. Beides sind separate Erkennungsfragen.
Was können Sie tun? Es gibt keine Self-Service-Option, um die XML anzupassen. Sammeln Sie die Original-PDF und die zugehörige XML (herunterladbar beim Dokument im Posteingang) und/oder die Dokument-ID der Konvertierungsaufgabe, und melden Sie dies dem Support. Auf dieser Basis passt das Team die Erkennung oder den Lieferantenabgleich an. Wie bei anderen Erkennungsfehlern gilt hier keine harte Bearbeitungszeit-Zusage.
Suchvarianten: „Währung nicht korrekt erkannt", „Währung falsch erkannt", „falsche Währung IDR", „SEK statt NOK", „currency wrong PDF", „Währungserkennung Rechnung", „PDF Währung falsch", „Währung falsch gelesen".
Die Währung ist ein standardmäßig erkanntes Feld (siehe Tabelle oben) und fällt unter dieselben generischen PDF→XML-Erkennungsfehler wie Rechnungsnummer oder Betrag: Die IDR kann den ISO-Währungscode im Vergleich zur PDF falsch erkennen (zum Beispiel SEK statt NOK). Dies ist keine separate Funktionalität und kein eigenständiges Problem, sondern dieselbe Erkennungsfrage wie bei anderen Feldern.
Was können Sie tun? Melden Sie die Abweichung dem Support und legen Sie die Original-PDF sowie die zugehörige XML (aus dem Posteingang) oder die Dokument-ID der Konvertierungsaufgabe vor. Daraufhin optimiert das Team die Erkennung für das betreffende Lieferantenformat. Wie bei anderen Erkennungsfehlern gilt hier keine harte Bearbeitungszeit-Zusage.
Mit dem Professional-Abonnement werden zusätzliche Felder erkannt:
Suchvarianten: "amerikanisches Datum", "amerikanisches Rechnungsdatum", "US-Lieferant Datum", "USA Rechnungsdatum", "MDY Rechnungsdatum", "MDY statt DMY", "Datumsformat Vereinigte Staaten", "Rechnungsdatum nicht richtig erkannt amerikanischer Lieferant", "American date format invoice date", "US supplier date format MDY".
Die IDR erkennt Datumsangaben auf PDF-Rechnungen und konvertiert sie in das standardisierte UBL-Datumformat (YYYY-MM-DD). Weil Datumsnotationen je nach Land unterschiedlich sind, legt die IDR anhand des Landes des Lieferanten fest, wie mehrdeutige Daten interpretiert werden:
MDY (Monat-Tag-Jahr). Das Datum 03/11 wird als 11. März interpretiert.DMY (Tag-Monat-Jahr). Das Datum 03/11 wird als 3. November interpretiert.Sehen Sie bei einem Lieferanten aus den Vereinigten Staaten ein Rechnungsdatum, das Ihrer Meinung nach falsch erkannt wurde? Prüfen Sie zuerst diese Länderregel, bevor Sie dies als Felderkennungsfehler melden: Bei einem amerikanischen Lieferanten ist 03/11 beispielsweise der 11. März, nicht der 3. November. Ist die Datumsnotation nicht die Erklärung, handelt es sich um eine andere Erkennungsfrage (siehe oben).
Wenn die automatische Landserkennung nicht ausreicht, kann pro Lieferant über den Hint-Mechanismus ein spezifischer Hinweis für das Datumsformat ergänzt werden.
Tip: falsch interpretierte Daten (zum Beispiel 03/11 als 11. März statt 3. November) sind fast immer eine Erkennungsfrage, kein Plattformproblem. Die Plattform zeigt das Datum immer so an, wie es in der UBL steht.
Beim Professional-Abonnement wird die erkannte IBAN mit dem Verification Store verglichen: einer Datenbank zuvor manuell validierter IBAN-Nummern pro Lieferant. Wenn die IBAN auf der Rechnung von dem abweicht, was zuvor verifiziert wurde, wird dies signalisiert. Das hilft, Scheinrechnungen oder geänderte Bankdaten zu erkennen.
Hinweis: Die IBAN auf einer Rechnung dient gemäß der europäischen Norm EN16931 primär zur Identifikation des Lieferanten, nicht als Zahlungsanweisung. Eine geänderte IBAN muss immer zuerst in den Stammdaten Ihres Finanzsystems validiert werden, bevor darauf gezahlt wird.
Neben den Standardreferenzen (Bestellnummer, Vertragsnummer, Projektnummer) können weitere Referenzen pro Lieferant spezifisch konfiguriert werden, etwa Budgetcodes, Budgetverantwortliche oder interne Referenzen. Das ist Maßarbeit, die auf Streifenkartenbasis eingerichtet wird.
Die Erkennung konfigurierbarer Referenzen nutzt ein dreischichtiges Verfahren:
Tip: Die Bestellnummer ist die am häufigsten genutzte Referenz und wird von den meisten Lieferanten auf der Rechnung angegeben. Wenn ein Lieferant ein bestimmtes Referenzfeld in seiner Software nicht ausfüllen kann, macht es wenig Sinn, danach zu fragen. Nutzen Sie in dem Fall die Bestellnummer als primäre Referenz.
Hinweis: Bestellnummer, Vertragsnummer und Projektnummer sind Professional-Standardfelder, aber die Erkennung greift erst nach einer einmaligen Support-Einrichtung pro Kunde/Lieferant (auf Basis von mindestens 5 Beispielrechnungen, ggf. ergänzt durch eine Regex). Wenden Sie sich an den Support und liefern Sie idealerweise eine Beispielrechnung.
Erhalten Sie über die API die informative Antwort Order Reference detection skipped as Sample store is empty oder Contract Reference detection skipped as Sample store is empty? Das ist kein Verarbeitungsfehler. Die IDR befüllt diese Referenzen erst, wenn der Customer Sample Store für Ihren Endpunkt Beispielreferenzen zum Abgleich enthält. Ist der Store leer, wird nur diese Referenzerkennung übersprungen; alle anderen Felder und Funktionen werden normal erkannt.
Lösung: Liefern Sie einige Beispiel-Bestellnummern oder Vertragsreferenzen (mindestens 3 Zeichen pro Beispiel) genau so, wie sie auf den Rechnungen stehen, damit der Support sie im Customer Sample Store konfigurieren kann. Danach gilt zunächst ein Label-Abgleich (zum Beispiel „Your order number“), mit Regex als Fallback. Für die Einrichtung der PO-Nummer-Erkennung ist über den Vertrieb auch ein Remote Starter verfügbar.
Nein, nicht direkt in der Plattform. Sie verwalten den Customer Sample Store, die Formatierungsregeln oder die RegEx für die Bestellnummererkennung nicht selbst; das richtet der eConnect-Support ein.
Indirekt jedoch, indem Sie:
Best Practice für das Bestellreferenz-Format auf der PDF:
Bestellnummer: 420000007 statt PO420000007;Siehe auch Einreichungsfehler bei einer blockierten oder abgelehnten Rechnung aufgrund einer falsch erkannten Bestellnummer.
Suchvarianten: "mehrere PO-Nummern", "mehrere Bestellnummern eine Rechnung", "mehrere Auftragsreferenzen PDF", "OrderReference Kopf", "PO auf Rechnungsposition", "Positionserkennung PO", "mehrere PO-Nummern Erkennung".
Erwarten Sie keine automatische Verknüpfung mehrerer PO-Nummern mit mehreren Kopf-Auftragsreferenzen. Prüfen Sie bei einem Multi-PO-Layout zunächst die Professional- und Sample-Store-Einrichtung für die eine Kopf-PO; zusätzliche PO-Nummern landen als Positionstext, nicht als separate Bestellpositions-Referenz, sofern der Empfänger dies nicht selbst eingerichtet hat. Siehe auch Positionserkennung für Referenzfelder pro Position.
Gemäß der europäischen Norm EN16931 ist eine Referenz (Buyer Reference) auf einer E-Rechnung Pflicht; dies ist häufig eine Bestellnummer oder eine andere Referenz des Empfängers. Ein Absender kann in dieses Feld einen falschen Wert eintragen.
eConnect lehnt eine Rechnung standardmäßig nicht auf Basis der Referenz ab. Eine Rechnung erfüllt die Grundregeln der europäischen Norm nur dann nicht, wenn überhaupt keine Referenz vorhanden ist. Ob eine Rechnung aufgrund einer unbekannten oder falschen Referenz abgelehnt wird, hängt von der Konfiguration des Empfängers ab: In einer spezifischen Empfängerkonfiguration kann eine Rechnung abgelehnt werden, wenn die Referenz unbekannt ist. Dies ist daher eine Eigenschaft der empfangenden Konfiguration, nicht der Standard-eConnect-Verarbeitung.
Tipp: Wenn Sie Rechnungen bei fehlenden oder unbekannten Referenzen ablehnen möchten, konfigurieren Sie dies über RBE (Rule Based Enrichment) am empfangenden Endpunkt.
-NOTFOUND)Die Rechnungsnummer (UBL-Feld cbc:ID, BT-1) ist in EN 16931, UBL BIS Billing 3.0 und NLCIUS für reguläre Rechnungen Pflicht. Die IDR verarbeitet jedoch einen gemischten Dokumentenstrom: reguläre Rechnungen, Gutschriften, Kostenerstattungen und Belege. Belege fallen unter das vereinfachte Rechnungsregime (Transaktionen bis ca. € 100 inkl. MwSt.), für das die Steuerbehörde keine Rechnungsnummer als gesetzliche Anforderung vorschreibt. Eine Ablehnung bei fehlender Rechnungsnummer würde alle Belege und Kostenerstattungen aus der Verarbeitung ausschließen.
Daher generiert die IDR-Pipeline automatisch eine Ersatznummer, wenn beim Erkennen keine Rechnungsnummer aus dem Dokument extrahiert werden kann. Das Feld cbc:ID (BT-1) wird dann mit der Struktur befüllt:
YYYYMMDDHHmmss-NOTFOUND
Der Zeitstempel ist der Zeitpunkt der Verarbeitung durch die IDR-Pipeline, nicht das Datum auf dem Dokument selbst. Beispiel: 20240315143022-NOTFOUND.
Eine Filterung ist auf zwei Ebenen möglich:
cbc:ID) auf -NOTFOUND endet. Darauf basierend kann das Dokument für eine manuelle Überprüfung zurückgehalten, in ein separates Postfach umgeleitet oder automatisch abgelehnt werden.-NOTFOUND im Feld cbc:ID ist ausreichend.Mit der Zeilenerkennung werden auch einzelne Rechnungszeilen erkannt: Beschreibung, Stückpreis, Menge, Zeilenbetrag und Referenzfelder pro Zeile. Das ist ein separates Feature, das Sie selbst über Meine Umgebung aktivieren können.
Neugierig, wie die Erkennung technisch funktioniert? Lesen Sie Wie funktioniert Scan & Erkennung (IDR/OCR)?.
Zu Ihren Konvertierungsaufgaben