Sjaak Groeneveld (SG) (Min. IenM) Jaap Jan Nienhuis (JJN) Wouter van Schaik (WS) (Simplerinvoicing/SIDN) Bas van Schaik (BS) (Min.

Transcriptie

1 Notulen Aan Werkgroep Semantic Model efactuur Van M.H.M. Stornebrink Onderwerp Notulen werkgroepbijeenkomst 05 november 2015 Locatie Skype-call 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) Wouter van Schaik (WS) (Simplerinvoicing/SIDN) Bas van Schaik (BS) (Min. VenJ) Jos van der Heiden (JH) (Logius) Peter Potgieser (PP) (RBS) Hendricus Wind (HW) (ZET Solutions) Beheerder (TNO): Michiel Stornebrink (MS) Wouter van den Berg (WB) Actiepunten # Omschrijving Actiehouder Status Adresseren interoperabiliteitsdoelstelling in Stuurgroep. HH Gedaan Volgende bijeenkomsten plannen en uitnodigingen WB Gedaan versturen Release policy agenderen voor stuurgroep SMeF MS Afgevoerd Reeds geadresseerd in SMeF beheermodel Onderscheid cbc:paymentmeanscode en WB Nieuw bc:paymentchannelcode nader uitzoeken Controleer regel 4 van de tabel over SMeF in het WB Nieuw input-document, en wijzig zo nodig de betreffende regel Controleer of Doel en Definitie van het element 3.9 WB Nieuw moeten worden aangepast om consistent te zijn met de wijziging in cardinaliteiten Agenderen voor WG in januari: MS Nieuw Negatieve/positieve bedragen op factuur Verplichte elementen voor partijen op factuur

2 Notulen 1. Opening en vaststellen agenda MS heet iedereen welkom en opent de SMeF werkgroep vergadering. Op de agenda staat het inhoudelijk bespreken van de openstaande punten ten aanzien van SMeF 1.4 en de SMeF SI vergelijking. Alvast vooruitkijkend: op donderdag 3 dec bespreken we het EU model in relatie tot SMeF en voor 14 januari staat de detaillering van alle elementen op het programma. Het bestand _SMeF_WG_Analyse openstaande punten SMeF en 1.4 en SI.docx was de input van deze bijeenkomst. 2. SI-SMeF vergelijking Onderstaande tabel geeft de besluiten weer omtrent de SMeF vs SimplerInvoicing vergelijking die is uitgevoerd in voorbereiding op deze werkgroepbijeenkomst. Voor toelicht

3 Overzicht van besluiten omtrent elementen die in SI terugkomen maar niet in SMeF Elementen uit vergelijking (wel SI, niet SMef) Vraag/voorstel/opmerking Besluit 2. doc:invoice/cac:billingreference 3. doc:invoice/cac:billingreference/cac:invoicedocumentreference 4. doc:invoice/cac:contractdocumentreference 5. doc:invoice/cac:additionaldocumentreference 6. doc:invoice/cac:additionaldocumentreference/cac:attachment In SMeF is nog niet ruimte voor dergelijke referenties. Welke dienen te worden toegevoegd? (N.B.: #2 en #5 zijn in SMeF 1.4 reeds toegevoegd. 7. doc:invoice/cac: Party/cac:Party/cbc:EndpointID Informatie over een logistieke rol van een partij lijkt niet in een SMeF factuur thuis te horen. 8. doc:invoice/cac: Party/cac:Party/cac:PartyTaxScheme SMeF veronderstelt het NLse belastingstelsel. Deze punten parkeren voor bespreking EU 9. doc:invoice/cac:paymentmeans/cbc:paymentchannelcode 10. doc:invoice/cac:paymentmeans/cbc:paymentid 11. doc:invoice/cac:paymentmeans/cac:cardaccount 12. doc:invoice/cac:paymentmeans/cac:payeefinancialaccount/cac:f inancialinstitutionbranch/cac:financialinstitution/cac:addres s model. Wat betekenen deze elementen in SI? Is #10 een betalingskenmerk? Factuurnummer als betalingskenmerk voldoende? In hoeverre dient het adres van de bank opgenomen te worden in de factuur? Voorstel: geen onderdeel van de SMeF factuur. Deze referenties opnemen in SMeF, en relatie tussen Contract en Purchase Order toelichten. Daarnaast doel van Bijlage element in SMeF aanscherpen. Niet meenemen in SMeF Parkeren voor bespreking EU model (volgende WG bijeenkomst). #9: verplichting weg en verder parkeren voor bespreking EU model. #10: i.e. betalingskenmerk, opnemen in SMeF. #11: Parkeren voor WG bijeenkomst over verdere detaillering van SMeF (jan. 16) maar belangrijk voor ondersteuning van meerdere betalingsmethoden Achterhaald. Is mogelijk nodig voor non-sepa betalingsverkeer. Niet opnemen in SMeF. 13. doc:invoice/cac:allowancecharge/cac:taxcategory Interessant voor WG3 (detaillering van SMeF) goed naar kijken en niet zomaar overnemen; parkeren voor bespreking EU model. 14. doc:invoice/cac:taxexchangerate SMeF vereist belastingbedragen Discussie loopt op EU niveau. Op

4 15. doc:invoice/cac:taxtotal/cac:taxsubtotal/cbc:transactioncurr encytaxamount 16. doc:invoice/cac:taxtotal/cac:taxsubtotal/cac:taxcategory/cbc :TaxExemptionReasonCode 17. doc:invoice/cac:taxtotal/cac:taxsubtotal/cac:taxcategory/cbc :TaxExemptionReason 18. doc:invoice/cac:legalmonetarytotal/cbc:lineextensionamount 19. doc:invoice/cac:legalmonetarytotal/cbc:taxinclusiveamount 20. doc:invoice/cac:legalmonetarytotal/cbc:allowancetotalamount 21. doc:invoice/cac:legalmonetarytotal/cbc:chargetotalamount 22. doc:invoice/cac:legalmonetarytotal/cbc:prepaidamount 23. doc:invoice/cac:legalmonetarytotal/cbc:payableroundingamount 24. doc:invoice/cac:invoiceline/cac:delivery 25. doc:invoice/cac:invoiceline/cac:delivery/cbc:quantity 26. doc:invoice/cac:invoiceline/cac:delivery/cbc:actualdeliveryd ate 27. doc:invoice/cac:invoiceline/cac:allowancecharge/cbc:amount 28. doc:invoice/cac:invoiceline/cac:allowancecharge/cac:taxcateg ory 29. doc:invoice/cac:invoiceline/cac:allowancecharge/cac:taxtotal 30. doc:invoice/cac:invoiceline/cac:taxtotal/cac:taxsubtotal/cbc :TransactionCurrencyTaxAmount 31. doc:invoice/cac:invoiceline/cac:item/cbc:name 32. doc:invoice/cac:invoiceline/cac:item/cac:buyersitemidentific ation 33. doc:invoice/cac:invoiceline/cac:item/cac:origincountry 34. doc:invoice/cac:invoiceline/cac:item/cac:commodityclassifica tion 35. doc:invoice/cac:invoiceline/cac:item/cac:classifiedtaxcatego ry 36. doc:invoice/cac:invoiceline/cac:item/cac:additionalitemprope rty in EUR dus voor internationale handel zijn deze element wellicht wenselijk. Voorstel: parkeren voor bespreking EU model. Deze elementen liggen semantisch dicht tegen 5.2 Indicatie BTW vrij. Mee nemen naar detaillering SMeF. Worden deze subtotalen binnen SI in de praktijk gebruikt? Deze waarden zijn verschillende berekeningen van dezelfde bedragen op de factuur. WG moet bepalen welke hiervan in SMeF terug moeten komen. Hoe gebruikt SI deze elementen? Wat is dit anders dan bijv. quantity op regel niveau? #27 valt in SMeF onder 4.1 Toeslagen/ 4.3 Kortingen maar tot nu toe is daar geen ruimte voor belastinginformatie. Voorstel is om dit te parkeren voor EU model (zie #15) Deze informatie zou in een verdere detaillering van 8.2 Artikelomschrijving kunnen. (N.B.: #34 komt overeen met 8.9 Classificatie in SMeF 1.4) header-niveau dit element overnemen in SMeF, maar besluit over dit element op regelniveau parkeren voor bespreking EU model. Huidige element volstaat voor NL maar niet voor buitenland. Parkeren voor bespreking EU cbc:payableroundingamount negeren. De rest parkeren voor bespreking EU model. Parkeren voor bespreking van het EU model. Ook parkeren voor de bespreking van het EU model. Parkeren voor bespreking EU model. parkeren tot bespreking EU model / detaillering

5 37. doc:invoice/cac:invoiceline/cac:price/cac:allowancecharge 38. doc:invoice/cac:invoiceline/cac:price/cac:allowancecharge/cb c:multiplierfactornumeric 39. doc:invoice/cac:invoiceline/cac:price/cac:allowancecharge/cb c:amount 40. doc:invoice/cac:invoiceline/cac:price/cac:allowancecharge/cb c:baseamount 41. doc:invoice/cac:invoiceline/cac:price/cac:allowancecharge/ca c:taxcategory 42. doc:invoice/cac:invoiceline/cac:price/cac:allowancecharge/ca c:taxtotal Informatie over kortingen en toeslagen kan men in SI kwijt op invoiceline-niveau maar ook op price-niveau, zoals hiernaast. Hoe worden deze elementen in SI in de praktijk gebruikt t.o.v. hun varianten op line niveau? Gaan we niet overnemen in SMeF omdat men dezelfde informatie kwijt kan op invoiceline-niveau.

6 3. Bespreking (openstaande) punten uit 2014 JH merkt op dat er vanuit de laatste werkgroep SMeF nog een ander punt was: mappings. Zijn vraag is of die er nu bewust niet bij zitten (omdat mappings buiten scoop is gesteld). MS antwoordt dat het inderdaad een bewuste keuze was, maar niet om die reden. De eigenaars van de mappings zijn de sectoren, maar SMeF wil weldegelijk de totstandkoming en publicatie faciliteren. JH stelt dat de OHNLmapping samen met SMeF uitgebracht werd, en de laatst gepubliceerde versie niet actueel is. Hij zal gaan kijken of er nog aanvullende aandachtspunten zijn voor SMeF. 1) SMeF v1.3.1 Bij de bespreking van de analyse van de openstaande punten in SMeF v1.3.1 werd het volgende opgemerkt: - Land van herkomst is in principe geen kernonderdeel van de factuur, maar op de volgende bijeenkomst wordt gekeken of we met dit besluit de aansluiting met het EU model niet verliezen. - JH wijst erop dat in he input-bestand een fout staat in regel 4 van de kolom over SMeF v Daar wordt namelijk in gezegd dat er een aantal dingen in de release notes van SMeF v1.3.1 missen maar dit is niet het geval. WB wijzigt betreffende regel [AP , WB]. 2) SMeF v1.4 Bij de bespreking van de analyse van de openstaande punten in SMeF v1.4 werd het volgende opgemerkt: - Het toevoegen van elementen 2.14 Factuurverwijzing en 2.15 Bijlage is al eerder tijdens deze bijeenkomst besproken - Zoals in de analyse van het input document staat was de aanleiding voor het wijzigen van element 3.6 Bankgegevens niet duidelijk uit de notulen op te maken. MS geeft aan dat deze wijziging voortkwam uit de bespreking van SEeF (toen SIUS). Voor specificeren van automatische incasso s moeten rekeninggegevens van klant opgenomen kunnen worden in de factuur. - De suggestie om het element 3.9 Bedrijfsidentificatie te controleren op consistentie tussen Doel, Definitie en cardinaliteit wordt door de WG geaccepteerd. WB controleert of Doel en Definitie van het element moeten worden aangepast om consistent te zijn met de wijziging in cardinaliteiten [AP , WB]. 4. Rondvraag en sluiting JH wijst op een struikelpunt uit de SI analyse: positieve en negatieve bedragen. SMeF stelt voor om alles positief te presenteren. Dat knelt met anderen zoals SI. Blijkbaar was dit een vrij lastig onderwerp want in diverse WG vergaderingen en andere gremia is dit punt meermalen besproken. FB onderstreept dat het ook een discussie is in EU context. Het gaat om aantal situaties die je wil ondersteunen waaronder crediteren en correcties. Die discussie gaat nog gevoerd worden in EU. MS meldt dat de laatste UBL ketentest update ook hierover ging. FB voegt toe dat SI dichter bij dagelijkse praktijk staat en met dit issue anders omgaat dan OHNL. Eventuele conversies omtrent positieve en negatieve bedragen kunnen vrij complex worden dus dat moet zeker getest worden. MS stelt voor, ook gezien de tijd, om dit punt te agenderen voor de WG vergadering in januari [AP , MS]. JH brengt naar voren dat er in SMeF gegevens omtrent een partij (BTW nummering, adres, e.a.) verplicht zijn gesteld voor álle partijen op de factuur. Dit is echter niet altijd voor alle partijen verplicht. Ook dit punt wordt geagendeerd voor de vergadering in januari [AP , MS]. Er zijn verder geen punten voor de rondvraag. MS sluit de vergadering en bedankt iedereen voor zijn bijdrage.

7 Bijlage: Discussie bij bespreking agenda punt 2: elementen vergelijking SMeF SimplerInvoicing #1 - #6 FB vertelt dat de EU norm slechts enkele document referenties bevat, en Invoice Document Reference wordt alleen als correctie gebruikt. HS vraagt zich over Contract Reference af hoe de relatie daarvan is met het budget order nummer? Volgens FB valt Purchase Order onder Contract en zijn er transacties zonder order en dan is een contract wel handig. Besluit: Deze referenties opnemen in SMeF, waarbij relatie tussen Contract en Purchase Order expliciet wordt beschreven. HH (via eerder bericht aan MS) uit de zorg dat er allemaal extra informatie aan de factuur gehangen wordt: JH suggereert aanscherpen van beschrijving van hoe bijlage-element gebruikt dient te worden. JN snapt het punt van HH maar wijst erop dat een bijlage geen onderdeel van de factuur is. FB meldt dat bijlagen door EU norm ook wordt ondersteund, met een specificatie van toegestane bestandtypen. Besluit: doel aanscherpen zodat duidelijk wordt dat de inhoud van de bijlage ter ondersteuning factuur dient. #7 JN geeft aan dat SI dit overgenomen heeft van EU (PEPPOL) maar wordt nooit gebruikt. Besluit: niet meenemen SMeF. #8 Volgens WB veronderstelt SMeF nu nog het NLse belastingstelsel. Er moet ruimte komen voor andere belastingstelsels maar de manier waarop dat in SMeF komt moet aansluiten met EU norm. WG is akkoord. Besluit: parkeren voor volgende werkgroepbijeenkomst (bespreking EU model) #9 #11 JN stelt dat cbc:paymentchannelcode in SI niet ongebruikelijk is om te vullen, en wel belangrijk. MS vraagt wat het verschil is tussen cbc:paymentmeanscode en cbc:paymentchannelcode, waarop FB uitlegt dat het met SEPA regels te maken heeft en gaat over welk betaalnetwerk je de betaling wil sturen. In NL heb je er echter maar één. In PEPPOL worden deze zaken vooral gebruikt als je naast overschrijvingen ook incasso en creditcard wil ondersteunen. FB voegt daaraan toe dat het best practice is om rekeningnummers van partijen in stamtabellen bij te houden om betaling van spookfacturen te voorkomen. Betalingsgegevens zouden dan ook niet verplicht moeten zijn op de factuur. Besluit: verplichting weg, parkeren EU model. Actie: Onderscheid cbc:paymentmeanscode en cbc:paymentchannelcode nader uitzoeken [AP , WB]. WB vraagt of PaymentID als betalingskenmerk wordt gebruikt. Antwoord is positief. Besluit: #10 opnemen in SMeF want betekent inderdaad betalingskenmerk. JN zegt dat cbc:cardaccount over de ondersteuning van creditcardbetalingen B2B gaat. Deze informatie laat dus zien met welke cc account het bedrag al is betaald. Besluit: Parkeren detaillering maar belangrijk voor ondersteuning meerdere betalingsmethoden. #12 FB vindt #12 achterhaald. Volgens JN is het mogelijk nodig voor internationale betalingen, zoals een wire naar VS. MS vraagt of je dan echt het adres hebben moet, of dat het dan om BIC codes en dat soort zaken gaat? JN geeft aan dat ook dit element is overgenomen vanuit PEPPOL en heeft het nog nooit gebruikt zien worden. FB maakt twee punten: 1) dit gaat inderdaad over betalingen buiten SEPA, 2) In SI blijkt hetzelfde element te bestaan maar op Institution niveua, hier is het op Branche. De vraag is of het model ook non-sepa betalingen wil ondersteunen. Besluit: niet opnemen in SMeF. #13 MS licht doe dat op dit moment zowel kortingen als toeslagen herkend worden, maar belastingen worden op header-line of invoice-line gedefinieerd en niet specifiek op allowance of charge. FB meldt dat

8 toeslagen of kortingen op regelniveau in EU norm per definitie dezelfde tax-category als de betreffende regel hebben. Hij wijst erop dat dit element echter het hoofdnivea (header) betreft. MS vat samen: dit element is op header niveau gewoon nodig, op regelniveau dus bij EU model kijken. JH voegt toe dat het EU model relevant is voor alle belastingelementen in de lijst. FB zegt dat het soms voldoende is om die andere bedragen alleen in sub-totalen van belastingcategorie op te nemen. Het advies is om even goed te kijken naar welke elementen je nodig hebt. JH wijst erop dat je op de regels kan aangeven wat bijvoorbeeld het totaal aan BTW is, en dan moet je zelf narekenen waarom de som niet klopt door middel van toeslagen en kortingen.. Besluit: goed naar kijken en niet zomaar overnemen; parkeren voor bespreking EU model. #14 #15 WB stelt dat het wederom belastingelementen betreft, dus stelt voor om ook deze te parkeren voor bespreking EU model. FB stemt in; dit gaat over transacties met belasting in andere currencies dan de rest van de bedragen. Daar is in EU team overlegd over de toevoeging van exchange rate maar die vonden ze redundant omdat je hem kan uitrekenen. Echter in sommige wetgevingen is het noemen van de rate wel verplicht gesteld maar daar wordt nog over gediscussieerd. Besluit: op header niveau overnemen in SMeF, maar besluit over dit element op regelniveau parkeren voor bespreking EU model. #16 #17 WB merkt op dat de huidige indicatie BTW vrij in SMeF ( 5.2) een zeer specifiek element is t.o.v. de andere, abstractere elementen. JH herinnert zich dat PF eerder aangaf dat de flag voldoende is voor regelgeving NL. HS beaamt dat. FB meldt dat de reden voor exemptie in het algemeen nodig is vanwege controle door belastingdienst. De vraag is of het gecodeerd kan worden. Dat loopt nu in de EU. Die reden komt sowieso in het model terug. Mogelijk zijn het er echter zoveel dat het coderen te lastig is. Voorbeeld van sectoren waar redenen zijn voor exemption: gezondheidszorg, onderwijsdiensten. Dus in buitenland is vaak wel een uitleg nodig. Besluit: Parkeren voor bespreking EU model. #18 #23 JN stelt vast dat TaxInclusiveAmount en LineExtensionAmount verplicht zijn in SI en dus veel gebruikt worden. Anderen worden zelden gebruikt, maar zijn wel belangrijk. FB wijst erop dat in EU norm een heel rekenmodel zit, en stelt voor hetzelfde te doen voor SMeF indien dergelijke subtotalen worden opgenomen. JH wijst erop dat de NLse overheid alleen de dingen verplicht stelt die in SMeF staan. PrepaidAmount is niet nodig, en PayableRoundingAmount is erg technisch. FB beaamt dat allowance, charge en prepaid inderdaad niet voorgeschreven worden door NLse Belastingdienst maar wel in EU. MS vat samen: er moeten dus in SMeF wellicht (sub)totalen komen die niet verplicht worden gesteld door de NLse Belastingdienst, maar de vraag is welke dat dan zijn. Dat lijkt een aantal van deze te zijn maar in elk geval niet PayableRoundingAmount. Besluit: PayableROundingAmount niet opnemen in SMeF. Rest parkeren naar EU model want hun verplichtingen bepalen welke totalen er bij moeten. #24 #26 JN legt uit dat het hier gaat het om een delivery en wat daadwerkelijk geleverd is. Er kan onderscheid zijn daartussen. Ook voor deze geldt dat SI de keuzes van PEPPOL overgenomen hebben. FB licht toe dat er branches zijn waarbij dit gebruikelijk is. Bijv. boekenbranche die dan dozen levert zonder precies te weten hoeveel erin zitten. Vers-branch is ook een voorbeeld. Heeft dus niets te maken met nalevering. Dit komt waarschijnlijk ook in EU model voor. Besluit: nu niet opnemen en verder Parkeren voor EU model. #27 #29 FB herhaalt dat het EU model het standpunt inneemt dat de tax-category van de invoiceline dezelfde moet zijn als die van eventuele allowances en/of charges op die line. Op header niveau is belastinginformatie over allowances en toeslagen sowieso nodig. Besluit: parkeren voor bespreking EU model. #30

9 Besproken, zie #15. #31 #36 Volgens JH zijn dit geen onderdeel van de kern van een factuur. FB meldt dat het wel voor komt in het EU model; het schijnt in sommige landen verplicht te zijn om aan te geven. MS: besluit: parkeren tot EU en/of detaillering. #37 #42 JN geeft aan niet uit het hoofd te weten hoe deze elementen in SI gebruikt worden t.o.v. hun equivalenten op invoiceline-niveau. MS en FB stellen dat deze AllowanceCharge op line niveau mogelijk is en op prijsniveau onnodig complex is. Besluit: niet opnemen.