In Nederland is in de jaren 2013-2019 veel gewerkt met de standaard SI-UBL 1.2 voor UBL-facturen. Ook de UBL-Ketentest heeft deze SI-UBL standaard jarenlang als uitgangspunt gebruikt. De bedoeling is dat alle SI-UBL 1.2 facturen vervangen worden door de Europese standaard EN 16931 en de daar vanaf geleide Nederlandse versie NLCIUS en PEPPOL BIS. Dit onderdeel is bedoeld om een handvat te geven voor deze conversie. 

Bron:
Het document "Impact analyses on SI-UBL 1.2 due to NL-CIUS and PEPPOL-CIUS (and thus EN 16931" samengesteld met handvatten voor de conversie van SI-UBL 1.2 naar de nieuwe Europese standaard EN 16931, rekening houdend met NLCIUS en PEPPOL-CIUS. Dit document hebben wij mede gebruikt om onderstaande conversie aandachtspunten samen te stellen.

Zie ook STPE voor de specificatie van onder andere NLCIUS.

In de regel maken de debiteuren- en crediteurenadministratie standaard deel uit van boekhoudsoftware. Primair gaat het dan om de openstaande posten administratie en het bewaken daarvan. Bij grote organisaties kan aan de verkoopzijde creditmanagement een rol spelen. Creditmanagement houdt zich in uitgebreide betekenis van het woord bezig met het managen en optimaliseren van de 'pre-quote to cash cycle'. In de praktijk komt dit neer op het managen en (continu) optimaliseren van: het kredietrisico, de cashflow, het quote to cash proces en de klantrelatie. Aan de inkoopzijde kan Purchase-to-Pay (P2P) een rol spelen. P2P duidt op het traject, bekeken vanuit de koper, dat start met de aankoop door de klant en dat eindigt met de betaling van de inkoopfactuur. Dit WIKI onderdeel gaat uitsluitend over de debiteuren- en crediteurenadministratie als onderdeel van boekhoudsoftware.

Elektronisch factureren en elektronische factuurverwerking is vandaag de dag meer regel dan uitzondering als het gaat om dergelijke functies binnen boekhoudsoftware. Nog even voor de zekerheid: een factuur in PDF-formaat mailen valt niet onder elektronisch factureren. Onder elektronisch factureren wordt verstaan het op elektronische wijze, in een afgesproken formaat, verzenden van facturen door een leverancier en het op elektronische wijze ontvangen en verwerken van facturen door een afnemer. Een Synoniem voor elektronisch factureren is eFacturatie. Het alleen elektronisch ontvangen en verwerken van facturen wordt aangeduid als elektronische factuurverwerking.

Het PDF-document kan, indien gewenst, embedded opgenomen worden in het UBL-document. Zie hiervoor ook WIKI UBL onderdeel "Opbouw UBL Factuur, bijlagen als embedded document".

Als gewerkt wordt met een factuur als email bijlage is aan te raden dat de naam van beide documenten (UBL en PDF) dezelfde is, behalve natuurlijk de suffix. (bijv. factuur50301.xml en factuur50301.pdf). Op deze wijze is altijd duidelijk dat betreffende documenten bij elkaar behoren. Dit is uiteraard niet van toepassing als alleen sprake is van een UBL-factuur met embedded (ingesolten) een PDF. Dit laatste is bijvoorbeeld het geval bij gebruik van het Peppol netwerk. 

Onder de noemer "EN 16931" is in Europa gewerkt aan het maken van één norm voor elektronisch factureren (met als syntaxen UBL en UN/CEFACT). Er wordt hierbij gesproken over een "kernfactuur". De Europese richtlijn 2014/55/EU schrijft voor dat in ieder geval alle aanbestedende diensten in de EU met deze nieuwe norm en bijbehorende syntaxen moeten werken sinds medio april 2019.

PEPPOL BIS
Onder de noemer "PEPPOL BIS V3" kent PEPPOL ook een specificatie om een factuur op te bouwen. Deze specificatie is volledig afgestemd op de Europese standaard EN 16931 voor wat betreft UBL. 

PEPPOL BIS (V3) aangevuld met enkele landgebonden specificaties (voor Nederland) vormt de NLUBL waar deze WIKI mede betrekking op heeft. 

NLUBL is de (verzamel)naam voor de implementatie standaard van UBL in Nederland op basis van PEPPOL-BIS en de NLCIUS.
De opbouw van NLUBL wordt weergegeven door onderstaand schema:

Voordat de elementen op een UBL Factuur verder worden toegelicht volgt onderstaand eerst een simpel, maar compleet, voorbeeld van een factuur met 1 factuurregel en (dus) 1 BTW-percentage.

Een UBL factuur bevat de volgende (overige) referenties:

1. [0..1] OrderReference; inkooporder en desgewenst verkooporder (SalesOrderID).
   Met de elementen:
   - [1..1] ID; inkoopordernummer, uitgegeven door de koper. 
   - [0..1] SalesOrderID; verkooporder, uitgegeven door de leverancier. 
   
   PEPPOL BIS (PEPPOL-EN16931-R003)
   Een factuur moet een koperreferentie (BuyerReference) of een inkooporderreferentie (OrderReference) hebben.
   
   NLCIUS (BR-NL-2)
   Een factuur moet een koperreferentie (BuyerReference) of een inkooporderreferentie (OrderReference) hebben.
   Indien er een Inkoopordernummer is gecommuniceerd dient deze door Nederlandse leveranciers verplicht opgenomen te worden.
     
2. [0..*] BillingReference); factuurreferentie 
   A reference to a commercial invoice or corrective invoice of which the current invoice is a correction of. Dus een verwijzing naar een eerdere factuur.
   Met de elementen:
   - [1..1] InvoiceDocumentReference;
              [1..1] ID 
              [0..1] IssueDate; formaat "JJJJ-MM-DD".
   
   NLCIUS:
   - Voor Nederlandse leveranciers verplicht bij correctie facturen (code 384). Kan ook gebruikt worden bij deelfacturatie.
   - IssueDate (vorige factuurdatum) wordt afgeraden.
     
3. [0..*] DespatchDocumentReference); verzendreferentie
   [0..1] EU-N
   Met element:
   [1..1] ID.
     
4. [0..*] ReceiptDocumentReference); ontvangstreferentie
   [0..1] EU-N
   Met element:
   [1..1] ID.
     
5. [0..*] OriginatorDocumentReference; Inschrijvings(tender)referentie
   [0..1] EU-N
   Met element:
   [1..1] ID.
      
6. [0..*] ContractDocumentReference; Contract(document)referentie
   [0..1] EU-N
   Met element:
   [1..1] ID.
   
   

De gegevens van de afzender van de factuur zijn in UBL ondergebracht onder:
[1..1] <AccountingSupplierParty>
   [1..1[ <party>:

1. [0..1] EndpointID; Elektronische netwerkadressering (EndpointID) van de leverancier, zoals PEPPOL adressering;
   [1..1] PEPPOL  
   Met verplicht SchemeID volgens ISO 6523 ICD code. Voor KVK code 0106 en voor OIN code 0190.
   Nadere specificaties PEPPOL netwerk binnen een UBL-factuur.
   
   
2. [0..*] PartyIdentification; Identificatie van de verkoper. 
   Met element:
   - [1..1] ID; Met optioneel SchemeID volgens ISO 6523 ICD code.
    
   PEPPOL BIS toelichting:
   Dit element wordt zowel gebruikt voor de identificatie van de verkoper, als voor de unieke bankreferentie-identificatie van de verkoper (toegewezen door de bank van de verkoper). Gebruik voor verkoperidentificatie de ICD-codelijst, gebruik SEPA voor een aan de SEPA bank toegewezen crediteurreferentie. Om ervoor te zorgen dat de koper automatisch een leverancier identificeert, moet deze identificatie van de verkoper, de wettelijke registratienummer van de verkoper (zie punt 6) en/of de btw-identificatie van de verkoper (zie punt 5) aanwezig zijn.
   
   SchemeID
   Het identificatieschema-ID van de verkoper-ID, bijvoorbeeld 0106 (KVK) of 0190 (OIN). Voor aan de bank toegewezen crediteur-ID MOET de waarde "SEPA" zijn
   
   NLCIUS toelichting:
   Voor het identificeren van de Leverancier (in de communicatie tussen Leverancier en Afnemer) kunnen verschillende soorten identifiers worden gebruikt. Bijvoorbeeld het GLN, KVK nummer, KVK vestigingsnummer, een sector identifier, of bilateraal afgesproken identifier. Dit veld wordt aanvullend gebruikt op het Registratienummer leverancier (zie punt 6) en het BTW nummer (Zie punt 5). (BT-31).
   Het KVK vestigingsnummer kan niet worden gebruikt voor routing op het PEPPOL netwerk, maar alleen voor het identificeren van partijen.
   
   UBL Ketentest:
   Bovenstaand wordt in de meeste gevallen het KVK-nummer of OIN-nummer gebruikt (zie punt 6).
   In dat geval dus het zelfde nummer als bij het eerder genoemde EndpointID voor SEPA.
      
3. [0..*] PartyName; Naam van de afzender.
   [0..1] EU-N
   Met element: 
   - [1..1] Name.
   
   EU-N:
   EU-N stelt zich op het standpunt dat alleen de registratienaam verplicht is (zie onder punt 6 PartyLegalEntity) en daarom deze naam (PartyName) optioneel is!
   Advies UBL Ketentest: naam altijd opgeven.
   
   
4. [0..1] PostalAddress; Postadres van de afzender.
   [1..1] EU-N 
   Met elementen:
   - [0..1] StreetName; straat.
     [1..1] NLCIUS; verplicht indien leverancier in NL.
   - [0..1] AdditionalStreetName. 
   - [0..1] CityName; woonplaats.
     [1..1] NLCIUS; verplicht indien leverancier in NL.
   - [0..1] PostalZone; postcode.
     [1..1] NLCIUS; verplicht indien leverancier in NL
   - [0..1] CountrySubentity; provincie. Niet gebruikelijk in Nederland.
   - [0..*] AddressLine; een of meer aanvullende adresregels.
     [0..1] EU-N
              [1..1] Line; aanvullende adresregel
   - [1..1] Country; landcode.
              [1..1[ IdentificationCode; bijv. NL.
   
   PEPPOL BIS
   Er moeten voldoende onderdelen van het adres worden gevuld om aan de wettelijke eisen te voldoen.
   
   NLCIUS: 
   Volgens de Belastingdienst moeten adressen zo compleet mogelijk zijn. Vermelding van alleen een postbusnummer is niet voldoende. De factuur wordt niet gebruikt om stamgegevens bij te werken. Het ontvangende systeem zal doorgaans niets doen met adresgegevens.
   
   Gebruik aanvullende adresgegevens wordt afgeraden.
   Gebruik provincie wordt afgeraden.
   
   UBL Ketentest
   Oneens dat ontvangende systeem niets doet met adresgegevens.
   1. Kan gebruikt worden om adresgegevens leverancier op te nemen als deze nieuw is.
   2. Kan gebruikt worden als sprake is van een adreswijziging. Advies is dan wijziging vooraf melden en laten autoriseren. 
   
   Uitgaande facturen; zoveel mogelijk straat inclusief huisnummer.
   Inkomende facturen; straat aanvullen met inhoud huisnummer als dit laatste apart is gevuld (via BuildingNumber - dat bij EU-N niet gebruikt wordt). 
   De reden is dat in vorige UBL versies (zoals SI-UBL 1.2) het huisnummer apart opgegeven moest worden via BuildingNumber.
   
   
5. [0..*] PartyTaxScheme; BTW-gegevens van de afzender;
   [0..2] EU-N
   Met elementen:
   - [0..1[ CompanyID; BTW-nummer afzender.
     [1..1] PEPPOL 
   - [1..1] TaxScheme; aanduiding VAT.
              [1..1] ID; aanduiding altijd "VAT".
   
   NLCIUS
   Dit veld betreft het BTW nummer van de Leverancier. Indien leverancier BTW plichtig is in Nederland, dan moet dit gegeven opgenomen worden.
      
6. [0..n] PartyLegalEntity; KvK-gegevens van de afzender 
   [1..1] EU-N
   Met elementen:
   - [0..1] RegistrationName; Registratienaam van de afzender
     [1..1] EU-N
   - [0..1] CompanyID; Vooraf gegaan door SchemeID volgens ISO 6523 ICD code. Veelal KvK-nummer van de afzender. 
   In plaats van KvK kan ook sprake zijn van een andere instantie, c.q. nummer-uitgave. Zo kennen we in Nederland OIN (Overheids Identificatie Nummer) voor overheden die geen KvK-nummer hebben.
   
   OIN staat voor openbare Organisatie-identificatienummers (ook wel "Overheids indentificatienummers" genoemd). 
   Voor meer informatie en raadplegen van OIN zie de Centrale OIN Raadpleegvoorziening. 
   
   NLCIUS:
   Als Nederlandse leverancier dan verplicht en alleen gebruiken KVK code 0106 of OIN code 0190.
   
   - [0..1] CompanyLegalForm; Juridische informatie
   NLCIUS: Juridische informatie (CompanyLegalForm) afgeraden. N.v.t. voor Nederlandse leveranciers.
      
7. [0..1] Contact; Contactgegevens afzender.
   Met elementen: 
   - [0..1] Name; 
   - [0..1] Telephone; 
   - [0..1] ElectronicMail; emailadres.