Je eigen organisatie (de leverancier) is niet correct geselecteerd in de factuur. Dit gebeurt wanneer het leveranciersveld handmatig is aangepast of als de organisatie nog niet is geactiveerd.

Oplossing: Klik op het potloodje naast "Leverancier" en selecteer je eigen organisatie opnieuw. Als je organisatie nog niet is geactiveerd, doe dat dan eerst via Organisatie toevoegen en activeren.

Je hebt een bijlage toegevoegd met een MIME-type dat niet is toegestaan in de huidige Peppol BIS Billing V3-validatie. Het platform accepteert de volgende bijlagetypen (BT-125):

application/xml is niet toegestaan als bijlage-MIME-type in de huidige BIS Billing V3-validatie. XML als bijlage hoort bij EN 16931-1:2026 en een toekomstige Peppol-versie (mogelijk BIS Billing 4.0) — voeg geen XML-bijlage toe om BR-CL-24 op te lossen.

Veelvoorkomende oorzaak (Business Central en andere ERP's): het ERP sluit automatisch bijlagen in die aan de geboekte factuur zijn gekoppeld. Een bijlage met een niet-toegestaan type (bijv. een Word-document) veroorzaakt dan BR-CL-24.

Oplossing:

1. Controleer welke bijlagen aan de factuur zijn gekoppeld in het ERP (Business Central: Geboekte verkoopfactuur > Bijlagen).
2. Verwijder of vervang bijlagen met een niet-toegestaan type — zet bijv. een Word-document om naar PDF.
3. Verstuur de factuur opnieuw.

De eenheid die je bij een factuurregel hebt ingevuld, wordt niet herkend als een geldige UN/ECE-code. Dit komt voor als je een afkorting of eigen benaming gebruikt.

Oplossing: Gebruik een standaardeenheid uit de keuzelijst, zoals "Stuks" (EA), "Uren" (HUR) of "Dagen" (DAY).

Het identifiertype bij "OrganisatieID" wijkt af van het identifiertype bij "Zenden via". Bijvoorbeeld: het OrganisatieID staat op OIN, maar "Zenden via" staat op KvK.

Oplossing: Zorg dat beide velden hetzelfde identifiertype gebruiken. Factureer je aan de overheid, zet dan beide op OIN/OINO. Factureer je aan een bedrijf, gebruik dan bij beide KvK (0106).

Het BTW-nummer van de leverancier ontbreekt in de factuur.

Oplossing: Vul je BTW-nummer in bij de organisatie-instellingen.

Heb je als organisatie geen BTW-nummer (bijvoorbeeld een stichting, overheid of zorgaanbieder die uitsluitend BTW-vrijgestelde diensten levert)? Kies dan op factuurregelniveau voor 'BTW niet van toepassing'. Bij deze instelling vervalt de verplichting om een BTW-nummer in te vullen en voldoet de factuur aan de Peppol-standaard. Zie ook BTW-verlegd en BTW-categorie O voor uitleg over de BTW-categoriecodes.

Stichtingen, bepaalde overheden en zorgaanbieders die uitsluitend BTW-vrijgestelde diensten leveren, hebben geen BTW-nummer. Bij het opstellen van een factuur via het platform verschijnt dan de verplichting om een leverancier-BTW-nummer in te vullen.

Oplossing: Kies in het factuurformulier op factuurregelniveau voor 'BTW niet van toepassing' (UNCL5305-code O, "Services outside scope of tax"). Bij deze instelling vervalt de UI-verplichting op het BTW-nummer-veld en kan de factuur worden verzonden zonder leverancier-BTW-nummer. Categorie 'O' is de correcte keuze voor organisaties zonder BTW-plicht.

Onderscheid 'E' en 'O': BTW-categorie 'E' (Exempt from VAT) is bedoeld voor BTW-plichtige organisaties die een specifieke vrijgestelde transactie factureren. Categorie 'E' vereist wél een BTW-nummer. Categorie 'O' is voor organisaties die helemaal geen BTW-plicht hebben.

Bij facturering aan de Rijksoverheid (Basisfactuur Rijk, via Digipoort) is een IBAN-nummer verplicht.

Oplossing: Vul je IBAN-nummer in bij de betalingsgegevens van de factuur. Het is sowieso aan te raden om altijd een IBAN op te nemen in je factuur, dit wordt in de toekomst breder verplicht.

Deze fout treedt op wanneer het CompanyID (het veld PartyLegalEntity in de UBL) een BTW-nummer bevat in plaats van een KvK-nummer of OIN. Dat is niet toegestaan: de NLCIUS-validatie eist dat Nederlandse partijen altijd een KvK-nummer (schemeID 0106) of OIN (schemeID 0190) als CompanyID gebruiken. NL-R-003 geldt voor de leverancier, NL-R-005 voor de klant.

De verwarring ontstaat doordat het EndpointID (het Peppol-adres dat voor de routering wordt gebruikt) wél een BTW-nummer mag bevatten (schemeID 9944). Een factuur met een BTW-nummer als EndpointID komt dus prima aan op het Peppol-netwerk, maar wordt alsnog afgekeurd als datzelfde BTW-nummer ook in het CompanyID staat.

Technisch: EndpointID en CompanyID zijn twee aparte velden met een eigen doel. Het EndpointID bepaalt de routering via Peppol en accepteert elk type uit de EAS-codelijst (waaronder 9944 voor BTW-nummers). Het CompanyID identificeert de juridische entiteit en moet voor Nederlandse partijen altijd een KvK (0106) of OIN (0190) zijn.

Oplossing: Controleer de UBL die je systeem genereert en zorg dat het CompanyID een KvK-nummer of OIN bevat, ook als het EndpointID een BTW-nummer is. Beide velden moeten naar dezelfde organisatie verwijzen, maar mogen een verschillend identifiertype hebben.

Tip: De ViDA-wetgeving maakt de relatie tussen EndpointID en CompanyID stapsgewijs strenger. Zorg dat je integratie nu al correct is ingericht, zodat je niet verrast wordt door toekomstige regelwijzigingen.

R120 is een berekeningsregel die controleert of LineExtensionAmount = (Quantity × PriceAmount ÷ BaseQuantity) + toeslagen − kortingen. R120 verbiedt niet expliciet negatieve bedragen; de validatie faalt wanneer de rekensom niet sluitend is. Dat gebeurt vaak wanneer een regelkorting (AllowanceCharge op regelniveau) de artikelprijs overschrijdt.

Oplossing: gebruik het netto creditbedrag direct als PriceAmount en laat het AllowanceCharge-element op de regel weg. Zie het artikel over toeslagen en kortingen voor de details en een XML-voorbeeld.

Deze EN 16931-validatieregels controleren of de BTW-breakdown en factuurtotalen onderling consistent zijn. De waarden worden berekend door het verzendende softwarepakket -- dit zijn geen velden die je in de eConnect-UI kunt corrigeren.

Veelvoorkomende oorzaak: BTW per regel afronden in plaats van per BTW-tarief, of een mismatch tussen regelbedragen en kortingen op factuurniveau.

Oplossing: neem contact op met de leverancier van het verzendende softwarepakket voor een correctie. eConnect kan deze waarden niet bijregelen omdat de berekening is vastgelegd in de aangeleverde XML.

BTW-categorie E vs. O: heeft de organisatie geen BTW-nummer (stichting, overheid, zorg)? Gebruik dan categorie O (BTW niet van toepassing) -- zie het accordeon-item "BTW-vrijgestelde organisaties: categorie O" hierboven. Categorie E vereist altijd een BTW-nummer.

Deze generieke foutmelding wordt veroorzaakt door de pre-verzending validatie in de platform-UI. Het platform controleert vóór verzending of de identifier-waarde (bijv. OINO, KvK) overeenkomt met het verwachte formaat. Als die controle mislukt, verschijnt deze foutmelding.

Veelvoorkomend voorbeeld: schemeID 0190 (OINO) vereist exact 20 cijfers. Als de waarde een prefix bevat -- bijvoorbeeld NL:OINO:00000001001932779000 in plaats van alleen 00000001001932779000 -- faalt de validatie.

Let op: deze foutmelding kan ook optreden bij facturen die via de API zijn aangemaakt, niet alleen bij handmatige facturen.

Oplossing: controleer de identifier-waarden en verwijder eventuele prefixes of ongeldige tekens. De waarde moet exact voldoen aan het verwachte formaat bij het schemeID (bijv. 20 cijfers voor OINO, 8 cijfers voor KvK).

Algemene regel -- alleen de numerieke waarde invullen, het platform voegt het schemeID-prefix zelf toe. Dit geldt voor elk identificatieschema, niet alleen OINO. Vult de gebruiker het prefix zelf ook in (bijv. 0088:1234567890123 terwijl het schema al op GLN/0088 staat), dan faalt de opmaakvalidatie. GLN-voorbeeld (schemeID 0088, GS1): kies schema GLN en vul in het waardeveld alleen de GLN-cijfers in -- niet 0088: ervoor.

Bij verzendfouten vanuit 4PS is de oorzaak vaak niet meteen bekend. Ga niet op voorhand ervan uit dat een ontbrekende PSB-aansluiting (Peppol Service Bus) de oorzaak is.

Stappenplan:

1. TechSupport stelt de oorzaak vast. Routeer niet direct naar sales op basis van een vermoeden.
2. Oorzaak is een ontbrekende actieve PSB-aansluiting bij eConnect? Dan is de vervolgstap sales voor PSB-onboarding. Geef de klant geen 4PS-configuratieadvies -- zonder PSB-aansluiting valt er niets te configureren.
3. Oorzaak is iets anders? Behandel het via de relevante foutmelding of oplossing op deze pagina (of in de 4PS-integratiepagina's).

Kort: diagnose door TechSupport gaat altijd vóór de sales-route. De sales-route (PSB-onboarding) is alleen van toepassing wanneer TechSupport heeft vastgesteld dat een ontbrekende PSB-aansluiting de oorzaak is.

Als een leverancier een apostrof vóór het OIN-nummer plaatst in de XML (een bekend Excel-artefact), mislukt de Peppol-routering. Het legacy platform herkent de factuur wel en bezorgt hem intern -- de ontvanger ziet geen factuur in zijn crediteuren-inbox, maar ontvangt een notificatiemail met een link.

Oplossing: vraag de leverancier het OIN-nummer zonder apostrof in de XML te vermelden en de Excel-exportinstellingen te controleren.

not available bij het (test)verzenden naar een ontvanger betekent: de ontvanger staat niet actief op Peppol om te ontvangen op de gebruikte identifier. Het is geen probleem aan afzenderzijde.

• Peppol-routering loopt via het EndpointID van de ontvanger (KvK/OIN), niet via het BTW-nummer van de afzender. Een geldig BTW-nummer maakt een organisatie op zichzelf niet vindbaar of bereikbaar -- registratie op Peppol is vereist (zie Wat is mijn Peppol ID? en Registreren op Peppol).
• Het platform biedt bij not available automatisch de e-mail-fallback aan, zodat het document alsnog via e-mail bij de ontvanger kan worden bezorgd.
• Aandachtspunt afzenderzijde: verzenden via Peppol werkt automatisch zodra de eigen organisatie is geactiveerd. Activatie voor productie is een KYC-eis; testen kan via de pilot (zie Registreren op Peppol).

Deze melding verschijnt in het Postvak UIT wanneer de factuur niet bij de ontvanger kon worden afgeleverd via het Peppol-netwerk. Mogelijke oorzaken:

• Ontvanger niet op Peppol geregistreerd: de ontvanger heeft geen actieve Peppol-registratie. Het platform biedt in dat geval automatisch de e-mail fallback aan.
• EndpointID onjuist: het Peppol-adres van de ontvanger klopt niet. Controleer het KvK-nummer of OIN-nummer dat je als debiteur hebt ingevuld.
• Ontvangende partij heeft een technisch probleem: de factuur is correct verstuurd maar kon niet worden verwerkt door het systeem van de ontvanger. Dit ligt buiten je invloed, neem contact op met de ontvanger.

Bij een mislukte bezorging kun je de factuur opnieuw verzenden en daarbij het EndpointID corrigeren.

Het leveranciersveld bevat geen gegevens. Dit gebeurt als je organisatie niet is geselecteerd of als de organisatie niet is geactiveerd.

Oplossing: Klik op het potloodje naast het leveranciersveld en selecteer je organisatie. Is je organisatie nog niet geactiveerd? Volg dan eerst de stappen in Organisatie toevoegen en activeren.

Validatieregel BR-CO-09 controleert of het BTW-nummer een geldig formaat heeft. Het BTW-nummer moet altijd worden ingevoerd inclusief de landcode en zonder punten, spaties of scheidingstekens.

Landcodes volgen de ISO 3166-1 alpha-2 standaard. BTW-nummers zijn verplicht wanneer de leverancier of ontvanger BTW-plichtig is en het tarief niet vrijgesteld is.

Als het ingevoerde bedrag verdwijnt wanneer je naar de volgende stap gaat, bevat het veld waarschijnlijk tekens die niet zijn toegestaan. Het bedragveld accepteert alleen cijfers met een komma als decimaalteken. Voer bedragen in als 100,00, niet als € 100,00 of 100.00.

Als de verzendknop niet reageert of het laadscherm blijft hangen bij het versturen van een Peppol-factuur, en je ziet onvertaalde template-syntax zoals {{invoice.data.supplierDetails.name}} in plaats van de ingevulde waarden, is de oorzaak waarschijnlijk browser-autovertaling.

Hetzelfde speelt op de inlogpagina van platform.econnect.eu en elders in de UI: placeholder-teksten of raw i18n-keys (bijvoorbeeld {{lang.text}} of I18N_COLLABRR_WS.*) in plaats van normale labels. Gebruikers melden dit vaak als "ik kan niet inloggen". Zie ook Inloggen en 2FA.

Browser-autovertaling (automatisch vertalen van de pagina in Chrome of Edge) grijpt in op de DOM van het platform. Daardoor reageren knoppen niet meer correct en blijven template- of i18n-placeholders zichtbaar.

Oplossing:

1. Schakel automatisch vertalen in de browser uit voor het eConnect-platform (o.a. platform.econnect.eu).
2. Ververs de pagina.
3. Lukt het nog steeds niet? Leeg dan de browsercache en log opnieuw in.

Belgische Peppol-ID's kunnen twee vormen hebben:

BTW-nummer formaat: BE gevolgd door precies 10 cijfers (voorloopnullen toevoegen indien nodig). Controleer het BTW-nummer via de VIES-validatietool van de Europese Commissie (ec.europa.eu/taxation_customs/vies).

Peppol-optie verschijnt niet voor Belgische debiteur? Controleer met welk identifier-type de debiteur op Peppol is geregistreerd. Sommige Belgische organisaties zijn alleen via 0208: (KBO/EN-nummer) geregistreerd en niet via 9925: (BTW). Probeer in dat geval het KBO-nummer: het BTW-nummer zonder BE ervoor (bijv. voor BE0123456789 wordt het EN-nummer 0123456789; voor BE1xxxxxxxxx wordt dat 1xxxxxxxxx -- beide prefixes zijn geldig).

AFAS: ondernemingsnummer met punten faalt bij Peppol BIS V3. Wanneer AFAS aanvankelijk een SI2.0-factuur verstuurt, treedt geen validatie op het Belgische ondernemingsnummer op -- formaten met punten (bijv. 0809.948.614) worden dan geaccepteerd. Bij de overstap naar Peppol BIS V3 komt de formaatfout naar voren, omdat BIS V3 wél valideert op het ondernemingsnummer. Oplossing: de klant past de stamdata in AFAS aan en verwijdert de punten uit het ondernemingsnummer. Het formaat is uitsluitend 10 cijfers beginnend met een 0 of 1, zonder scheidingstekens.

Overig: negatieve prijsregels zijn niet toegestaan bij Belgische facturen; gebruik een negatief aantal met een positieve prijs.

BR-DE- foutcodes* zijn Duitse landspecifieke validatieregels voor XRechnung.

Ontbrekende Leitweg-ID (EAS 0204): veelvoorkomend bij facturatie aan de Duitse overheid. Vraag de Leitweg-ID op bij de opdrachtgevende instantie en voeg deze toe als identifier met schemeID 0204.

PDF niet geaccepteerd: sinds 1 januari 2025 geldt in Duitsland een ontvangstverplichting voor e-facturen. Een gewone PDF volstaat vaak niet meer. Verstuur de factuur als XRechnung of ZUGFeRD.

KSeF-afwijzing: vaak veroorzaakt door een ongeldig FA_VAT XML-formaat. De eConnect PSB zorgt normaal voor de juiste transformatie naar het Poolse KSeF-formaat.

Certificaatfouten: kunnen optreden als de KSeF-certificaten niet correct zijn geïnstalleerd of verlopen zijn.

Rate limiting: KSeF hanteert limieten op het aantal verzoeken. eConnect past batchverwerking toe om dit te voorkomen.

Bij het verzenden van een factuur kan de foutmelding "EndpointID ontbreekt" verschijnen. Dit is een bekende bug in het platform -- het is geen Peppol-registratieprobleem aan klantzijde. Een automatische diagnose classificeert dit soms foutief als registratieprobleem; dat is onjuist.

Oplossing (workaround): open het factuurblokje → klik het potloodpictogram rechtsboven → selecteer de leverancier en/of debiteur opnieuw → verstuur de factuur opnieuw. Het platform bouwt daarmee de identifiers in de XML opnieuw op en kan de factuur alsnog correct versturen.

Dit hoort bij dezelfde potloodje-herstelhandeling als bij "Het veld Leverancier is leeg" / BR-NL-1 en "Leverancierskenmerk is verplicht". Het onderscheid zit in de specifieke foutmelding "EndpointID ontbreekt".

Deze melding verschijnt wanneer je een XML-factuur uploadt in het platform. Het platform neemt de gegevens uit de XML over, maar de leverancier-identifier ontbreekt in het bestand. Hierdoor kan het platform de factuur niet versturen.

Oplossing: klik op het potloodje naast het leveranciersveld en selecteer je organisatie opnieuw. Het platform bouwt daarna de leverancier-sectie opnieuw op en voegt de benodigde identifiers toe aan de XML.

Dit is dezelfde herstelhandeling als bij "Het veld Leverancier is leeg" en BR-NL-1: selecteer je eigen organisatie opnieuw via het potloodje. Het verschil is dat hier de specifieke melding "Leverancierskenmerk is verplicht" verschijnt door een ontbrekende leverancier-identifier in de aangeleverde XML.

UWV hanteert eigen validatieregels bovenop de standaard Peppol/NLCIUS-validatie.

• UWV Grote Geldstroom (re-integratie, scholing, voorzieningen): OIN 00000004191771249000
• UWV Kleine Geldstroom (bedrijfsvoering): OIN 00000004172892677000

Oplossing per UWV-code: vul het ontbrekende veld aan in de factuur. Bij UWV001-reeks gaat het om verplichte leveranciersvelden; bij UWV002-reeks om identificatie-elementen.

Als een factuur niet verstuurd kan worden en in de map "Concepten" blijft staan, controleer dan twee dingen:

1. Verzenden ingeschakeld: controleer in de organisatie-instellingen of "Verzenden van documenten" is geactiveerd. Als dit niet aan staat, neem dan contact op met support.
2. Zenden via ingesteld: bij het kopje "Debiteur" moet naast het OrganisatieID ook een "Zenden via"-optie zijn geselecteerd. Zonder deze instelling kan de factuur niet worden verstuurd.

Het eConnect-platform gebruikt soms een namespace-prefix in gegenereerde UBL-facturen (bijv. <urn:Invoice xmlns:urn="...">). Beide vormen -- met en zonder prefix -- zijn technisch geldige XML.

Een ontvanger die facturen weigert op basis van de namespace-prefix is niet compliant binnen Peppol. De namespace-prefix is niet configureerbaar per ontvanger.

Communicatie naar klant: de factuur is technisch correct. De ontvanger moet een correcte XML-parser gebruiken die zowel prefix- als default namespaces verwerkt. Weigering op basis van namespace-prefix is niet toegestaan binnen Peppol.

EBMS-foutcodes zoals EBMS:0003 en EBMS:0004 zijn AS4-transportfouten bij communicatie tussen Access Points. Klanten zien in het platform een SentError of SentRetry -- de EBMS-code zelf is niet zichtbaar in de klantinterface.

Actie: verwijs de klant door naar TechSupport. TechSupport kan de foutdetails inzien via de audittrail en Application Insights.

Foutcode status 40 betekent dat het document niet succesvol is verwerkt. Twee mogelijke oorzaken:

1. IDR-verwerkingsfout: de IDR kan het document niet verwerken en retourneert status 40.
2. Platform-zijdige afkeuring: de IDR heeft het document wel verwerkt, maar het platform zet het daarna op status 40 (bijv. door een validatiefout na conversie).

Diagnostiek: een eConnect-medewerker moet in CloudWatch onderzoeken welke verwerkingsstappen het document heeft doorlopen.

Via de optie Opnieuw versturen in Postvak UIT kun je een reeds verzonden factuur opnieuw aanbieden. Vóór het daadwerkelijk versturen kun je velden als de referentie (PO-nummer, OrderReference) nog aanpassen. De factuur wordt dan met hetzelfde factuurnummer opnieuw verstuurd, maar met de gecorrigeerde referentie.

Dit is de aangewezen werkwijze wanneer een ontvanger een factuur weigert vanwege een verkeerd PO-nummer of een andere referentiefout. Hiermee sla je het traject van crediteren en een nieuwe factuur opstellen over.

In de huidige Peppol BIS Billing 3.0 en NLCIUS kan per factuur slechts naar 1 ordernummer worden gerefereerd (OrderReference). Dit is een beperking die voortkomt uit de Europese norm EN 16931. Heeft een factuur betrekking op meerdere orders, dan moet de leverancier meerdere facturen versturen.

AdditionalDocumentReference kan wel extra referenties van andere typen bevatten (project-, contract- of buyer reference), maar niet meerdere OrderReferences.

Toekomst: de herziene EN 16931-1:2026 (formeel goedgekeurd door CEN op 13 maart 2026) voegt ondersteuning toe voor meerdere purchase orders per factuur. Dit wordt naar verwachting doorgevoerd in een nieuwe versie van de Peppol-standaard (mogelijk BIS Billing 4.0). Tot die tijd geldt in BIS Billing 3.0 en NLCIUS de huidige beperking van 1 OrderReference per factuur.

Als een factuur wordt afgekeurd wegens een ontbrekend of onbekend ordernummer, zijn er twee niveaus die je uit elkaar moet houden.

1. Referentie is verplicht conform EN 16931. Een referentie -- ordernummer of een andere referentie (BuyerReference, contract- of projectreferentie) -- is verplicht. Een factuur zonder enige referentie voldoet niet aan de basisregels van de norm.

2. eConnect keurt standaard niet af op de inhoud van de referentie. De enige situatie waarin het platform op dit punt afkeurt, is wanneer er helemaal geen referentie aanwezig is.

3. Klantspecifieke inrichting kan strenger zijn. De daadwerkelijke afkeuring hangt af van de inrichting van de ontvanger. In een specifieke inrichting kan een factuur wél worden afgekeurd als de referentie bij die ontvanger onbekend is. Dit is configuratie-afhankelijk en geen standaardgedrag van het eConnect-platform.

4. PO-nummer (BT-13, OrderReference/ID) wordt bij de ontvanger niet herkend. Een PO-nummer in XML hoort door het ontvangende ERP normaal herkend te worden. In de praktijk gaat de matching soms mis door een van deze oorzaken:

• Het ERP-systeem van de ontvanger is niet ingericht om de PO-waarde automatisch te matchen.
• De verzender stuurt de PO-waarde op een afwijkende manier mee (bijv. in een ander referentieveld dan het ERP verwacht).
• De PO-waarde staat in een ander referentieveld dan waarnaar het ontvangende ERP kijkt.

eConnect kan dit productmatig corrigeren per ontvanger, zodat het matching-proces goed doorloopt. Dit kan ook voor één specifieke leverancier worden ingeregeld.

Actie:

• Stuur de factuur opnieuw in via Opnieuw versturen (zie accordion-item hierboven) met een geldige referentie.
• Is het ordernummer onbekend, neem dan contact op met de ontvanger over de gewenste procedure.
• Lukt matching structureel niet bij een specifieke ontvanger? Neem contact op met support -- eConnect kan een maatwerkoplossing per ontvanger (en eventueel per leverancier) inrichten.

Een factuur met eindstatus InvoiceSentError (na een 4xx-validatiefout) onderneemt geen verdere verzendpogingen. Alleen 5xx-fouten worden geretried (maximaal 8 pogingen, circa 35 uur). Bij een 4xx-fout blijft het bij één poging; er gaat niets meer richting de ontvanger.

Er is geen DELETE-endpoint voor verkoopfacturen (salesInvoice). Een verstuurde of afgekeurde verkoopfactuur is een audit-relevante gebeurtenis en blijft 90 dagen beschikbaar in de audittrail. Was de factuur inhoudelijk fout, stel dan een credit note of correctiefactuur op via de standaard boekhoudkundige flow.

Het Peppol-netwerk kent een automatisch herleverings-/retry-mechanisme bij tijdelijke bezorgfouten tussen Access Points. Wanneer aflevering aan het ontvangende Access Point (C3) tijdelijk mislukt -- bijvoorbeeld door een storing aan ontvangerszijde -- probeert het verzendende Access Point (C2) het document later opnieuw af te leveren.

• Tijdelijke fout (5xx) = retry; permanente fout (4xx) = geen retry. Op eConnect-verzendniveau worden alleen 5xx-fouten geretried (maximaal 8 pogingen, circa 35 uur). Een 4xx-validatiefout is permanent en blijft bij één poging -- zie ook het accordion-item "InvoiceSentError" hieronder.
• Status in het platform: tijdens een retry ziet de klant de status SentRetry (AS4-transportniveau). Bij definitief falen wordt dat SentError.
• Gevolg bij netwerk- of Access Point-storing: de factuur kan pas enkele dagen na verzending worden afgeleverd, namelijk zodra de retry slaagt. De verzender hoeft niets te doen -- het herleveren verloopt automatisch binnen het retry-venster.
• Precieze vensterlengte: het exacte retry-venster van het Peppol-netwerk (buiten de eConnect-verzend-retry) is niet publiek gestandaardiseerd en kan per Access Point verschillen.

Dit herleveringsmechanisme verklaart mede waarom de ontvangstdatum enkele dagen na de factuurdatum (IssueDate) kan liggen. Zie ook Factuurdatum (IssueDate) vs. ontvangstdatum in eConnect voor de uitleg aan de ontvangstkant.

Bron: expertbevestiging Johan Schaeffer (Peppol & E-facturatie), 2026-07-04, n.a.v. ticket #15268901 (W776).

Validatiefouten als TaxInclusiveAmount '-1.336061E6' is geen geldige xs:decimal ontstaan doordat het bronsysteem een numeriek bedrag serialiseert in wetenschappelijke notatie (bijv. -1.336061E6 voor -1.336.061,00). UBL-bedragvelden zijn van type xs:decimal, dat geen E-notatie toestaat.

Veelvoorkomende oorzaak: het bronsysteem houdt bedragen intern in een double/float en gebruikt de standaard string-conversie, die bij grote of erg kleine waarden automatisch overschakelt op exponent-notatie.

Oplossing aan klantzijde: bronsysteem aanpassen zodat bedragen altijd als gewone decimale string worden weggeschreven (bijv. via decimal/BigDecimal-types of een locale-onafhankelijk decimal pattern zonder duizendseparators en zonder E-notatie).

Aan eConnect-zijde: niet automatisch te corrigeren -- de waarde staat al fout in de aangeleverde XML. Doorsturen naar de leverancier van het softwarepakket.

Dit scenario speelt wanneer de leverancier stelt te hebben verzonden maar de ontvanger niets heeft ontvangen, en de factuur nog niet de eindstatus 'Afgeleverd' heeft of de status onduidelijk is.

Diagnose in drie stappen:

1. Controleer de verzendstatus in het platform. Ga naar Postvak UIT (platform) of PSB Control > Events (PSB). De klant kan dit zelf doen (zelf-diagnose). Staat de factuur op 'Verzonden' of 'Afgeleverd' in Postvak UIT of als geslaagde event in PSB Control, dan is de factuur bij het Peppol-netwerk aangeboden. Staat het Participant ID van de ontvanger geregistreerd op een ander of concurrerend Access Point, dan is de factuur aan dat Access Point geleverd -- dat is dan geen eConnect-verzendprobleem.
2. Ontvanger niet geactiveerd? Dan niet routeerbaar. Je kunt niet versturen naar een niet-geactiveerde organisatie: die staat niet als Participant gepubliceerd in het SMP/SML en het Participant ID is niet routeerbaar via eConnect. Veelgemaakte fout: verzenders denken dat ze ook de ontvanger (hun klant) als organisatie moeten aanmaken in het platform -- dat is niet nodig. Alleen de eigen verzendende organisatie moet geactiveerd zijn; de ontvanger hoeft niet in het eigen account te staan.
3. Ontvanger zit bij een andere provider? Migratie nodig. Wil de ontvanger (of de leverancier zelf) overstappen naar eConnect: meld eerst af bij de oude Service Provider en registreer daarna bij eConnect. Activeer de organisatie eerst zodat de registratie direct uitvoerbaar is, of vraag een migratiecode op (dit gaat in het platform nog niet automatisch). Zie Peppol registratie en migratie.

Voor het scenario waarbij de status al Afgeleverd toont maar de ontvanger zegt niets te hebben ontvangen, zie het accordion-item "Status 'afgeleverd' maar ontvanger heeft de factuur niet ontvangen" hieronder.

De status Afgeleverd betekent dat het ontvangende Access Point (de Peppol-dienstverlener van de debiteur) het document technisch heeft geaccepteerd en die acceptatie heeft teruggemeld. eConnect ontvangt daarbij een returnedMessageId (formaat GUID@econnect.eu): het bewijs dat de factuur bij het ontvangende Access Point is aangekomen. Waar het returnedMessageId zichtbaar is, verschilt tussen platform en PSB -- controleer de juiste omgeving van de klant.

Als de debiteur zegt de factuur niet te hebben ontvangen terwijl de status 'Afgeleverd' toont, is het document wel degelijk afgeleverd bij het Access Point van de debiteur, maar nog niet zichtbaar in diens eigen software of administratie. Dit is een downstream-probleem aan ontvangerszijde.

Stappenplan:

1. Bevestig aan de klant dat de factuur succesvol naar het Peppol Access Point van de debiteur is verzonden en dat eConnect een afleverbevestiging heeft ontvangen.
2. Adviseer de klant om de debiteur te vragen contact op te nemen met diens eigen Peppol-dienstverlener. Het returnedMessageId kan daarbij worden meegegeven: met dat ID kan het ontvangende Access Point het document terugvinden.
3. De verdere afhandeling ligt bij het Access Point van de debiteur; eConnect heeft als verzendende partij geen zicht op de verwerking voorbij het punt van aflevering.

Nieuwe gebruikers -- met name overstappers van andere e-facturatiediensten -- proberen soms bij het versturen van een factuur de ontvangende organisatie als eigen organisatie toe te voegen op het platform. Dit is niet nodig en levert een foutmelding op.

Om een factuur te versturen naar een ontvanger hoeft die organisatie niet in je eigen account te staan: bij het aanmaken van de factuur selecteer je de ontvanger via het debiteur-zoekveld. Je zoekt de debiteur op KvK-nummer, bedrijfsnaam of OIN-nummer.

Foutmelding "De identifier is al geverifieerd in een andere organisatie"

Deze melding verschijnt bij factuurindiening (via Peppol) of bij "ontvangende organisatie toevoegen". De melding kent twee scenario's met een andere oorzaak en oplossing:

Scenario 1: de melding staat op de identifier van de KLANT (afnemer/ontvanger). Dit is een uiting van verkeerd platformgebruik: de gebruiker probeert een klant-/ontvanger-organisatie toe te voegen aan zijn eigen omgeving. Dit is geen vrijgave-issue -- support hoeft de identifier niet intern vrij te maken. De juiste werkwijze: voeg alleen je eigen organisatie(s) toe en activeer die in je eigen omgeving. Stuur de factuur daarna naar de ontvanger via het debiteur-zoekveld -- de ontvanger hoeft niet in je account te staan.

Scenario 2: de melding staat op de EIGEN identifier van de gebruiker. De identifier is al geregistreerd onder een andere organisatie in een ander account. Dit is geen verkeerd platformgebruik: de gebruiker wil terecht zijn eigen organisatie aanmaken. Mogelijke oorzaken: een collega heeft de organisatie al aangemaakt, of de organisatie bestaat nog in een oud account.

• Intern: ga na wie de organisatie eerder heeft aangemaakt en voeg de nieuwe gebruiker toe aan dat account of die organisatie.
• Als de aanmaker onbekend is: support kan het e-mailadres van de aanmaker opzoeken, zodat de gebruiker rechtstreeks contact kan opnemen. Support koppelt de identifier niet zelf los of over -- dat is geen onderdeel van de standaard supportprocedure.