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 in een formaat dat niet wordt ondersteund. Het platform accepteert alleen PDF, PNG en JPEG als bijlageformaat. Word-documenten, Excel-bestanden en andere Office-formaten worden niet geaccepteerd.

Oplossing: Exporteer het bestand naar PDF en voeg de PDF-versie toe als bijlage.

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).

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.

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.

Het BTW-nummer moet worden ingevuld zonder spaties, punten of streepjes, inclusief de landcode. Het juiste formaat voor Nederland is NL123456789B01. Belgische BTW-nummers moeten worden ingevuld als BE gevolgd door precies 10 cijfers, zonder scheidingstekens.

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.

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.

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.

Deze melding verschijnt wanneer je een XML-factuur handmatig uploadt en het veld EndpointID van de leverancier ontbreekt in het bestand. In de platform-UI is dit het veld "Partij-ID" onder het kopje "Leverancier".

Oplossing: selecteer via de dropdown een waarde uit je eigen organisatie. Als de dropdown niet het juiste resultaat toont, selecteer dan de leverancier opnieuw zodat de koppeling wordt vernieuwd.

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.

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.

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.

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.