Scope en breder gebruik van het factuurmodel

Memorandum

Aan

Menno van Drunen, Sierd Westerfield, Logius Jan Julianus, Erik Wijnen, Min. EL&I Van

Capitool 10 7521 PL Enschede www.tno.nl T +31 88 866 21 48 F +31 88 866 21 47 [email protected]

Onderwerp

Suggesties voor vervolgstappen semantisch factuurmodel

Datum 15 november 2011 Doorkiesnummer +31 6 51894657

Aanleiding TNO heeft in opdracht van Logius een ‘Aanzet tot een semantische specificatie voor e-Facturen’ ([ASSEF]) gemaakt en zich daarbij conform de opdracht gebaseerd op de functionele specificaties van facturen zoals beschreven in [FMEBF] en (vooral) de wet (op de Omzetbelasting). Daarnaast heeft TNO gekeken naar een afbeelding van het functionele factuurmodel uit [FMEBF] naar een Europees Core Invoice factuurmodel dat door CEN is vastgelegd [CEN-CI]. We hebben vastgesteld dat de specificaties uit [FMEBF] ontoereikend zijn om aan de wet (op de Omzetbelasting) te voldoen. De specificaties lijken gebaseerd te zijn op minder geschikte ontwerpparadigma’s en vertonen inconsistenties met andere 1 ontwerpdocumenten . Daarnaast zijn er de nodige verschillen tussen het NL factuurmodel en het CEN-CI factuurmodel die in een volgende versie opgelost zouden moeten worden. Dit is voor Menno van Drunen (Projectmanager DigiInkoop / e-Factureren) aanleiding geweest TNO te vragen aanbevelingen te doen ter verbetering. Deze memo bevat de visie en aanbevelingen van TNO met betrekking tot een vervolgversie.

Scope en breder gebruik van het factuurmodel Volgens het Besluit Digipoort voor e-Facturen [BDeF] moeten elektronische facturen (e-Facturen) vanaf 1 januari 2011 via Digipoort ontvangen kunnen worden en in behandeling genomen door het ministerie dat het aangaat. De specificatie voor e-Facturen, die volgens [BDeF] door de Staat wordt bepaald, bevat alle regels (eisen, afspraken) waaraan betrokkenen zich dienen te houden teneinde e-Facturen te kunnen verwerken. Bijgevolg moet zo’n specificatie tenminste een syntactische en een semantische component bevatten (zie hoofdstuk 1.3 [ASSEF] voor meer details hieromtrent en hoofdstuk 1.1 voor de problematiek). Het doel van dit Besluit is dus om afspraken te maken voor standaarden voor e-Factureren om zodoende de semantische interoperabiliteit en de samenwerking tussen facturerende/betalende partijen te optimaliseren.

1

Deze en andere ervaringen zijn (deels) beschreven in de ‘Discussie’ paragrafen van [ASSEF].

Datum 15 november 2011

De semantische component bevat regels die de betekenis specificeren van (factuur)gegevens in termen van wat ermee moet kunnen worden gedaan. Semantische regels stammen uit verschillende bronnen, waaronder: •

afspraken zoals we die in de B.V. Nederland met elkaar hebben gemaakt en (dus) wettelijk zijn vastgelegd. Voorbeeld: “een factuurdatum is de datum waarop de factuur is c.q. wordt uitgereikt” (bron: Wob68).

•

afspraken die voor een of meer belanghebbenden nodig zijn om een of meer processen uit te kunnen voeren. Voorbeeld: “een factuurdatum is de datum waarop de factuur is aangemaakt” (belanghebbende = leverancier; bron = diens facturatie proces). Ander voorbeeld: “een factuurdatum is de datum waarop de factuur is ontvangen” (belanghebbende = klant; bron = diens betalingsproces).

•

afspraken c.q. voorwaarden die door de ene belanghebbende aan een andere worden opgelegd en als zodanig ook bekend staan als ‘voorwaarden’; vaak hebben die met het afdekken van risico’s te maken. Voorbeeld: “de factuur moet binnen 30 dagen na de factuurdatum zijn betaald” (belanghebbenden zijn leverancier en klant; de regel beoogt liquiditeitsproblemen bij de leverancier te voorkomen door de klant te verplichten tijdig te betalen). Dit soort (ook semantische) regels kun je generiek vastleggen, of je kunt ervoor kiezen deze per geval af te spreken, bijvoorbeeld door ze als voorwaarde in de factuur of in een contract op te nemen.

Het probleem van semantische interoperabiliteit kan op basis hiervan als volgt worden geformuleerd. ’Elke verwerker van facturen kent een eigen semantiek, bestaande uit alle regels volgens welke (gegevens uit) de factuur door hem wordt verwerkt (aangemaakt, gebruikt, veranderd of verwijderd). Deze regels komen uit de wetgeving waaraan die specifieke verwerker moet voldoen, uit het bedrijfsproces waarin door middel van facturen verrekend wordt en uit maatregelen die de verwerker besloten heeft te implementeren teneinde risico’s die aan de verwerking kleven, te mitigeren. Twee verwerkers zijn ‘semantisch interoperabel’ met betrekking tot facturen als elke factuur die zij elkaar sturen voldoet aan zowel alle semantische regels van de een als aan die van de ander en dat ze deze regels kennen, begrijpen en er naar handelen.’ In de praktijk wordt de term ‘factuur’ voor semantisch verschillende concepten gebruikt. Een zogenaamde ‘pro-forma factuur’ bijvoorbeeld hoeft niet aan de semantische specificaties (voor facturen) van de belastingdienst te voldoen; datzelfde geldt voor een ‘voorstel factuur’. Hieruit concluderen we dat het opschrijven van een volledig dekkende semantische beschrijving, als losstaand document niet nuttig en dus ook onwenselijk is. Immers, er zijn diverse processen waarin verschillende vormen van facturen gebruikt worden en het hebben van één enkele volledig dekkende beschrijving zou werk opleveren voor elke partij die iets met e-Facturen doet. Dat is niet geheel in lijn met onder meer het in [BSF2009] genoemde besluit om de regels voor elektronisch factureren sterk te vereenvoudigen en de vormgeving en implementatie van oplossingen voor elektronisch factureren aan marktpartijen over te laten.

Blad 2/9

Datum 15 november 2011

Het is aan te raden om de semantische specificaties zodanig op te stellen dat het leeuwendeel van de facturen, dat relatief eenvoudig is, ook eenvoudig gespecificeerd kan worden zoals aangegeven in [WEEF] of met behulp van een sjabloon als [FFUBL]. Wel moet het mogelijk zijn om specialisaties van deze eenvoudige semantiek te definiëren, zoals voor producten c.q. diensten waarvoor (ook) specifiekere wetgeving bestaat (bijvoorbeeld energielevering), of als overheidspartijen of partijen uit het bedrijfsleven processen hebben van waaruit additionele eisen aan facturen gesteld moeten kunnen worden (zoals bij import). Op basis van het voorgaande bevelen we aan om verschillende soorten eFactuurmodellen te ondersteunen voor specifieke doeleinden en die modellen specialisaties te laten zijn van één basis factuurmodel. Een factuurmodel structuur hiervoor voldoet aan de volgende criteria (eisen, specificaties): C1: Voor elk type factuur bestaat precies één (expliciete) specificatie van: (a) het doel dat met facturen van dat type wordt nagestreefd (i.e. ‘waartoe’ zulke facturen bestaan) (b) de verzameling van factuur types waarvan het een specialisatie is; (c) de verzameling van (soorten) belanghebbenden en processen voor welke de specificatie relevant is; (d) de syntactische en semantische regels die, naast alle syntactische en semantische regels van elk factuur type waarvan het gespecificeerde factuur type een specialisatie is (zoals bedoeld onder (b)), specifiek voor het gespecificeerde factuurtype gelden. C2: Er bestaat precies één type factuur die geen specialisatie is van enige andere factuur (de zgn. ‘basisfactuur’). C3: Elke factuur is een instantie van precies één factuur type en moet daarom voldoen aan alle specificaties (syntax en semantiek) van dat factuur type (inclusief die welke zijn overgeërfd van de factuurtypes waarvan dat type een specialisatie is). Het volgen van een dergelijke e-Factuurmodel structuur maakt het volgende mogelijk: •

De verantwoordelijkheid voor en het beheer van elk type factuur, d.w.z. van de (expliciete) specificatie daarvan, is eenvoudig en eenduidig te beleggen. Als bijvoorbeeld het e-Inkoop proces van de Dienst Justitiële Inrichtingen (DJI) specifieke eisen zou willen stellen aan facturen die zij geacht wordt te betalen, dan kunnen zij een factuur van het type ‘DJI-factuur’ specificeren, die een specialisatie is van (bijvoorbeeld) ‘Overheidsfactuur’, en daarbij de syntactische en semantische regels vastleggen die DJI-facturen van Overheidsfacturen onderscheidt. Dit soort specialisaties dienen dan alleen gebruikt te worden indien de basis e-Factuur niet voldoet. Daar hebben alleen die belanghebbenden ‘last van’ (c.q.: baat bij) die facturen naar DJI sturen. Deze eigenschap beperkt niet alleen de beheerlast tot het noodzakelijke, maar belegt deze ook daar waar de kennis is om dat te doen.

Blad 3/9

•

Het technisch beheer en het ontsluiten van de specificaties kan, voor de verschillende soorten facturen, centraal worden geregeld. Dat kan bijvoorbeeld door het inrichten van een ‘repository’, waarbij belanghebbenden voor elk type factuur de complete set specificaties kan krijgen, d.w.z. de specificaties die specifiek voor dat type factuur zijn gedefinieerd alsmede de specificaties van alle factuur types waar het een (directe of afgeleide) specialisatie van is. Op deze wijze weet elke belanghebbende voor elke factuur die hij verwerkt steeds aan welke syntactische en semantische regels moet worden voldaan; daarop kan hij zijn IT inrichten. Dat geldt zowel voor overheidsinstanties als voor andere partijen. Er zijn (bestaande) e-Factuur modellen2 die reeds handvatten bevatten voor het omgaan met deze semantische problematiek. Zo kent UBL ([UBL20]) bijvoorbeeld het element cbc:CustomizationID, waarmee de factuur typering zoals hiervoor beschreven kan worden geïmplementeerd: er kan worden aangegeven wat de naam is van zo’n factuurtype (schemeName), welke partij het factuurtype beheert (schemeAgencyID, schemeAgencyName), de versie van de specificatie voor het betreffende factuur type (schemeVersionID), en de locatie van de specificatie (schemeURI, schemeDataURI). Op eenzelfde wijze kent CEN-CI ([CEN-CI]) de data-elementen “Customization identifier” en “Business process identifier”. UBL zelf specificeert al syntax (en een beetje semantiek) van facturen. De syntax is echter erg uitgebreid, kennelijk omdat de opstellers ervan menen dat ze alle mogelijke soorten facturen ermee zouden moeten kunnen representeren. Voor de syntax specificaties lijkt dat misschien een goed idee, maar vanuit semantisch oogpunt is dat niet realistisch: de semantiek van facturen zal altijd kunnen verschillen, afhankelijk van de contexten waarin deze wordt verwerkt. De (weinige) semantische regels die UBL voor facturen specificeert, in het bijzonder de multipliciteitsregels, lijken geen beperkingen op te leggen die het werken op de door ons voorgestelde wijze verhinderen.

Aansluiting bij het CEN-CI factuurmodel De focus van deze sectie is op de semantische vergelijking van het factuurmodel (zoals min of meer beschreven in [ASSEF]) en het CEN-CI factuurmodel [CEN-CI CWA-2]. Indien relevant, is in de onderbouwing van de observaties in dit document ook de syntactische vergelijking gedaan tussen corresponderende dataelementen uit beide modellen. Het Logius factuur datamodel EBF verschilt in omvang aanzienlijk van het CEN-CI datamodel. EBF bevat 57 data-elementen, CEN-CI bevat 102 data-elementen. Dit verschil in aantal data-elementen geeft al een duidelijke indicatie dat een 1-op-1 afbeelding tussen de data-elementen uit beide datamodellen niet mogelijk is. Onderstaande tabel geeft aan wat het gevolg is van de wijze waarop in het 2 Deze modellen zijn evenwel geen semantische modellen in de zin zoals wij die bedoelen: ze specificeren syntax en op zijn best suggereren ze stukken semantiek

Datum 15 november 2011 Blad 4/9

elektronisch factuurmodel wordt omgegaan met de data-elementen waarvoor de mapping tussen EBF en CEN-CI ambigu is. Mapping tussen EBF en CEN-CI Data-elementen uit EBF zonder mapping naar een data-element uit CEN-CI Data-elementen uit CEN-CI zonder mapping naar een data-element uit EBF Data-elementen uit EBF met discutabele semantische mapping naar een data-element uit CEN-CI en vice versa

Data-elementen uit EBF met goede mapping naar een data-element uit CEN-CI met kleine (semantische of syntactische) definitieverschillen en vice versa

Afwegingen Voor deze data-elementen dient te worden afgewogen of er voldoende reden is om deze in het EBF op te (blijven) nemen. Voor deze data-elementen dient te worden afgewogen of er voldoende reden is om deze alsnog in het EBF op te nemen. Voor deze data-elementen dient het gebruik van de mapping tussen beide datamodellen met zorgvuldigheid te worden uitgevoerd, omdat de aspecten waarover deze dataelement gaan verschillend kunnen zijn t.g.v. verschillen in de semantische beschrijving. Per data-element dient een aanpassing / oplijning van de definitie te worden heroverwogen. Voor deze data-elementen zijn de verschillen niet zodanig dat een heroverweging van de definitie nodig is, maar wel zorgvuldigheid is geboden bij de (automatische) mapping tussen beide datamodellen.

In het vervolg van deze sectie wordt een aantal gedetailleerde bevindingen uit de vergelijking beschreven met bijbehorende aanbeveling. Het CEN-CI data-model bevat data-elementen (INV001 “Customization identifier” en INV002 “Business process identifier”) om een invoice te relateren aan een specifieke gebruikscontext en/of business proces. Dit geeft ook de mogelijkheid om beter toegesneden en specifieke invullingen en syntax voor de eFactuur te gebruiken voor een specifieke toepassing of context. EBF biedt hiervoor niet de structuur: het bevat geen overeenkomstige data-elementen voor gebruikscontext en voor procesverwijzingen. Dit beperkt de verdere mogelijkheden voor het flexibel inzetten en aanpassen van het datamodel voor gerelateerde processen. EBF bevat wel het data-element “factuursoort” dat eventueel gebruikt kan worden om een workflow mee te identificeren. Het is aan te bevelen om het opnemen van vergelijkbare data-elementen in EBF te overwegen, zodat deze ook de structuur borgt om deze flexibel voor diverse gebruiks- en procescontexten te kunnen gebruiken. Merk op dat dit data element een e-Factuur model structuur ondersteunt zoals we dat in voorgaand hoofdstuk hebben gespecificeerd. De structuur voor het indelen en beschrijven van de data-elementen verschilt tussen diverse datamodellen voor de eFactuur (inclusief een eerdere versie van EBF (v1.1)):

Datum 15 november 2011 Blad 5/9

Het CEN-CI data-model document [CEN-CI CWA-2] beschrijft de dataelementen in een “platte lijst” zonder daarin een verdere opdeling naar categorieën (hiërarchische niveaus). De eFactuur v1.1 beschrijving [E-Factv1.1] gebruikt een hiërarchische structuur met op het hoogste niveau de entiteit “Bericht”, met daaronder het tweede niveau met de entiteiten: ”Persoon (Debiteur)”, ”Persoon (Afnemer)”, ”Persoon (Crediteur)”, ”Persoon (Leverancier)”, ”Factuur”. Op de volgende niveaus worden de individuele data-elementen hierbinnen verder benoemd. [FMEBF] heeft een tussenvorm als structuur, met slechts twee niveaus (“Algemeen” en “Factuurregel”) Dat de hiërarchische structuur die de auteurs van deze documenten voor ogen staat mogelijk toch aanwezig is, blijkt uit de mappings naar UBL (varianten) die in andere documenten beschikbaar is. Wij bevelen aan om een hiërarchische structuur te handhaven en te overwegen deze verder op te lijnen met de hiërarchische structuur zoals die blijkt uit de syntactische mapping documenten voor CEN-CI [CEN-CI CWA-3]. We hebben per data-element uit het EBF v.1.6 datamodel een semantische mapping gemaakt op gerelateerde elementen uit het CEN CI datamodel, en vice versa. De gedetailleerde resultaten van deze mappings in beide richtingen zijn vastgelegd in de MS Excel spreadsheet “Mapping EBF v1.6 and CEN CI.xlsx” [MAP]. Door het grote verschil in aantal data-elementen tussen het Logius EBF eFactuur datamodel en het CEN-CI e-Factuur datamodel is er niet een eeneenduidige semantische mapping tussen overeenkomende data-elementen uit beide e-Factuur datamodellen.. Het gevolg is hiervan dat er verschil is tussen EBF en CEN-CI in de mate van uitgebreidheid waarin verschillende eigenschappen per factuur en factuurregel kunnen worden opgenomen. Dit is een potentiële beperking van de functionaliteit van EBF. We bevelen aan te heroverwegen voor welke eigenschappen onderscheidende data-elementen tussen het niveau van de factuur en het niveau van de factuurregel dienen te worden opgenomen. 3

Een eerdere versie van EBF (EFV1.1 ) maakt in de rollen onderscheid tussen Debiteur, Afnemer, Crediteur en Leverancier. Daarbij wordt dus onderscheid gemaakt tussen enerzijds de rollen die afnemen/leveren (de “beslissende” rollen) en anderzijds de rollen die betalen/innen (de “administrerende” rollen). EBF doet dat niet, alleen klant en leverancier, waarbij voor de klant weer wel een onderscheid wordt gemaakt in het factuuradres en het afleveradres. CEN-CI onderscheidt wel de buyer en de seller. Wij bevelen aan de onderscheiden zoals CEN-CI die maakt, te volgen. Er is in de EBF een aantal data-elementen waarvoor een een een-eenduidige semantische mapping met een data-element uit CEN-CI [CEN-CI CWA-2] ontbreekt. Dit betreft de data-elementen: “identificatie laatste factuur” 3 Het EFV1.1 is formeel buiten de scope van de vergelijking tussen datamodellen. Het onderscheid in de vier partijen ervan wordt hier echter gebruikt om het verschil in aanpakken tussen de verschillende datamodellen voor eFacturen inzichtelijk te maken.

Datum 15 november 2011 Blad 6/9

“leveringsconditie” “opdrachtgever” “belastingen” “belastingcategorie” “belastingpercentage” Wij bevelen aan om voor deze data-elementen te heroverwegen om deze in het EBF op te (blijven) nemen. Er is in CEN-CI een groot aantal data-elementen waarvoor niet een mapping is met een data-element uit de EBF. Een aantal van deze data-elementen benoemen we hier omdat ze van groter belang worden geacht voor de inhoud van een invoice: INV034, INV035, INV036 en INV037 m.b.t. “Buyer Contact” INV012, INV083 en INV084 m.b.t. “Contract” INV001 m.b.t. “Customization” Zie hiervoor het eerdere punt met betrekking tot de flexibiliteit en herbruikbaarheid van het datamodel voor de eFactuur in verschillende contexten en processen. Wij bevelen aan om voor deze data-elementen te heroverwegen om deze in het EBF op te nemen. Er is een aantal data-elementen waarvoor het EBF één enkel overkoepelend dataelement benoemt, terwijl het CEN-CI dit verder uitsplitst in meer gedetailleerde data-elementen. Dit geldt bijvoorbeeld voor de data-elementen: Voor het data-element “adres” gebruikt EBF één enkel data-element (“adres”, voor leverancier) of het data-element (“factuuradres” en “afleveradres”, voor klant). CEN-CI splitst dit veel verder uit naar de data-elementen “straat”, “huisnummer”, “postcode”, “plaats”, etc. -

Maar: in de UBL en HR-XML standaarden is het generieke dataelement voor “adres” ook verder opgedeeld naar deelelementen. De mapping van deze uitsplitsing naar de corresponderende CEN-CI data-elementen is goed uitvoerbaar.

Voor het data-element “bankgegevens” gebruikt EBF één enkel data-element CEN-CI splitst dit verder uit naar de data-elementen “Account identifier”, “Seller financial institution branch ID” en “Financial institution branch identifier”. Voor het data-element “contactpersoon” gebruikt EBF één enkel data-element CEN-CI splitst dit verder uit naar de data-elementen “Seller contact person name”, “Seller contact telephone number”, “Seller contact fax number” en “Seller contact email address”. Voor de data-elementen “kortingindicator” en “toeslagindicator” gebruikt EBF één enkel data-element CEN-CI splitst deze verder uit naar de dataelementen “Document level allowance or charge details”, “Allowances and charges detail text” en ““Allowances and charges reason code”. - Maar ook UBL heeft ook aanvullende velden voor "AllowanceCharge" om meer beschrijvende elementen toe te voegen. De mapping van

Datum 15 november 2011 Blad 7/9

deze uitsplitsing naar de corresponderende CEN-CI data-elementen is goed uitvoerbaar. Wij bevelen aan te overwegen de werkwijze van CEN-CI hierin te volgen.

Algemene aanbevelingen Vanuit het voorafgaande hebben we de volgende aanbevelingen: 1. Specificeer een (Nederlandse) Basisfactuur zoals bedoeld in criterium C2 (zie hierboven), die de meest eenvoudige subset is van de UBL basisfactuur en alleen de hoogst noodzakelijke semantische specificaties bevat. Het eigenaarschap van deze specificatie zou kunnen worden belegd bij Logius. 2. Specificeer een ‘80%-factuur’ als specialisatie van die basisfactuur, die voor verreweg de meeste gevallen gebruikt kan worden, analoog aan [FFUBL]. Het eigenaarschap van dit type factuur zou kunnen worden belegd bij de eigenaar van het e-Inkoop proces. 3. Specificeer een factuur type voor elk proces dat e-Facturen verwerkt die niet met een reeds bestaand type factuur uit de voeten kan, conform de criteria C1 t/m C3 op pagina 3. Beleg het eigenaarschap van dit factuurtype bij de proceseigenaar resp. een groep van belanghebbenden (waar de proceseigenaar dan onderdeel van uitmaakt). 4. Maak een lijst van andere noties, zoals Order, Aanmaningen, Vrachtbrief, enzovoorts, en ga na in hoeverre voornoemde aanbevelingen ook relevant zijn voor deze noties. Voor de realisatie van zo een e-Factuur structuur kunnen de volgende acties worden uitgezet: 1. Richt een repository in voor factuur specificaties, met daarin de specificatie van de Basisfactuur en de ‘80%-factuur’. Eigenaarschap en beheer van de repository zou belegd kunnen worden bij Logius. 2. Richt een interface in op de repository die belanghebbenden kunnen gebruiken om de voor hen relevante factuur specificaties te kunnen zoeken en raadplegen. 3. Richt een interface in op de repository die door beheerders van factuur specificaties gebruikt kan worden voor het aanmaken, wijzigen en uitfaseren van (versies van) factuur specificaties. 4. Richt een opleiding in voor eigenaren van processen waarin facturen worden verwerkt, zodat zij a. kunnen (laten) bepalen of en wanneer het nodig is factuur types te specificeren c.q. aan te passen (vanuit belangen van hun processen); b. factuur types adequaat kunnen (laten) specificeren, zowel syntactisch als semantisch, teneinde specifieke procesbelangen te dienen c.q. proces risico’s te mitigeren.

Datum 15 november 2011 Blad 8/9

5. Richt ondersteuning in voor eigenaren als bedoeld in de vorige aanbeveling bij het maken c.q. beheren van de daar bedoelde specificaties.

Referenties ASSEF BDeF BSF2009

CEN-CI

CEN CI CWA-2

CEN CI CWA-3 CHESSS

E-Factv1.1 FFUBL

MAP

UBL20

WEEF

Wob68

R. Joosten, “Aanzet tot een semantische specificatie voor eFacturen”, TNO-rapport, 28 oktober 2011. Besluit Digipoort voor e-Facturen (nr. WJZ/10145713). http://wetten.overheid.nl/BWBR0028947 Besluit van de staatssecretaris van Financiën d.d. 12 februari 2009, betrekking hebbende op “Omzetbelasting, administratieve en factureringsverplichtingen”. http://wetten.overheid.nl/BWBR0025315 CEN: MUG - 'Core' Cross Industry Invoice European Message Implementation Guideline Project http://www.cen.eu/cen/sectors/sectors/ISSS/Activity/pages/mug.aspx CEN Workshop Agreement (CWA) 16356-2, “Guide for a European CORE INVOICE data model with UN/CEFACT CII Implementation Guideline - Part 2: European CORE INVOICE data model”, September 2011 CEN Workshop Agreement (CWA) 16356-3, “Guide for a European CORE INVOICE data model with UN/CEFACT CII Implementation Guideline - Part 3: European CORE INVOICE syntax mapping”, September 2011 CEN's Horizontal European Service Standardization Strategy, i.h.b. Module 6. http://www.cen.eu/cen/Services/Business/Value/CHESSS/Pages/ default.aspx Logius (M. van Drunen en R. Hommes), “eFactuur Functioneel Ontwerp, versie 1.1”, 15 September 2010 Factuur formulier (UBL) is een praktisch hulpmiddel voor het maken van facturen. http://www.rijksoverheid.nl/bestanden/documenten-en-publicaties/ formulieren/2010/12/17/factuurformulier/factuur-formulier-ubl.pdf TNO, Semantische mapping van EBF v1.6 en CEN CI, “Mapping EBF v1.6 and CEN CI.xlsx”, TNO deliverable i.o.v. Logius, Oktober 2011. OASIS: Universal Business Language v2.0 Standard, 12 December 2006. http://docs.oasis-open.org/ubl/os-UBL-2.0.zip, aangevuld met http://docs.oasis-open.org/ubl/os-UBL-2.0-update-delta.zip van mei 2008. Belastingdienst, Wettelijke eisen aan elektronische facturen. http://www.belastingdienst.nl/zakelijk/elektronisch_factureren/ elektronisch_factureren-06.html#P50_4962 Wet op de omzetbelasting 1968. http://wetten.overheid.nl/BWBR0002629

Datum 15 november 2011 Blad 9/9