Notulen Aan Werkgroep Semantic Model efactuur Van M.H.M. Stornebrink Onderwerp Notulen werkgroepbijeenkomst 03 december 2015 Locatie TNO New Babylon, Anna van Buerenplein 1, Den Haag Aanwezig/afwezig Patrick Frijns (PF) (Belastingdienst) Hans Hodes (HH) (KPN) Harry van der Sanden (HS) (I-bridge/Randstad) Fred van Blommestein (FB) Sjaak Groeneveld (SG) (Min. IenM) Jaap Jan Nienhuis (JJN) (SIDN/Simpler Invoicing) Bas van Schaik (BS) (Min. VenJ) Patrick Stokkers (PS) (Min. IenM) Jos van der Heiden (JH) (Logius) Peter Potgieser (PP) Hendricus Wind (HW) (ZET Solutions) Beheerder (TNO): Michiel Stornebrink (MS) Wouter van den Berg (WB) Actiepunten nieuw # Omschrijving Actiehouder Status 2015-4 Onderscheid cbc:paymentmeanscode en WB In behandeling cbc:paymentchannelcode nader uitzoeken 2015-5 Controleer regel 4 van de tabel over SMeF 1.3.1 in het WB Gedaan input-document, en wijzig zo nodig de betreffende regel. 2015-6 Controleer of Doel en Definitie van het element 3.9 WB Gedaan moeten worden aangepast om consistent te zijn met de wijziging in cardinaliteiten 2015-7 Agenderen voor WG in januari: MS In behandeling Negatieve/positieve bedragen op factuur Verplichte elementen voor partijen op factuur Standpunt innemen over afleveradres op line niveau 2015-8 Controleren of BTW bedrag wettelijk verplicht in EUR moet PF Nieuw 2015-9 Richtlijn over technische elementen aan SMeF toevoegen WB Nieuw 2015-10 JH maakt zijn evaluatie van het inputdocument af en zoekt JH Nieuw contact met TNO op. 2015-11 Fouten (2) in input document corrigeren WB Nieuw
Notulen Eerdere notulen vaststellen JH noemt drie wijzigingen in de notulen van de bijeenkomst op 05-11-2015: Onder 2. SI-SMeF vergelijking : o Punt 14, TaxExchangeRate. De aanvulling: op headerniveau nodig op regelniveau parkeren tot bespreking EU model. o Punt 31 36, diverse item velden. Cell waarin besluit hoort te staan is leeg. Moet zijn: parkeren tot bespreking EU model / detaillering Onder 3. Bespreking (openstaande) punten uit 2014 : o Eerste alinea laatste zin: JH zou nog kijken of er aanvullende punten zijn. Opening en vaststellen agenda MS heet iedereen welkom en opent de SMeF werkgroep-bijeenkomst. Het bestand 20151127 - Verschilanalyse EN en SMeF.xlsx vormt de input van deze bijeenkomst. Op de agenda staat het vergelijken van SMeF en de Europese Norm (EN), ook wel het EU model. Alvast vooruitkijkend: op donderdag 14 januari 2016 bespreken we de verdere detaillering en structurering van SMeF. Bespreking verschillen tussen EU model en SMeF Uitgangspunten/overview MS toont het bovenstaande Venn diagram waarin de soorten verschillen tussen het EU model en SMeF staan uitgebeeld. Naar de elementen in het oranje deel van de afbeelding is nog niet gekeken. Dit is een stuurgroep vraagstuk; moet een factuur die aan het EU model voldoet, ook aan SMeF voldoen? (Indien ja, wat is dan de toegevoegde waarde van SMeF?) JH merkt op dat we met dit soort vragen worden gedwongen om na te denken over het toepassingsgebied van SMeF. Is het alleen voor facturen tussen NLse leveranciers, of ook voor facturen naar het buitenland?
MS licht toe dat de focus vandaag ligt op de vraag: voldoet een SMeF-factuur aan het EU model? We zoomen in op de elementen in SMeF die dit belemmeren (rood en grijs). Een uitzondering zijn de elementen in het blauw; die worden geparkeerd voor de volgende werkgroep bijeenkomst, waarin SMeF verder wordt gedetailleerd. Na deze toelichting opent MS het input-document om de rode elementen één voor één te bespreken. Stapsgewijze bespreking van elementen Regel 4 Invoice type code FB meldt dat met dit element kan worden aangeduid dat het een credit nota betreft, en dan moet je kijken hoe je met negatieve bedragen om gaat. Besluit: meegaan met EU model, maar omgang met negatieve bedragen blijft een belangrijk onderwerp. Regels 6/7 Invoice currency code & VAT accounting currency Gesignaleerd is dat VAT accounting currency voor EU model optioneel is, terwijl in SMeF dit vermeld staat als verplicht. Discussie ontstaat of dit inderdaad verplicht is volgens NL wetgeving én of BTW bedragen van Nederlandse facturen in EUR moeten worden vermeld. Actie: Patrick Frijns controleert of het in EUR noemen van BTW bedragen inderdaad verplicht is in NL [2015-8, PF]. Terugkoppeling Patrick Frijns, 8-dec-2015 Ten aanzien van mijn actiepunt inzake valuta eis bedrag BTW op de factuur het volgende: In artikel 35a, lid 1, van de Wet op de omzetbelasting 1968 is onder andere vastgelegd dat op de factuur de volgende vermeldingen verplicht zijn: - letter h: de vergoeding voor elk tarief of elke vrijstelling, de eenheidsprijs, belasting niet inbegrepen, evenals de eventuele vooruitbetalingskortingen, prijskortingen en -rabatten indien die niet in de eenheidsprijs zijn begrepen; - letter j: het te betalen bedrag van de belasting, tenzij er een bijzondere regeling van toepassing is waarvoor deze wet die vermelding uitsluit. Tot zover géén nadere eis. Maar dan: artikel 35, lid 4, Wet op de omzetbelasting 1968 vermeld: " Op een factuur kunnen bedragen in willekeurig welke munteenheid voorkomen, mits het te betalen of te herziene bedrag van de belasting is uitgedrukt in euro's en daarbij gebruik wordt gemaakt van het in artikel 91 van de BTW- Richtlijn 2006 bedoelde wisselkoersmechanisme*. " * = dagkoers Hiermee is dus bepaald dat de factuur in alle valuta mag mits het btw-bedrag maar in euro's wordt weergegeven. Regel 10 Buyer reference FB meldt dat dit element maximaal één keer op EU factuur kan. HS deelt mee dat diens klanten meerdere referenties vereisen, zoals purchase nummer, project code en afdelingscode. Als er ruimte is om deze drie uit te drukken, dan is er wat HS betreft geen probleem. Bij elke code wordt overigens het type vermeldt. HH voegt toe dat het wat hem betreft pas problematisch wordt als het per factuurregel-niveau kan afwijken; op factuur-niveau is er geen bezwaar als het er meerdere zijn, maar als er op factuurregelniveau afwijkingen zijn dan gaat de controle door Accounts Payable goed mis. FB wijst erop dat afdelingscode in het contact-element van het EU model past. Project code is er echter niet (specifiek), maar wel purchase order code en receiving en dispatching code.
Besluit: verzoek naar EU draft review tot de mogelijkheid om meerdere toe te staan én aan te kunnen geven wat voor code. Regel 16 Invoice note Besluit: inbrengen bij EU-draft review dat de multipliciteit van dit element wordt gewijzigd van 0..1 naar 0..N Regel 19 Payment terms Besluit: inbrengen bij EU-draft review dat de multipliciteit van dit element wordt gewijzigd van 0..1 naar 0..N Regels 20 en 22 PROCESS CONTROL & Business process type identifier Besluit: Dit is een technisch element, dus niet als element opnemen in SMeF maar wel als richtlijn. Actie: richtlijn aan SMeF toevoegen (als die er nog niet is) dat een syntax dit soort informatie wel moet opnemen [2015-9, TNO]. Regel 32 Seller identifier HH wijst erop dat men in de praktijk ook van dit element meerdere wil kunnen meegeven, bijvoorbeeld debiteurennummer en klantnummer. Besluit: EU model volgen; van 0..1 in SMeF naar 0..n Regel 45 SELLER CONTACTING DETAILS MS vat de vraag samen: wil je meerdere contactpersonen-toestaan? FB stelt dat we over de kernfactuur praten, dus gewoon 1 contact. Niet andere contactpersonen voor andere zaken. Besluit: EU model volgen; van 0..n in SMef naar 0..1 Regel 62 BUYER CONTACTING DETAILS Zie hierboven. Besluit: EU model volgen; van 0..n in SMef naar 0..1 Regel 97 ACCOUNT IDENTIFICATION HH meldt dat dit eigenlijk gebaseerd is op oude SEPA logica. De trend is voor organisaties nu juist om zo min mogelijk rekeningen te houden. Maximum moet naar één. FB merkt daarnaast op dat het element in SMeF verplicht is en in het EU model niet, omdat in het laatstgenoemde ook creditcard betaling kan worden opgeven. Dit is iets dat in SMeF ook moet komen. Minimum dus naar 0. Besluit: EU model volgen; van 1..n in SMeF naar 0..1. Regel 108 Document level allowance VAT category code Er ontstaat discussie over specificeren van toeslagen en kortingen op SMeF factuur. FB noemt drie manieren voor het specificeren van kortingen of toeslagen zoals ondersteund door EU model. 1) Op hoofdniveau (middels element Allowances en Charges) 2) Op regelniveau (middels element Allowances en Charges in Line). Op line niveau geldt het btw tarief dat van toepassing is op de line ook voor betreffende toeslagen of kortingen. 3) De korting of toeslag als aparte regel opnemen MS stelt dat we vanuit SMeF niet beperkend willen zijn in het kiezen van deze drie opties. Dat betekent dat we elk van de mogelijkheden toestaan in SMeF. In SMeF is er op dit moment geen ruimte om voor een toeslag of korting een belastingcategorie te specificeren. Op hoofdniveau is dit echter wel nodig. Besluit: Element Document level allowance VAT category code overnemen uit EU model.
Regel 110 Document level allowance reason FB wijst erop dat de verplichting van dit element door het EU model niet logisch, want als er een code wordt gegeven (regel 111) dan hoeft de tekst natuurlijk niet meer. MB stelt voor om het als gevonden fout terug te communiceren naar de EU draft review. Besluit: terugkoppeling naar EU draft review dat de verplichting van dit element een fout lijkt te zijn. Niet verplicht maken in SMeF. Regel 112 DOCUMENT LEVEL CHARGES MS licht toe: SMeF heeft niet-btw belastingen als aparte elementen, terwijl het EU model toeslagen en niet-btw belastingen samenvoegt onder charges. In energiesector hebben we ook gezegd, andere belastingen zijn gewoon invoice-lines want daar gaat ook BTW over betaald worden. Voorstel is om het EU model hierin te volgen. FB vult aan dat er gevallen zijn waarbij het lastig te bepalen is of iets nou een belasting of een toeslag is. JH stelt voor om het in SMeF dan tenminste wel expliciet in de omschrijving van toeslagen te noemen dat er ook niet-btw belastingen in kunnen. Besluit: EU model volgen en niet-btw belastingen als toeslagen behandelen. Maar wel deze samenvoeging in de definitie en beschrijving van het toeslag-element noemen. Regel 116 Document level charge VAT category code Zie discussie en besluit omtrent regel 108. Regel 118 Document level charge reason Zie discussie en besluit omtrent 110. Regel 121 Sum of Invoice line net amount Besluit: aangeven naar EU dat we dit niet verplicht vinden vanuit NL. Reactie afwachten. Regel 124 Invoice total amount without VAT Besluit: EU model volgen en betekenis van SMeF element beperken tot BTW (zie redenering achter besluit regel 112). Regel 132 VAT category tax amount JH wijst erop dat de opmerking in het input document bij dit element niet klopt; SMeF specificeert wel BTW totalen per tax category, zoals in de business rules te lezen is. Dit is aangepast in het exceloverzicht. Besluit: fout in de analyse, SMeF kent wel degelijk subtotalen per categorie. Toevoegen subtotaal BTW categorie als apart element. Actie: correctie doorvoeren in input document [2015-11, TNO]. Regel 133 VAT category code MS wijst erop dat in het EU model de VAT category code verplicht is en het percentage optioneel, terwijl dit in NL nu precies andersom is. FB wijst erop dat VAT percentage in SMeF niet verplicht is wanneer er vrijstelling van BTW is. Iemand in de groep herinnert de rest eraan dat één categorie soms meerdere percentages kan hebben vanwege een overgangsperiode na een verandering in regelgeving. Besluit: feedback naar EU dat de maximale aantal VAT percentages soms hoger moet kunnen zijn dan 1. Regel 143 Invoice line note Zie discussie en besluit omtrent regel 16. Regel 144 Invoiced quantity JH: kern van het verhaal: in feite is het niet 0..1 maar op het laagste niveau is ie verplicht. Besluit hangt af van subline besluit.
Regel 148 Buyer accounting reference Verwezen wordt naar discussie en besluit op regel 10. Besluit: verzoek naar EU draft review tot de mogelijkheid om meerdere toe te staan én aan te kunnen geven wat voor code. Regel 157 Invoice line allowance reason Zie discussie en besluit omtrent regel 110. Regel 163 Invoice line charge reason Zie discussie en besluit omtrent regel 110. Regels 172 en 173 Invoiced item VAT category code & Invoiced item VAT rate Zie discussie en besluit omtrent regel 133. JH meldt een fout in het inputdocument. De tarieven zijn weldegelijk vastgelegd. Het SMeF gaat juist uit van percentages. Actie: cell M173 in het input document bevat een fout en moet worden gecorrigeerd [2015-11, TNO]. Wel in SMeF, niet in EU model Indicatie laatste factuur Besluit: dit element niet wijzigen in SMeF maar ook niet inbrengen in EU draft review. Leveringsconditie FB meldt dat in SI deze zelfs gestructureerd is. In de EU gaat dit het niet halen. Deze informatie staat overigens in het contract, en niet in de factuur. Besluit: laten staan als aparte NLse extensie, niet inbrengen in EU draft review. Subline MS meldt dat de oorsprong van deze structuur te vinden in in de OAGIS structuur en HR-XML, niet in UBL. HS voegt toe dat hij dit element massaal gebruikt en ondersteund ziet worden. FB stelt vast dat het element dan in een sector specificatie/extensie thuishoort. JH benoemt daarnaast dat deze subline dus niet gebruikt kan worden bij internationale facturatie, en dat dit als regel aan SMeF toegevoegd dient te worden. Besluit: Subline behouden en isoleren, bijvoorbeeld als NLse extensie. Als regel opnemen in SMeF dat dit element niet gebruikt mag worden in het geval van een internationale factuur. Actie: Hoe we dit besluit gaat vormgeven parkeren we voor de volgende WG bijeenkomst [2015-7, TNO]. Afleveradres Besluit: er moet een standpunt komen vanuit SMeF hierover, maar er was geen tijd meer. Actie: agenderen voor volgende keer [2015-7, TNO]. BTW Grondslag Besluit: fout in de analyse. Staat wel in het EU model. 8.6 Bestellingnummer Besluit: hier was geen tijd meer voor, parkeren voor de volgende keer.
Rondvraag en sluiting JH zegt dat hij vermoedt dat er misschien wat regels in de input Excelsheet zijn die een andere kleur zouden moeten hebben. Actie: JH maakt zijn evaluatie van het inputdocument af en zoekt contact met ons op [2015-10, JH]. Daarnaast vraagt JH zich af wat het standpunt van SMeF zou moeten zijn over het feit dat er 3 syntaxen zijn die je moet ondersteunen in NL (UN/CEFACT, EDIFACT en UBL). FB herinnert de groep aan politieke dimensie van dit onderwerp. Vooral de verplichting van EDIFACT staat ter discussie. Veel gehoord argument (vanuit GS1 gemeenschap) is dat EDIFACT verreweg de grootste dekking heeft in het bedrijfsleven, en dat verdere implementatiekosten van deze standaard dus relatief laag zullen zijn. JH wijst erop dat het doel is om efactureren te bevorderen, en meerdere syntaxen verplichten doet dat niet. FB voegt toe dat vanuit EZ Rogier de Boer het standpunt uit: zo min mogelijk syntaxen ondersteunen, en in ieder geval niet EDIFACT. Michiel geeft aan dat dit een stuurgroep aangelegenheid is, en vraagt JH om zijn standpunt op papier te zetten zodat dit naar de stuurgroep kan. Er zijn verder geen punten voor de rondvraag. MS sluit de vergadering en bedankt iedereen voor zijn bijdrage.