Wenn Sie eine Rechnung bei eConnect einreichen, durchläuft das Dokument eine Reihe von Verarbeitungsschritten. Wie genau diese Verarbeitung abläuft, hängt vom Dateityp (XML oder PDF) und der Qualität der eingereichten Datei ab. Dieser Artikel erklärt, was hinter den Kulissen passiert.

eConnect kennt zwei grundlegend verschiedene Verarbeitungsrouten:

XML-Verarbeitung (direkte Route): Wenn Sie eine gültige UBL-Rechnung (SI-UBL 2.0, Peppol BIS Billing 3.0 oder ein anderes unterstütztes XML-Format) einreichen, wird diese direkt verarbeitet. Die Plattform liest die strukturierten Daten aus der XML, validiert sie und routet das Dokument an den Empfänger. Dies ist die schnellste und zuverlässigste Route.

PDF-Verarbeitung (Konvertierung via IDR): Wenn Sie eine PDF-Rechnung einreichen, wird diese vom Intelligent Document Recogniser (IDR) verarbeitet. Der IDR extrahiert die Rechnungsdaten via OCR und Mustererkennung und erstellt eine UBL-Rechnung auf Basis der erkannten Daten. Dieser Prozess ist grundsätzlich weniger zuverlässig als die direkte XML-Verarbeitung, da er von der Qualität des PDFs abhängt.

Tipp: UBL-Einreichung ist gegenüber PDF immer vorzuziehen. Es ist schneller, günstiger und zuverlässiger. Fragen Sie Ihren Lieferanten oder Softwareanbieter, ob UBL-Export verfügbar ist.

Bei der Einreichung einer XML-Datei durchläuft eConnect die folgenden Schritte:

Die Plattform erkennt automatisch, welchem Format die Datei folgt, basierend auf der CustomizationID und dem XML-Schema. Unterstützte Formate sind unter anderem NLCIUS, BIS Billing V3, XRechnung, CII und Factur-X.

Die Rechnung wird gegen die Regeln des erkannten Profils validiert. Dies umfasst:

• Schema-Validierung: Entspricht die XML der UBL 2.1- oder CII-Schemastruktur?
• Geschäftsregeln: Stimmen die Berechnungen? Sind Pflichtfelder ausgefüllt? Stimmen die Codelistenwerte überein?
• Länderspezifische Regeln: Werden die korrekten NL-R-, DK-R- oder andere Landesregeln eingehalten?

Tipp: Erhalten Sie die Meldung, dass "keine Validierungsregeln" gefunden wurden? Das bedeutet in der Regel, dass die CustomizationID in Ihrer XML fehlt oder nicht erkannt wird. Ohne erkennbares Profil kann der Validator keine Geschäftsregeln anwenden. Prüfen Sie, ob Ihre Rechnung eine gültige CustomizationID enthält, z.B. die von NLCIUS oder BIS Billing V3.

Ein bemerkenswertes Merkmal der eConnect-Verarbeitung ist die automatische Reparatur von XML-Dateien. Bekannte Fehler werden über XSL-Transformationen korrigiert. Die Plattform akzeptiert im Prinzip jede UBL; nicht-essenzielle fehlende Felder werden mit Standardwerten gefüllt. Diese Reparaturfunktion wird kontinuierlich auf Basis von Kundenfeedback weiterentwickelt und ist produktionsreif.

Beispiele für automatische Reparaturen:

• Fehlende optionale Felder werden mit korrekten Standardwerten befüllt
• Bekannte Formatfehler in Identifikationsfeldern werden korrigiert
• Unvollständige Kontaktdaten werden ergänzt (wenn das ElectronicMail-Feld des Lieferanten leer ist, füllt eConnect automatisch support@econnect.eu ein, damit abgelehnte Rechnungen trotzdem beim Absender ankommen)

Wenn der Empfänger ein anderes Format als das Quellformat unterstützt, transformiert die PSB das Dokument automatisch. Eine NLCIUS-Rechnung kann beispielsweise in XRechnung transformiert werden, wenn der Empfänger eine deutsche Behörde ist. Dies ist möglich, weil alle unterstützten Formate auf demselben semantischen Modell (EN 16931) basieren.

Technisch: Beim Herunterladen einer Rechnung über die API können Sie über den Parameter targetDocumentTypeId das gewünschte Empfangsformat angeben. Die PSB transformiert das Dokument dann in dieses Format.

ZUGFeRD und Factur-X sind hybride Rechnungsformate: eine PDF/A-3-Datei mit einer eingebetteten CII-XML-Rechnung. Bei diesen Dokumenten versucht die Plattform zunächst, die eingebettete XML aus dem PDF zu extrahieren. Wenn die XML gültig ist, wird sie direkt verarbeitet, genau wie eine reguläre XML-Rechnung. Erst wenn sich die eingebettete XML als ungültig erweist, fällt das System auf die OCR-Verarbeitung via IDR zurück.

Eine ZUGFeRD-Rechnung, die in externen Validatoren besteht, aber dennoch via OCR verarbeitet wird, weist auf ein Problem mit der eingebetteten XML im eConnect-Validierungsprozess hin. In diesem Fall können Sie den Support kontaktieren.

Technisch: Die Legacy-Plattform kann ausschließlich gültige UBL-Rechnungen speichern. Wenn eine ZUGFeRD-Rechnung via IDR als PDF verarbeitet wird, muss die IDR-Ausgabe zunächst in gültige UBL (BIS Billing V3 oder NLCIUS) transformiert werden. Wenn diese Transformation fehlschlägt, weil die Quelldaten nicht genügend Felder für eine gültige UBL-Rechnung enthalten, kann die Plattform die Rechnung nicht speichern. In der PSB/Control ist dies weniger problematisch, da Rechnungen dort im Originalformat gespeichert und erst bei der Zustellung transformiert werden.

Wenn Sie eine XML-Datei einreichen, die nicht gültig ist, fällt das System automatisch auf das mitgesendete PDF zurück. Dies funktioniert wie folgt:

1. Die Plattform versucht zunächst, die XML-Komponente zu verarbeiten.
2. Wenn die UBL nicht gültig ist, wird das mitgesendete PDF als Fallback aufgegriffen.
3. Das PDF wird über die IDR-Route (OCR und Mustererkennung) verarbeitet.

Dieser Mechanismus stellt sicher, dass die Rechnung immer verarbeitet wird, auch wenn die XML Fehler enthält. Es ist jedoch eine teurere und langsamere Route als die direkte XML-Verarbeitung.

SI-UBL 1.2 (Simplerinvoicing 1.2) wurde zum 1. Januar 2024 endgültig eingestellt. Rechnungen in diesem Format werden im Peppol-Netzwerk abgelehnt. eConnect kann veraltete SI-Dateien, die per E-Mail eingehen, manchmal noch in gültiges NLCIUS transformieren, sofern die wesentlichen Daten vorhanden sind. Bei fehlenden Daten kann die Validierung fehlschlagen.

Achtung: Erhalten Sie Fehlermeldungen beim Versenden von Rechnungen? Prüfen Sie, ob Ihr Softwarepaket noch SI-UBL 1.2 generiert. Wenn ja, bitten Sie Ihren Anbieter um ein Upgrade auf NLCIUS/SI-UBL 2.0 oder BIS Billing V3.

Die Verarbeitung unterscheidet sich leicht zwischen der Legacy-Plattform und PSB/Control:

• Legacy-Plattform: Eine Rechnung wird immer zuerst in gültige UBL (BIS Billing V3 oder NLCIUS) transformiert, bevor sie gespeichert wird. Wenn diese Transformation fehlschlägt, kann die Rechnung nicht gespeichert werden.
• PSB/Control: Eine Rechnung wird bei Empfang validiert und gespeichert. Die Transformation findet erst später statt, wenn sie benötigt wird, z.B. bei der Zustellung an ein ERP-System. Dies bedeutet, dass eine Rechnung in der PSB gespeichert werden kann, aber später ein Transformationsfehler auftreten kann, wenn das Zielformat nicht generiert werden kann.

Eine Adresse auf der Rechnungsanzeige, die eine Mischung aus Hausadresse und Postfachangaben zeigt, ist keine Vermischung, die eConnect beim Empfang vornimmt. eConnect gibt UBL-Adressfelder (cac:PostalAddress) 1:1 weiter und schreibt oder normalisiert Adressen nicht um. Vermischt die Quell-UBL Hausadress- und Postfachkomponenten in einem PostalAddress-Block, folgt die Anzeige dieser Quelle.

Ein typisches Vermischungsmuster in der Quell-UBL:

• cbc:StreetName = Straße und Hausnummer (Hausadresse)
• cbc:AdditionalStreetName = Postleitzahl der Hausadresse, im falschen Feld
• cbc:BuildingName = Postfach N (das kanonische Postfachfeld in UBL ist cbc:Postbox)
• cbc:PostalZone = Postleitzahl des Postfachs

Die Rechnungsanzeige zeigt dann oft die Straßenzeile zusammen mit PostalZone/CityName, was eine visuell "vermischte Adresse" ergibt, ohne dass eConnect Felder kombiniert oder korrigiert. Beide Adresskomponenten können für sich genommen korrekt sein, aber ihre Kombination in einem gemeinsamen Adressblock mit vertauschten Postleitzahlen ist ein Mapping-Fehler in der Quell-UBL.

Maßnahme: Öffnen Sie die Quell-UBL und prüfen Sie die PostalAddress-Kindelemente der betreffenden Partei. Der Lieferant korrigiert das Mapping: entweder eine konsistente Hausadresse (StreetName mit passender PostalZone), oder ein Postfach im richtigen Postfachfeld (Postbox) mit der zugehörigen Postleitzahl -- nicht beides vermischt mit vertauschten Postleitzahlen. Nach einer korrekten Quell-UBL stimmt die Anzeige von selbst.

Beispiel -- Kreditrechnung „Payee/Empfänger = eigene Organisation": Bei Gutschrift versus Lastschrift tauschen AccountingSupplierParty und AccountingCustomerParty nicht. Die Richtung (zu zahlen oder zu empfangen) steckt im Dokumenttyp und im Vorzeichen von PayableAmount, nicht in umgekehrten Parteien. eConnect passt Parteirollen nicht an und wendet eine frühere Payee-Korrektur nicht automatisch erneut an, wenn die Quell-UBL bereits korrekt ist -- dasselbe Passthrough-Prinzip wie oben. Ausgearbeitet mit Beispiel: Gutschrift-Varianten.

Suchvarianten: "Gutschrift Payee", "Kreditrechnung Payee eigene Organisation", "Supplier Customer wechseln Gutschrift".

Möchten Sie prüfen, ob Ihre XML-Datei korrekt verarbeitet wird? Nutzen Sie den kostenlosen eConnect Validator, um Ihre Rechnung vorab zu testen.

• Der Aufbau einer UBL-Rechnung
• Was ist der Unterschied zwischen XML, UBL, BIS Billing V3 und NLCIUS?
• Wichtige Sendefelder in UBL
• SEEF: die Standard-Energie-E-Rechnung
• XML-Beispieldateien herunterladen
• Von Semantik bis Syntax