Beim Versenden einer Rechnung über die eConnect-Plattform kann es vorkommen, dass Sie eine Fehlermeldung erhalten. Die meisten Fehlermeldungen hängen mit fehlenden oder falschen Daten in der Rechnung zusammen. Nachfolgend finden Sie die häufigsten Meldungen, ihre Ursache und die Lösung.

Diese generische Fehlermeldung wird durch die Pre-Versand-Validierung in der Plattform-UI ausgelöst. Die Plattform prüft vor dem Versand, ob der Identifier-Wert (z. B. OINO, Handelsregisternummer) dem erwarteten Format entspricht. Schlägt diese Prüfung fehl, erscheint diese Fehlermeldung.

Häufiges Beispiel: SchemeID 0190 (OINO) erfordert genau 20 Stellen. Enthält der Wert einen Präfix — z. B. NL:OINO:00000001001932779000 statt nur 00000001001932779000 — schlägt die Validierung fehl.

Hinweis: Dieser Fehler kann auch bei Rechnungen auftreten, die über die API erstellt wurden, nicht nur bei manuell erstellten Rechnungen.

Lösung: Prüfen Sie die Identifier-Werte und entfernen Sie ggf. Präfixe oder ungültige Zeichen. Der Wert muss genau dem erwarteten Format bei der SchemeID entsprechen (z. B. 20 Stellen für OINO, 8 Stellen für Handelsregisternummer).

Allgemeine Regel -- geben Sie nur den numerischen Wert ein; die Plattform fügt den SchemeID-Präfix automatisch hinzu. Dies gilt für jedes Identifikationsschema, nicht nur OINO. Gibt der Benutzer den Präfix selbst ebenfalls ein (z. B. 0088:1234567890123, obwohl das Schema bereits auf GLN/0088 steht), schlägt die Formatvalidierung fehl. GLN-Beispiel (SchemeID 0088, GS1): Wählen Sie Schema GLN und tragen Sie im Wertefeld nur die GLN-Ziffern ein -- nicht 0088: davor.

Wenn ein Lieferant in der XML einen Apostroph vor die OIN-Nummer setzt (ein bekanntes Excel-Artefakt), schlägt die Peppol-Routierung fehl. Das Legacy-System erkennt die Rechnung und stellt sie intern zu — der Empfänger sieht keine Rechnung in seinem Kreditorenpostfach, erhält jedoch eine Benachrichtigungs-E-Mail mit einem Link.

Lösung: Bitten Sie den Lieferanten, die OIN-Nummer ohne Apostroph in der XML anzugeben und die Excel-Exporteinstellungen zu prüfen.

Bei Sendefehlern aus 4PS ist die Ursache oft nicht sofort erkennbar. Gehen Sie nicht von vornherein davon aus, dass eine fehlende PSB-Verbindung (Peppol Service Bus) die Ursache ist.

Vorgehensweise:

1. TechSupport stellt die Ursache fest. Leiten Sie nicht auf Basis einer Vermutung direkt an den Vertrieb weiter.
2. Ursache ist eine fehlende aktive PSB-Verbindung bei eConnect? Dann ist der nächste Schritt der Vertrieb für das PSB-Onboarding. Geben Sie dem Kunden keine 4PS-Konfigurationsberatung — ohne PSB-Verbindung gibt es nichts zu konfigurieren.
3. Ursache ist etwas anderes? Behandeln Sie es über die entsprechende Fehlermeldung oder Lösung auf dieser Seite (oder in den 4PS-Integrationsseiten).

Kurz: Die Diagnose durch TechSupport geht immer dem Vertriebsweg vor. Der Vertriebsweg (PSB-Onboarding) gilt nur, wenn TechSupport festgestellt hat, dass eine fehlende PSB-Verbindung die Ursache ist.

Die Plattform validiert jede Rechnung anhand der geltenden Peppol- und NLCIUS-Standards, bevor sie versendet wird. Fehlercodes, die mit BR (Business Rule) beginnen, zeigen an, welche Regel nicht eingehalten wurde.

Ihre eigene Organisation (der Lieferant) ist in der Rechnung nicht korrekt ausgewählt. Das passiert, wenn das Lieferantenfeld manuell geändert wurde oder wenn die Organisation noch nicht aktiviert ist.

Lösung: Klicken Sie auf das Stiftsymbol neben "Lieferant" und wählen Sie Ihre Organisation erneut aus. Wenn Ihre Organisation noch nicht aktiviert ist, erledigen Sie das zunächst über Organisation hinzufügen und aktivieren.

Sie haben einen Anhang mit einem MIME-Typ hinzugefügt, der in der aktuellen Peppol BIS Billing V3-Validierung nicht zulässig ist. Folgende Anhangstypen sind erlaubt (BT-125):

application/xml ist nicht zulässig als Anhang-MIME-Typ in der aktuellen BIS Billing V3-Validierung. XML als Anhang gehört zu EN 16931-1:2026 und einer zukünftigen Peppol-Version (möglicherweise BIS Billing 4.0) — fügen Sie keinen XML-Anhang hinzu, um BR-CL-24 zu beheben.

Häufige Ursache (Business Central, Unit4 ERPx und andere ERPs): Das ERP bettet automatisch Anhänge ein, die der gebuchten Rechnung zugeordnet sind, oder exportiert unvollständige UBL-Blöcke. Ein nicht unterstützter Anhangstyp (z. B. ein Word-Dokument) verursacht BR-CL-24; fehlendes BT-122 führt zu BR-52; Überweisung ohne IBAN zu BR-61; leere Tags zu PEPPOL-EN16931-R008. Mehrere Codes gleichzeitig deuten auf die Payload/ERP-Export hin, nicht auf eine eConnect-Umgebungsstörung. Vorab prüfen über den Document Validator.

Lösung:

1. Prüfen Sie, welche Anhänge der Rechnung im ERP zugeordnet sind (Business Central: Gebuchte Verkaufsrechnung > Anhänge).
2. Entfernen oder ersetzen Sie Anhänge mit einem nicht zulässigen Typ -- exportieren Sie z. B. ein Word-Dokument als PDF.
3. Senden Sie die Rechnung erneut.

BR-52 tritt auf, wenn der Block zusätzliches Dokument (BG-24) ohne Supporting document reference (BT-122) vorhanden ist. Das kommt u. a. bei ERP-UBL-Export vor, z. B. Unit4 ERPx in Test oder Pilot.

Lösung: pro Anhang bzw. Dokumentreferenz eine ID (BT-122) eintragen oder den unvollständigen Anhangsblock weglassen. Die Korrektur liegt im UBL-Export des ERP, nicht bei eConnect.

BR-61 tritt auf, wenn Payment means type code (BT-81) eine Überweisung ist (z. B. SEPA oder local/non-SEPA credit transfer, Codes wie 30 oder 58) ohne Payment account identifier (BT-84, in der Regel IBAN). Das ist EN 16931 BR-61.

Lösung: IBAN oder Kontonummer in den Zahlungsdaten eintragen, oder keinen Überweisungscode senden, solange keine Kontonummer mitgeht.

PEPPOL-EN16931-R008 tritt auf, wenn die UBL leere XML-Elemente (leere Tags) enthält.

Lösung: Felder ohne Wert im UBL-Export vollständig weglassen; keine leeren Tags mitsenden. Die Korrektur liegt im ERP-/UBL-Export, nicht bei eConnect.

Die Einheit, die Sie bei einer Rechnungsposition angegeben haben, wird nicht als gültiger UN/ECE-Code erkannt. Das kommt vor, wenn Sie eine Abkürzung oder eigene Bezeichnung verwenden.

Lösung: Verwenden Sie eine Standardeinheit aus der Auswahlliste, wie "Stück" (EA), "Stunden" (HUR) oder "Tage" (DAY).

Der Identifiertyp bei "OrganisationsID" weicht vom Identifiertyp bei "Senden über" ab. Beispiel: Die OrganisationsID steht auf OIN, aber "Senden über" steht auf KvK.

Lösung: Stellen Sie sicher, dass beide Felder denselben Identifiertyp verwenden. Stellen Sie Rechnungen an Behörden, setzen Sie dann beide auf OIN/OINO. Stellen Sie Rechnungen an ein Unternehmen, verwenden Sie bei beiden KvK (0106).

Die USt-Nummer des Lieferanten fehlt in der Rechnung.

Lösung: Tragen Sie Ihre USt-Nummer in den Organisationseinstellungen ein.

Hat Ihre Organisation keine USt-Nummer (zum Beispiel eine Stiftung, Behörde oder ein Gesundheitsdienstleister, der ausschließlich mehrwertsteuerbefreite Leistungen erbringt)? Verwenden Sie nicht den Platzhalterwert NL000000000B01. Wählen Sie stattdessen MwSt.-Kategorie 'O' — nicht steuerbar beim Erstellen der Rechnung. Bei Kategorie 'O' entfällt die Pflicht zur Angabe einer USt-Nummer und die Rechnung entspricht dem Peppol-Standard. Siehe auch Steuerschuldumkehr und MwSt.-Kategorie O für eine Erklärung der MwSt.-Kategoriecodes.

Stiftungen, bestimmte Behörden und Gesundheitsdienstleister, die ausschließlich mehrwertsteuerbefreite Leistungen erbringen, haben keine USt-Nummer. Beim Erstellen einer Rechnung über die Plattform erscheint dann die Pflichtangabe für eine Lieferanten-USt-Nummer.

Lösung: Wählen Sie im Rechnungsformular MwSt.-Kategorie 'O' — nicht steuerbar (UNCL5305-Code O, "Services outside scope of tax"). Bei Kategorie 'O' entfällt die UI-Pflicht für das USt-Nummern-Feld und die Rechnung kann ohne Lieferanten-USt-Nummer versendet werden.

Verwenden Sie keine USt-Platzhalterwerte wie NL000000000B01 — das ist nicht die vorgesehene Lösung für dieses Szenario. Kategorie 'O' ist die richtige Wahl für Organisationen ohne USt-Pflicht.

Unterschied 'E' und 'O': MwSt.-Kategorie 'E' (Exempt from VAT) ist für mehrwertsteuerpflichtige Organisationen vorgesehen, die eine spezifische steuerbefreite Transaktion abrechnen. Kategorie 'E' erfordert eine USt-Nummer. Kategorie 'O' ist für Organisationen ohne jegliche USt-Pflicht.

Bei Rechnungen an die niederländische Zentralregierung (Basisfactuur Rijk, über Digipoort) ist eine IBAN-Nummer Pflicht.

Lösung: Tragen Sie Ihre IBAN-Nummer bei den Zahlungsdaten der Rechnung ein. Es ist generell empfehlenswert, immer eine IBAN in Ihre Rechnung aufzunehmen, da dies in Zukunft breiter verpflichtend wird.

Dieser Fehler tritt auf, wenn die CompanyID (das Feld PartyLegalEntity in der UBL) eine USt-Nummer statt einer KvK-Nummer oder OIN enthält. Das ist nicht zulässig: Die NLCIUS-Validierung verlangt, dass niederländische Parteien immer eine KvK-Nummer (schemeID 0106) oder OIN (schemeID 0190) als CompanyID verwenden. NL-R-003 gilt für den Lieferanten, NL-R-005 für den Kunden.

Die Verwechslung entsteht, weil die EndpointID (die Peppol-Adresse, die für die Routierung verwendet wird) durchaus eine USt-Nummer enthalten darf (schemeID 9944). Eine Rechnung mit einer USt-Nummer als EndpointID kommt also problemlos im Peppol-Netzwerk an, wird aber dennoch abgelehnt, wenn dieselbe USt-Nummer auch in der CompanyID steht.

Technisch: EndpointID und CompanyID sind zwei separate Felder mit je einem eigenen Zweck. Die EndpointID bestimmt die Routierung über Peppol und akzeptiert jeden Typ aus der EAS-Codeliste (darunter 9944 für USt-Nummern). Die CompanyID identifiziert die juristische Person und muss für niederländische Parteien immer eine KvK (0106) oder OIN (0190) sein.

Lösung: Prüfen Sie die von Ihrem System generierte UBL und stellen Sie sicher, dass die CompanyID eine KvK-Nummer oder OIN enthält, auch wenn die EndpointID eine USt-Nummer ist. Beide Felder müssen auf dieselbe Organisation verweisen, dürfen aber einen unterschiedlichen Identifiertyp haben.

Tipp: Die ViDA-Gesetzgebung verschärft die Beziehung zwischen EndpointID und CompanyID schrittweise. Stellen Sie sicher, dass Ihre Integration bereits jetzt korrekt eingerichtet ist, damit Sie nicht von zukünftigen Regeländerungen überrascht werden.

Suchvarianten: "BR-AE-10", "SOAP:CLIENTBR-AE-10", "Reverse charge shall have a VAT exemption reason", "BT-120", "BT-121", "fehlender Befreiungsgrund Steuerschuldumkehr", "Rechnungen abgelehnt reverse charge".

BR-AE-10 tritt auf, wenn eine MwSt.-Kategorie AE (Reverse Charge) in der MwSt.-Aufschlüsselung (BG-23) keinen Befreiungsgrund enthält: weder BT-121 (Code) noch BT-120 (Text, z.B. "Steuerschuldnerschaft des Leistungsempfängers" oder "Reverse charge"). Dies ist ein Fehler in der gelieferten UBL aus dem ERP oder der Rechnungssoftware -- eConnect validiert die Rechnung, passt AE-Felder aber nicht automatisch an.

Lösung:

1. Prüfen Sie, ob jede Rechnungsposition oder jeder Zuschlag mit MwSt.-Kategorie AE einen MwSt.-Satz von 0% hat.
2. Füllen Sie im UBL-Export des Quellsystems das Feld TaxExemptionReason (BT-120) und/oder den Code (BT-121) für jede AE-Aufschlüsselung aus.
3. Validieren Sie die Rechnung vorab über den Document Validator.
4. Senden Sie die korrigierte Rechnung erneut -- das erneute Senden der ursprünglichen, fehlerhaften XML löst dies nicht.

Siehe auch Steuerschuldumkehr: Codes K, AE und G für die vollständige Erklärung der Steuerschuldumkehr-Codes.

Diese EN 16931-Validierungsregeln prüfen, ob die MwSt.-Aufschlüsselung und die Rechnungssummen untereinander konsistent sind. Die Werte werden vom versendenden Softwarepaket berechnet — dabei handelt es sich nicht um Felder, die Sie in der eConnect-UI korrigieren können.

Suchvarianten BR-CO-12 / BR-E-01: "BR-CO-12", "BR-E-01", "ChargeTotalAmount", "BT-108", "Zuschlagssumme stimmt nicht", "Versandkosten nicht auf Rechnungsposition", "Shipping costs AllowanceCharge", "Exempt-Aufschlüsselung fehlt".

BR-CO-12 tritt auf, wenn die Zuschlagssumme auf Rechnungsebene nicht mit der Summe der einzelnen Dokumentzuschläge übereinstimmt — zum Beispiel bei Versandkosten, die als separater AllowanceCharge auf Rechnungsebene aufgenommen wurden (ChargeIndicator=true, Grund "Shipping costs" / Code FC). Dies ist gültiges UBL; siehe Zuschläge und Rabatte für den Aufbau. BR-E-01 tritt auf, wenn eine Rechnungsposition, ein Dokumentzuschlag oder -rabatt mit MwSt.-Kategorie 'Von der MwSt. befreit' (E) keine passende Exempt-Aufschlüsselung in der MwSt.-Zusammenfassung hat.

Häufige Ursache: MwSt. je Position runden statt je MwSt.-Satz, oder eine Diskrepanz zwischen Positionsbeträgen und Rabatten auf Rechnungsebene.

Lösung: Wenden Sie sich an den Anbieter des versendenden Softwarepakets, um eine Korrektur zu erhalten. eConnect kann diese Werte nicht nachregeln, da die Berechnung in der gelieferten XML festgelegt ist.

Suchvarianten: "Invalid payload BR-S-08", "Delivery Failed BR-S-08", "MwSt.-Zusammenfassung stimmt nicht", "Rechnungsposition keine Menge", "fehlende Menge Rechnungsposition", "BT-116", "VAT category taxable amount".

Neben Rundungsfehlern schlägt BR-S-08 auch fehl, wenn eine Rechnungsposition keine (oder eine leere) Menge hat (Invoiced quantity / BT-129). Dann stimmt der Positionsbetrag exkl. MwSt. nicht (Menge x Einzelpreis plus Positionszuschläge minus Positionsrabatte), wodurch die Summe der Positionen vom VAT category taxable amount (BT-116) in der MwSt.-Aufschlüsselung für Standard rated abweicht. Die wörtliche Fehlermeldung sieht oft so aus: Invalid payload. [BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is Standard rated, the VAT category taxable amount (BT-116)....

Unterschied zu xs:decimal-Fehlern: Im Abschnitt "'...ist kein gültiger xs:decimal'" oben ist das Betragsfeld selbst keine gültige Dezimalzahl (leer oder wissenschaftliche Notation). Bei BR-S-08 ist das Betragsfeld eine gültige Zahl, aber die Berechnung zwischen Positionsbeträgen und MwSt.-Aufschlüsselung stimmt nicht.

First-Line-Checkliste (vor Eskalation an den Softwarelieferanten):

1. Prüfen Sie alle Rechnungspositionen auf eine ausgefüllte Menge und einen Positionsbetrag exkl. MwSt..
2. Positionsbetrag = Menge x Einzelpreis (plus Positionszuschläge, minus Positionsrabatte); keine leeren Betragsfelder.
3. Lassen Sie die MwSt.-Summen im Quellsystem neu berechnen.
4. Senden Sie eine korrigierte Rechnung über Peppol. Erneutes Senden desselben Dokuments ohne Korrektur löst BR-S-08 nicht -- Erneut versenden im Postausgang passt keine Positions- oder MwSt.-Beträge an (gleicher Resend-Scope wie bei R120 oben).
5. Tritt der Fehler bei vollständigen Mengen weiterhin auf? Dann handelt es sich um einen Rundungsfehler oder einen anderen Berechnungsfehler im ERP oder UBL-Export -- weiter an den Softwarelieferanten.

MwSt.-Kategorie E vs. O: Hat die Organisation keine USt-Nummer (Stiftung, Behörde, Gesundheitswesen)? Verwenden Sie Kategorie O (nicht steuerbar) — siehe Abschnitt "MwSt.-befreite Organisationen: Kategorie O" oben. Kategorie E erfordert immer eine USt-Nummer.

R120 ist eine Berechnungsregel, die prüft, ob LineExtensionAmount = (Quantity × PriceAmount ÷ BaseQuantity) + Zuschläge − Rabatte. R120 verbietet nicht explizit negative Beträge; die Validierung schlägt fehl, wenn die Berechnung nicht aufgeht. Das tritt häufig auf, wenn ein Positionsrabatt (AllowanceCharge auf Positionsebene) den Artikelpreis übersteigt.

Lösung: Verwenden Sie den Netto-Gutschriftsbetrag direkt als PriceAmount und lassen Sie das AllowanceCharge-Element auf der Position weg. Weitere Details und ein XML-Beispiel finden Sie im Artikel Zuschläge und Rabatte.

Diese drei Fehlercodes erscheinen, wenn die Rechnung technisch gesendet wurde, aber der Empfänger oder Validator den Inhalt aufgrund von Basisfeldern in der UBL/XML ablehnt. Die Ursache liegt in der XML-Datei selbst, nicht in der Peppol-Verbindung, der Peppol-ID oder der Zustellart an den Kunden.

Lösung: Passen Sie die betreffenden Felder in der Software an, in der die Rechnung erstellt wird -- CustomizationID und ProfileID sind feste Werte pro Dokumenttyp, keine Einstellung in der eConnect-Plattform. Fehlen sowohl BuyerReference als auch OrderReference, fügen Sie eines von beiden hinzu, bevor die Rechnung erneut gesendet wird.

Hinweis zu R007 und anderen BIS-Profilen: Der Standardwert in der Tabelle gilt für eine reguläre Rechnung/Gutschrift. Self-Billing und andere Peppol-BIS-Profile (z. B. Self-Billing-Invoicing) haben eine eigene, abweichende ProfileID. Erzwingen Sie den Standardwert nicht bei Rechnungen, die bewusst ein anderes BIS-Profil verwenden -- prüfen Sie zuerst, welches Profil zutrifft, bevor Sie dieses FAQ anwenden.

Nicht zu verwechseln mit: einer fehlenden Peppol-Registrierung beim Empfänger, einer falschen EndpointID, einem Access-Point-Ausfall oder der Meldung "keine Validierungsregeln verfügbar" (siehe den entsprechenden Abschnitt weiter unten) -- diese Fälle haben andere Symptome als diese Kombination aus Spezifikation, Profil und Referenz.

Dieser Fehler tritt auf, wenn cbc:InvoiceTypeCode (BT-3) den Wert 326 (Teilrechnung) oder 384 (Korrekturrechnung) hat, während Lieferant und Empfänger nicht beide deutsche Organisationen sind. Die Peppol-BIS-Billing-3.0-Regel PEPPOL-EN16931-P0112 erlaubt 326 und 384 nur, wenn beide Parteien deutsch sind.

Portal-UI: Die Rechnungstyp-Auswahl befindet sich rechts im Rechnungsentwurf. Kundenseitige Labels umfassen u. a. Teilrechnung (neben den Standardbegriffen "Korrekturrechnung" und "Handelsrechnung") -- leicht zu übersehen.

Lösung (Portal, Rechnung NL oder nicht-DE):

1. Gehen Sie zu Verkaufsrechnung → Rechnung erstellen.
2. Rechts im Entwurf: prüfen Sie den Rechnungstyp -- achten Sie auf das Label Teilrechnung.
3. Wählen Sie Handelsrechnung (Typcode 380) statt Korrekturrechnung, außer es handelt sich um eine echte Korrektur und sowohl Absender als auch Empfänger sind deutsch.
4. Für eine Korrektur an einen nicht-deutschen Empfänger: verwenden Sie eine Gutschrift oder eine negative 380 plus eine neue Rechnung -- siehe Gutschrift-Varianten. Verwenden Sie Typcode 326/384 nicht außerhalb von DE→DE.

Quelle: Peppol BIS Billing 3.0 -- PEPPOL-EN16931-P0112.

Dieser Fehler tritt bei Rechnungsposition(en) mit der USt-Kategorie Innergemeinschaftliche Lieferung / Intra-community supply (K, BT-151) auf, wenn eine verpflichtende USt-Angabe fehlt. Bei Kategorie K sind erforderlich: seller VAT (BT-31) oder seller tax representative VAT (BT-63), und buyer VAT (BT-48). Die fehlenden Angaben befinden sich in den Partei-Stammdaten (Organisation oder Debitor), nicht auf der Rechnungsposition selbst. Die Fehlermeldung verweist nicht auf eine bestimmte Zeilennummer -- die Regel greift, sobald eine der Rechnungspositionen Kategorie K verwendet.

Lösung:

1. Ermitteln Sie, welche Rechnungsposition(en) die USt-Kategorie K (innergemeinschaftliche Lieferung) verwenden.
2. Tragen Sie die USt-Nummer des Lieferanten (seller VAT) in den Organisationseinstellungen ein, oder hinterlegen Sie den steuerlichen Vertreter (seller tax representative VAT).
3. Tragen Sie die USt-Nummer des Kunden (buyer VAT) in den Debitordaten ein.
4. Senden Sie die Rechnung erneut. Das Dokument im Postausgang ist schreibgeschützt -- bei einem Fehler muss eine neue Verkaufsrechnung erstellt werden.

Belgische Peppol-IDs können zwei Formen haben:

USt-Nummernformat: BE gefolgt von genau 10 Stellen (ggf. führende Nullen ergänzen). Prüfen Sie die USt-Nummer über das VIES-Validierungstool der Europäischen Kommission (ec.europa.eu/taxation_customs/vies).

Peppol-Option erscheint nicht für belgischen Debitor? Prüfen Sie, mit welchem Identifiertyp der Debitor bei Peppol registriert ist. Einige belgische Organisationen sind nur über 0208: (KBO-Nummer) und nicht über 9925: (USt-Nummer) registriert. Versuchen Sie in diesem Fall die KBO-Nummer: die USt-Nummer ohne vorangestelltes BE (z. B. für BE0123456789 ist die KBO-Nummer 0123456789; für BE1xxxxxxxxx ist es 1xxxxxxxxx -- beide Präfixe sind gültig).

AFAS: Unternehmensnummer mit Punkten schlägt bei Peppol BIS V3 fehl. Wenn AFAS zunächst eine SI2.0-Rechnung versendet, erfolgt keine Validierung der belgischen Unternehmensnummer -- Formate mit Punkten (z. B. 0809.948.614) werden akzeptiert. Beim Wechsel auf Peppol BIS V3 tritt der Formatfehler auf, da BIS V3 die Unternehmensnummer validiert. Lösung: Der Kunde passt die Stammdaten in AFAS an und entfernt die Punkte aus der Unternehmensnummer. Das korrekte Format ist genau 10 Ziffern beginnend mit 0 oder 1, ohne Trennzeichen.

Sonstiges: Negative Preispositionen sind bei belgischen Rechnungen nicht zulässig; verwenden Sie eine negative Menge mit einem positiven Preis.

BR-DE- Fehlercodes* sind deutsche länderspezifische Validierungsregeln für XRechnung.

Fehlende Leitweg-ID (EAS 0204): tritt häufig bei der Rechnungsstellung an deutsche Behörden auf. Erfragen Sie die Leitweg-ID beim Auftraggeber und fügen Sie sie als Identifier mit SchemeID 0204 hinzu.

PDF nicht akzeptiert: Seit dem 1. Januar 2025 gilt in Deutschland eine Empfangspflicht für E-Rechnungen. Eine einfache PDF ist häufig nicht mehr ausreichend. Versenden Sie die Rechnung als XRechnung oder ZUGFeRD.

KSeF-Ablehnung: häufig verursacht durch ein ungültiges FA_VAT-XML-Format. Der eConnect PSB sorgt normalerweise für die korrekte Umwandlung in das polnische KSeF-Format.

Zertifikatsfehler: können auftreten, wenn die KSeF-Zertifikate nicht korrekt installiert sind oder abgelaufen sind.

Rate Limiting: KSeF begrenzt die Anzahl der Anfragen. eConnect setzt Stapelverarbeitung ein, um dies zu vermeiden.

UWV wendet eigene Validierungsregeln zusätzlich zur Standard-Peppol/NLCIUS-Validierung an.

• UWV Großer Geldstrom (Wiedereingliederung, Schulung, Beihilfen): OIN 00000004191771249000
• UWV Kleiner Geldstrom (Betriebsführung): OIN 00000004172892677000

Lösung je UWV-Code: Ergänzen Sie das fehlende Feld in der Rechnung. Bei der UWV001-Reihe handelt es sich um Pflichtfelder des Lieferanten; bei der UWV002-Reihe um Identifikationselemente.

Nein. eConnect ist das Peppol Access Point: Es übernimmt den Transport Ihrer Rechnung über das Peppol-Netzwerk (siehe Was ist Peppol?). eConnect ist keine Buchhaltungs- oder Rechnungssoftware.

Faustregel für die Abgrenzung: Ein Fehler, der bevor die Rechnung bei eConnect eingeht, entsteht -- zum Beispiel eine Feldvalidierung bei Stadt/Postleitzahl oder anderen Kundendatensätzen in der Software, in der die Rechnung erstellt wird -- liegt außerhalb des Verantwortungsbereichs von eConnect.

• Prüfen Sie zunächst selbst, ob die betreffenden Felder (Ort, Postleitzahl usw.) im Kundendatensatz des Empfängers in Ihrer eigenen Rechnungs-/Buchhaltungssoftware korrekt ausgefüllt sind.
• Besteht die Meldung weiterhin, wenden Sie sich an den Anbieter dieser Rechnungs-/Buchhaltungssoftware.
• Siehe auch "Lieferantenkennzeichen ist erforderlich" bzw. den entsprechenden Abschnitt zu unbekannten Bestellnummern weiter unten ("ERP-spezifisches Feld"): eConnect kann einen Fehlercode anzeigen, bedient aber nicht das ERP-/Buchhaltungspaket des Kunden selbst.

Diese Meldung erscheint im Postausgang, wenn die Rechnung nicht über das Peppol-Netzwerk beim Empfänger zugestellt werden konnte. Mögliche Ursachen:

• Empfänger nicht bei Peppol registriert: Der Empfänger hat keine aktive Peppol-Registrierung. Die Plattform bietet in diesem Fall automatisch den E-Mail-Fallback an.
• EndpointID falsch: Die Peppol-Adresse des Empfängers stimmt nicht. Prüfen Sie die KvK-Nummer oder OIN-Nummer, die Sie als Debitor angegeben haben.
• Empfangende Partei hat ein technisches Problem: Die Rechnung wurde korrekt versendet, konnte aber vom System des Empfängers nicht verarbeitet werden. Das liegt außerhalb Ihres Einflussbereichs, kontaktieren Sie den Empfänger.

Bei einer fehlgeschlagenen Zustellung können Sie die Rechnung erneut versenden und dabei die EndpointID korrigieren.

not available beim (Test-)Senden an einen Empfänger bedeutet: Der Empfänger ist auf der verwendeten Kennung nicht aktiv auf Peppol registriert, um Dokumente zu empfangen. Es handelt sich nicht um ein Problem auf der Absenderseite.

• Das Peppol-Routing läuft über die EndpointID des Empfängers (Handelsregisternummer / OIN), nicht über die USt-IdNr. des Absenders. Eine gültige USt-IdNr. macht eine Organisation für sich genommen nicht auffindbar oder erreichbar -- eine Peppol-Registrierung ist erforderlich (siehe Was ist meine Peppol-ID? und Bei Peppol registrieren).
• Bei not available bietet die Plattform automatisch den E-Mail-Fallback an, sodass das Dokument dem Empfänger trotzdem per E-Mail zugestellt werden kann.
• Hinweis für die Absenderseite: Das Versenden über Peppol funktioniert automatisch, sobald die eigene Organisation aktiviert ist. Die Aktivierung für den Produktivbetrieb ist eine KYC-Anforderung; Tests sind über das Pilotprogramm möglich (siehe Bei Peppol registrieren).

Das Lieferantenfeld enthält keine Daten. Das passiert, wenn Ihre Organisation nicht ausgewählt ist oder wenn die Organisation nicht aktiviert ist.

Lösung: Klicken Sie auf das Stiftsymbol neben dem Lieferantenfeld und wählen Sie Ihre Organisation aus. Ist Ihre Organisation noch nicht aktiviert? Folgen Sie dann zunächst den Schritten unter Organisation hinzufügen und aktivieren.

Das Lieferantenfeld akzeptiert nur eine Organisation, die Sie aus der Dropdown-Liste auswählen. Wenn Sie selbst Text in dieses Feld eingeben -- zum Beispiel Ihren eigenen Firmennamen -- anstatt die Organisation auszuwählen, wird der Lieferanten-Abschnitt der Rechnung nicht korrekt aufgebaut. Das Feld scheint ausgefüllt, aber die Rechnung wird beim Versenden abgelehnt. Dieser Fehler tritt häufig unter einer anderen Meldung auf, wie "USt-Nummer fehlt" oder "Lieferantenkennzeichen ist erforderlich".

Lösung: Entfernen Sie den eingegebenen Text aus dem Lieferantenfeld, klicken Sie auf das Feld und wählen Sie Ihre eigene Organisation aus der Dropdown-Liste aus. Versenden Sie die Rechnung danach erneut.

Dies ist dieselbe Korrekturmaßnahme wie bei "Das Feld Lieferant ist leer" und BR-NL-1: Wählen Sie Ihre eigene Organisation über das Dropdown aus. Der Unterschied ist, dass das Feld hier auf den ersten Blick ausgefüllt erscheint, da tatsächlich Text darin steht -- nur keine gültige Auswahl.

Validierungsregel BR-CO-09 prüft, ob die USt-Nummer ein gültiges Format hat. Die USt-Nummer muss immer inklusive Ländercode und ohne Punkte, Leerzeichen oder Trennzeichen eingegeben werden.

Ländercodes folgen dem ISO 3166-1 alpha-2 Standard. USt-Nummern sind erforderlich, wenn der Lieferant oder Empfänger umsatzsteuerpflichtig ist und der Steuersatz nicht befreit ist.

Wenn der eingegebene Betrag verschwindet, sobald Sie zum nächsten Schritt wechseln, enthält das Feld wahrscheinlich nicht zulässige Zeichen. Das Betragsfeld akzeptiert nur Ziffern mit einem Komma als Dezimalzeichen. Geben Sie Beträge als 100,00 ein, nicht als € 100,00 oder 100.00.

Suchvarianten: "rotes Stoppzeichen senden", "rotes Symbol senden", "Rechnung kann nicht gesendet werden", "Senden schlägt fehl", "Stoppsymbol Rechnung", "Rechnungsnotiz erforderlich", "IBAN Bankkonto erforderlich", "Mehr Infos Rechnungsnotiz", "Zahlungsdaten IBAN leer", "Pflichtfelder Rechnung senden".

Beim Senden einer manuellen Verkaufsrechnung kann ein rotes Stoppzeichen erscheinen: Die Rechnung wird nicht versendet. Die Ursache ist eine clientseitige Formularvalidierung -- kein Peppol- oder Netzwerkfehler und kein Plattformdefekt. Debitor/OIN, Peppol-Erreichbarkeit und Bestellnummer können bereits korrekt sein, während das Senden dennoch fehlschlägt, weil ein anderes Pflichtfeld leer geblieben ist.

Prüfen Sie diese beiden Felder:

1. Rechnungsnotiz (Abschnitt Mehr Infos) -- tragen Sie eine kurze Notiz oder Referenz ein, z. B. die Bestellnummer oder die mit dem Kunden vereinbarte Referenz.
2. IBAN Bankkonto (Abschnitt Zahlungsdaten) -- tragen Sie die IBAN ein, auf die die Zahlung eingeht, ggf. über Ändern. Die IBAN auf Organisationsebene ist optional, aber eine leere IBAN auf der Rechnung selbst kann das Senden trotzdem blockieren.

Unterschied zu anderen Blockaden:

• Sendeschaltfläche reagiert nicht oder zeigt Platzhalter: siehe "Peppol-Senden-Schaltfläche reagiert nicht" weiter unten (Browser-Autoübersetzung).
• Rechnung bleibt in den Entwürfen: siehe den Abschnitt dazu (Organisationseinstellung oder fehlendes "Senden über").

Schlägt das Senden nach dem Ausfüllen beider Felder weiterhin fehl? Bitten Sie um einen Screenshot der genauen Fehlermeldung, nicht nur des Stoppzeichens.

Suchvarianten: "Bankkontonummer nicht korrekt formatiert", "Bankkonto nicht korrekt formatiert", "IBAN nicht korrekt formatiert", "IBAN Formatfehler", "IBAN Leerzeichen", "Zahlungsdaten IBAN Formatierung", "manuelle Rechnung senden IBAN Fehler".

Beim Senden einer manuellen Verkaufsrechnung kann die Meldung erscheinen, dass die Bankkontonummer oder IBAN nicht korrekt formatiert ist, auch wenn die Nummer inhaltlich stimmt. Die Ursache ist eine Formatvalidierung vor dem Senden für IBAN oder Bankkonto im Abschnitt Zahlungsdaten -- kein Peppol- oder Netzwerkfehler. Leerzeichen, Bindestriche oder andere Trennzeichen (oder ein fehlender Ländercode) lassen die Prüfung fehlschlagen.

Lösung:

1. Öffnen Sie die Rechnung und gehen Sie zu Zahlungsdaten (IBAN oder Bankkonto).
2. Geben Sie die vollständige IBAN als durchgehende Zeichenfolge ein: Ländercode plus Ziffern/Buchstaben, ohne Leerzeichen, Bindestriche oder andere Trennzeichen (Form: NL00BANK0123456789).
3. Verwenden Sie keine alte Kontonummer ohne Ländercode -- niederländische Konten beginnen mit NL.
4. Speichern Sie und senden Sie die Rechnung erneut.

Unterschied zu anderen Blockaden:

• Leeres IBAN-Feld mit rotem Stoppzeichen bei Pflichtfeldern -- siehe "Rotes Stoppzeichen beim Senden" oben.
• "ID nicht korrekt formatiert" betrifft die Identifier-/schemeID-Formatierung, nicht das Bankkonto -- siehe die Abschnitte zu unbekannten Fehlern/Identifier-Validierung oben.

Erscheint die Meldung weiterhin? Bitten Sie um den genauen Feldinhalt (einschließlich Leerzeichen oder Zeichen) und die genaue Fehlermeldung oder einen Screenshot.

Suchvarianten: "Sendeschaltfläche reagiert nicht", "Ladebildschirm hängt beim Senden", "seltsamer Text auf Rechnung", "merkwürdiger Lieferantenname", "unlogische Einheit auf Rechnung", "Organisation zeigt seltsamen Text", "mehrmals anmelden zum Speichern", "erneut anmelden zum Senden", "Rechnungsfelder übersetzt", "Browserübersetzung beim Erstellen der Rechnung", "kann mich nicht anmelden", "Anmeldeseite seltsamer Text".

Wenn die Senden-Schaltfläche beim Versenden einer Peppol-Rechnung nicht reagiert oder der Ladebildschirm hängt und Sie unübersetzte Vorlagen-Syntax wie {{invoice.data.supplierDetails.name}} statt der eingetragenen Werte sehen, liegt die Ursache wahrscheinlich in der Browser-Autoübersetzung.

Dasselbe Muster kann beim Erstellen einer (neuen) Rechnung auftreten: unlogische oder „übersetzte“ Bezeichnungen/Feldwerte u. a. bei Lieferant, Organisation und Einheit, wobei Speichern oder Senden erst nach mehrfachem erneutem Anmelden gelingt. Dies hat dieselbe Ursache wie die Platzhalter an der Senden-Schaltfläche -- kein Produktfehler und kein Anlass, die Client-Software neu zu installieren (die Plattform ist browserbasiert).

Dasselbe passiert auf der Anmeldeseite von platform.econnect.eu und anderswo in der Benutzeroberfläche: Platzhaltertexte oder rohe i18n-Schlüssel (zum Beispiel {{lang.text}} oder I18N_COLLABRR_WS.*) anstelle normaler Bezeichnungen. Benutzer melden dies oft als „ich kann mich nicht anmelden“. Siehe auch Anmelden und 2FA.

Die Browser-Autoübersetzung (automatische Seitenübersetzung in Chrome oder Edge) greift in das DOM der Plattform ein. Dadurch reagieren Schaltflächen nicht mehr korrekt und Vorlagen- oder i18n-Platzhalter bzw. unlogische Feldbezeichnungen bleiben sichtbar.

Lösung (Reihenfolge First-Line):

1. Deaktivieren Sie die automatische Übersetzung im Browser für die eConnect-Plattform (u. a. platform.econnect.eu).
2. Hartes Neuladen (Strg+F5) und erneut anmelden; öffnen oder erstellen Sie die Rechnung bei Bedarf neu.
3. Immer noch nicht erfolgreich? Leeren Sie den Browser-Cache und/oder probieren Sie einen anderen Browser aus.
4. Problem besteht weiterhin? Bitten Sie um einen Screenshot der Rechnungsseite inklusive Browser und Version.

Suchvarianten: "Fehlermeldung beim Senden", "intermittierender Portalfehler", "nach Neustart geht es wieder", "Sendefehler ohne Details", "Fehlermeldung ohne Inhalt".

Manchmal meldet ein Benutzer einen Fehler beim Senden über die Plattform, ohne den genauen Fehlertext oder einen Screenshot mitzuliefern. Ohne diesen Inhalt liegen nicht genügend Informationen für eine belastbare Diagnose vor; es handelt sich nicht um eine bekannte breite Störung.

Möglicher erster Schritt (keine bestätigte Ursache):

1. Browser-Cache leeren und/oder einen anderen Browser ausprobieren.
2. Hilft das nicht, fordern Sie mehr Kontext an: die genaue Fehlermeldung oder einen Screenshot, den Zeitpunkt und die Rechnungsnummer.

Nicht zu verwechseln mit:

• Sendeschaltfläche reagiert nicht, Ladebildschirm hängt, oder unlogische Bezeichnungen/Platzhalter -- siehe "Peppol-Senden-Schaltfläche reagiert nicht" oben (Browser-Autoübersetzung, mit eigener First-Line-Reihenfolge).
• Status SentRetry oder SentError nach Annahme -- siehe den Abschnitt zur automatischen Peppol-Wiederzustellung weiter unten auf dieser Seite; das ist ein serverseitiger Retry-Mechanismus, kein Browser-Cache-Problem.

Beim Versenden einer Rechnung kann die Fehlermeldung „EndpointID fehlt“ erscheinen. Dies ist ein bekannter Plattform-Bug — es handelt sich nicht um ein Peppol-Registrierungsproblem auf Kundenseite. Eine automatische Diagnose klassifiziert dies manchmal fälschlicherweise als Registrierungsproblem; diese Klassifizierung ist falsch.

Lösung (Workaround): Öffnen Sie den Rechnungsblock → klicken Sie auf das Stiftsymbol oben rechts → wählen Sie den Lieferanten und/oder Debitor erneut aus → senden Sie die Rechnung erneut. Die Plattform baut die Identifier in der XML neu auf und kann die Rechnung dann korrekt versenden.

Dies gehört zur gleichen Stiftsymbol-Behebung wie bei „Das Feld Lieferant ist leer“ / BR-NL-1 und „Lieferantenkennzeichen ist erforderlich“. Der Unterschied liegt in der spezifischen Fehlermeldung „EndpointID fehlt“.

Diese Meldung erscheint, wenn Sie eine XML-Rechnung auf der Plattform hochladen. Die Plattform übernimmt die Daten aus der XML, aber der Lieferanten-Identifier fehlt in der Datei. Dadurch kann die Plattform die Rechnung nicht versenden.

Lösung: Klicken Sie auf das Stiftsymbol neben dem Lieferantenfeld und wählen Sie Ihre Organisation erneut aus. Die Plattform baut dann den Lieferantenbereich neu auf und fügt die erforderlichen Identifier in die XML ein.

Dies ist dieselbe Maßnahme wie bei „Das Feld Lieferant ist leer“ und BR-NL-1: Wählen Sie Ihre eigene Organisation erneut über das Stiftsymbol aus. Der Unterschied besteht darin, dass hier die spezifische Meldung „Lieferantenkennzeichen ist erforderlich“ aufgrund eines fehlenden Lieferanten-Identifiers in der hochgeladenen XML erscheint.

Suchvarianten: „Keine versandaktivierten Kennungen für das Lieferantenunternehmen gefunden“, versandaktivierte Kennungen, „Lieferantenverifizierung noch nicht erfolgt“, Rechnung neue Administration versenden, zwei Organisationen mit und ohne GmbH, Kennungen nicht verifiziert.

Diese Meldung, und die Kundenformulierung „Lieferantenverifizierung noch nicht erfolgt“ bei einer ersten Rechnung oder neuen Administration, deutet meist nicht auf einen separaten Lieferanten-KYC-Schritt hin. Die Ursache liegt fast immer in einem dieser vier Punkte.

Checkliste (in Reihenfolge):

1. Richtige Lieferantenorganisation ausgewählt? Bei zwei ähnlichen Organisationen (z. B. derselbe Name mit und ohne „GmbH“) kann die falsche gewählt worden sein. Wählen Sie über das Stiftsymbol die Organisation mit verifizierten Kennungen — eine Organisation ohne verifizierte Kennungen kann nicht versenden.
2. Organisation aktiviert? Noch nicht aktiviert: zuerst aktivieren über Organisation hinzufügen und aktivieren.
3. Schalter „Versenden“ aktiv? Gehen Sie zu Organisationen → Ihre Organisation → Details und prüfen Sie, ob mindestens eine Kennung (vorzugsweise Handelsregisternummer) den Schalter Versenden aktiviert hat. Bei einer aktivierten Organisation ist dies in der Regel bereits der Fall.
4. USt-IdNr. korrekt? Prüfen Sie sowohl Lieferanten- als auch Debitoren-USt-IdNr. auf Ländercode und Trennzeichen — siehe BR-CO-09 oben. Ein USt-Formatfehler kann gleichzeitig mit dieser Meldung auftreten.

Besteht die Meldung nach diesen vier Schritten weiterhin, versenden Sie die Rechnung erneut, nachdem die Organisations- oder Rechnungsdaten korrigiert wurden.

Wenn eine Rechnung nicht versendet werden kann und im Ordner "Entwürfe" verbleibt, prüfen Sie zwei Dinge:

1. Versand aktiviert: Prüfen Sie in den Organisationseinstellungen, ob "Versenden von Dokumenten" aktiviert ist. Falls nicht, kontaktieren Sie den Support.
2. Senden über eingestellt: Beim Abschnitt "Debitor" muss neben der OrganisationsID auch eine "Senden über"-Option ausgewählt sein. Ohne diese Einstellung kann die Rechnung nicht versendet werden.

Die eConnect-Plattform verwendet manchmal einen Namespace-Präfix in generierten UBL-Rechnungen (z. B. <urn:Invoice xmlns:urn="...">). Beide Formen — mit und ohne Präfix — sind technisch gültiges XML.

Ein Empfänger, der Rechnungen aufgrund des Namespace-Präfixes ablehnt, ist nicht Peppol-konform. Der Namespace-Präfix ist nicht pro Empfänger konfigurierbar.

Kommunikation an Kunden: Die Rechnung ist technisch korrekt. Der Empfänger muss einen korrekten XML-Parser verwenden, der sowohl Präfix- als auch Standard-Namespaces verarbeitet. Eine Ablehnung aufgrund des Namespace-Präfixes ist innerhalb von Peppol nicht zulässig.

EBMS-Fehlercodes wie EBMS:0003 und EBMS:0004 sind AS4-Transportfehler bei der Kommunikation zwischen Access Points. Kunden sehen im Platform SentError oder SentRetry — der EBMS-Code selbst ist in der Kundenoberfläche nicht sichtbar.

Maßnahme: Verweisen Sie den Kunden an TechSupport. TechSupport kann die Fehlerdetails über den Auditpfad und Application Insights einsehen.

Fehlercode Status 40 bedeutet, dass das Dokument nicht erfolgreich verarbeitet wurde. Zwei mögliche Ursachen:

1. IDR-Verarbeitungsfehler: Die IDR kann das Dokument nicht verarbeiten und gibt Status 40 zurück.
2. Plattformseitige Ablehnung: Die IDR hat das Dokument verarbeitet, aber die Plattform setzt es anschließend auf Status 40 (z. B. durch einen Validierungsfehler nach der Konvertierung).

Diagnose: Ein eConnect-Mitarbeiter muss in CloudWatch untersuchen, welche Verarbeitungsschritte das Dokument durchlaufen hat.

Über die Option Erneut versenden im Postausgang können Sie eine bereits gesendete Rechnung erneut einreichen. Vor dem eigentlichen Versand können Sie noch Felder wie die Referenz (Bestellnummer, OrderReference) anpassen. Die Rechnung wird dann mit derselben Rechnungsnummer, aber mit der korrigierten Referenz erneut versandt.

Dies ist die empfohlene Vorgehensweise, wenn ein Empfänger eine Rechnung wegen einer falschen Bestellnummer oder eines anderen Referenzfehlers ablehnt. Es erspart die Notwendigkeit, eine Gutschrift und eine neue Rechnung zu erstellen.

Veraltete oder geänderte EndpointID (z. B. nach einer USt-Nummer-Änderung beim Empfänger): Wurde eine Rechnung an eine falsche oder inzwischen geänderte Peppol-ID gesendet, ist Erneut versenden mit Korrektur der EndpointID die bevorzugte Vorgehensweise -- nicht Gutschrift plus Neurechnung. Gehen Sie zum Postausgang, suchen Sie die Rechnung, die an die falsche Peppol-ID gegangen ist, klicken Sie auf Erneut versenden, korrigieren Sie vor dem Versand die EndpointID auf die richtige ID und senden Sie die Rechnung. Sie wird unter derselben Rechnungsnummer erneut an die richtige Peppol-ID gesendet. Überprüfen Sie die richtige ID über das Peppol Directory.

Eine Gutschrift mit vollständiger Neurechnung ist für dieses Szenario nicht erforderlich. Diese schwerere Route gilt nur, wenn die ursprüngliche Rechnung bereits (teilweise) ausgeliefert wurde oder aus buchhalterischen Gründen korrigiert werden muss.

Erneutes Versenden kann ein Kunde nur selbst durchführen mit einem aktivierten Plattform-Konto mit Zugriff auf den Postausgang. Ein IT-Partner ohne eigenes Konto muss sich zunächst registrieren.

In der aktuellen Peppol BIS Billing 3.0 und NLCIUS wird pro Rechnung nur 1 Bestellreferenz (OrderReference) unterstützt. Dies ist eine Einschränkung, die aus der europäischen Norm EN 16931 resultiert. Wenn eine Rechnung mehrere Bestellungen abdeckt, muss der Lieferant separate Rechnungen senden.

AdditionalDocumentReference kann zusätzliche Referenzen anderer Typen enthalten (Projekt-, Vertrags- oder Käuferreferenz), jedoch keine mehreren OrderReferences.

Zukunft: Die überarbeitete EN 16931-1:2026 (formell von CEN am 13. März 2026 genehmigt) fügt Unterstützung für mehrere Bestellungen pro Rechnung hinzu. Dies wird voraussichtlich in einer zukünftigen Version des Peppol-Standards (möglicherweise BIS Billing 4.0) eingeführt. Bis dahin gilt in BIS Billing 3.0 und NLCIUS die aktuelle Beschränkung von 1 OrderReference pro Rechnung.

Wenn eine Rechnung wegen einer fehlenden oder unbekannten Bestellnummer abgelehnt wird, müssen zwei Ebenen unterschieden werden.

1. Eine Referenz ist gemäß EN 16931 Pflicht. Eine Referenz -- Bestellnummer oder eine andere Referenz (BuyerReference, Vertrags- oder Projektreferenz) -- ist erforderlich. Eine Rechnung ohne jegliche Referenz entspricht nicht den Grundregeln der Norm.

2. eConnect lehnt standardmäßig nicht aufgrund des Referenzinhalts ab. Die einzige Situation, in der die Plattform auf diesen Punkt ablehnt, ist, wenn überhaupt keine Referenz vorhanden ist.

3. Kundenspezifische Konfiguration kann strenger sein. Die tatsächliche Ablehnung hängt von der Konfiguration des Empfängers ab. In einer spezifischen Einrichtung kann eine Rechnung abgelehnt werden, wenn die Referenz beim Empfänger unbekannt ist. Dies ist konfigurationsabhängig und kein Standardverhalten der eConnect-Plattform.

4. Bestellnummer (BT-13, OrderReference/ID) wird vom Empfänger nicht erkannt. Eine Bestellnummer im XML sollte normalerweise vom ERP des Empfängers erkannt werden. In der Praxis schlägt das Matching aus einem der folgenden Gründe manchmal fehl:

• Das ERP-System des Empfängers ist nicht so konfiguriert, dass es den Bestellwert automatisch abgleicht.
• Der Absender übermittelt den Bestellwert auf eine nicht standardmäßige Weise (z. B. in einem anderen Referenzfeld als vom ERP erwartet).
• Der Bestellwert befindet sich in einem anderen Referenzfeld als dem, das das ERP des Empfängers auswertet.

eConnect kann dies produktseitig pro Empfänger beheben, sodass der Matching-Prozess korrekt abläuft. Dies kann auch für einen bestimmten Absender eingerichtet werden.

Maßnahme:

• Senden Sie die Rechnung über die Option Erneut versenden (siehe obigen Abschnitt) mit einer gültigen Referenz erneut.
• Ist die Bestellnummer unbekannt, wenden Sie sich an den Empfänger bezüglich der gewünschten Vorgehensweise.
• Schlägt das Matching bei einem bestimmten Empfänger dauerhaft fehl, wenden Sie sich an den Support -- eConnect kann eine maßgeschneiderte Lösung pro Empfänger (und optional pro Absender) einrichten.

Eine Rechnung mit Endstatus InvoiceSentError (nach einem 4xx-Validierungsfehler) unternimmt keine weiteren Zustellversuche. Nur 5xx-Fehler werden wiederholt (maximal 8 Versuche, ca. 35 Stunden). Bei einem 4xx-Fehler wird nur ein Versuch unternommen; es wird nichts weiteres an den Empfänger gesendet.

Es gibt keinen DELETE-Endpunkt für Ausgangsrechnungen (salesInvoice). Eine gesendete oder abgelehnte Ausgangsrechnung ist ein audit-relevantes Ereignis und bleibt 90 Tage im Auditpfad verfügbar. War die Rechnung inhaltlich fehlerhaft, stellen Sie eine Gutschrift oder Korrekturrechnung gemäß dem üblichen Buchführungsablauf aus.

Das Peppol-Netzwerk verfügt über einen automatischen Wiederzustellungs-/Retry-Mechanismus bei temporären Lieferfehlern zwischen Access Points. Wenn die Zustellung an den empfangenden Access Point (C3) vorübergehend fehlschlägt -- zum Beispiel aufgrund einer Störung auf Empfängerseite -- versucht der sendende Access Point (C2), das Dokument zu einem späteren Zeitpunkt erneut zuzustellen.

• Temporärer Fehler (5xx) = Retry; permanenter Fehler (4xx) = kein Retry. Auf eConnect-Versandebene werden nur 5xx-Fehler wiederholt (maximal 8 Versuche, ca. 35 Stunden). Ein 4xx-Validierungsfehler ist permanent und führt zu nur einem Versuch -- siehe auch den Abschnitt "InvoiceSentError" oben.
• Status in der Plattform: Während eines Retries sieht der Kunde den Status SentRetry (AS4-Transportebene). Bei endgültigem Fehlschlagen wird dieser zu SentError.
• Auswirkung bei Netzwerk- oder Access-Point-Störung: Die Rechnung kann erst mehrere Tage nach dem Versand zugestellt werden, nämlich sobald der Retry erfolgreich ist. Der Sender muss keine Maßnahmen ergreifen -- die Wiederzustellung erfolgt automatisch innerhalb des Retry-Fensters.
• Genaue Fensterlänge: Das genaue Retry-Fenster des Peppol-Netzwerks (außerhalb des eConnect-Versand-Retries) ist nicht öffentlich standardisiert und kann je nach Access Point variieren.

Dieser Wiederzustellungsmechanismus erklärt teilweise, warum das Eingangsdatum mehrere Tage nach dem Rechnungsdatum (IssueDate) liegen kann. Siehe auch Rechnungsdatum (IssueDate) vs. Eingangsdatum in eConnect für die Erläuterung auf der Empfangsseite.

Quelle: Expertenbestätigung Johan Schaeffer (Peppol & E-Invoicing), 2026-07-04, zu Ticket #15268901 (W776).

Validierungsfehler wie TaxInclusiveAmount '-1.336061E6' ist kein gültiger xs:decimal entstehen, weil das Quellsystem einen numerischen Betrag in wissenschaftlicher Notation serialisiert (z. B. -1.336061E6 für -1.336.061,00). UBL-Betragsfelder sind vom Typ xs:decimal, der keine E-Notation erlaubt.

Häufige Ursache: Das Quellsystem speichert Beträge intern als double/float und verwendet die Standard-String-Konvertierung, die bei sehr großen oder sehr kleinen Werten automatisch auf Exponent-Notation umschaltet.

Zweite, andere Ursache -- leeres Betragsfeld: Der Fehler The string '' is not a valid Decimal value bei einem PriceAmountType-Feld tritt auf, wenn ein Betragsfeld (z. B. cbc:PriceAmount) bei einer oder mehreren Rechnungspositionen einen leeren String ("") statt einer Dezimalzahl enthält. xs:decimal lässt einen leeren String als lexikalischen Wert nicht zu. Dies ist eine andere, eigenständige Ursache als die wissenschaftliche Notation, aber dieselbe Fehlermuster-Klasse ("kein gültiger xs:decimal"/"not a valid Decimal value"): Das Quellsystem lässt das Feld einfach leer, statt eine falsch formatierte Zahl zu senden.

Lösung auf Kundenseite (beide Varianten): Quellsystem anpassen, sodass Beträge immer als normale Dezimalzeichenfolge geschrieben werden (z. B. über decimal/BigDecimal-Typen oder ein gebietsschemaärmeres Dezimalmuster, ohne Tausendertrennzeichen und ohne E-Notation), und sodass kein Betragsfeld leer bleibt.

Auf eConnect-Seite: Kann nicht automatisch korrigiert werden -- der Wert ist bereits (oder leer) in der gelieferten XML falsch. An den Lieferanten des Softwarepakets weiterleiten; die Rechnung muss mit gültigem Betrag auf allen Positionen erneut eingereicht werden.

Dieses Szenario tritt auf, wenn der Lieferant behauptet, die Rechnung versendet zu haben, der Empfänger jedoch nichts erhalten hat und die Rechnung noch nicht den Endstatus 'Zugestellt' erreicht hat oder der Status unklar ist.

Diagnose in drei Schritten:

1. Sendestatus in der Plattform prüfen. Gehen Sie zu Postausgang (Plattform) oder PSB Control > Events (PSB). Der Kunde kann dies selbst prüfen (Selbstdiagnose). Zeigt die Rechnung im Postausgang 'Gesendet' oder 'Zugestellt' oder als erfolgreiches Event in PSB Control, wurde die Rechnung an das Peppol-Netzwerk übergeben. Ist die Participant-ID des Empfängers bei einem anderen oder konkurrierenden Access Point registriert, wurde die Rechnung an diesen Access Point zugestellt -- das ist dann kein eConnect-Sendeproblem.
2. Empfänger nicht aktiviert? Dann nicht routingfähig. Sie können nicht an eine nicht aktivierte Organisation senden: diese ist nicht als Participant im SMP/SML veröffentlicht und die Participant-ID ist über eConnect nicht routingfähig. Häufiger Fehler: Absender glauben, dass sie den Empfänger (ihren Kunden) ebenfalls als Organisation in der Plattform anlegen müssen -- das ist nicht notwendig. Nur die eigene sendende Organisation muss aktiviert sein; der Empfänger muss nicht im eigenen Konto vorhanden sein.
3. Empfänger ist bei einem anderen Anbieter? Migration erforderlich. Möchte der Empfänger (oder der Lieferant selbst) zu eConnect wechseln: zuerst beim alten Service Provider abmelden, dann bei eConnect registrieren. Die Organisation zuerst aktivieren, damit die Registrierung direkt durchgeführt werden kann, oder einen Migrationscode anfordern (dies läuft in der Plattform noch nicht automatisch). Siehe Peppol-Registrierung und Migration.

Für das Szenario, bei dem der Status bereits Zugestellt anzeigt, der Empfänger aber angibt, nichts erhalten zu haben, siehe den Abschnitt "Status 'zugestellt' aber Empfänger hat die Rechnung nicht erhalten" unten.

Der Status Zugestellt bedeutet, dass der empfangende Access Point (der Peppol-Dienstleister des Schuldners) das Dokument technisch akzeptiert und diese Akzeptanz bestätigt hat. eConnect erhält dabei eine returnedMessageId (Format GUID@econnect.eu): Nachweis, dass die Rechnung beim Access Point des Empfängers angekommen ist. Wo die returnedMessageId sichtbar ist, unterscheidet sich zwischen Plattform und PSB — prüfen Sie die richtige Umgebung für den Kunden.

Wenn der Schuldner angibt, die Rechnung nicht erhalten zu haben, obwohl der Status 'Zugestellt' angezeigt wird, wurde das Dokument beim Access Point des Schuldners tatsächlich abgeliefert, ist aber in dessen eigener Software oder Buchhaltung noch nicht sichtbar. Dies ist ein nachgelagertes Problem auf Empfängerseite.

Lösungsschritte:

1. Dem Kunden bestätigen, dass die Rechnung erfolgreich an den Peppol Access Point des Schuldners gesendet wurde und dass eConnect eine Zustellungsbestätigung erhalten hat.
2. Den Kunden beraten, den Schuldner zu bitten, sich an dessen eigenen Peppol-Dienstleister zu wenden. Die returnedMessageId kann dabei angegeben werden: Mit dieser ID kann der empfangende Access Point das Dokument zurückverfolgen.
3. Die weitere Abwicklung liegt beim Access Point des Schuldners; eConnect hat als sendende Partei keinen Einblick über den Lieferpunkt hinaus.

Suchvarianten: „Organisation hinzufügen“ bei einer Rechnung, Lieferantenportal, Organisationsname + Handelsregisternummer oben rechts, bestehende Organisationszeile nicht bearbeitbar, bestehende Organisation nicht umbenennbar, Screenshot Kundenorganisation oben rechts, Identifier-Meldung beim Hinzufügen einer Organisation (Lieferant), eigene Organisation separat hinzufügen, Schuldner als eigene Organisation, Rechnungsempfänger zur Umgebung hinzufügen, Behördenschuldner-Organisation aktivieren, Empfänger muss in Umgebung sein, Anmeldung unter der eigenen OIN einer Gemeinde, Kunden-OIN als eigene Organisation, Rechnung an Gemeinde mit eigener OIN, Empfänger-OIN nicht eigener Identifier, Schema 0190 Schuldner.

Neue Benutzer -- insbesondere solche, die von anderen E-Invoicing-Diensten wechseln -- versuchen manchmal, die empfangende Organisation beim Senden einer Rechnung als eigene Organisation auf der Plattform hinzuzufügen. Dies ist nicht notwendig und führt zu einer Fehlermeldung.

Um eine Rechnung an einen Empfänger zu senden, muss sich diese Organisation nicht in Ihrem eigenen Konto befinden: Beim Erstellen der Rechnung wählen Sie den Empfänger über das Schuldner-Suchfeld aus. Sie suchen nach Handelsregisternummer, Firmennamen oder OIN-Nummer.

Fehlermeldung "Der Identifier wurde bereits in einer anderen Organisation verifiziert"

Diese Meldung erscheint bei der Rechnungseinreichung (via Peppol) oder beim Versuch, eine "empfangende Organisation hinzuzufügen". Die Meldung umfasst zwei Szenarien mit unterschiedlichen Ursachen und Lösungen:

Szenario 1: Die Meldung betrifft den Identifier des KUNDEN (Empfänger/Schuldner). Dies ist ein Ausdruck falscher Plattformnutzung: Der Benutzer versucht, eine Kunden-/Empfängerorganisation seiner eigenen Umgebung hinzuzufügen. Dies ist kein Freigabeproblem — Support muss den Identifier nicht intern freigeben. Die korrekte Vorgehensweise: Fügen Sie nur Ihre eigene(n) Organisation(en) hinzu und aktivieren Sie diese in Ihrer eigenen Umgebung. Senden Sie die Rechnung anschließend über das Schuldner-Suchfeld an den Empfänger — der Empfänger muss nicht in Ihrem Konto vorhanden sein.

Szenario 2: Die Meldung betrifft den EIGENEN Identifier des Benutzers. Der Identifier ist bereits unter einer anderen Organisation in einem anderen Konto registriert. Dies ist keine falsche Plattformnutzung: Der Benutzer möchte zu Recht seine eigene Organisation anlegen. Mögliche Ursachen: Ein Kollege hat die Organisation bereits angelegt, oder die Organisation existiert noch in einem alten Konto.

• Intern: Ermitteln Sie, wer die Organisation früher angelegt hat, und fügen Sie den neuen Benutzer zu diesem Konto oder dieser Organisation hinzu.
• Falls der Ersteller unbekannt ist: Der Support kann die E-Mail-Adresse des Erstellers nachschlagen, damit der Benutzer direkt Kontakt aufnehmen kann. Der Support koppelt oder überträgt den Identifier nicht selbst — das ist kein Bestandteil des Standard-Supportverfahrens.

Suchvarianten: "enabled for Peppol sending", "additional Peppol activation", "is sending already enabled", "zusätzliche Sendeaktivierung", "University of Luxembourg", "9938", "ausländischer Empfänger Scheme".

Bei einer aktivierten Organisation ist Versenden standardmäßig aktiv -- das gehört zur Standardverbindung. Es gibt keinen separaten Schritt "Peppol send enable" neben einem aktiven Organisationsstatus. Siehe Bei Peppol registrieren für das vollständige Aktivierungsverfahren.

Geben Sie den Empfänger (beispielsweise eine ausländische Peppol-Partei wie eine luxemburgische Universität) nur auf der Rechnung ein, über das Debitoren-Suchfeld (Organisations-ID + Senden über). Fügen Sie den Empfänger nicht als eigene Organisation im Konto hinzu -- siehe auch den Abschnitt "Verwechslung: Empfängerorganisation als eigene Organisation hinzufügen" oben.

Erhalten Sie weiterhin eine Fehlermeldung, die hier nicht beschrieben wird? Kontaktieren Sie uns über support.econnect.eu.