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, Unit4 ERPx en andere ERP's): het ERP sluit automatisch bijlagen in die aan de geboekte factuur zijn gekoppeld, of exporteert incomplete UBL-blokken. Een bijlage met een niet-ondersteund type (bijv. Word-document) veroorzaakt BR-CL-24; ontbrekende BT-122 leidt tot BR-52; overschrijving zonder IBAN tot BR-61; lege tags tot PEPPOL-EN16931-R008. Meerdere codes tegelijk wijzen op de payload/ERP-export, niet op een eConnect-omgevingsstoring. Vooraf valideren kan via de Document Validator.

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.

BR-52 treedt op wanneer het blok aanvullend document (BG-24) aanwezig is zonder Supporting document reference (BT-122). Dat komt onder meer voor bij ERP-UBL-export, bijvoorbeeld Unit4 ERPx in test of pilot.

Oplossing: vul per bijlage of documentreferentie een ID (BT-122), of laat het incomplete bijlageblok weg. De fix zit in de UBL-export van het ERP, niet in eConnect.

BR-61 treedt op wanneer Payment means type code (BT-81) een overschrijving is (bijv. SEPA of local/non-SEPA credit transfer, codes zoals 30 of 58) zonder Payment account identifier (BT-84, doorgaans IBAN). Dit is EN 16931 BR-61.

Oplossing: vul IBAN of rekeningnummer in bij de betalingsgegevens, of stuur geen overschrijvingscode zolang er geen rekeningnummer meegaat.

PEPPOL-EN16931-R008 treedt op wanneer de UBL lege XML-elementen (lege tags) bevat.

Oplossing: velden zonder waarde volledig weglaten in de UBL-export; stuur geen lege tags mee. De fix zit in de ERP-/UBL-export, niet in eConnect.

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.

Zoekvarianten: "BR-E-02", "BTW vrijgesteld werk", "vrijgesteld van btw factuur sturen zonder BTW-nummer", "categorie E vs O platform", "handmatige platformfactuur BR-E-02".

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 foutmelding BR-E-02: "Een factuur die een Factuurregel bevat waarbij de btw-categoriecode van het gefactureerde artikel 'Vrijgesteld van btw' is, moet de SellerVATIdentifier, het SellerTaxRegistrationIdentifier en/of het SellerTaxRepresentativeVATIdentifier bevatten." Kort: bij categorie E (Vrijgesteld van btw) is een BTW-nummer verplicht -- en dat heeft deze organisatie niet.

Oplossing (platform-UI, stap voor stap):

1. Open de verkoopfactuur op platform.econnect.eu.
2. Kies per factuurregel de BTW-categorie 'BTW niet van toepassing (O)' in plaats van 'Vrijgesteld van btw (E)'.
3. Laat het leverancier-BTW-nummer leeg -- gebruik geen dummy-BTW-nummer.
4. Verstuur de factuur opnieuw.

Categorie 'O' (UNCL5305-code O, "Services outside scope of tax") laat de UI-verplichting op het BTW-nummer-veld vervallen en 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 (BR-E-02). 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.

Zoekvarianten: "BR-NL-10", "BR-NL-10", "Verwerking is niet mogelijk", "wettelijke identificatie van de klant", "CompanyID leeg", "schemeID 0190 waarde leeg".

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, of wanneer het CompanyID-veld wel het juiste schemeID heeft maar geen waarde. Dat is niet toegestaan: de NLCIUS-validatie eist dat Nederlandse partijen altijd een KvK-nummer (schemeID 0106) of OIN (schemeID 0190) als CompanyID gebruiken, mét een gevulde waarde. NL-R-003 geldt voor de leverancier, NL-R-005 voor de klant. Het platform of de validator toont deze fout soms als [BR-NL-10] in plaats van of naast NL-R-005 -- dit is dezelfde regel onder een andere naam.

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, met een niet-lege waarde. De officiële Peppol-test controleert expliciet op een niet-lege waarde -- een correct schemeID met een leeg elementveld is dus ook een fout.

Faalpatroon: schemeID aanwezig, waarde leeg. De XML bevat bijvoorbeeld CompanyID schemeID="0190", maar het elementveld zelf is leeg. Dit geeft dezelfde afkeuring als een verkeerd identifiertype, met de melding "Verwerking is niet mogelijk". Vaak is dan ook het klant-EndpointID met hetzelfde schemeID leeg -- corrigeer beide velden. Dit is geen aangescherpte validatie: de regel is ongewijzigd, eerdere facturen hadden de waarde meestal wél gevuld.

Voorbeeld (UWV): bij facturering aan UWV Grote Geldstroom (re-integratie, scholing, voorzieningen) horen CompanyID en EndpointID beide de OIN 00000004191771249000 met schemeID 0190 te bevatten. Voor UWV Kleine Geldstroom (bedrijfsvoering) is dat OIN 00000004172892677000. Controleer bij twijfel altijd welke geldstroom van toepassing is.

Oplossing: Controleer de UBL die je systeem genereert en zorg dat het CompanyID een KvK-nummer of OIN bevat met een gevulde waarde, ook als het EndpointID een BTW-nummer is. Vul bij voorkeur ook het klant-EndpointID consistent in (dezelfde entiteit, OIN of KvK naar de juiste Peppol-registratie). 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.

Zoekvarianten: "BR-AE-10", "SOAP:CLIENTBR-AE-10", "Reverse charge shall have a VAT exemption reason", "BT-120", "BT-121", "BTW verlegd vrijstellingsreden ontbreekt", "facturen geweigerd reverse charge".

BR-AE-10 treedt op wanneer een BTW-categorie AE (Reverse Charge) in de VAT-breakdown (BG-23) geen vrijstellingsreden bevat: geen BT-121 (code) en geen BT-120 (tekst, bijvoorbeeld "BTW verlegd" of "Reverse charge"). Dit is een fout in de aangeleverde UBL vanuit het ERP of facturatiepakket -- eConnect valideert de factuur, maar past AE-velden niet automatisch aan.

Oplossing:

1. Controleer of elke factuurregel of -toeslag met BTW-categorie AE een BTW-percentage van 0% heeft.
2. Vul in de UBL-export van het bronsysteem het TaxExemptionReason-veld (BT-120) en/of de code (BT-121) in bij elke AE-breakdown.
3. Valideer de factuur vooraf via de Document Validator.
4. Verstuur de gecorrigeerde factuur opnieuw -- de oorspronkelijke, foute XML opnieuw versturen lost dit niet op.

Zie ook BTW-verlegd: codes K, AE en G voor de volledige uitleg van de BTW-verleggingscodes.

Deze drie foutcodes verschijnen wanneer de factuur technisch is verstuurd, maar de ontvanger of validator de inhoud afkeurt op basisvelden in de UBL/XML. De oorzaak zit in het XML-bestand zelf, niet in de Peppol-verbinding, het Peppol-ID of de bezorgwijze naar de debiteur.

Oplossing: pas de betreffende velden aan in de software waarin de factuur wordt opgesteld -- CustomizationID en ProfileID zijn vaste waarden per documenttype, geen instelling in het eConnect-platform. Ontbreekt zowel BuyerReference als OrderReference, voeg dan een van beide toe voordat de factuur opnieuw wordt verstuurd.

Let op bij R007 en andere BIS-profielen: de standaardwaarde in de tabel geldt voor een reguliere factuur/credit note. Self-billing en andere Peppol BIS-profielen (bijv. self-billing invoicing) hebben een eigen, afwijkende ProfileID. Forceer de standaardwaarde niet op facturen die bewust een ander BIS-profiel gebruiken -- controleer eerst welk profiel van toepassing is voordat je deze FAQ toepast.

Niet verwarren met: een ontbrekende Peppol-registratie bij de ontvanger, een verkeerd EndpointID, een Access Point-storing, of de melding "geen validatieregels beschikbaar" (zie het accordion-item hierover verderop) -- die gevallen hebben andere symptomen dan deze combinatie van specificatie, profiel en referentie.

Bron: ticket #15272547 (2026-07-28).

Zoekvarianten: "P0112", "factuurtypecode 326 of 384 is alleen toegestaan wanneer zowel koper als verkoper Duitse organisaties zijn", "typecode 326", "deelfactuur", "waar factuurtype wijzigen", "factuurtypecode aanpassen portaal", "ik zie geen veld factuurtype".

Deze foutmelding treedt op wanneer cbc:InvoiceTypeCode (BT-3) de waarde 326 (partial invoice, portaal-label deelfactuur) of 384 (corrected invoice/Correctiefactuur) heeft, terwijl niet zowel leverancier als ontvanger een Duitse organisatie zijn. Peppol BIS Billing 3.0-regel PEPPOL-EN16931-P0112 staat 326 en 384 alleen toe wanneer beide partijen Duits zijn.

Portaal-UI: de factuurtype-keuze staat rechts op de conceptfactuur. Klantlabels omvatten onder meer deelfactuur (naast de standaardtermen "Correctiefactuur" en "Commerciële factuur") -- makkelijk over het hoofd gezien.

Oplossing (portaal, factuur NL of niet-DE):

1. Ga naar Verkoopfactuur → factuur opstellen (concept).
2. Rechts op het concept: controleer het factuurtype -- let op het label deelfactuur.
3. Kies Commerciële factuur (typecode 380) in plaats van deelfactuur (326) of Correctiefactuur (384), tenzij het een echte correctie betreft en zowel verzender als ontvanger Duits zijn.
4. Voor een correctie naar een niet-Duitse ontvanger: gebruik een creditnota of negatieve 380 plus een nieuwe factuur -- zie Creditnota-varianten. Gebruik typecode 326/384 niet buiten DE→DE.

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

Deze fout treedt op bij factuurregel(s) met BTW-categorie Intracommunautaire levering / Intra-community supply (K, BT-151) wanneer een verplicht BTW-gegeven ontbreekt. Bij categorie K zijn verplicht: seller VAT (BT-31) of seller tax representative VAT (BT-63), én buyer VAT (BT-48). De ontbrekende gegevens zitten in de partijgegevens (organisatie of debiteur), niet op de factuurregel zelf. De foutmelding wijst niet naar één specifiek regelnummer -- de regel triggert zodra een van de factuurregels categorie K gebruikt.

Oplossing:

1. Bepaal welke factuurregel(s) BTW-categorie K (intracommunautaire levering) gebruiken.
2. Vul het BTW-nummer van de leverancier (seller VAT) in bij de organisatie-instellingen, of vul de fiscale vertegenwoordiger (seller tax representative VAT) in.
3. Vul het BTW-nummer van de klant (buyer VAT) in bij de debiteurgegevens.
4. Verstuur de factuur opnieuw. Het document in Postvak UIT is alleen-lezen -- bij een fout moet een nieuwe verkoopfactuur worden aangemaakt.

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.

Zoekvarianten BR-CO-12 / BR-E-01: "BR-CO-12", "BR-E-01", "ChargeTotalAmount", "BT-108", "toeslagtotaal sluit niet", "verzendkosten niet op factuurregel", "Shipping costs AllowanceCharge", "Exempt from VAT breakdown ontbreekt".

BR-CO-12 treedt op wanneer het toeslagtotaal op factuurniveau niet aansluit op de som van de afzonderlijke document-level charges -- bijvoorbeeld bij verzendkosten die als aparte AllowanceCharge op factuurniveau zijn opgenomen (ChargeIndicator=true, reden "Shipping costs" / code FC). Dit is geldige UBL; zie Toeslagen en kortingen voor de opbouw. BR-E-01 treedt op wanneer een factuurregel, documenttoeslag of documentkorting met BTW-categorie 'Vrijgesteld van btw' (E) geen bijbehorende Exempt-breakdown heeft in de BTW-samenvatting.

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.

BR-S-08 -- tweede root cause: ontbrekend of leeg aantal op de factuurregel

Zoekvarianten: "Invalid payload BR-S-08", "Delivery Failed BR-S-08", "BTW-samenvatting sluit niet", "factuurregel geen aantal", "ontbrekend aantal factuurregel", "BT-116", "VAT category taxable amount".

Naast afronding faalt BR-S-08 ook wanneer een factuurregel geen (of leeg) aantal heeft (Invoiced quantity / BT-129). Dan klopt het regelbedrag excl. BTW niet (aantal x eenheidsprijs plus regeltoeslagen min regelkortingen), waardoor de som van de regels afwijkt van de VAT category taxable amount (BT-116) in de BTW-breakdown voor Standard rated. De letterlijke foutmelding lijkt vaak op: 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)....

Onderscheid met xs:decimal-fouten: bij het accordion-item "'...is geen geldige xs:decimal'" hierboven is het bedragveld zelf geen geldig decimaal getal (leeg of wetenschappelijke notatie). Bij BR-S-08 is het bedragveld wel een geldig getal, maar klopt de rekensom tussen regelbedragen en de BTW-breakdown niet.

First-line checklist (vóór softwareleverancier-escalatie):

1. Controleer alle factuurregels op een ingevuld aantal én regelbedrag excl. BTW.
2. Regelbedrag = aantal x eenheidsprijs (plus regeltoeslagen, min regelkortingen); geen lege bedragvelden.
3. Laat de BTW-totalen opnieuw berekenen in het bronsysteem.
4. Verstuur een gecorrigeerde factuur via Peppol. Opnieuw versturen van hetzelfde document zonder correctie lost BR-S-08 niet op -- Opnieuw versturen in Postvak UIT past geen regel- of BTW-bedragen aan (zelfde resend-scope als bij R120 hierboven).
5. Blijft de fout terugkomen met wel complete aantallen? Dan gaat het om afronding of een andere rekenfout in ERP of UBL-export -- door naar de softwareleverancier.

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.

Zoekvarianten: "invoices niet in portal", "facturen niet zichtbaar na verzenden", "facturen niet in portal", "waar vind ik verzonden facturen", "uitgaande facturen zoeken", "Postvak UIT terug te vinden", "succesvol verwerkt postvak uit", "sent invoices not in portal", "outbox invoices missing".

First-step diagnose bij de melding dat facturen niet (meer) zichtbaar zijn in het portal na verzenden:

1. Open Postvak UIT (outbox) -- niet Postvak IN.
2. Zoek op documentnummer, factuurnummer of datum.
3. Status succesvol verwerkt bij het uitgaande document betekent: verwerkt en terug te vinden in Postvak UIT.
4. Veelvoorkomende oorzaak: gezocht in de verkeerde map (IN in plaats van UIT) of te smalle zoekfilters.

Blijft de factuur onvindbaar? Support kan per document-ID bevestigen of de factuur in Postvak UIT staat.

Zoekvarianten: "waarom gaan facturen niet naar Peppol", "PDF en XML meesturen factuur niet verzonden", "dubbele factuur niet naar Peppol", "bestaande facturen alsnog Peppol", "XML genegeerd bij PDF", "alleen XML Peppol email receiver".

Een veelvoorkomende oorzaak dat een factuur niet via Peppol wordt verstuurd, is de combinatie van PDF en XML in dezelfde e-mail naar de Email Receiver:

1. Stuur je zowel een PDF als een XML mee in één e-mail, dan verwerkt het platform de PDF en wordt de XML genegeerd (zie Email ontvanger sectie Foutmeldingsgedrag).
2. De PDF komt via IDR-verwerking vaak op status Concept terecht, of -- bij een factuurnummer dat al bekend is -- op status Dubbele.
3. Een document met status Dubbele gaat niet automatisch de verzendstroom in totdat je het overrides of een nieuwe geldige aanlevering doet.

Bestaande factuur alsnog via Peppol versturen -- afhankelijk van de status in Postvak UIT of concepten:

Preventie: zet op het verkoopfacturen-adres van de Email Receiver XML auto-send aan, en laat het ERP alleen de XML aanleveren -- zonder een parallelle PDF in dezelfde e-mail. Zo gaat de factuur automatisch en zonder omweg via Concept of Dubbele naar Peppol.

Vraag bij deze melding altijd het factuurnummer en de exacte status in Postvak UIT (of concepten) op -- dat bepaalt welke actie uit de tabel hierboven van toepassing is.

Zoekvarianten: "efacturen niet verzonden", "e-facturen niet verzonden", "waarom geen efactuur", "Peppol deelname gecontroleerd", "eFactuur Subjectenscherm", "uitvallijst Peppol", "foutmelding in database", "foutmelding Postvak UIT", "conversietaak niet gestart", "PDF wel ingestuurd niet verzonden".

First-line volgorde bij de melding dat e-facturen niet worden verzonden, ondanks Peppol-deelname of een actieve eFactuur-instelling:

1. Postvak UIT / concepten -- zoek op document- of factuurnummer. De status bepaalt het vervolgpad:
   • Aanwezig met Aflevering mislukt of een validatiefout: zie de BR-*, EndpointID- en SMP-gerelateerde accordion-items op deze pagina.
   • Concept, Dubbele of de PDF+XML-combinatie: zie "Waarom gaan facturen niet naar Peppol?" hierboven.
   • Succesvol verwerkt of afgeleverd: zie "First-step: Peppol-facturen niet aangekomen bij debiteur" hieronder.
   • Niet gevonden op het uitgaande pad: het document is mogelijk nooit de verzendstroom in gegaan. Controleer het instuurkanaal (Email Receiver, PDF-herkenning of ERP) vóór een check op de Peppol-registratie van de ontvanger.
2. Foutlocatie: ga uit van de status/foutmelding per factuur in Postvak UIT (of concepten) als eerste bron, niet van een aparte klant-side "database-uitvallijst".
3. Anti-patroon: niet meteen het EndpointID of de Peppol-registratie van de ontvanger als eerste reactie geven zonder eerst de Postvak UIT-status te controleren of te bevestigen dat het document bij eConnect de verzendstroom is ingegaan.

Nee. eConnect is het Peppol Access Point: het verzorgt het transport van je factuur over het Peppol-netwerk (zie Wat is Peppol?). eConnect is geen boekhoud- of facturatiesoftware.

Vuistregel voor de scope-grens: een foutmelding die ontstaat voordat de factuur bij eConnect binnenkomt -- bijvoorbeeld een veldvalidatie op Stad, Postcode of andere klantrecordgegevens in de software waarin de factuur wordt aangemaakt -- valt buiten het beheer van eConnect.

• Controleer eerst zelf of de betreffende velden (Plaats, Postcode, etc.) correct zijn ingevuld in het klantrecord van de ontvanger in je eigen factuur-/boekhoudsoftware.
• Blijft de melding bestaan, neem dan contact op met de leverancier van die factuur-/boekhoudsoftware.
• Zie ook het accordion-item "Factuur afgekeurd: geen of onbekend ordernummer" hieronder (subblok "ERP-specifiek veld"): eConnect kan een foutcode aanwijzen, maar bedient het ERP-/boekhoudpakket zelf niet.

Zoekvarianten: "Ongeldige/Invalid identifier", "Invalid identifier", "ongeldige identifier", "identifier ongeldig", "ID niet juist geformatteerd", "identifier niet juist geformatteerd", "ontvanger-ID formaat", "ID formatting fout", "schema OIN waarde verkeerd", "0190 prefix niet invullen", "NL:OINO in waardeveld".

Deze generieke foutmeldingen worden 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 o.a. "Onbekende fout tijdens het oproepen van de toepassingsgebeurtenis", de melding "ID niet juist geformatteerd", of de combi-melding "Ongeldige/Invalid identifier" -- dezelfde root-cause-familie: de waarde past niet bij het schemeID-formaat.

First-line bij een kale melding "Ongeldige/Invalid identifier" (weinig context): vraag na:

1. De exacte letterlijke melding (plus eventuele foutcode of screenshot).
2. Waar de melding optreedt: organisatie toevoegen/opslaan, factuur versturen, ontvanger/debiteur invullen, of via API/koppeling.
3. Het identifiertype, de ingevulde waarde en het gekozen schema (0106 KvK, 0190 OIN, 0088 GLN, 0060 DUNS, BTW, ...).
4. Bij meerdere identifiers tegelijk: welk veld precies faalt.

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.

Niet te verwarren met (andere melding, andere pagina):

• "Geen organisatie gevonden voor de opgegeven identifier" (lookup/Purple Pages) -- zie Organisatie niet gevonden bij registratie.
• "De identifier is al geverifieerd in een andere organisatie" -- zie Organisatie toevoegen en activeren.
• Ongeldige DUNS/0060 (bijv. een Companies House CRN ingevuld als DUNS) -- zie Wat is mijn Peppol ID?.

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.

Zoekvarianten: "organisatie verdwenen", "ik maak geen deel uit van de organisatie", "maak geen deel uit van de organisatie", "kan niks meer in het portaal", "kan helemaal niks".

Het leveranciersveld bevat geen gegevens. Dit gebeurt als je organisatie niet is geselecteerd of als de organisatie niet is geactiveerd. Klanten melden dit soms met andere woorden -- bijvoorbeeld "organisatie verdwenen" of "kan niks meer in het portaal", vaak bij de eerste conceptfactuur. De organisatie bestaat meestal nog gewoon; dit is geen organisatie-verwijdering en geen rechten- of accountprobleem.

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.

Het leveranciersveld accepteert alleen een organisatie die je selecteert uit de dropdownlijst. Typ je zelf tekst in dit veld -- bijvoorbeeld je eigen bedrijfsnaam -- in plaats van de organisatie te selecteren, dan wordt de Leverancier-sectie van de factuur niet correct opgebouwd. Het veld lijkt gevuld, maar de factuur wordt bij verzenden afgekeurd. Deze fout verschijnt vaak onder een andere melding, zoals "BTW-nummer ontbreekt" of "Leverancierskenmerk is verplicht".

Oplossing: verwijder de getypte tekst uit het leveranciersveld, klik op het veld en selecteer je eigen organisatie uit de dropdownlijst. Verstuur de factuur daarna opnieuw.

Dit is dezelfde herstelhandeling als bij "Het veld Leverancier is leeg" en BR-NL-1: selecteer je eigen organisatie via de dropdown. Het verschil is dat het veld hier op het eerste gezicht gevuld lijkt, omdat er wel tekst in staat -- alleen geen geldige selectie.

Zoekvarianten: "validatiecriteria", "Het inkomende verzoek voldoet niet aan de validatiecriteria", "BTW punten", "debiteur Details bewerken", "Opslaan concept geblokkeerd".

Validatieregel BR-CO-09 controleert of het BTW-nummer een geldig formaat heeft. Het BTW-nummer moet altijd worden ingevoerd inclusief de landcode (ISO 3166-1 alpha-2, in hoofdletters, bijv. NL niet nl) en zonder punten, spaties of scheidingstekens.

Generieke melding bij Opslaan van een concept: de platform-UI kan in plaats van expliciet "BR-CO-09" de melding "Het inkomende verzoek voldoet niet aan de validatiecriteria" tonen. Een veelvoorkomende trigger is een debiteur-BTW-nummer met punten, maar dit is niet de enige mogelijke oorzaak -- controleer daarna ook identifiers en OrganisatieID.

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. Controleer zowel de leverancier-BTW als de debiteur-BTW: beide kunnen deze validatiefout veroorzaken.

Debiteur-BTW corrigeren: open de conceptfactuur, ga naar Debiteur en klik op Details bewerken. Corrigeer het BTW-nummer volgens bovenstaande tabel en klik op Opslaan. Verstuur de factuur daarna opnieuw via Peppol.

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.

Zoekvarianten: "rood stopteken verzenden", "rood rondje verzenden", "factuur kan niet worden verzonden", "Verzenden lukt niet", "stopteken factuur", "Factuur notitie verplicht", "IBAN bankrekening verplicht", "Meer info factuur notitie", "Betaalgegevens IBAN leeg", "verplichte velden factuur verzenden".

Bij Verzenden op een handmatige verkoopfactuur kan een rood stopteken/rondje verschijnen: de factuur gaat niet de deur uit. De oorzaak is client-side formuliervalidatie -- geen Peppol- of netwerkfout en geen platformdefect. Debiteur/OIN, Peppol-bereikbaarheid en ordernummer kunnen al kloppen terwijl Verzenden alsnog faalt door een andere leeg gebleven verplicht veld.

Controleer deze twee velden:

1. Factuur notitie (sectie Meer info) -- vul een korte notitie of referentie in, bijvoorbeeld het ordernummer of de afgesproken referentie van de afnemer.
2. IBAN bankrekening (sectie Betaalgegevens) -- vul het IBAN in waarop de betaling binnenkomt, desnoods via Wijzigen. Het IBAN op organisatieniveau is optioneel, maar op de factuur zelf kan een leeg IBAN het verzenden alsnog blokkeren.

Onderscheid met andere blokkades:

• Verzendknop reageert niet of toont placeholders: zie "Peppol-verzendknop reageert niet" hieronder (browser-autovertaling).
• Factuur blijft in concepten staan: zie het accordion-item hierover (organisatie-instelling of ontbrekende "Zenden via").

Blijft verzenden falen na het invullen van beide velden? Vraag een screenshot van de exacte foutmelding, niet alleen van het stopteken.

Zoekvarianten: "bankrekeningnummer niet juist geformatteerd", "bankrekening niet juist geformatteerd", "IBAN niet juist geformatteerd", "IBAN formaat fout", "IBAN spaties", "Betaalgegevens IBAN opmaak", "handmatig factuur verzenden IBAN fout".

Bij Verzenden van een handmatige verkoopfactuur kan de melding verschijnen dat het bankrekeningnummer of IBAN niet juist geformatteerd is, ook als het nummer inhoudelijk klopt. De oorzaak is een pre-verzending formaatvalidatie op IBAN of bankrekening in de sectie Betaalgegevens -- geen Peppol- of netwerkfout. Spaties, streepjes of andere scheidingstekens (of een ontbrekende landcode) laten de check falen.

Oplossing:

1. Open de factuur en ga naar Betaalgegevens (IBAN of bankrekening).
2. Vul het volledige IBAN in als een doorlopende reeks: landcode plus cijfers/letters, zonder spaties, streepjes of andere scheidingstekens (vorm: NL00BANK0123456789).
3. Gebruik geen oud rekeningnummer zonder landcode -- Nederlandse rekeningen beginnen met NL.
4. Sla op en verstuur de factuur opnieuw.

Onderscheid met andere blokkades:

• Leeg IBAN-veld met rood stopteken bij verplichte velden -- zie "Rood stopteken/rondje bij Verzenden" hierboven.
• "ID niet juist geformatteerd" gaat over de identifier-/schemeID-opmaak, niet over de bankrekening -- zie "Ongeldige/Invalid identifier" hierboven.

Blijft de melding verschijnen? Vraag de exacte veldinhoud (inclusief spaties of tekens) en de letterlijke foutmelding of een screenshot op.

Zoekvarianten: "verzendknop reageert niet", "laadscherm blijft hangen bij verzenden", "vreemde teksten factuur", "rare naam leverancier", "onlogische eenheid factuur", "organisatie rare tekst", "meerdere keren inloggen opslaan", "opnieuw inloggen om te versturen", "factuurvelden vertaald", "browser vertaling factuur opstellen", "kan niet inloggen", "inlogpagina rare teksten".

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 patroon kan optreden bij het opstellen van een (nieuwe) factuur: onlogische of "vertaalde" labels/veldwaarden bij onder meer leverancier, organisatie en eenheid, waarbij opslaan of versturen pas lukt na herhaaldelijk opnieuw inloggen. Dit is dezelfde oorzaak als de verzendknop-placeholders -- geen productfout en geen aanleiding om clientsoftware opnieuw te installeren (het platform is browser-only).

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 of onlogische veldlabels zichtbaar.

Oplossing (first-line volgorde):

1. Schakel automatisch vertalen in de browser uit voor het eConnect-platform (o.a. platform.econnect.eu).
2. Harde refresh (Ctrl+F5) en log opnieuw in; open of stel de factuur zo nodig opnieuw op.
3. Lukt het nog steeds niet? Leeg dan de browsercache en/of probeer een andere browser.
4. Blijft het probleem bestaan? Vraag een screenshot van de factuurpagina inclusief browser en versie.

Zoekvarianten: "foutmelding bij versturen", "intermittente portaal-fout", "na opnieuw starten wel door", "fout bij versturen zonder details", "foutmelding zonder inhoud".

Soms meldt een gebruiker een foutmelding bij het versturen via het platform, zonder de letterlijke fouttekst of een screenshot erbij. Zonder die inhoud is er onvoldoende informatie voor een harde diagnose; dit is geen bekende brede storing.

Mogelijke eerste stap (geen bevestigde oorzaak):

1. Browsercache legen en/of een andere browser proberen.
2. Helpt dat niet, geef dan meer context: de letterlijke foutmelding of een screenshot, het tijdstip en het factuurnummer.

Niet verwarren met:

• Verzendknop reageert niet, laadscherm blijft hangen, of onlogische labels/placeholders -- zie "Peppol-verzendknop reageert niet" hierboven (browser-autovertaling, met eigen first-line volgorde).
• Status SentRetry of SentError na acceptatie -- zie het accordion-item over automatische Peppol-herlevering elders op deze pagina; dat is een serverzijdig retry-mechanisme, geen browsercache-kwestie.

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.

Dezelfde melding kan ook een andere oorzaak hebben: heeft de organisatie geen BTW-nummer (stichting, overheid of zorgaanbieder)? Kies dan BTW-categorie 'O' (BTW niet van toepassing) in plaats van 'Vrijgesteld van btw (E)' -- zie "BTW-vrijgestelde organisaties: categorie O" hierboven. Dat pad geldt bij handmatige/platform-facturen; het potloodje-pad hieronder geldt bij een geüploade XML-factuur.

Oplossing (XML-upload): 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.

Zoekvarianten: "Geen verzendgeactiveerde identificaties gevonden voor het leveranciersbedrijf", verzendgeactiveerde identificaties, "verificatie leverancier nog niet gedaan", factuur versturen nieuwe administratie, twee organisaties met en zonder B.V., identifiers niet geverifieerd.

Deze melding, en de klantfrase "verificatie leverancier nog niet gedaan" bij een eerste factuur of nieuwe administratie, wijst meestal niet op een aparte leverancier-KYC-stap. De oorzaak zit vrijwel altijd in een van deze vier punten.

Checklist (in volgorde):

1. Juiste leverancier-organisatie geselecteerd? Bij twee vergelijkbare organisaties (bijvoorbeeld dezelfde naam met en zonder "B.V.") kan de verkeerde zijn gekozen. Kies via het potloodje de organisatie met geverifieerde identifiers -- een organisatie zonder geverifieerde identifiers kan niet verzenden.
2. Organisatie geactiveerd? Nog niet geactiveerd: activeer eerst via Organisatie toevoegen en activeren.
3. Schakelaar "Verzenden" aan? Ga naar Organisaties → je organisatie → Details en controleer of minstens één identifier (bij voorkeur KvK) de schakelaar Verzenden aan heeft staan. Bij een geactiveerde organisatie staat dit doorgaans al aan.
4. BTW-nummer correct? Controleer leverancier- én debiteur-BTW op landcode en scheidingstekens -- zie BR-CO-09 hierboven. Een BTW-formaatfout kan gelijktijdig optreden met deze melding.

Blijft de melding na deze vier stappen bestaan, verstuur de factuur dan opnieuw nadat de organisatie- of factuurgegevens zijn gecorrigeerd.

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) of het EndpointID (Peppol-routerings-ID) nog aanpassen. De factuur wordt dan met hetzelfde factuurnummer opnieuw verstuurd, maar met de gecorrigeerde waarde.

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.

Verouderd of gewijzigd EndpointID (bijvoorbeeld na een BTW-nummerwijziging bij de ontvanger): is een factuur naar een verkeerd of inmiddels gewijzigd Peppol-ID verstuurd, dan is Opnieuw versturen met correctie van het EndpointID de voorkeursroute, niet crediteren en herfactureren. Ga naar Postvak UIT, zoek de factuur die naar het verkeerde Peppol-ID is gegaan, klik op Opnieuw versturen, corrigeer vóór verzending het EndpointID naar het juiste ID en verstuur. De factuur gaat opnieuw uit onder hetzelfde factuurnummer naar het juiste Peppol-ID. Verifieer het juiste ID via de Peppol Directory.

Een credit note met volledige herfacturering is voor dit scenario niet nodig. Die zwaardere route geldt alleen wanneer de oorspronkelijke factuur al (gedeeltelijk) was uitgeleverd of om boekhoudkundige redenen gecorrigeerd moet worden (zie het accordion-item "InvoiceSentError" hieronder).

Resend kun je als klant alleen zelf uitvoeren met een geactiveerd platform-account met toegang tot Postvak UIT. Een IT-partner zonder eigen account moet zich eerst registreren.

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.

Tweede, andere root cause -- leeg bedragveld: de foutmelding The string '' is not a valid Decimal value op een PriceAmountType-veld ontstaat wanneer een bedragveld (bijv. cbc:PriceAmount) op een of meer factuurregels een lege string ("") bevat in plaats van een decimaal getal. xs:decimal staat geen lege string toe als lexicale waarde. Dit is een andere, aparte oorzaak dan wetenschappelijke notatie, maar dezelfde foutpatroon-klasse ("geen geldige xs:decimal"/"not a valid Decimal value"): het bronsysteem laat het veld gewoon leeg in plaats van een verkeerd geformatteerd getal te sturen.

Oplossing aan klantzijde (beide varianten): 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), en zodat geen enkel bedragveld leeg blijft.

Aan eConnect-zijde: niet automatisch te corrigeren -- de waarde staat al fout (of leeg) in de aangeleverde XML. Doorsturen naar de leverancier van het softwarepakket; factuur moet opnieuw worden aangeleverd met geldig bedrag op alle regels.

Zoekvarianten: "open invoices Peppol", "Open invoices", "facturen niet aangekomen bij klant", "debiteur ontvangt niets ook geen fout", "verzonden volgens logs niet bij ontvanger", "Peppol nothing received no error", "niets binnengekomen geen foutmelding", "sender claimt verzonden debiteur niets", "cross-AP niets binnengekomen", "first-step Peppol aflevering".

Context: de melder is vaak de verzender of diens softwarepartner. Debiteur of diens Access Point ziet niets in het systeem en geen reject. Sender-side logs claimen wel verzonden via Peppol.

Diagnosevolgorde (bestaande secties -- niet overslaan):

1. IDs -- factuurnummer(s); bij voorkeur ook verzenddatum/-tijd en exact Peppol EndpointID van de debiteur. Zonder ID is geen betrouwbare Postvak UIT-/PSB-check mogelijk.
2. Status in Postvak UIT (platform) of events in PSB Control -- zelf-diagnose; zie ook cross-AP hieronder.
3. Branch op status:
   • Afgeleverd (+ returnedMessageId): technisch geaccepteerd door het Access Point van de debiteur -- zie accordion-item "Status 'afgeleverd' maar ontvanger heeft de factuur niet ontvangen". Geen eConnect-verzendfout; de debiteur moet bij diens eigen Peppol Access Point navragen.
   • Aflevering mislukt / reject: foutcode of event -- behandel via de overige verzend-troubleshooting (lookup, SMP, documenttype, validatie).
   • Niet gevonden / nooit bij eConnect: partner-log "verzonden" is niet hetzelfde als afgeleverd via eConnect; controleer of de zending via dit account of deze participant liep (cross-AP).
4. XML pas bij inhoudelijke, encoding- of validatiediscussie nadat de transportstatus bekend is -- niet als first response op "niets binnengekomen".

Anti-pattern first response: concluderen "niet afgeleverd" zonder Postvak UIT-status, of meteen XML vragen zonder statuspad.

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.

Zoekvarianten: "organisatie toevoegen" bij factuur, leveranciersportaal, rechtsboven organisatienaam KvK, bestaande organisatieregel niet bewerken, niet hernoemen bestaande organisatie, screenshot organisatie klant rechtsboven, identifier melding bij organisatie toevoegen (leverancier), eigen organisatie apart toevoegen, debiteur als eigen organisatie, factuurontvanger toevoegen omgeving, overheidsdebiteur organisatie activeren, ontvanger moet in omgeving, aanmelden onder OIN gemeente, OIN klant als eigen organisatie, factureren aan gemeente eigen OIN, OIN ontvanger niet eigen identifier, scheme 0190 debiteur.

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, of een bestaande klantorganisatie (rechtsboven in het organisatieoverzicht herkenbaar aan naam + KvK-nummer) te bewerken of te hernoemen. Dit is geen vrijgave-issue -- support hoeft de identifier niet intern vrij te maken. De juiste werkwijze: ga naar Organisaties → Voeg organisatie toe en voer daar uitsluitend je eigen KvK-nummer en organisatienaam in (niet de bestaande klantregel bewerken of hernoemen); activeer die eigen organisatie. 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.

Zoekvarianten: "enabled for Peppol sending", "additional Peppol activation", "is sending already enabled", "extra verzendactivatie", "University of Luxembourg", "9938", "buitenlandse ontvanger scheme".

Bij een geactiveerde organisatie staat verzenden standaard aan -- dit is onderdeel van de standaardverbinding. Er is geen aparte "Peppol send enable"-stap naast een actieve organisatiestatus. Zie Peppol registratie en migratie voor de volledige activatieprocedure.

De ontvanger (bijvoorbeeld een buitenlandse Peppol-partij zoals een Luxemburgse universiteit) voer je alleen in op de factuur, via het debiteur-zoekveld (OrganisatieID + Zenden via). Voeg de ontvanger niet toe als eigen organisatie in het account -- zie ook het accordion-item "Verwarring: ontvangende organisatie proberen toe te voegen als eigen organisatie" hierboven.

Luxemburg: de identifier is EAS 9938 (BTW-nummer). Stem scheme en waarde altijd af op de Peppol-registratie van de ontvanger, bijvoorbeeld via de Peppol Directory -- zie Wat is mijn Peppol ID?.

Zoekvarianten: "geen organisatie gevonden", "ontvanger niet gevonden op naam", "debiteur zoeken faalt", "naamzoek debiteur", "kan niet op Peppol-ID zoeken", "factuur via GLN", "handmatig debiteur invullen", "bedrijfsdatabase niet Peppol", "buitenlandse ontvanger niet in zoekresultaat", "organisatie niet selecteerbaar".

Kern: naamzoek op debiteur doorzoekt de bedrijfsdatabase (KvK/KBO e.d.), niet Peppol. De melding "geen organisatie gevonden" op organisatienaam betekent dus niet dat de ontvanger niet op Peppol staat, en ook niet dat zoeken op Peppol-ID onmogelijk is.

Oplossing:

1. Debiteur niet gevonden via de bedrijfsdatabase? Vul de debiteur handmatig in met de gegevens van de ontvanger (naam, adres, identifier).
2. Is de Peppol-identifier van de ontvanger bekend -- vaak een GLN (scheme 0088, labels GS1/EAN)? Zet Zenden via op GLN en vul bij OrganisatieID alleen de cijfers in, zonder prefix 0088: (zie de algemene digits-only-regel hierboven bij identifier-opmaak).
3. Maak de ontvanger niet aan via Organisatie toevoegen -- die functie is voor de eigen organisatie, niet voor de factuurontvanger (zie het accordion-item "Verwarring: ontvangende organisatie proberen toe te voegen als eigen organisatie" hierboven).