Informatiegids voor het deponeren van een jaarrekening met SBR … · 2018-03-09 · 3 Voorwoord...

1

Informatiegids voor het deponeren van een jaarrekening met SBR

Datum: 9 maart 2018 Versie: 1.0 Status: Definitief

2

Versiebeheer

De inhoudelijke wijzigingen in de informatiegids voor het deponeren van een jaarrekening met SBR ten opzichte van voorgaande versies worden hieronder uiteengezet:

Versie Datum Beschrijving van wijzigingen Auteur

1.0 9 maart 2018 Initiële versie

Om de volledigheid en juistheid van deze informatiegids te borgen houdt de Kamer van Koophandel zich voortdurend aanbevolen voor reacties en commentaren. Deze reacties en commentaren kunnen gestuurd worden naar het service center van de KvK (zie hoofdstuk 2.2). De ontvangen commentaren en ontwikkelingen in de praktijk kunnen aanleiding geven voor aanpassing van deze informatiegids.

3

Voorwoord

Welkom bij de informatiegids voor het deponeren van een jaarrekening met Standard Business Reporting (SBR) bij het handelsregister van de Kamer van Koophandel (KvK). Op basis van het Besluit elektronische deponering handelsregister van 16 juni 2016 zijn micro-, kleine en middelgrote rechtspersonen verplicht om hun jaarverantwoording met SBR te deponeren bij het handelsregister van de KvK.

Deze informatiegids gaat nader in op alle relevante onderwerpen omtrent het deponeren van een jaarrekening bij het handelsregister van de KvK met SBR.

4

Inhoudsopgave

DEEL A – ALGEMENE INFORMATIE .......................................................................................................... 9

1. Inleiding ......................................................................................................................................... 10

1.1 Achtergrond ........................................................................................................................... 10

1.2 Doel van dit document .......................................................................................................... 10

1.3 Indeling van dit document..................................................................................................... 10

1.4 Conventies in dit document .................................................................................................. 11

1.5 Verwijzing naar andere documenten .................................................................................... 11

1.6 Verklarende woordenlijst ...................................................................................................... 12

2. Ondersteuning ............................................................................................................................... 13

2.1 Ondersteuning bij het deponeren van de jaarrekening met SBR.......................................... 13

2.2 Contactinformatie ................................................................................................................. 14

DEEL B - ONDERNEMERS ....................................................................................................................... 15

3. Deponeren van de jaarrekening met SBR door ondernemers ...................................................... 16

4. Voorbereiding ................................................................................................................................ 17

4.1 Stel vast of u onder de SBR verplichtstelling valt .................................................................. 17

4.1.1 Fasering van de SBR verplichtstelling ............................................................................ 17

4.1.2 Uitzonderingen op de SBR verplichtstelling .................................................................. 18

4.1.3 Veelgestelde vragen en antwoorden omtrent de SBR verplichtstelling ....................... 18

4.2 Bepaal de insteek voor het opstellen van de jaarrekening ................................................... 19

4.2.1 Micro- en kleine rechtspersonen .................................................................................. 20

4.2.2 Middelgrote en grote rechtspersonen .......................................................................... 20

4.3 Zelf doen of uitbesteden ....................................................................................................... 21

4.3.1 Micro- en kleine rechtspersonen .................................................................................. 21

4.3.2 Middelgrote en grote rechtspersonen .......................................................................... 22

4.4 Stel vast in hoeverre de taxonomie aansluit bij uw jaarrekening ......................................... 24

4.5 Maak afspraken met uw accountant indien een accountantsverklaring vereist of gewenst is

25

4.6 Bepaal de wijze van deponeren met SBR .............................................................................. 26

4.6.1 Deponeren van de jaarrekening van micro- en kleine rechtspersonen ........................ 26

4.6.2 Deponeren van de jaarrekening van middelgrote en grote rechtspersonen ................ 27

4.7 Zorg dat u de beschikking heeft over de benodigde middelen ............................................. 28

5. Opstellen van de jaarrekening....................................................................................................... 31

5

5.1 Selecteer het juiste entrypoint .............................................................................................. 31

5.1.1 Boekjaar ......................................................................................................................... 32

5.1.2 GAAP .............................................................................................................................. 32

5.1.3 Bedrijfsklasse ................................................................................................................. 32

5.1.4 Publicatiestuk of inrichtingsstuk ................................................................................... 33

5.1.5 Waarderingsgrondslagen .............................................................................................. 33

5.1.6 Beschikbare modellen ................................................................................................... 33

5.1.7 Beschikbare elementen ................................................................................................. 34

5.2 Maak eventueel een preparer extension .............................................................................. 35

5.2.1 Bepalen of een preparer extension nodig is ................................................................. 36

5.2.2 Creëren van een preparer extension............................................................................. 40

5.3 Voer de gegevens in .............................................................................................................. 42

5.3.1 Taal van de jaarrekening ............................................................................................... 42

5.3.2 Gebroken boekjaren ...................................................................................................... 42

5.3.3 Verlengde of verkorte boekjaren .................................................................................. 43

5.3.4 Meer dan één valuta in de jaarrekening ....................................................................... 43

5.3.5 Vergelijkende cijfers ...................................................................................................... 44

5.3.6 Afrondingen ................................................................................................................... 44

5.3.7 Mintekens ...................................................................................................................... 45

5.3.8 Granulariteit van tekstuele toelichtingen ..................................................................... 45

5.3.9 Accountantsverklaring bij de jaarrekening .................................................................... 46

5.4 Genereer en valideer het XBRL instance document ............................................................. 47

5.5 Render het XBRL instance document t.b.v. review ............................................................... 47

5.6 Stuur de jaarrekening in XBRL formaat naar uw accountant voor de accountantscontrole 48

5.7 Veelgestelde vragen en antwoorden omtrent het opstellen van de jaarrekening ............... 48

6. Deponeren van de jaarrekening .................................................................................................... 50

6.1 Ontvang de gewaarmerkte jaarrekening en accountantsverklaring van uw accountant ..... 50

6.2 Vul de relevante gegevens aan in de jaarrekening ten behoeve van de deponering ........... 51

6.3 Stuur de jaarrekening in naar Digipoort ................................................................................ 51

6.4 Verkrijg de bevestiging van ontvangst en verwerking .......................................................... 51

6.5 Ontvang een gerenderde versie van de jaarrekening per e-mail .......................................... 52

DEEL C - ACCOUNTANTS ........................................................................................................................ 53

7. De rol van de accountant bij de jaarrekening in XBRL formaat .................................................... 54

7.1 Groenboek “De accountant in een SBR-omgeving” .............................................................. 54

6

7.2 Veelgestelde vragen en antwoorden omtrent de rol van de accountant bij de jaarrekening

in XBRL formaat ................................................................................................................................. 54

DEEL D – SOFTWAREONTWIKKELAARS ................................................................................................. 57

8. Software voor het deponeren van de jaarrekening met SBR ........................................................ 58

8.1 Bepaal de te ondersteunen functionaliteit ........................................................................... 58

8.2 Neem kennis van de specificaties ......................................................................................... 60

8.3 Testen van de functionaliteit ................................................................................................. 60

9. Opstellen van de jaarrekening in XBRL formaat ............................................................................ 62

9.1 Relevante specificaties .......................................................................................................... 62

9.2 Een jaarrekening in XBRL formaat nader uiteengezet .......................................................... 62

9.2.1 XML declaration ............................................................................................................. 63

9.2.2 XML comment ............................................................................................................... 63

9.2.3 XBRL/Schema sectie ...................................................................................................... 63

9.2.4 Entrypoint sectie ........................................................................................................... 64

9.2.5 Context sectie ................................................................................................................ 64

9.2.6 Unit sectie ...................................................................................................................... 67

9.2.7 Inhoud sectie ................................................................................................................. 68

9.2.8 Afsluiting ........................................................................................................................ 68

9.3 Bijzonderheden uit de praktijk .............................................................................................. 69

9.3.1 Naamgeving van het instance document ...................................................................... 69

9.3.2 Taal van de jaarrekening ............................................................................................... 69

9.3.3 Geconsolideerde of enkelvoudige jaarrekening ............................................................ 70

9.3.4 Jaarrekening op basis van commerciële of fiscale waarderingsgrondslagen ................ 70

9.3.5 De toepassing van een preparer extension bij het opstellen van de jaarrekening ....... 70

9.3.6 Verloopoverzichten ....................................................................................................... 71

9.3.7 Gebruik van ‘nil’ waardes in het instance document .................................................... 72

9.3.8 Technische validatie van het instance document ......................................................... 73

10. Opstellen van een preparer extension ...................................................................................... 76


10.2 Een preparer extension nader uiteengezet ........................................................................... 76

10.2.1 Importeren van een bestaand entrypoint uit de KvK taxonomie.................................. 76

10.2.2 Uitzetten van elementen ............................................................................................... 76

10.2.3 Veranderen van de presentatievolgorde van concepten .............................................. 78

10.2.4 Veranderen van de presentatievolgorde van tabellen.................................................. 80

10.2.5 Toevoegen van reeds bestaande elementen aan het entrypoint ................................. 82

7

10.2.6 Toevoegen van nieuwe elementen ............................................................................... 85

10.2.7 Toevoegen van formulas ............................................................................................... 89

11. Opstellen van de accountantsverklaring in XBRL formaat ........................................................ 90

12. Renderen van de documenten .................................................................................................. 91

12.1 Renderen van de jaarrekening .............................................................................................. 91

12.2 Renderen van de accountantsverklaring ............................................................................... 91

13. Ondertekenen en waarmerken ................................................................................................. 92


13.2 Ondertekenen en waarmerken nader uiteengezet ............................................................... 92

13.2.1 Selectie van de jaarrekening en de bijbehorende accountantsverklaring .................... 93

13.2.2 Buitensluiten van de vaststellings- en contactgegevens ............................................... 93

13.2.3 Creatie van een unieke hash van de jaarrekening en de accountantsverklaring .......... 95

13.2.4 Toevoegen van unieke object identificaties aan de hashes van de jaarrekening en de

accountantsverklaring ................................................................................................................... 96

13.2.5 Beschrijvingen opnemen van de jaarrekening en de accountantsverklaring en deze

koppelen aan de unieke object identificaties ............................................................................... 96

13.2.6 Selectie van het ondertekeningsbeleid ......................................................................... 97

13.2.7 Opnemen van de commitments en deze koppelen aan de unieke object identificaties

98

13.2.8 Creatie van een unieke hash van de ondertekeningseigenschappen ........................... 98

13.2.9 Op basis van de drie hashes met behulp van de private sleutel van het

persoonsgebonden beroepscertificaat de digitale handtekening maken .................................... 99

13.3 Bijzonderheden uit de praktijk .............................................................................................. 99

13.3.1 Waarmerken van een preparer extension .................................................................... 99

13.3.2 Valideren van een detached signature ........................................................................ 101

14. Deponeren van de jaarrekening .............................................................................................. 103

14.1 Relevante specificaties ........................................................................................................ 103

14.2 Deponeren nader uiteengezet ............................................................................................ 103

14.2.1 Aanleververzoek .......................................................................................................... 103

14.2.2 Terugkoppeling vanuit Digipoort en de KvK ................................................................ 108

DEEL E - SPECIFICATIES ........................................................................................................................ 109

15. Deponeren van de jaarrekening via Digipoort ........................................................................ 110

16. SBR instances & taxonomieën ................................................................................................. 112

16.1 Algemene toepassing .......................................................................................................... 112

16.2 Specifieke toepassing ten behoeve van het deponeren bij de KvK .................................... 115

16.2.1 KvK taxonomie ............................................................................................................. 115

8

16.2.2 NBA taxonomie ............................................................................................................ 115

17. SBR koppelvlakken................................................................................................................... 116


17.1.1 Aanleverservice ........................................................................................................... 116

17.1.2 Statusinformatieservice............................................................................................... 117

17.1.3 Afleverservice .............................................................................................................. 117


18. SBR i-processen ....................................................................................................................... 119



19. SBR linking & signing ............................................................................................................... 121



20. SBR ondertekeningsbeleid ....................................................................................................... 127


20.1.1 Ondersteunde versie(s) ............................................................................................... 127

20.1.2 Typen verplichtingen (‘commitments’) ....................................................................... 128

20.1.3 Aanvullende voorschriften vanuit het SBR ondertekeningsbeleid .............................. 129


21. SBR Preparer Extensions ......................................................................................................... 133


21.1.1 Architectuur van een preparer extension ................................................................... 133

21.1.2 Architectuurregels voor een preparer extension ........................................................ 136


22. SBR Consistente Presentatie ................................................................................................... 138



23. KvK backoffice ......................................................................................................................... 140

Appendix A – Verklarende woordenlijst .............................................................................................. 142

9

DEEL A – ALGEMENE INFORMATIE

10

1. Inleiding

1.1 Achtergrond

Rechtspersonen waarop Titel 9 van Boek 2 van het Burgerlijk Wetboek (hierna: BW) van toepassing is, zijn verplicht te voldoen aan wettelijke voorschriften inzake het opmaken, vaststellen en openbaar maken van de jaarrekening, het jaarverslag en de overige hieraan toe te voegen gegevens (hierna wordt voornamelijk gesproken over de jaarrekening, waaronder ook het jaarverslag en de overige daaraan toe te voegen gegevens kunnen vallen). Doorgaans betreft het rechtspersonen met een onderneming. De jaarrekening biedt een cijfermatig inzicht in de financiële toestand van een rechtspersoon, terwijl in het jaarverslag het bestuur verslag doet over de gang van zaken in de onderneming. De rechtspersonen die verplicht zijn een jaarrekening op te stellen met inachtneming van Titel 9 zijn verplicht die jaarlijks bij het handelsregister van de Kamer van Koophandel te deponeren op basis van artikel 2:394 lid 1 BW.

Sinds boekjaar 2016 dienen micro en kleine rechtspersonen de jaarstukken met SBR te deponeren in het handelsregister van de Kamer van Koophandel. Vanaf boekjaar 2017 geldt dat ook voor middelgrote rechtspersonen. Deze informatiegids is bedoeld als leidraad voor ondernemers, intermediairs en softwareleveranciers om hen te ondersteunen in de overgang naar elektronisch deponeren met SBR.

1.2 Doel van dit document

De informatiegids voor het deponeren van een jaarrekening met SBR is dé bron voor alle informatie omtrent het opstellen en deponeren van de jaarrekening in XBRL formaat bij het handelsregister van de KvK. Wanneer in dit document gesproken wordt over de jaarrekening, wordt hiermee bedoeld de jaarrekening, het bestuursverslag en de overige hieraan toe te voegen gegevens zoals een accountantsverklaring die ingevolge artikel 2:394 BW gedeponeerd dienen te worden.

Dit document beoogt om alle relevante informatie te verstrekken die ondernemers, accountants of softwareontwikkelaars nodig hebben in het kader van het deponeren van de jaarrekening bij de KvK. Dit kan zowel direct door het opnemen van de informatie in dit document of door het verwijzen naar andere documenten waarin deze informatie te vinden is. Het doel is om zo min mogelijk informatie dubbel op te nemen, waardoor regelmatig met onderbouwing zal worden verwezen naar andere, SBR-gerelateerde documenten.

Om de consistentie en vindbaarheid van de informatie te vergroten bevat dit document alle informatie die expliciet van toepassing is op het deponeren van de jaarrekening met SBR bij de Kamer van Koophandel.

1.3 Indeling van dit document

Dit document hanteert een zogenaamde ‘doelgroep-benadering’. Dit betekent dat de relevante onderwerpen zijn uitgewerkt naar de aard van de verschillende doelgroepen. In het kader van het deponeren van de jaarrekening met SBR bij de KvK zijn drie belangrijke doelgroepen te onderkennen:

11

• Ondernemers1: verantwoordelijk voor het deponeren van de jaarrekening bij de KvK;

• Accountants: controleren de jaarrekening en geven hierbij een verklaring af;

• Softwareontwikkelaars: ondersteunen ondernemers en accountants met functionaliteit;

De indeling van dit document is opgebouwd langs deze doelgroepen. In deel B staan de ondernemers centraal, in deel C de accountants en in deel D de softwareontwikkelaars. Daarnaast zijn de relevante specificaties in een aparte sectie E opgenomen.

1.4 Conventies in dit document

De conventies die in dit document gehanteerd worden, zijn hieronder kort beschreven.

Verwijzing naar andere documenten Indien in een tekst naar een specifiek document wordt verwezen, is dit document met blauwe onderstreepte letters opgenomen. Dit verduidelijkt dat hier sprake is van een verwijzing naar een ander document. De betreffende documenten zijn op basis van de informatie in paragraaf 1.5 eenvoudig te achterhalen.

Voorbeelden De voorbeelden die gebruikt worden in dit document zijn niet-normstellend. De voorbeelden worden als volgt aangeduid in een apart kader.

Voorbeeld

Tips Met een grijs-gearceerd kader worden handige tips aangegeven. Dit ziet er als volgt uit:

Tip:

1.5 Verwijzing naar andere documenten

In de informatiegids wordt naar de volgende documenten verwezen.

Wet- en regelgeving:

Document Versie Datum

Besluit elektronische deponering handelsregister - 14 april 2016

Vragen en antwoorden over verplichting van elektronisch deponeren van jaarstukken in het handelsregister bij de Kamer van Koophandel

4 Januari 2018

SBR specificaties:


1 Onder ondernemers wordt in dit kader verstaan die rechtspersonen die hun jaarrekening dienen te deponeren bij de Kamer van

Koophandel.

12

SBR Filing Rules 1.1 5 oktober 2017

Koppelvlakbeschrijving WUS 2.0 voor Bedrijven versie 1.2 1.1 20 april 2015

Servicebeschrijving Digipoort WUS 2.0 Bedrijven Aanleveren Koppelvlakversie 1.2

1.1 27 maart 2015

Servicebeschrijving Digipoort WUS 2.0 Bedrijven Statusinformatie Koppelvlakversie 1.2

1.1 28 april 2015

SBR Consistente Presentatie specificatie 1.3.1 19 januari 2018

NTA voor Preparer Extensions 1.3.1 -

Toelichting op het SBR ondertekeningsbeleid 2.0 10 oktober 2017

Overige documenten:


Toelichting op het gebruik van de online service Zelf Deponeren Jaarrekening

- Maart 2017

KvK Business Rules - 1 januari 2018

Handleiding bij de NBA Taxonomie 2.0 - 13 oktober 2017

Informatiegids voor de KvK taxonomie 1.0 13 december 2017

1.6 Verklarende woordenlijst

In dit document komen verschillende begrippen voor die voor de lezer wellicht onbekend zijn. In Appendix A is een verklarende woordenlijst opgenomen die de verschillende begrippen nader uiteenzet.

13

2. Ondersteuning

2.1 Ondersteuning bij het deponeren van de jaarrekening met SBR

Voor vragen omtrent het deponeren van de jaarrekening met SBR bij de Kamer van Koophandel kunt u bij verschillende organisaties terecht. In het onderstaande overzicht is meer informatie opgenomen welke vragen u waar kunt stellen.

Bij het Servicecenter van de Kamer van Koophandel kunt u terecht voor vragen over: - hoe te deponeren, - wat te deponeren, - wanneer te deponeren, - de online service Zelf Deponeren Jaarrekening, - toegang tot tool opstellen XBRL, - toegang tot tool deponeren XBRL, - foutmeldingen bij deponering, - het toetsingskader KvK (reikwijdte van het Besluit), - de informatievoorziening op KvK.nl, - de informatiegids voor het deponeren van een jaarrekening met SBR, - het gebruik van de KvK taxonomie.

Voor sommige vragen kunt u worden doorverwezen naar:

• Logius

• NBA

• Intermediair

• Softwareleverancier

Bij het Servicecentrum van Logius kunt u terecht voor: - hulp bij aansluiten op Digipoort, - informatie over een storings- of onderhoudsbericht, - het melden van een storing, - vragen over de Digipoort en toelichting op foutmeldingen, - technische vragen over de specificaties binnen het SBR afsprakenstelsel.

Bij de NBA kunt u als intermediair terecht met vragen over: - de NBA taxonomie, - de NBA verklaringen generator, - digitale ondertekeningen.

Bij een intermediair kunt u terecht voor advies over: - de inhoud van deponeringsstukken.

Bij een softwareleverancier kunt u terecht met vragen over: - ondersteuning door de betreffende software.

14

Hoe te handelen indien elektronisch deponeren niet mogelijk lijkt te zijn? De rechtspersoon is verantwoordelijk voor het indienen van een jaarrekening die voldoet aan de wet en die een zodanig inzicht geeft dat een verantwoord oordeel kan worden gevormd omtrent de financiële positie van de rechtspersoon (artikel 2:362 van het BW).

Het is aan de rechter om in individuele gevallen te besluiten of een rechtspersoon elektronisch moet deponeren in het Handelsregister. Het is daarom in beginsel niet aan de overheid - noch aan het Ministerie van Economische Zaken en Klimaat (EZK) noch aan de Kamer van Koophandel (KvK) - om juridisch advies te geven aan klanten over de reikwijdte van het besluit. De KvK hanteert een toetsingskader dat breed is afgestemd met partijen zoals grote accountantskantoren en de NBA.

Wanneer u, na beraad (eventueel met uw intermediair en/of juridisch adviseurs), van mening bent dat uw jaarstukken niet via SBR kunnen worden gedeponeerd omdat SBR of de taxonomie niet geschikt is terwijl u daartoe wel verplicht bent, kunt u contact opnemen met de KvK. Per individueel geval zal bepaald worden hoe te handelen en of afstemming met EZK noodzakelijk is.

Indien SBR niet geschikt blijkt te zijn doordat aan overheidszijde sprake is van een tekortkoming (zoals dat de taxonomie niet geschikt is of dat Digipoort niet bereikbaar is), dan zal bekeken worden of dit technisch op te lossen is, zo ja, op welke termijn. Zo nee, wordt een aanpassing van het Besluit elektronische deponering handelsregister in gang gezet. Omdat een aanpassing van het Besluit enige tijd in beslag zal nemen, zal tussentijds de communicatie verlopen via het document Vragen en antwoorden over verplichting van elektronisch deponeren van jaarstukken in het handelsregister bij de Kamer van Koophandel.

Wanneer een rechtspersoon van mening is dat de jaarstukken niet via SBR gedeponeerd kunnen worden, kan deze in een begeleidend schrijven een legitieme reden aangeven waarom men op papier deponeert (zie hiervoor ook het toetsingskader van de KvK).

2.2 Contactinformatie

Hieronder is de contactinformatie opgenomen van het servicecenter van de KvK en het servicecentrum van Logius.

Servicecenter van de KvK: Contactformulier: http://www.kvk.nl/contact/

Servicecentrum van Logius: Telefonisch: 0900 555 4555 (10 ct. p/m) E-mail: [email protected] Contactformulier: https://www.logius.nl/contact/

15

DEEL B - ONDERNEMERS

16

3. Deponeren van de jaarrekening met SBR door ondernemers

Als ondernemer moet u zich over uw handelen verantwoorden naar de samenleving. Dit doet u onder meer door het deponeren van de jaarrekening bij het handelsregister van de Kamer van Koophandel. De gefaseerde invoering van SBR voor het deponeren van de jaarrekening kan impact hebben op u. De daadwerkelijke impact verschilt echter per ondernemer.

Wanneer u uw administratie en/of verantwoordingswerkzaamheden uitbesteed aan een intermediair, zoals een accountants- of administratiekantoor, is de impact van de invoering van SBR beperkt. De intermediair regelt in dit geval de overgang naar SBR; meestal zonder dat u hiervan iets merkt. Als u zelf de jaarrekening opstelt en deponeert bij de Kamer van Koophandel wordt u wel geraakt door de invoering van SBR. U moet dus zelf actie ondernemen.

Een model van de verschillende fasen die u als ondernemer moet doorlopen om een jaarrekening te deponeren met SBR is in de onderstaande figuur opgenomen.

Figuur 1 – Te doorlopen fasen voor het deponeren van de jaarrekening met SBR

In de bovenstaande figuur zijn de fasen die u moet doorlopen in het blauw opgenomen. De fase in het grijs is situationeel en betreft de controle van de jaarrekening door een accountant. Deze fase is alleen verplicht voor middelgrote en grote rechtspersonen en optioneel voor micro- en kleine rechtspersonen.

In deze sectie gaan we nader in op de activiteiten, uitdagingen en vraagstukken waar u als ondernemer tegenaan kunt lopen tijdens de verschillende fases van het proces voor het deponeren van de jaarrekening met SBR. Dit begint in hoofdstuk 4 bij de ‘voorbereiding’, gevolgd door het ‘opstellen van de jaarrekening’ in hoofdstuk 5 en het ‘deponeren van de jaarrekening’ in hoofdstuk 6. In deze sectie gaan we niet in op de controle van de jaarrekening door de accountant.

17

4. Voorbereiding

De voorbereiding op het deponeren een jaarrekening met SBR is wellicht de belangrijkste fase voor u. Uw keuzes tijdens de voorbereiding bepalen de impact van SBR voor het deponeren van de jaarrekening. Hierbij maken we vaak een onderscheid tussen micro- en kleine rechtspersonen enerzijds en middelgrote en grote rechtspersonen anderzijds. Dit onderscheid wordt gemaakt omdat het jaarrekeningproces – het proces van de totstandkoming van de jaarrekening – van deze twee soorten rechtspersonen sterk van elkaar verschillen. Dit verschil vloeit onder meer voort uit de grotere omvang van de rapportagevereisten van en de verplichte accountantscontrole op de jaarrekening van middelgrote en grote rechtspersonen.

Onderstaand stappenplan helpt u bij het maken van deze keuzes.

Figuur 2 – Stappenplan voorbereiding voor het deponeren van de jaarrekening met SBR

In de volgende paragrafen worden deze stappen nader uitgewerkt.

4.1 Stel vast of u onder de SBR verplichtstelling valt

De eerste stap die u als ondernemer moet doorlopen tijdens de voorbereidingsfase is vaststellen of u onder de verplichting valt voor het deponeren van de jaarrekening met SBR. In de volgende paragrafen gaan we nader in op de verschillende aspecten rond deze verplichtstelling.

4.1.1 Fasering van de SBR verplichtstelling

Op basis van het Besluit elektronische deponering handelsregister is de verplichting om jaarrekeningen uitsluitend met SBR te deponeren voor micro- en kleine rechtspersonen van toepassing voor boekjaren die starten op of na 1 januari 2016. Deze categorie omvat circa 98% van de deponeringsplichtige rechtspersonen. Voor middelgrote rechtspersonen is de verplichting van toepassing voor boekjaren die starten op of na 1 januari 2017.

18

Voor grote rechtspersonen is het moment van inwerkingtreding nog niet volledig duidelijk. Grote rechtspersonen moeten voldoen aan de meest uitgebreide verslaggevingsvereisten. Daarom is het voornemen om deze rechtspersonen een langere overgangsperiode te geven. Daarnaast is de ingangsdatum gerelateerd aan de aankomende verplichtstelling van ESMA (European Securities Market Authority) voor het digitaal formaat waarin jaarrekeningen van rechtspersonen die een beursnotering hebben op Europees niveau verplicht worden aangeleverd. Dit zal vermoedelijk van toepassing zijn voor boekjaren die starten op of na 1 januari 2020.

In de onderstaande tabel is per categorie rechtspersoon aangegeven vanaf welk boekjaar het deponeren van de jaarrekening met SBR verplicht is, dan wel vanaf wanneer vrijwillig gebruik gemaakt kan worden van SBR voor het deponeren van jaarrekeningen.

Boekjaar 2016 2017 2018 2019 2020

Micro-rechtspersonen Verplicht Verplicht Verplicht Verplicht Verplicht

Kleine rechtspersonen Verplicht Verplicht Verplicht Verplicht Verplicht

Middelgrote rechtspersonen Vrijwillig Verplicht Verplicht Verplicht Verplicht

Grote rechtspersonen Vrijwillig Vrijwillig Vrijwillig Vrijwillig Verwacht

Tabel 1 – Fasering van de SBR verplichtstelling

4.1.2 Uitzonderingen op de SBR verplichtstelling

Voor bepaalde rechtspersonen is in het Besluit elektronische deponering handelsregister geen verplichting tot deponering langs elektronische weg via SBR opgenomen. Voor een volledig beeld verwijzen we naar het Besluit elektronische deponering handelsregister. Een andere optie is gebruik maken van het toetsingskader van de KvK, bedoeld als een praktisch hulpmiddel. Op basis van de vragen in dit toetsingskader kunt u - op hoofdlijnen - afleiden of u verplicht bent om de jaarrekening over het boekjaar 2017 met SBR te deponeren. De beantwoording van de vragen in het toetsingskader geeft echter geen officieel overheidsstandpunt weer; het is aan de rechter om in concrete gevallen de wet te interpreteren.

Het toetsingskader van de Kamer van Koophandel kunt u vinden in de sectie ‘Wanneer kan ik de jaarstukken van mijn onderneming in de bedrijfsklasse middelgroot wel op papier deponeren?’ op de volgende pagina van de KvK website: https://www.kvk.nl/inschrijven-en-wijzigen/deponeren/jaarrekening-deponeren/hoe-deponeert-u-uw-jaarrekening/

4.1.3 Veelgestelde vragen en antwoorden omtrent de SBR verplichtstelling

De veelgestelde vragen en antwoorden omtrent de SBR verplichtstelling zijn opgenomen in het document Vragen en antwoorden over verplichting van elektronisch deponeren van jaarstukken in het handelsregister bij de Kamer van Koophandel. Hier komt een variëteit aan vragen aan bod omtrent in welke situaties welke rechtspersonen nu wel en niet onder de SBR verplichtstelling vallen. De meest recente versie van dit document kunt u vinden op: http://www.kvk.nl/hoedeponeren

19

4.2 Bepaal de insteek voor het opstellen van de jaarrekening

De tweede stap is het bepalen wat de insteek wordt voor het opstellen van de jaarrekening. Deze stap is uiteraard alleen van belang indien u het voeren van de administratie en alle hieruit voortvloeiende verantwoordingen niet heeft uitbesteed aan een intermediair.

Een onderneming dient altijd een jaarrekening op te stellen voor haar eigen administratie. Deze jaarrekeningen staan ook wel bekend als de inrichtingsstukken. Daarnaast dient een onderneming zijn jaarrekening ook te deponeren bij het handelsregister van de Kamer van Koophandel binnen (uiterlijk) 12 maanden na het einde van het boekjaar. De jaarrekeningen die onder deze verplichting tot deponeren vallen, staan ook wel bekend als de publicatiestukken. De SBR verplichtstelling ziet uitsluitend toe op het deponeren van de publicatiestukken.

Het verschil tussen de inrichtingsstukken en de publicatiestukken is dat de publicatiestukken voor rechtspersonen in bepaalde bedrijfsklassen minder uitgebreid zijn dan de inrichtingsstukken. Voor zowel micro-, kleine als middelgrote rechtspersonen is sprake van een verschil tussen de inrichtingsstukken en publicatiestukken als gevolg van de vrijstellingen uit artikelen 2:395a, 396 en 397 BW. Grote rechtspersonen kennen geen verschil tussen de inrichtingsstukken en publicatiestukken.

In de KvK taxonomie zijn entrypoints opgenomen voor zowel de inrichtingsstukken als de publicatiestukken. Hierdoor heeft u als ondernemer de mogelijkheid om een inrichtingsstuk en een publicatiestuk op te stellen in XBRL-formaat.

Als u het opstellen van de jaarrekening niet uitbesteedt, kiest u eerst de insteek die u gebruikt voor het opstellen van het inrichtingsstuk en het publicatiestuk. Conceptueel zijn hiervoor twee varianten te onderkennen: een ‘bolt-on’ jaarrekeningproces en een ‘built-in’ jaarrekeningproces. In de onderstaande figuur is het verschil tussen deze twee varianten gevisualiseerd.

Figuur 3 – Jaarrekeningproces ‘bolt-on’ versus ‘built-in’

20

Een bolt-on jaarrekeningproces Een bolt-on jaarrekeningproces kenmerkt zich door de situatie dat het publicatiestuk (het XBRL instance document) wordt opgesteld op basis van het inrichtingsstuk. Het inrichtingsstuk is in dit geval in een papier-georiënteerd formaat, zoals .docx of .pdf, opgesteld. Deze omzetting kan op verschillende manieren plaatsvinden. Hier gaan we in de volgende paragraaf nader op in.

Een built-in jaarrekeningproces Een built-in jaarrekeningproces kenmerkt zich door de situatie waarin het publicatiestuk gelijktijdig met het inrichtingsstuk tot stand komt. Dit is mogelijk wanneer de XBRL-tags direct in de applicaties van het jaarrekeningproces zijn geïntegreerd. In dit geval is sprake van (functionele) systeemintegratie via XBRL.

Er zijn in dit kader echter duidelijke verschillen waarneembaar tussen micro- en kleine rechtspersonen enerzijds en middelgrote en grote rechtspersonen anderzijds.

4.2.1 Micro- en kleine rechtspersonen

Voor het opstellen van jaarrekeningen van micro- en kleine rechtspersonen wordt verhoudingsgewijs veel gebruik gemaakt van een built-in jaarrekeningproces. Dit wordt veroorzaakt door een samenloop van omstandigheden. De grote hoeveelheid micro- en kleine rechtspersonen in Nederland, de beperkte omvang van deze jaarrekeningen en veelal cijfermatige inhoud die direct afkomstig is uit de financiële administratie, hebben ervoor gezorgd dat er in de afgelopen jaren veel built-in oplossingen beschikbaar zijn gekomen. Deze oplossingen zorgen voor een eenvoudige wijze om zowel de inrichtingstukken als publicatiestukken te maken.

Dit betekent overigens niet dat een bolt-on jaarrekeningproces niet meer wordt gebruikt door micro- en kleine rechtspersonen. Dit is zeker nog het geval; vooral in die situaties waar ondernemers zelf hun jaarrekening opstellen. Hier gaat paragraaf 4.3 verder op in.

4.2.2 Middelgrote en grote rechtspersonen

De situatie voor middelgrote en grote rechtspersonen is beduidend anders dan die van micro- en kleine rechtspersonen. Dit komt omdat het opstellen van de inrichtingsstukken van middelgrote en grote rechtspersonen vaak handmatig plaatsvindt, meestal door de financiële afdeling van de onderneming zelf. Vaak gebruiken zij hiervoor een tekstverwerker. Er zijn daarnaast ook weinig built-in oplossingen beschikbaar voor deze rechtspersonen. Dit komt mede door het beperkte aantal van deze rechtspersonen en het feit dat veel informatie niet (direct) uit de financiële administratie is te halen.

Dit betekent dat meestal sprake is van een bolt-on jaarrekeningproces voor het opstellen van de publicatiestukken. Hierbij wordt op basis van het papier-georienteerde inrichtingsstuk een publicatiestuk in XBRL formaat opgesteld. Dit is uiteraard niet de meest efficiënte manier om XBRL te implementeren, aangezien het een extra stap is na het opstellen van het inrichtingsstuk. Het voordeel van deze ‘bolt-on’ methode is echter dat een onderneming op een relatief eenvoudige wijze een jaarrekening in XBRL formaat kan opstellen om te voldoen aan de verplichting tot het deponeren van de jaarrekening met SBR.

21

4.3 Zelf doen of uitbesteden

De derde keuze die u als ondernemer moet maken is te bepalen hoe u de jaarrekening in XBRL formaat wilt gaan opstellen voor het deponeren bij de KvK (oftewel de publicatiestukken). Hierbij maken we een onderscheid tussen het opstellen van de jaarrekening van micro- en kleine rechtspersonen enerzijds en middelgrote en grote rechtspersonen anderzijds.

4.3.1 Micro- en kleine rechtspersonen

Als ondernemer bent u altijd verantwoordelijk voor het opstellen van de jaarrekening in XBRL formaat. U heeft hierbij twee opties: u kunt het opstellen van de jaarrekening in XBRL formaat uitbesteden of u kunt dit zelf doen.

4.3.1.1 Uitbesteden

Het grootste deel van de micro- en kleine rechtspersonen hebben het voeren van de administratie en het opstellen van de jaarrekening (zowel de inrichtingsstukken als publicatiestukken) uitbesteed aan een intermediair, zoals een accountants- of administratiekantoor.

De intermediair verzorgt het opstellen van het inrichtingsstuk voor de ondernemer en regelt voor hen dat het publicatiestuk ook met SBR wordt gedeponeerd bij de KvK. De ondernemer wordt hierdoor volledig ontzorgd en merkt nagenoeg niets van de invoering van SBR voor het deponeren van de jaarrekening. De intermediair werkt hierbij over het algemeen met built-in oplossingen die zowel de inrichtingstukken als publicatiestukken genereren.

4.3.1.2 Zelf doen

Een deel van de micro- en kleine rechtspersonen stelt zelf de jaarrekening op, bijvoorbeeld met een tekstverwerker of spreadsheetsoftware. Deze ondernemers dienen vervolgens nog wel het publicatiestuk in XBRL formaat te deponeren. Hiervoor heeft de ondernemer twee mogelijkheden:

1. Gebruik maken van de online service Zelf Deponeren Jaarrekening 2. Gebruik maken van software met functionaliteit voor het opstellen van een jaarrekening in

XBRL formaat

Online service Zelf Deponeren Jaarrekening Met de online service Zelf Deponeren Jaarrekening (ZDJ) kunt u de jaarrekening invoeren en vervolgens direct deponeren in een online portaal van de Kamer van Koophandel. Het invoeren van de jaarrekening is een bolt-on methode waarmee het publicatiestuk in XBRL formaat wordt gezet.

In het document Toelichting op het gebruik van de online service Zelf Deponeren Jaarrekening is uitgebreid beschreven hoe de online service Zelf Deponeren Jaarrekening werkt. Meer informatie over de online service Zelf Deponeren Jaarrekening is verder te vinden op: http://www.kvk.nl/zelfdeponeren

Met de online service Zelf Deponeren Jaarrekening kan een jaarrekening worden ingevoerd op basis van het entrypoint ‘publicatiestukken van micro-rechtspersonen’ en ‘publicatiestukken van kleine rechtspersonen’. Indien u als micro- of kleine rechtspersoon een jaarrekening op basis van een ander entrypoint wilt deponeren, moet u gebruikmaken van software met functionaliteit voor het opstellen van een jaarrekening in XBRL formaat.

22

Software met functionaliteit voor het opstellen van een jaarrekening in XBRL formaat Er bestaan verschillende (betaalde) softwareproducten waarmee u een jaarrekening kunt opstellen in XBRL formaat. Op basis van uw inrichtingsstuk kunt u met deze software (al dan niet met enige mate van handmatige invoer) het publicatiestuk in XBRL formaat realiseren. Deze softwareproducten kennen verschillende verschijningsvormen, waaronder Excel plug-ins, geavanceerde webformulieren en separate applicaties. Op basis van uw eigen wensen kunt u een keuze maken voor de door u gewenste software.

4.3.2 Middelgrote en grote rechtspersonen

Het jaarrekeningproces van middelgrote en grote rechtspersonen is anders dan die van micro- en kleine rechtspersonen, aangezien een accountant de jaarrekening moet controleren. Als ondernemer bent u altijd zelf verantwoordelijk voor het opstellen van de jaarrekening in XBRL formaat. U heeft hierbij twee opties: u kunt zelf de jaarrekening in XBRL formaat opstellen of u kunt dit uitbesteden.

4.3.2.1 Zelf doen

Het grootste deel van de middelgrote en grote rechtspersonen stelt zelf het inrichtingsstuk op, meestal met een tekstverwerker of spreadsheetsoftware. Vervolgens moet nog wel het publicatiestuk in XBRL formaat worden omgezet. Hiervoor zijn twee mogelijkheden:

1. Gebruikmaken van de tool Opstellen XBRL 2. Gebruikmaken van software met functionaliteit voor het opstellen van een jaarrekening in

XBRL formaat

Tool Opstellen XBRL Met de tool Opstellen XBRL kunnen middelgrote rechtspersonen een jaarrekening in XBRL-formaat opstellen. Het op deze wijze opstellen van de jaarrekening is een bolt-on methode waarmee het publicatiestuk in XBRL formaat wordt gezet. Met deze tool kunt u de gegevens van uw jaarrekening invullen in een webformulier dat tot stand komt op basis van het entrypoint uit de KvK taxonomie. De tool creëert de XBRL jaarrekening voor u. Vervolgens kunt u de jaarrekening in XBRL formaat downloaden en versturen naar uw accountant. De tool Opstellen XBRL is een tijdelijke voorziening die bedoeld is om de transitie naar de jaarrekening in XBRL formaat in de komende jaren te ondersteunen.

Voordelen van deze werkwijze:

• Uw huidige jaarrekeningproces blijft nagenoeg in stand. U hoeft, naast het toevoegen van deze extra stap, geen verdere aanpassingen in het proces te doen.

• U hoeft geen XBRL software aan te schaffen.

Nadelen van deze werkwijze:

• Het handmatig invullen van de gegevens in een webformulier kan veel tijd in beslag nemen.

• Het is uitsluitend mogelijk om gegevens in te vullen op basis van het gestandaardiseerde raamwerk van de taxonomie. Het is niet mogelijk om dit raamwerk uit te breiden met behulp van een preparer extension, aangezien deze niet worden ondersteund in de tool Opstellen XBRL.

Meer informatie over de tool Opstellen XBRL is te vinden op: https://www.kvk.nl/inschrijven-en-wijzigen/deponeren/jaarrekening-deponeren/xbrl-jaarrekening-opstellen-en-deponeren/

23

Met de tool Opstellen XBRL kunt u een jaarrekening opstellen op basis van de volgende entrypoints uit de KvK taxonomie (NT12):

• Publicatiestukken van middelgrote rechtspersonen

• Inrichtingstukken van middelgrote rechtspersonen

• Commerciële stichtingen en verenigingen

• Middelgrote en grote organisaties zonder winststreven

• Toegelaten instellingen volkshuisvesting

• Fondsenwervende instellingen

• Vennootschappen onder firma & commanditaire vennootschappen

• Coöperaties

De entrypoints voor grote rechtspersonen worden niet ondersteund door de tool Opstellen XBRL. Indien u als middelgrote rechtspersoon een jaarrekening op basis van een ander entrypoint wilt opstellen, moet u gebruikmaken van software met functionaliteit voor het opstellen van een jaarrekening in XBRL formaat.

Software met functionaliteit voor het opstellen van een jaarrekening in XBRL formaat Er bestaan verschillende (betaalde) softwareproducten waarmee u als middelgrote rechtspersoon een jaarrekening kunt opstellen in XBRL formaat. Op basis van uw inrichtingsstuk kunt u met behulp van deze software (met een bepaalde mate van handmatige invoer) het publicatiestuk in XBRL formaat realiseren. Deze softwareproducten kennen verschillende verschijningsvormen, waaronder Excel plug-ins, geavanceerde webformulieren en separate applicaties. Op basis van uw eigen wensen kunt u een keuze maken voor de door u gewenste software.


• De beschikbare software assisteert u bij het opstellen en valideren van de jaarrekening. Het biedt beduidend meer functionaliteit dan de tool Opstellen XBRL.

• Indien de geselecteerde software het ondersteunt, is het mogelijk om de jaarrekening uit te breiden met eigen begrippen en relaties in de vorm van een preparer extension (zie paragraaf 4.4 voor meer informatie over preparer extensions).


• U dient zelf XBRL software aan te schaffen en te implementeren.

4.3.2.2 Uitbesteden

U kunt het opstellen van de jaarrekening uitbesteden aan een gespecialiseerde bolt-on dienstverlener. Deze verzorgen de jaarrekening in XBRL formaat op basis van de door u opgestelde jaarrekening in een papier-georiënteerd formaat. Op deze wijze wordt u volledig ontzorgd.


• U hoeft geen XBRL software aan te schaffen.

• U hoeft zelf heeft geen tijd te besteden aan het opstellen van de XBRL jaarrekening

• Een gespecialiseerde bolt-on dienstverlener zorgt ervoor dat de XBRL jaarrekening is afgeleid van het inrichtingsstuk en aan alle technische eisen voldoet.

• Een gespecialiseerde bolt-on dienstverlener faciliteert het ontwerp en de toepassing van een preparer extension bij de XBRL jaarrekening.


• Het inschakelen van een gespecialiseerde bolt-on dienstverlener kost geld.

24

• Het opstellen van de XBRL jaarrekening heeft enige doorlooptijd.

4.4 Stel vast in hoeverre de taxonomie aansluit bij uw jaarrekening

De vierde stap tijdens de voorbereidingsfase, is vaststellen in hoeverre de inhoud van het geselecteerde entrypoint uit de KvK taxonomie aansluit op de inhoud van uw jaarrekening. Dit is met name relevant voor middelgrote en grote rechtspersonen.

De financiële overzichten (balans, winst-en-verliesrekening en kasstroomoverzicht) in de KvK taxonomie zijn opgezet op basis van de vereisten volgens het Besluit Modellen Jaarrekening, Titel 9 BW2 en de Richtlijnen voor de Jaarverslaggeving. Hierdoor bevat de KvK taxonomie een gestandaardiseerd raamwerk van posten die in de financiële overzichten gebruikt worden.

In de jaarrekening wijkt u wellicht af van de standaard modellen van de financiële overzichten uit de wet- en regelgeving. Deze afwijkingen kunnen voortvloeien uit het inzicht dat u met de jaarrekening dient te geven aan het maatschappelijk verkeer en zijn mogelijk in overleg met uw accountant tot stand gekomen. Dit zal in de jaarrekening in XBRL formaat niet anders zijn. Het is daarom verstandig om op hoofdlijnen te analyseren in hoeverre uw jaarrekening dergelijke specifieke posten in de financiële overzichten bevat die niet in het relevante entrypoint van de KvK taxonomie zijn opgenomen.

Tip: Analyseer de KvK taxonomie met behulp van een taxonomie viewer

Het op hoofdlijnen analyseren van de KvK taxonomie kan het beste plaatsvinden met behulp van een taxonomie viewer. Een taxonomie viewer is een interactieve tool waarmee u de inhoud van de verschillende entrypoints van de KvK taxonomie kunt bekijken.

Het SBR programma in Nederland heeft een online taxonomie viewer beschikbaar gesteld waarmee de entrypoints van de KvK taxonomie in de browser zijn te bekijken. Deze tool is te vinden op http://www.taxonomie-viewer.nl

Op basis van deze globale analyse kunt u een inschatting maken van de noodzaak een zogenaamde ‘preparer extension’ te gebruiken. Met een preparer extension kunt u de KvK taxonomie aanvullen met eigen begrippen en/of de presentatiestructuren van de KvK taxonomie aanpassen om meer in lijn te komen met de presentatiewijze van uw jaarrekening.

Indien u uit de voeten kunt met het gestandaardiseerde raamwerk van posten in de KvK taxonomie heeft u geen preparer extension nodig. Als u posten wilt rapporteren die niet of niet voldoende in het gestandaardiseerde raamwerk van het betreffende entrypoint van de KvK taxonomie zijn opgenomen, heeft u waarschijnlijk wel een preparer extension nodig. Deze preparer extension kunt u dan gebruiken om de jaarrekening in XBRL formaat op te stellen en moet u ook deponeren bij de KvK.

Het is niet mogelijk om een jaarrekening met een preparer extension op te stellen met de tool Zelf Deponeren Jaarrekening of de tool Opstellen XBRL. In dit geval moet u gebruikmaken van commerciële software die het mogelijk maakt om een preparer extension op te stellen. Dit is nadrukkelijk een andere functionaliteit dan het opstellen van een jaarrekening op basis van een preparer extension. Het is ook mogelijk om dit volledig uit te besteden aan een gespecialiseerde dienstverlener.

25

4.5 Maak afspraken met uw accountant indien een accountantsverklaring vereist of

gewenst is

De vijfde stap die u moet doorlopen tijdens de voorbereidingsfase betreft het maken van afspraken met uw accountant wanneer u een accountantsverklaring bij de te deponeren jaarrekening nodig hebt. Dit kan zowel wettelijk verplicht zijn (in het geval van middelgrote en grote rechtspersonen) of vrijwillig (voor micro- of kleine rechtspersonen).

Bij de te deponeren jaarrekening in XBRL geeft de accountant ook een accountantsverklaring in XBRL formaat af voorzien van een digitale handtekening. Deze documenten - de accountantsverklaring en de digitale handtekening – dienen tezamen met de jaarrekening gedeponeerd te worden bij de KvK. De accountantsverklaring wordt pas afgegeven wanneer de accountant heeft vastgesteld dat het publicatiestuk voldoet aan de daaraan te stellen eisen.

In dit kader is het van belang om af te spreken wanneer u de jaarrekening in XBRL aan uw accountant beschikbaar stelt. Hiervoor zijn grofweg twee scenario’s te onderkennen: tegen het einde van de jaarrekeningcontrole of voor aanvang van de jaarrekeningcontrole.

Tegen het einde van de jaarrekeningcontrole De jaarrekeningcontrole vindt over het algemeen plaats op basis van het inrichtingsstuk (of de onderliggende cijfers hiervan, wanneer het inrichtingsstuk nog niet gereed is). Wanneer u het inrichtingsstuk in een op papier-georiënteerd formaat opstelt, geeft de accountant hierbij ook een accountantsverklaring af in een op een papier-georiënteerd formaat. Het proces van de jaarrekeningcontrole kan zodoende grotendeels uitgevoerd worden op basis van het ‘papieren’inrichtingsstuk.

In deze situatie zal het opstellen van het publicatiestuk - de jaarrekening in XBRL formaat - plaatsvinden via een ‘bolt-on’ methode. Het publicatiestuk wordt pas opgesteld wanneer het inrichtingsstuk de status van definitief concept heeft gekregen. Als een van de laatste stappen van het proces van de jaarrekeningcontrole, wil de accountant vaststellen dat het publicatiestuk voldoet aan de vereisten. Dit houdt in dat het publicatiestuk is afgeleid van het inrichtingsstuk waarbij het gebruik maakt van de beschikbare vrijstellingen. Nadat de accountant dit heeft vastgesteld, kan de accountantsverklaring in XBRL formaat, voorzien van een digitale handtekening, worden afgegeven bij het publicatiestuk.

Voor aanvang van de jaarrekeningcontrole U kunt de jaarrekening in XBRL formaat ook voor aanvang van de jaarrekeningcontrole beschikbaar stellen aan de accountant. In deze situatie vindt het opstellen van het publicatiestuk plaats via een ‘built-in’ methode. Dit betekent dat eventuele aanpassingen naar aanleiding van de jaarrekeningcontrole automatisch verwerkt worden in het inrichtingsstuk en publicatiestuk.

Het is in dit geval ook mogelijk dat het inrichtingsstuk ook in XBRL formaat is opgesteld. Het proces van de jaarrekeningcontrole kan zodoende grotendeels uitgevoerd worden op basis van het inrichtingsstuk in XBRL formaat.

In de praktijk zal in de eerste jaren van de verplichtstelling vooral het scenario van toepassing zijn waarbij het publicatiestuk tegen het einde van de jaarrekeningcontrole beschikbaar zal worden gesteld.

26

4.6 Bepaal de wijze van deponeren met SBR

De zesde stap tijdens de voorbereidingsfase is bepalen van de wijze waarop u de jaarrekening wilt deponeren. Het deponeren bij de Kamer van Koophandel met SBR kan uitsluitend via Digipoort. Digipoort verzorgt de ontvangst, verwerking en aflevering van elektronische berichten die ondernemers verzenden naar verschillende overheidsorganisaties, waaronder de Kamer van Koophandel. Het insturen naar Digipoort verloopt via een beveiligde verbinding, waarin ook autorisatie en authenticatie plaatsvindt met behulp van digitale certificaten.

Hierbij maken we een onderscheid tussen het deponeren van de jaarrekening van micro- en kleine rechtspersonen enerzijds en middelgrote en grote rechtspersonen anderzijds.

4.6.1 Deponeren van de jaarrekening van micro- en kleine rechtspersonen

Als ondernemer bent u altijd zelf verantwoordelijk voor het deponeren van de jaarrekening bij de Kamer van Koophandel. Het deponeren is over het algemeen afhankelijk van de wijze waarop de jaarrekening in XBRL formaat tot stand is gekomen. De meest waarschijnlijke scenario’s zijn:

• Deponeren gefaciliteerd door uw intermediair

• Deponeren met de online service Zelf Deponeren Jaarrekening

• Deponeren met behulp van software

4.6.1.1 Deponeren gefaciliteerd door uw intermediair

Wanneer u het voeren van de administratie en het opstellen van de jaarrekening heeft uitbesteed aan een intermediair, kan deze ook het deponeren van de jaarrekening voor u verzorgen. Een groot aantal intermediairs stelt hiervoor een portaal beschikbaar aan hun klanten. In een dergelijk portaal kunt u meestal de datum van vaststelling van de jaarrekening opgeven en daarna explicit bevestigen dat u de jaarrekening wilt deponeren bij de Kamer van Koophandel. Andere intermediairs hebben dit wellicht niet middels een portaal ingeregeld, maar het proces is inhoudelijk vergelijkbaar.

4.6.1.2 Deponeren met de online service Zelf Deponeren Jaarrekening

Wanneer u gebruik maakt van de online service Zelf Deponeren Jaarrekening voor het opstellen van de jaarrekening (zie ook paragraaf 4.3.1.2), kunt u hier ook direct de jaarrekening deponeren. Na het invoeren van de jaarrekening in de online service, kunt u de invoer controleren en met een druk op de knop deponeren. De online service Zelf Deponeren Jaarrekening stuurt de jaarrekening in XBRL formaat in naar Digipoort voor verwerking in het Handelsregister.

4.6.1.3 Deponeren met software

Wanneer u gebruik maakt van (betaalde) software om de jaarrekening in XBRL formaat op te stellen, moet u deze over het algemeen ook zelf deponeren. Hiervoor dient u gebruik te maken van (betaalde) software die de functionaliteit bevat om een elektronisch bericht in te sturen naar Digipoort. In de meeste gevallen biedt de software die u gebruikt om de jaarrekening in XBRL formaat op te stellen, deze functionaliteit.

Software met deze functionaliteit heeft hiervoor een PKIoverheid (services) certificaat nodig voor het opzetten van een beveiligde verbinding met Digipoort. Bij een deel van de software kunt u gebruik maken van het certificaat van de softwareleverancier, zodat u zelf geen certificaat hoeft aan te

27

schaffen. Bij een ander deel moet u wel een eigen certificaat aanschaffen voordat u gebruik kunt maken van de geboden functionaliteit. Het is verstandig om hier bij het maken van een keuze voor de te hanteren software rekening mee te houden.

4.6.2 Deponeren van de jaarrekening van middelgrote en grote rechtspersonen

Het proces van het deponeren van de jaarrekening door middelgrote en grote rechtspersonen loopt anders dan dat van micro- en kleine rechtspersonen, aangezien de jaarrekening gecontroleerd is door een accountant. De meest waarschijnlijke scenario’s zijn:

• Deponeren met de tool Opstellen XBRL

• Deponeren gefaciliteerd door uw accountant

• Deponeren met behulp van software

4.6.2.1 Deponeren met de tool Opstellen XBRL

Als ondernemer bent u altijd zelf verantwoordelijk voor het deponeren van de jaarrekening bij de Kamer van Koophandel. Om dit zo eenvoudig mogelijk te maken, heeft de Kamer van Koophandel de mogelijkheid tot deponeren mogelijk gemaakt binnen de tool Opstellen XBRL. Via deze tool kunt u de jaarrekening in XBRL formaat en de accountantsverklaring in XBRL formaat en de digitale handtekening handmatig uploaden. Eenmaal geüpload kunt u de jaarrekening met een druk op de knop deponeren. De tool Opstellen XBRL stuurt de jaarrekening in XBRL formaat in naar Digipoort voor verwerking in het Handelsregister.

Meer informatie over het deponeren met behulp van de tool Opstellen XBRL is te vinden op: https://www.kvk.nl/inschrijven-en-wijzigen/deponeren/jaarrekening-deponeren/xbrl-jaarrekening-opstellen-en-deponeren/

4.6.2.2 Deponeren gefaciliteerd door uw accountant

Een accountant voert een controle uit op de jaarrekening van middelgrote en grote rechtspersonen. Een deel van deze accountants faciliteert het deponeren van de jaarrekening met accountantsverklaring voor hun klanten. Deze accountants stellen hiervoor meestal een portaal beschikbaar aan hun klanten, waarmee u de datum van vaststelling van de jaarrekening kunt opgeven en daarna explicit moet bevestigen dat u de jaarrekening wilt deponeren bij de Kamer van Koophandel.

Indien uw accountant dit faciliteert, hoeft u verder niets te regelen. Het ligt niet in de lijn der verwachting dat elke accountant dit voor zijn klanten gaat faciliteren.

4.6.2.3 Deponeren met software

Voor het deponeren van de jaarrekening kunt u ook gebruikmaken van (betaalde) software die de functionaliteit bevat om een elektronisch bericht in te sturen naar Digipoort. In de meeste gevallen biedt de software die u gebruikt om de jaarrekening in XBRL formaat op te stellen deze functionaliteit.

28

Software met deze functionaliteit heeft hiervoor een PKIoverheid (services) certificaat nodig voor het opzetten van een beveiligde verbinding met Digipoort. Bij een deel van de software kunt u gebruikmaken van het certificaat van de softwareleverancier, zodat u zelf geen certificaat hoeft aan te schaffen. Bij een ander deel moet u wel een eigen certificaat aanschaffen voordat u gebruik kunt maken van de geboden functionaliteit. Het is verstandig om hier bij het maken van een keuze voor de te hanteren software rekening mee te houden.

4.7 Zorg dat u de beschikking heeft over de benodigde middelen

De laatste stap is ervoor zorgen dat u beschikt over de middelen om aan de verplichtstelling te voldoen. Dit zijn de diensten, software of certificaten die nodig zijn om de jaarrekening met SBR te kunnen deponeren bij de KvK. De benodigde middelen zijn afhankelijk van de keuzes die gemaakt zijn in de voorgaande stappen.

Hieronder worden de verschillende scenario’s besproken voor het opstellen van deponeren van jaarrekeningen van micro- en kleine rechtspersonen enerzijds en middelgrote en grote rechtspersonen anderzijds. Per scenario wordt aangegeven wat hiervoor de benodigde middelen zijn.

Micro- en kleine rechtspersonen De volgende scenario’s zijn op basis van de voorgaande paragrafen te onderkennen:

Scenario Opstellen jaarrekening Deponeren jaarrekening Benodigde middelen

A. Uitbesteed aan intermediair Uitbesteed aan intermediair

Intermediair

B. Online service Zelf Deponeren Jaarrekening

Online service Zelf Deponeren Jaarrekening

Login KvK

C. Software met functionaliteit voor opstellen jaarrekening

Software met functionaliteit voor deponeren jaarrekening

Software (opstellen)Software (deponeren) Certificaat*

Tabel 2 – Benodigde middelen voor micro- en kleine rechtspersonen

Middelgrote en grote rechtspersonen De volgende scenario’s zijn op basis van de voorgaande paragrafen te onderkennen:

Scenario Opstellen jaarrekening Deponeren jaarrekening Benodigde middelen

D. Tool Opstellen XBRL Tool Opstellen XBRL Login KvK

E. Tool Opstellen XBRL Gefaciliteerd door accountant

Login KvK;Accountant

F. Software met functionaliteit voor opstellen jaarrekening (en eventueel preparer extension)

Software met functionaliteit voor deponeren jaarrekening

Software (opstellen);Software (PE); Software (deponeren);Certificaat

G. Software met functionaliteit voor opstellen jaarrekening

Tool Opstellen XBRL Software (opstellen);Software (PE); Login KvK

H. Software met functionaliteit voor opstellen jaarrekening (en eventueel preparer extension)

Gefaciliteerd door accountant

Software (opstellen);Software (PE); Accountant

29

I. Uitbesteed aan gespecialiseerde bolt-on dienstverlener

Tool Opstellen XBRL Bolt-on dienstverlener; Login KvK

J. Uitbesteed aan gespecialiseerde bolt-on dienstverlener

Bolt-on dienstverlener Bolt-on dienstverlener

K. Uitbesteed aan gespecialiseerde bolt-on dienstverlener

Gefaciliteerd door accountant

Bolt-on dienstverlener; Accountant

Tabel 3 – Benodigde middelen voor middelgrote en grote rechtspersonen

De benodigde middelen worden hieronder kort besproken:

Intermediair Wanneer u het voeren van uw administratie en opstellen van verantwoordingsrapportages heeft uitbesteed aan een intermediair, zal de intermediair ook het opstellen en deponeren van de jaarrekening bij de KvK voor u verzorgen.

Login KvK De ‘Login KvK’ is bedoeld om in te loggen bij de Kamer van Koophandel om gebruik te maken van de online service Zelf Deponeren Jaarrekening of tool Opstellen XBRL. Inloggen bij de KvK kan middels een KvK-account met autorisatie voor deponeren of een eHerkenningsmiddel van minimaal betrouwbaarheidsniveau 2 (EH2) of toegangscode gekoppeld aan de rechtspersoon waarvoor u deponeert. Een KvK-account kunt u gratis aanmaken. Voor het aanvragen van een eHerkenningsmiddel worden wel kosten in rekening gebracht; u kunt deze wel voor meerdere doeleinden gebruiken. Zie ook: https://www.kvk.nl/inlogpagina-jaarrekening-deponeren/

Software (opstellen) Met software met de functionaliteit voor het opstellen van een jaarrekening kunt u een jaarrekening in XBRL formaat opstellen. U moet deze software zelf aanschaffen. Deze software is meestal gericht op het opstellen van een jaarrekening op basis van de standaard taxonomie. Hiermee kunt u dus geen preparer extensie maken.

Software (PE) Met software met de functionaliteit voor het opstellen van een preparer extension kunt u de jaarrekening in XBRL formaat uitbreiden met eigen begrippen en relaties die niet zijn opgenomen in de standaard taxonomie. Deze functionaliteit is niet opgenomen in de tool Opstellen XBRL of in de online Service Zelf Deponeren Jaarrekening. Wanneer u hiervan gebruik wilt maken, moet u deze software zelf aanschaffen.

Software (deponeren) Met software met de functionaliteit voor het deponeren van een jaarrekening kunt u een jaarrekening in XBRL formaat (eventueel met preparer deponeren. U moet deze software zelf aanschaffen.

CertificaatDit is een PKIoverheid services certificaat. Het is afhankelijk van de geselecteerde software of u dit certificaat daadwerkelijk moet aanschaffen. PKIoverheid services certificaten kunnen worden aangeschaft bij een Trust Service Provider.

30

Accountant Uw accountant kan wellicht het deponeren van de jaarrekening voor u verzorgen. Het is verstandig hier afspraken over te maken en dit in de opdrachtbevestiging op te nemen. Het kan per accountant verschillen of aanvullende kosten in rekening worden gebracht voor het faciliteren van deze dienstverlening.

Bolt-on dienstverlener Wanneer u het opstellen van de jaarrekening wilt uitbesteden aan een gespecialiseerde bolt-on dienstverlener dient u een aanbieder te selecteren en hier een overeenkomst mee te sluiten. Aan deze dienstverlening zijn kosten verbonden.

31

5. Opstellen van de jaarrekening

Het opstellen van de jaarrekening valt onder de verantwoordelijkheid van u als ondernemer. Dit hoofdstuk gaat nader in op de wijze waarop een jaarrekening in de vorm van een XBRL instance document kan worden opgesteld met de KvK taxonomie en een eventuele preparer extension.

In de praktijk is een deel van de mogelijkheden die in dit hoofdstuk vermeld staan al gerealiseerd door de softwareleveranciers. Omdat dit per geval verschilt, worden alle inhoudelijke mogelijkheden voor de opsteller besproken in dit hoofdstuk.

Onderstaande stappenplan helpt u bij het opstellen van de jaarrekening in XBRL formaat.

Figuur 4 – Stappenplan opstellen van de jaarrekening

In de volgende paragrafen worden deze stappen nader uitgewerkt.

5.1 Selecteer het juiste entrypoint

De selectie van het juiste entrypoint in de KvK taxonomie is van groot belang voor de opsteller van de jaarrekening in XBRL formaat. Het geselecteerde entrypoint bepaalt immers welke rapportagemogelijkheden direct beschikbaar worden gesteld. De opsteller dient hierbij rekening te houden met de volgende aspecten die een impact kunnen hebben op de werkzaamheden van het opstellen van een jaarrekening in XBRL formaat:

1. Boekjaar 2. GAAP 3. Bedrijfsklasse 4. Publicatiestuk of inrichtingsstuk 5. Waarderingsgrondslagen 6. Beschikbare modellen 7. Beschikbare elementen

In de onderstaande paragrafen worden deze aspecten kort aangestipt.

32

5.1.1 Boekjaar

De wet- en regelgeving over jaarrekeningen wijzigt jaarlijks. Als gevolg van deze inhoudelijke aanpassingen wordt jaarlijks een nieuwe versie van de KvK taxonomie uitgebracht. In deze versie zijn dan de aanpassingen in de relevante wet- en regelgeving verwerkt, evenals de wijzigingen als gevolg van de introductie van nieuwe XBRL technieken. De wijzigingen in wet- en regelgeving die vanaf een bepaald boekjaar ingaan, zijn in de entrypoints voor dat betreffende jaar meegenomen.

Het is technisch mogelijk om een jaarrekening te deponeren op basis van een taxonomie bedoeld voor de jaarrekening over een voorgaand boekjaar. Logischerwijs zullen in deze taxonomie niet de recente wijzigingen in wet- en regelgeving meegenomen zijn. Het is daarom sterk aan te raden om altijd de taxonomie te hanteren die bestemd is voor het betreffende boekjaar.

5.1.2 GAAP

Een jaarrekening moet zijn opgesteld dat deze, volgens de normen die in het maatschappelijk verkeer als aanvaardbaar worden beschouwd, een zodanig inzicht geeft waarmee een verantwoord oordeel gevormd kan worden over het vermogen, resultaat en eventueel solvabiliteit en liquiditeit van de onderneming. In de Nederlandse situatie betekent dit meestal dat een jaarrekening dient te voldoen aan de wetgeving in titel 9 van het Burgerlijk Wetboek, Boek 2 (BW2) en aan de regelgeving in de Richtlijnen voor de Jaarverslaggeving (RJ). Deze combinatie wordt ook wel Dutch GAAP (NL-GAAP) genoemd. Het is echter ook mogelijk dat een onderneming ervoor kiest om, naast de wettelijke vereisten, te voldoen aan de regelgeving in de International Financial Reporting Standards (IFRS) zoals goedgekeurd door de Europese Commissie.

In de KvK taxonomie zijn entrypoints beschikbaar voor zowel NL-GAAP als IFRS.

5.1.3 Bedrijfsklasse

De keuze van de bedrijfsklasse is van groot belang bij het selecteren van het juiste entrypoint op basis van NL-GAAP. Op basis van de bedrijfsklasse zijn de bijbehorende wettelijke vrijstellingen toegepast in het entrypoint. Dit betekent bijvoorbeeld dat het entrypoint voor micro-rechtspersonen veel minder uitgebreid is dan die voor grote rechtspersonen, als gevolg van de van toepassing zijnde vrijstellingen voor micro-rechtspersonen.

De bedrijfsklassen ‘micro-rechtspersoon’, ‘kleine rechtspersoon’, ‘middelgrote rechtspersoon’ en ‘grote rechtspersoon’ zijn te onderkennen in de KvK taxonomie.

Tip: Controleer of de inhoud van een ‘hoger’ entrypoint niet beter past bij hetgeen u wilt rapporteren

Neem het volgende ook in overweging bij de selectie van het entrypoint: De selectie van het entrypoint hoeft zich niet te beperken tot de situatie die standaard voor u van toepassing is. Het is altijd toegestaan om een ‘hoger’ entrypoint te selecteren om de jaarrekening op te stellen.

In de entrypoints zijn de vrijstellingen op basis van de betreffende bedrijfsklasse toegepast. Als u een feit wil rapporteren waarvoor het betreffende concept niet in het geselecteerde entrypoint zit, kunt u voor een hoger entrypoint kiezen waarin dit element wel is opgenomen. Een voorbeeld hiervan is dat een element niet het entrypoint voor kleine rechtspersonen is opgenomen, maar bijvoorbeeld wel in het entrypoint voor middelgrote of grote rechtspersonen. In deze situatie is het wellicht een optie om een entrypoint te hanteren waarin het gewenste element wel beschikbaar is.

33

Het voordeel van deze mogelijkheid is dat dit u de moeite van het gebruik van een preparer extension bespaart om de gewenste jaarrekening in XBRL formaat te realiseren.

Het is niet toegestaan om ‘lagere’ entrypoints te hanteren voor het rapporteren van de jaarrekening.

5.1.4 Publicatiestuk of inrichtingsstuk

In paragraaf 4.2 is uitgebreid ingegaan op zowel de inrichtingsstukken als de publicatiestukken. Voor beiden zijn entrypoints beschikbaar in de KvK taxonomie. Het publicatiestuk bevat wel minder rapportagemogelijkheden dan het inrichtingsstuk als gevolg van de toepassing van de relevante vrijstellingen. Voor het opstellen van de jaarrekening is het van belang om te specificeren of het entrypoint van een inrichtingsstuk of publicatiestuk wordt gehanteerd. Het is toegestaan om in plaats van het entrypoint van een publicatiestuk het entrypoint voor een inrichtingsstuk te gebruiken; zelfs indien uitsluitend het publicatiestuk in XBRL wordt opgesteld.

Tip: Controleer of de inhoud van een inrichtingsstuk niet beter past bij hetgeen u wilt rapporteren

Net als bij een hogere bedrijfsklasse, kan in sommige gevallen ook het gebruik van het inrichtingsstuk nuttig zijn. Als u een feit wil rapporteren dat niet in het entrypoint van het publicatiestuk is opgenomen, maar wel in dat van het inrichtingsstuk, kunt u ervoor kiezen om het entrypoint van het inrichtingsstuk te hanteren als basis voor de jaarrekening in XBRL formaat.

Het voordeel is ook hier weer dat dit u de moeite van het gebruik van een preparer extension kan besparen.

5.1.5 Waarderingsgrondslagen

In alle NL-GAAP entrypoints is het mogelijk om op basis van commerciële waarderingsgrondslagen te rapporteren. Binnen NL-GAAP is echter ook de optie toegestaan om de jaarrekening op te stellen op basis van fiscale waarderingsgrondslagen. Deze mogelijkheid is alleen toegestaan voor micro- en kleine rechtspersonen. Zodoende is de mogelijkheid om op basis van fiscale waarderingsgrondslagen te rapporteren uitsluitend beschikbaar voor de entrypoints in de bedrijfsklassen ‘micro-rechtspersonen’ en ‘kleine rechtspersonen’.

5.1.6 Beschikbare modellen

De financiële overzichten in de jaarrekening, de balans, winst- en verliesrekening en het kasstroomoverzicht worden gekenmerkt door het gebruik van specifieke modellen. De keuze voor welk model u wilt gebruiken is medebepalend voor de selectie van het betreffende entrypoint in de KvK taxonomie. Hieronder wordt kort ingegaan op deze modellen.

Balans In het Besluit Modellen Jaarrekening (BMJ) is een aantal mogelijkheden beschikbaar voor het opstellen van de balans. Het primaire verschil zit tussen model A (ook wel horizontale model genoemd) en model B (ook wel verticale model genoemd). Dit verschil zit vooral in de presentatievolgorde van de verschillende onderdelen van de balans en een andere wijze van (sub)totalisering. Model C en model D zijn verkorte versies van de modellen A en B.

34

In de KvK taxonomie is voor een consistente modellering van de taxonomie gekozen voor de toepassing van de verkorte modellen van de balans. Dit betekent dat de nadere uitsplitsing van de betreffende posten in de toelichting zijn opgenomen in plaats van op de balans, met herhaling van de som.

Het verschil tussen de horizontale en verticale indeling van de balans is expliciet gemaakt door deze in verschillende entrypoints op te nemen. Het standaard model gaat uit van de horizontale indeling, aangezien deze het meest gebruikt is. De KvK taxonomie bevat echter ook entrypoints met de verticale indeling. Deze worden aangeduid door de term ‘verticaal’ in naam van het entrypoint.

Winst- en verliesrekening Net als voor de balans zijn in het Besluit Modellen Jaarrekening verschillende modellen opgenomen voor het opstellen van de winst- en verliesrekening. Hierbij is het mogelijk om te kiezen tussen een opstelling van de winst- en verliesrekening op basis van een categoriale of functionele indeling (modellen E en F van het BMJ respectievelijk). De categoriale indeling kenmerkt zich door het gebruik van kostencategorieën, zoals loonkosten, afschrijvingskosten, etc. De functionele indeling verdeelt de kosten naar hun functie, zoals kostprijs van de omzet, algemene beheerskosten en verkoopkosten. In de KvK taxonomie zijn zowel de categoriale en functionele indeling opgenomen in hetzelfde model, waardoor een entrypoint beide varianten ondersteunt.

In de KvK taxonomie zijn voor elke bedrijfsklasse wel de relevante vrijstellingen toegepast. Dit betekent voor de winst- en verliesrekening van de publicatiestukken van middelgrote rechtspersonen dat de verkorte modellen I en J zijn gehanteerd, waarin de brutomarge gesaldeerd is opgenomen.

Kasstroomoverzicht Richtlijn 360 van de Richtlijnen voor de Jaarverslaggeving gaat nader in op de verschillende onderdelen van het kasstroomoverzicht die u in een jaarrekening moet opnemen. Hierbij wordt ook onderscheid gemaakt tussen een directe methode en een indirecte methode van het opstellen van een kasstroomoverzicht.

In de KvK taxonomie zijn zowel de posten van de directe als indirecte methode opgenomen in hetzelfde model, waardoor een entrypoint beide varianten ondersteunt.

5.1.7 Beschikbare elementen

De keuze voor het juiste entrypoint is ook afhankelijk van de beschikbare elementen in het betreffende entrypoint. Het vaststellen welke elementen beschikbaar zijn in het entrypoint is het makkelijkste door gebruik te maken van de beschikbare presentatiestructuren, die de volgorde van de verschillende tabellen en de inhoud van de verschillende tabellen bepalen. Deze presentatiestructuren geven duidelijk weer welke elementen beschikbaar zijn en gebruikt kunnen worden in de jaarrekening.

De beschikbare elementen in het entrypoint kunt u gebruiken om te rapporteren met dit entrypoint. Indien andere elementen nodig zijn dan degene die beschikbaar zijn in het entrypoint, dan bestaat de mogelijkheid om een preparer extension op te stellen. Zie ook paragraaf 5.2 voor meer details hieromtrent.

Zoeken naar specifieke elementen Het is soms wenselijk om te bepalen of een specifiek element in een entrypoint is opgenomen. Dit kunt u doen op basis van de verwachte plaats in de jaarrekening. Het is eenvoudig om elementen te

35

lokaliseren als deze op een logische plaats zijn opgenomen in de presentatiestructuren van het entrypoint.

Als gevolg van de grote omvang van de inhoud van een entrypoint is het doorlopen van de beschikbare presentatiestructuren echter niet altijd een goede manier om vast te stellen of een element beschikbaar is in een entrypoint. Andere manieren zijn gebruikmaken van een zoekopdracht of het zoeken op een referentie naar wet- en regelgeving.

Het uitvoeren van een zoekopdracht kan via de meeste XBRL tools. Met een zoekopdracht kunt u zowel op de elementnaam als op de inhoud van een label of referentie zoeken naar een specifiek concept. Indien het element in de uitkomsten van de zoekopdracht naar voren komt, is het ook mogelijk om vast te stellen of, en zo ja waar, het element is opgenomen in (de presentatiestructuren van) het entrypoint.

Het gebruikmaken van de referenties is een andere manier om elementen te identificeren. De elementen in de KvK taxonomie zijn over het algemeen voorzien van een referentie naar de relevante wet- en regelgeving. Door het opzoeken van het relevante wetsartikel of richtlijn is het mogelijk het bijbehorende element te identificeren.

5.2 Maak eventueel een preparer extension

De relevantie van een preparer extension komt voort uit de flexibiliteit van de papier-georiënteerde jaarrekening. De papier-georiënteerde jaarrekening is zeer flexibel in de mogelijkheden om informatie te presenteren op basis van de van toepassing zijnde jaarverslaggevingsregels. Deze grote mate van flexibiliteit zorgt voor veel verschillende verschijningsvormen waarin informatie opgenomen kan worden in de jaarrekening.

De jaarrekening in XBRL formaat is gebaseerd op een gestandaardiseerd raamwerk van een jaarrekening dat is opgenomen in de KvK taxonomie. Deze standaardisatie leidt zodoende tot minder flexibiliteit. Het gestandaardiseerde raamwerk betreft logischerwijs geen volledige vertegenwoordiging van organisatie- of branche specifieke posten en toelichtingen die in jaarrekening toegepast kunnen worden. Dit komt omdat deze organisatie- of branche specifieke posten en toelichtingen niet altijd vooraf zijn te definiëren en op te nemen in de KvK taxonomie. Hier komt de rol van een preparer extension naar voren. Door toepassing van een preparer extension, kent de jaarrekening in XBRL formaat wel een bepaalde mate van flexibiliteit ten opzichte van het gestandaardiseerde raamwerk van de jaarrekening.

Een opsteller van de jaarrekening heeft de mogelijkheid om aanvullende begrippen – die niet in het entrypoint van de KvK taxonomie zijn opgenomen – toe te passen en om de presentatiestructuren van het entrypoint aan te passen. Dit soort wijzigingen noemen we een preparer extension. Van een preparer extension is sprake wanneer een opsteller concepten, definities of relaties toepast en/of wijzigt die niet beschikbaar zijn gesteld in het betreffende entrypoint van KvK taxonomie.

De specificatie van de toepassing van preparer extension is opgenomen in hoofdstuk 21. De technische wijze waarop een preparer extension gemaakt moet worden is opgenomen in hoofdstuk 10. Deze paragraaf probeert meer duiding te geven over de toepassing van een preparer extension voor de opstellers van een jaarrekening.

Hiervoor worden de volgende stappen voorzien:

36

1. Bepalen of een preparer extension nodig is; 2. Creëren van een preparer extension.

In de volgende paragrafen gaan we nader in op de bovenstaande stappen.

5.2.1 Bepalen of een preparer extension nodig is

Het is de vraag of de toepassing van een preparer extension altijd nodig is. Het kan soms ook een optie zijn om posten of meerdere afzonderlijke alinea’s van de toelichting samen te voegen als deze niet een op een te koppelen zijn aan concepten in de taxonomie. De consequentie hiervan kan wel zijn dat een rendering van de jaarrekening in XBRL formaat er anders uit kan zien dan een papier-georiënteerde jaarrekening, zoals de inrichtingsstukken.

De afwegingen wanneer u posten of toelichtingen wel samenvoegt en wanneer niet, wanneer u wel een preparer extension maakt en wanneer niet, zijn subjectief. Het is uiteindelijk aan u om hier een mening over te vormen.

In deze paragraaf geven we hiervoor enige handvaten voor het bepalen of het gebruik van een preparer extension nodig is voor het opstellen van een jaarrekening in XBRL formaat. Dit gebeurt via twee voorbeelden: Het eerste voorbeeld richt zich op de situatie waarin de KvK taxonomie een andere presentatiewijze en -volgorde hanteert dan de papier-georiënteerde jaarrekening.

Voorbeeld

De presentatiewijze en volgorde op basis van de KvK taxonomie wijkt af van de papier-georiënteerde jaarrekening

Situatiebeschrijving: In de papier-georiënteerde jaarrekening van ABV B.V. is de balans conform model B van het Besluit Modellen Jaarrekening gepresenteerd. De balans in het betreffende entrypoint van de KvK taxonomie gaat uit van het verkorte balansmodel D van het Besluit modellen jaarrekening. De nadere detaillering van de balansposten zoals deze in model B wordt gegeven is in de KvK taxonomie opgenomen in de vorm van uitsplitsingen welke in de toelichting op de jaarrekening zijn opgenomen. De papier-georiënteerde jaarrekening van ABC B.V. verschilt dus van de KvK taxonomie omdat de papier-georiënteerde jaarrekening de nadere detaillering van de balansposten in de balans opneemt.

Relevante wet- en regelgeving: Artikel 2:364 BW schrijft de hoofdindeling van de balans voor. Dit artikel beschrijft geen nadere detaillering anders dan de posten welke in de balansmodellen C en D van het Besluit modellen jaarrekening zijn opgenomen. Artikel 1 lid 1 van het Besluit modellen jaarrekening schrijft voor dat de balans moet zijn ingericht overeenkomstig model A of model B. Artikel 8 lid 1 van het Besluit geeft de mogelijkheid om de nadere detaillering van de ‘hoofdposten’ in de modellen A en B geheel of ten dele in de toelichting op te nemen in plaats van op de balans. De Richtlijnen voor de Jaarverslaggeving hebben het Besluit modellen jaarrekening als bijlage opgenomen en sluiten derhalve hierbij aan.

Oplossingsrichtingen: Om het verschil tussen de presentatiewijze en volgorde tussen de papier-georiënteerde jaarrekening en de jaarrekening in XBRL formaat op te lossen zijn twee opties te onderkennen.

37

De eerste optie is om de standaard presentatiestructuur van de KvK taxonomie te volgen waarin de uitsplitsing van de balansposten in de toelichting is opgenomen.

Voordelen van de eerste optie:

• Voor deze optie is geen preparer extension nodig;

• Deze optie sluit aan bij de gedachte van standaardisatie achter het gebruik van XBRL.

• Deze optie is op basis van wet- en regelgeving toegestaan. De relevante wet- en regelgeving geven de opsteller van de jaarrekening de mogelijkheid om te bepalen waar deze de nadere detaillering van de balansposten verantwoord in de jaarrekening.

Nadelen van de eerste optie:

• De jaarrekening in XBRL formaat wijkt, op het gebied van de presentatie van de balans, af van de papier-georiënteerde jaarrekening en hierdoor waarschijnlijk ook van de jaarrekening van voorgaand jaar. De nadere detaillering van de balans wordt verplaatst vanuit de balans naar de toelichting op de jaarrekening. Artikel 2:363 lid 4 BW geeft aan dat de indeling van de balans en de winst- en verliesrekening slechts wegens gegronde redenen mag afwijken van die van het voorafgaande jaar.

De tweede optie is om de presentatiewijze en volgorde van de KvK taxonomie aan te passen met behulp van een preparer extension zodat deze overeenkomt met de presentatiewijze en volgorde van de papier-georiënteerde jaarrekening. Hiervoor moeten de volgende wijzigingen in de KvK taxonomie middels een preparer extension gerealiseerd worden:

1. Aanvullen van het huidige verkorte balansmodel middels het toevoegen van de concepten welke de nadere detaillering van de balansposten betreft.

2. Verwijderen van de uitsplitsing van de balansposten in de toelichting op de jaarrekening door deze uit te zetten voor presentatie-doeleinden.

Voordelen van de tweede optie:

• De jaarrekening in XBRL formaat komt, op het gebied van de presentatie van de balans, geheel overeen met de papier-georiënteerde jaarrekening en de jaarrekening van voorgaand jaar. Hierdoor hoeft geen acht geslagen te worden op artikel 2:363 lid 4 BW.

Nadelen van de tweede optie: • De toepassing van een preparer extension kost tijd en inspanning.

In het bovenstaande voorbeeld moet de opsteller op basis van de voor-en nadelen een afweging maken of het beter is om aan te sluiten bij de standaard presentatiewijze van de KvK taxonomie of om toch een preparer extension te maken.

Het tweede voorbeeld richt zich op de situatie dat de papier-georiënteerde jaarrekening een of meer posten en/of toelichtingen bevat die niet beschikbaar zijn in het betreffende entrypoint van de KvK taxonomie.

Voorbeeld

De papieren jaarrekening bevat een of meer posten en/of toelichtingen die niet beschikbaar zijn in de KvK taxonomie

Situatiebeschrijving:

38

In de toelichting op de geconsolideerde jaarrekening van DEF B.V. wordt een uitsplitsing van de post ‘Overige vorderingen’ gepresenteerd in de vorm van een tabel, bestaande uit de posten: ‘Nog te ontvangen bedragen’, ‘Vooruitbetaalde bedragen’ en ‘Overige’. Zowel de uitsplitsing van ‘Overige vorderingen’ als de drie posten van deze uitsplitsing zijn niet beschikbaar in de KvK taxonomie.

Relevante wet- en regelgeving: Omtrent de tot de vlottende activa behorende vorderingen benoemd artikel 2:370 lid 1 BW een aantal vorderingen welke afzonderlijk opgenomen dienen te worden, waarbij de posten: ‘Nog te ontvangen bedragen’ en ‘Vooruitbetaalde bedragen’ niet worden onderkent. De papier-georiënteerde jaarrekening van DEF B.V. verstrekt dus meer informatie welke niet expliciet is vereist volgens wet- en regelgeving. In het kader van dit voorbeeld zijn wellicht ook RJ222 ‘Vorderingen’ en RJ224 ‘Overlopende Activa’ relevant. RJ 222:307 geeft aan dat vooruitbetalingen op diensten onder overige vorderingen of onder overlopende activa opgenomen kunnen worden. RJ 224:102 geeft aan dat vooruitbetaalde bedragen voor kosten die ten laste van de volgende periode komen en nog te ontvangen bedragen wegens bate ten gunste van de voorgaande periode komen overlopende actief posten kunnen zijn. RJ 224:105 beveelt aan om overlopende actiefposten alleen afzonderlijk in de balans op te nemen indien het bedrag ervan van voldoende belang is en in andere gevallen het bedrag samen te voegen met de overige vorderingen. Hierbij verwijst RJ 224:105 naar RJ 115 ‘Criteria voor opname en vermelding van gegevens’ paragraaf 2. RJ 115:214 geeft als indicaties voor de grootte van de criteria voor opname in de balans een minimum van 5% van de balanstelling of 10% van de rubriek waartoe de post behoort. Stel de posten waarnaar de overige vorderingen zijn uitgesplitst voldoen niet aan deze groottecriteria. Hierdoor is de noodzaak tot opname van deze posten vanuit het gestelde in artikel 2:362 lid 1 niet direct af te leiden.

Oplossingsrichtingen: Er zijn in dit geval een viertal oplossingsrichtingen te onderkennen.

De eerste optie is om de uitsplitsingstabel van overige vorderingen in de KvK taxonomie verder uit te breiden met behulp van een preparer extension. Er dienen een drietal nieuwe, organisatie-specifieke elementen te worden gedefinieerd en gekoppeld te worden aan het bestaande element van de post ‘overige vorderingen’. Hierdoor wordt de bestaande tabel in de toelichting dus verder uitgebreid.

Voordelen:

• De jaarrekening in XBRL formaat komt, op het gebied van de presentatie van de uitsplitsing van overige vorderingen, geheel overeen met de papier-georiënteerde jaarrekening;

• Met deze optie wordt de tagging op het hoogste granulaire niveau toegepast, aangezien elk bedrag een apart element is in de jaarrekening in XBRL formaat. Dit komt de bruikbaarheid van deze informatie ten goede en sluit derhalve aan bij de gewenste toepassing van XBRL.

Nadelen:

• De toepassing van een preparer extension is een intensief proces is, zoals al eerder in het eerste voorbeeld is aangegeven;

• Deze optie sluit wellicht niet aan bij de gedachte van standaardisatie die achter het gebruik van XBRL ligt.

39

• De noodzaak tot opname van deze posten is vanuit het gestelde in artikel 2:362 lid 1 niet direct af te leiden.

De tweede optie is om deze bedragen middels tekstopmaak (een tabel in HTML opmaak) toe te lichten in het tekstuele toelichtingsveld van de overige vorderingen.

Voordelen:

• De jaarrekening in XBRL formaat komt, op het gebied van de presentatie van de uitsplitsing van overige vorderingen, overeen met de papier-georiënteerde jaarrekening.

• Voor deze optie is geen preparer extension nodig

Nadelen:

• De bedragen van de drie posten in de uitsplitsing zijn niet als apart element beschikbaar, maar samengevoegd met tekstuele elementen binnen één toelichtingsveld. Dit gaat wellicht ten koste van de bruikbaarheid van deze informatie.

De derde optie is om deze bedragen tekstueel toe te lichten in de beschikbare tekstuele toelichtingsvelden van de overige vorderingen.

Voordelen:

• Voor deze optie is geen preparer extension nodig.

Nadelen:

• De bedragen van de drie posten in de uitsplitsing zijn niet als apart element beschikbaar, maar samengevoegd met tekstuele elementen binnen één toelichtingsveld. Dit gaat wellicht ten koste van de bruikbaarheid van deze informatie.

• De jaarrekening in XBRL formaat komt, op het gebied van de presentatie van de uitsplitsing van overige vorderingen, niet overeen met de papier-georiënteerde jaarrekening.

De vierde optie is om deze bedragen niet langer toe te lichten, aangezien het rapporteren over deze posten, gezien de omvang ervan, niet wordt vereist vanuit de wet- en regelgeving.

Voordelen:

• Voor deze optie is geen preparer extension nodig.

Nadelen:

• De informatiewaarde van de jaarrekening is lager dan voorgaand jaar, aangezien er minder feiten worden gerapporteerd;

• De jaarrekening in XBRL formaat komt, op het gebied van de presentatie van de uitsplitsing van overige vorderingen, niet overeen met de papier-georiënteerde jaarrekening

In het bovenstaande voorbeeld moet de opsteller van de jaarrekening op basis van de voor-en nadelen een afweging maken wat de beste optie is.

Het punt dat de bovenstaande voorbeelden probeert te maken is dat toepassing van een preparer extension niet altijd nodig is. Een preparer extension kan onnodig afbreuk doen aan de wenselijke standaardisatie van de jaarrekening. Daarnaast is het ook van belang rekening te houden met de

40

bruikbaarheid van de informatie in de jaarrekening in XBRL formaat. Het klopt in principe dat hoe meer details individueel worden getagged hoe (geautomatiseerd) bruikbaarder de informatie is. De vraag is wel of deze mate van detail op dit moment al relevant is.

Beide voorbeelden geven duidelijk weer dat het bepalen van de noodzaak voor een preparer extension een subjectief proces is. De opsteller van de jaarrekening doet er ook goed aan om de mening te polsen van de controlerend accountant over de noodzaak om een preparer extension toe te passen. Hiermee wordt vermeden dat de oplossingsrichting van de opsteller niet overeenkomt met de opvattingen van de controlerend accountant.

5.2.2 Creëren van een preparer extension

Het creëren van een preparer extension gebeurt via software. De exacte werking van de betreffende software verschilt van geval tot geval. Er zijn verschillende mogelijkheden te onderkennen wat een opsteller kan bereiken met een preparer extension, ongeacht de gebruikte software. In deze paragraaf gaan we kort in op deze mogelijkheden die een preparer extension faciliteert.

De volgende mogelijkheden zijn te onderkennen met een preparer extension: 1. Elementen toevoegen 2. Presentatievolgorde wijzigen 3. Organisatie- of branche-specifieke labels toevoegen 4. Afbeeldingen toevoegen

1. Elementen toevoegen Indien een opsteller informatie wil opnemen in haar jaarrekening in XBRL formaat waarvoor in het geselecteerde entrypoint geen elementen beschikbaar zijn, kan zij dit bewerkstelligen met behulp van een preparer extension. Hiervoor zijn twee opties mogelijk:

a. Bestaande elementen toevoegen b. Nieuwe elementen toevoegen

a. Bestaande elementen toevoegen Van bestaande elementen toevoegen is sprake wanneer een opsteller elementen wil gebruiken die wel gedefinieerd zijn in de taxonomie, maar niet zijn toegekend aan het geselecteerde entrypoint.

Voorbeeld

Stel een opsteller wil in de jaarrekening in XBRL formaat de post ‘Terreinen en gebouwen in eigen gebruik’ afzonderlijk verantwoorden onder de materiële vaste activa. De taxonomie bevat hiervoor al een element, maar deze is niet gekoppeld aan het door de opsteller geselecteerde entrypoint. De opsteller kan met behulp van een preparer extension dit element opnemen in de gehanteerde rapportagestructuur.

Het voordeel van het gebruik van bestaande elementen is dat de opsteller minder werk heeft aan het toevoegen van de gewenste elementen aan de rapportagestructuur. Het gewenste element bestaat immers al en hoeft dus niet gedefinieerd te worden, wat wel het geval is bij het toevoegen van nieuwe elementen.

b. Nieuwe elementen toevoegen

41

Van nieuwe elementen toevoegen is sprake wanneer een opsteller elementen wil gebruiken die nergens gedefinieerd zijn in de taxonomie.

Voorbeeld

Stel een opsteller wil in de jaarrekening in XBRL-formaat de post ‘Vliegtuigen’ afzonderlijk verantwoorden onder de materiële vaste activa. De taxonomie bevat hiervoor echter geen element. De opsteller zal dit element met behulp van een preparer extension moeten definiëren en vervolgens opnemen in de gehanteerde rapportagestructuur.

De mogelijkheid om nieuwe elementen toe te voegen biedt de opsteller veel flexibiliteit. Elk nieuw element moet echter wel gedefinieerd worden door de opsteller. Dit betekent in de praktijk dat de opsteller voor elk element een aantal zaken moet opgeven, waaronder de unieke technische naam van het element (elementnaam en namespace), de naam van de post die getoond moet worden in de rendering (label), een beschrijving van het element (documentation label), het soort element (datatype) en een koppeling van het nieuwe element naar een bestaand element uit de taxonomie waar het een verbijzondering van is (definition link).

Nadat het element gedefinieerd is, moet dit ook nog worden toegevoegd aan de rapportagestructuur. De meeste software zal de opsteller hierbij actief ondersteunen.

2. Presentatievolgorde wijzigen De taxonomie bevat informatie die de presentatievolgorde bepaalt bij het renderen van de jaarrekening in XBRL formaat. Wanneer de opsteller wil afwijken van deze presentatievolgorde is dit mogelijk door gebruik te maken van een preparer extension. Hiervoor zijn twee opties mogelijk:

a. Presentatievolgorde wijzigen binnen onderdelen van de jaarrekening b. Presentatievolgorde wijzigen tussen onderdelen van de jaarrekening

a. Presentatievolgorde wijzigen binnen onderdelen van de jaarrekening Het is mogelijk om de volgorde van elementen te wijzigen binnen een onderdeel van de jaarrekening. Hierbij is een onderdeel te zien als een op zichzelf staande sectie binnen de jaarrekening, zoals de balans, de toelichting op de materiële vaste activa of de niet uit de balans blijkende verplichtingen. Een voorbeeld van een wijziging van de presentatievolgorde binnen een onderdeel is wanneer volgorde van de posten in de uitsplitsing van de materiële vaste activa worden veranderd.

b. Presentatievolgorde wijzigen tussen onderdelen van de jaarrekening Het is ook mogelijk om de volgorde van onderdelen te wijzigen binnen de jaarrekening. Een voorbeeld van een wijziging van de presentatievolgorde tussen onderdelen is wanneer de volgorde van de verschillende onderdelen van de toelichting op de balans worden aangepast zodat deze overeenkomt met de gewijzigde volgorde in het balansmodel.

3. Organisatie- of branche-specifieke labels toevoegen Elk element in de taxonomie heeft een label. Het label is de voor de mens bekende naam van een bedrag of toelichting die in de jaarrekening wordt getoond. Een voorbeeld is het label ‘Vorderingen op handelsdebiteuren’. Indien de opsteller een element wil hanteren, maar wel met een iets andere woordkeuze dan het bestaande label, is dit mogelijk met een preparer extension. Hiervoor moet de opsteller een organisatie- of branche-specifiek label toevoegen aan het element en deze aanroepen in de presentatiestructuur. Hierdoor wordt het betreffende label getoond in de rendering van de jaarrekening in XBRL formaat. Het is hierbij van groot belang dat de definitie van het element

42

(vormgegeven in het documentation label) geen geweld wordt aangedaan. In ons voorbeeld kan ‘Handelsvorderingen’ als een organisatie-specifiek label worden toegevoegd.

4. Afbeeldingen toevoegen Het is technisch mogelijk om met behulp van een preparer extension afbeeldingen toe te voegen aan de jaarrekening in XBRL formaat. Afbeeldingen in de vorm van grafieken en foto’s moeten alleen worden toegevoegd wanneer deze ten behoeve van het verschaffen van grafisch inzicht of uitleg essentieel zijn voor het beeld van de jaarrekening.

5.3 Voer de gegevens in

Voor het opstellen van een jaarrekening in XBRL formaat gebruikt u software. Via deze software kunnen gegevens opgenomen worden in de jaarrekening. Het opnemen van de gegevens kan op verschillende manieren plaatsvinden. In de basis zijn er drie manieren: 1) via een automatische koppeling vanuit een andere bron; 2) via handmatige invoer; of 3) een combinatie van 1 en 2.

Een (groot) deel van de gegevens uit de jaarrekening vindt hun oorsprong in een (financiële) administratie of andersoortig bronbestand. Sommige software bevat een koppeling met een dergelijke bronadministratie, of heeft de mogelijkheid om hiermee een koppeling te maken. Via deze koppeling en een mapping tussen de gegevens in de bronadministratie naar de betreffende elementen in de KvK taxonomie, kunnen gegevens automatisch worden opgenomen in de jaarrekening in XBRL formaat. Sommige software heeft een dergelijke mapping al gefaciliteerd voor haar klanten, terwijl andere software juist de mogelijkheid hiervoor aan de opsteller laat.

Een (gedeeltelijke) handmatige invoer is een andere wijze om gegevens van de jaarrekening in te voeren. Deze handmatige invoer kan bijvoorbeeld plaatsvinden via een online portaal of andersoortige applicatie. Deze variant wordt veel gebruikt voor het opstellen van tekstuele toelichtingen, maar kan eventueel ook worden toegepast voor de numerieke waardes. Hierbij voert u de gegevens uit een bronadministratie handmatig in.

Bij het invoeren van gegevens moet u rekening houden met de volgende onderwerpen.

5.3.1 Taal van de jaarrekening

Op basis van artikel 2:394 lid 1 BW mag een jaarrekening in vier talen worden gedeponeerd de Kamer van Koophandel: in het Nederlands, Engels, Frans of Duits. De jaarrekening in XBRL formaat kan in een van deze vier talen worden opgesteld. Bij een deel van de beschikbare software voor het opstellen van de jaarrekening is het mogelijk om expliciet aan te geven in welke taal de jaarrekening in XBRL formaat is opgesteld.

5.3.2 Gebroken boekjaren

Het is mogelijk om een jaarrekening in XBRL formaat op te stellen over gebroken boekjaren. De begin- en einddatum van zowel de huidige als voorgaande periode geeft u op via de volgende concepten:

• Startdatum van de huidige financiële rapportageperiode

43

• Einddatum van de huidige financiële rapportageperiode

• Startdatum van de voorgaande financiële rapportageperiode

• Einddatum van de voorgaande financiële rapportageperiode

Voorbeeld

Een gebroken boekjaar (dat bijvoorbeeld loopt van juli tot en met juni) geeft u als volgt aan:

Startdatum van de huidige financiële rapportageperiode: 1 juli 2017 Einddatum van de huidige financiële rapportageperiode: 30 juni 2018 Startdatum van de voorgaande financiële rapportageperiode: 1 juli 2016 Einddatum van de voorgaande financiële rapportageperiode: 30 juni 2017

5.3.3 Verlengde of verkorte boekjaren

Het is mogelijk om een jaarrekening in XBRL formaat op te stellen over verlengde of verkorte boekjaren. De begin- en einddatum van zowel de huidige als voorgaande periode geeft u aan via de volgende concepten:

• Startdatum van de huidige financiële rapportageperiode

• Einddatum van de huidige financiële rapportageperiode

• Startdatum van de voorgaande financiële rapportageperiode

• Einddatum van de voorgaande financiële rapportageperiode

Voorbeeld

Een verlengd boekjaar in het voorafgaande jaar (van 24 december 2015 tot en met 31 december 2016) geeft u als volgt aan:

Startdatum van de huidige financiële rapportageperiode: 1 januari 2017 Einddatum van de huidige financiële rapportageperiode: 31 december 2017 Startdatum van de voorgaande financiële rapportageperiode: 24 december 2015 Einddatum van de voorgaande financiële rapportageperiode: 31 december 2016

Een verkort boekjaar in het voorafgaande jaar (van 24 januari 2016 tot en met 31 december 2016) kunt u als volgt aangeven:

Startdatum van de huidige financiële rapportageperiode: 1 januari 2017 Einddatum van de huidige financiële rapportageperiode: 31 december 2017 Startdatum van de voorgaande financiële rapportageperiode: 24 januari 2016 Einddatum van de voorgaande financiële rapportageperiode: 31 december 2016

5.3.4 Meer dan één valuta in de jaarrekening

Een jaarrekening kan slechts in één valuta worden opgesteld. Dit houdt in dat alle bedragen en van bedragen afgeleide meeteenheden in de jaarrekening dezelfde valuta moeten hebben. Als u wilt toelichten wat de waarde van een bepaalde post is in een andere valuta, moet u deze informatie in een tekstuele toelichting opnemen in de jaarrekening in XBRL formaat.

44

5.3.5 Vergelijkende cijfers

In de jaarrekening in XBRL formaat moet u ook vergelijkende cijfers opnemen als dat van toepassing is. Deze cijfers kunt u meestal in aparte velden in een tabel invullen. In het geval bedragen voorkomen in een tekstuele toelichting, kunnen hier desgewenst ook vergelijkende cijfers worden toegevoegd.

Voorbeeld

Stel in de toelichting is de volgende tekst opgenomen, waarbij het opnemen van vergelijkende cijfers ook gewenst is:

Onder post XYZ is in 2017 een bedrag van € 1.330.000 (2016: 1.299.000) opgenomen ten behoeve van doel ABC.

5.3.6 Afrondingen

Veel jaarrekeningen ronden de gerapporteerde bedragen af naar duizendtallen of naar miljoenen. Het opnemen van afgeronde bedragen is in een jaarrekening in XBRL formaat ook mogelijk. Het is echter technisch niet mogelijk om een verkorte versie van een bedrag te tonen op basis van de afronding. Oftewel het is niet mogelijk om het afgeronde bedrag van € 6.000.000,- op te nemen in de jaarrekening als € 6 en dan aan te geven dat dit in miljoenen euro’s is.

Voor alle numerieke waardes dient u de waarde in te vullen in hele eenheden in het instance document. Deze waardes mogen eventueel afgerond zijn, aangezien u altijd zelf de wijze van afronding bepaalt.

Bij sommige software kunt u aangeven op welk niveau u de opgenomen cijfers heeft afgerond. Hiervoor wordt in XBRL het decimals attribuut gebruikt, waarmee meer informatie kan worden geven omtrent de accuratesse van numerieke feiten. De mogelijke waardes van dit attribuut variëren per situatie. In de onderstaande tabel zijn de toegestane waarden van het @decimals voor bedragen gedefinieerd:

Accuratesse van het gerapporteerde feit Waarde van het @decimals

Exact bedrag INF

Bedrag nauwkeurig in miljarden -9

Bedrag nauwkeurig in miljoenen -6

Bedrag nauwkeurig in duizenden -3

Bedrag nauwkeurig in eenheden 0

Bedrag nauwkeurig in centen 2

Tabel 4 - Toegestane waarde van het @decimals

Voorbeeld

Stel het exact te rapporteren bedrag is € 1.329.912,- en u wilt dit afronden. U moet dit bedrag dan als volgt opnemen in de jaarrekening in XBRL formaat:

Afgerond op: hele eenheden : € 1329912 met @decimal=“0” of “INF” duizendtallen : € 1330000 met @decimal=“-3”

45

miljoenen : € 1000000 met @decimal=“-6”

In het geval bedragen opgenomen zijn in een tekstuele toelichting, dienen deze bedragen op dezelfde wijze opgenomen te worden als dat ze apart gerapporteerd worden. Het is niet wenselijk om bedragen af te korten in een tekstuele toelichting, aangezien dit de leesbaarheid van de informatie vermindert.

Voorbeeld

Stel in de toelichting is de volgende tekst opgenomen en de financiële overzichten zijn afgerond naar duizendtallen:

Onder post XYZ is in 2017 een bedrag van € 1.330.000 opgenomen ten behoeve van doel ABC.

5.3.7 Mintekens

Bij het invoeren van numerieke gegevens in de jaarrekening in XBRL formaat kunt u het minteken gebruiken om aan te geven dat de waarde van dit concept negatief is. De KvK taxonomie is zodanig ontworpen dat in de meeste gevallen een positief bedrag ingevuld moet worden. Hierdoor kan het gebruik van het minteken beperkt worden tot die situaties die afwijken van de reguliere situatie.

5.3.8 Granulariteit van tekstuele toelichtingen

Onder granulariteit wordt verstaan de mate van fijnmazigheid (of aggregatieniveau, mate van detaillering) waarop feiten kunnen worden gerapporteerd in de jaarrekening. Er zijn verschillende methodes om de gewenste granulariteit mee te geven aan de tekstuele toelichtingen. Hierbij dienen deze toelichtingen echter wel zodanig te worden opgesplitst, dat informatie op een reëel granulair niveau beschikbaar komt.

Het uitgangspunt is dat indien een presentatie of toelichtingsvereiste expliciet naar voren komt in de relevante wet- en regelgeving, dit ook apart in de jaarrekening in XBRL formaat opgenomen moet kunnen worden. Tegelijkertijd zijn er generieke concepten beschikbaar indien een specifiek concept niet afdoende is. Deze generieke concepten zijn een “catch-all” methode om te zorgen dat u alle gewenste informatie kunt opnemen in de jaarrekening in XBRL formaat. Hierbij is het niet de bedoeling dat informatie waarvoor specifieke concepten beschikbaar zijn in de generieke concepten worden opgenomen, aangezien dit de vergelijkbaarheid vermindert.

De term ‘granulariteit’ wordt nader toegelicht aan de hand van een eenvoudig voorbeeld van de grondslag van immateriële vaste activa. In het eerste voorbeeld is de gehele grondslag – inclusief alle sub-grondslagen – in één concept opgenomen. In dit geval acteert het concept ‘Grondslag van materiële vaste activa’ als een generiek concept.

Voorbeeld

Concept Tekst in de jaarrekening in XBRL formaat

Grondslag van immateriële vaste activa

De immateriële vaste activa zijn gewaardeerd tegen verkrijgingsprijs onder aftrek van afschrijvingen. Er wordt rekening gehouden met bijzondere waardeverminderingen.

46

Kosten van ontwikkelingUitgaven voor ontwikkelingsprojecten worden geactiveerd als onderdeel van de vervaardigingsprijs als het waarschijnlijk is dat het project commercieel en technisch succesvol zal zijn en de kosten betrouwbaar kunnen worden vastgesteld. De afschrijving van de geactiveerde ontwikkelingskosten vangt aan zodra de commerciële productie is gestart en vindt plaats over de verwachte toekomstige gebruiksduur van het actief.

Goodwill Goodwill voortkomend uit acquisities wordt geactiveerd en lineair afgeschreven gedurende de geschatte toekomstige gebruiksduur

In het eerste voorbeeld zijn de sub-grondslagen voor ‘Kosten van ontwikkeling’ en ‘Goodwill” niet apart opgenomen, maar onder de generieke grondslag van immateriële vaste activa geplaatst. In het tweede voorbeeld hieronder zijn deze sub-grondslagen wel in aparte concepten opgenomen.

Voorbeeld

Concept Tekst in de jaarrekening in XBRL formaat

Grondslag van immateriële vaste activa

De immateriële vaste activa zijn gewaardeerd tegen verkrijgingsprijs onder aftrek van afschrijvingen. Er wordt rekening gehouden met bijzondere waardeverminderingen.

Grondslag van kosten van ontwikkeling

Uitgaven voor ontwikkelingsprojecten worden geactiveerd als onderdeel van de vervaardigingsprijs als het waarschijnlijk is dat het project commercieel en technisch succesvol zal zijn en de kosten betrouwbaar kunnen worden vastgesteld. De afschrijving van de geactiveerde ontwikkelingskosten vangt aan zodra de commerciële productie is gestart en vindt plaats over de verwachte toekomstige gebruiksduur van het actief.

Grondslag van goodwill Goodwill voortkomend uit acquisities wordt geactiveerd en lineair afgeschreven gedurende de geschatte toekomstige gebruiksduur

In het tweede voorbeeld is sprake van een hogere mate van granulariteit dan in het eerste voorbeeld. Dit geeft aan dat hoe meer granulair (of fijnmaziger) de toelichting is opgenomen, des te nauwkeuriger de informatie verwerkt kan worden.

5.3.9 Accountantsverklaring bij de jaarrekening

Als een accountant de jaarrekening in XBRL formaat controleert, wordt ook een accountantsverklaring afgegeven. Deze accountantsverklaring is een apart XBRL instance document en maakt zodoende geen deel uit van de overige gegevens. In de overige gegevens moet dit in het concept ‘Verwijzing naar de accountantsverklaring’ worden opgenomen. In het onderstaande voorbeeld is de tekst opgenomen die door de NBA wordt aangeraden om te hanteren in de jaarrekening in XBRL formaat bij het verwijzen naar de accountantsverklaring.

47

Voorbeeld

De bij de jaarrekening verstrekte controleverklaring is hierbij separaat verstrekt.

5.4 Genereer en valideer het XBRL instance document

Een jaarrekening in XBRL formaat wordt vastgelegd in een XBRL instance document. Een XBRL instance document is een bestand dat door de computer kan worden verwerkt. Het bevat de gegevens van de jaarrekening in de vorm van zogenaamde ‘tags’ die verwijzen naar concepten en andere elementen uit de KvK taxonomie. Deze gegevens bestaan uit de feiten die gerapporteerd worden, evenals de contextuele gegevens die benodigd zijn om de feiten op een gestructureerde en consistente wijze te kunnen interpreteren.

Het genereren van een XBRL instance document is een activiteit die over het algemeen onder de motorkap van de software plaatsvindt nadat u de relevante gegevens hebt ingevoerd. In deze paragraaf gaan we niet nader in op de technische aspecten van genereren van het instance document. Hiervoor verwijzen we u naar hoofdstuk 9 in het deel van de softwareontwikkelaars.

De gehanteerde software draagt over het algemeen zorg voor de technische validiteit van het XBRL instance document gedurende het generatieproces. Zodoende wordt in deze paragraaf niet ingegaan op de technische validiteit van het instance document ten opzichte van de van toepassing zijnde XBRL specificatie(s), de SBR Filing Rules en eventueel aanvullende regels die zijn opgesteld door de Kamer van Koophandel.

Na het genereren van het XBRL instance document is het wel verstandig als u de uitkomsten naloopt van de business rules validatie. De business rules hebben tot doel om de inhoud van een jaarrekening, zoals opgenomen in het XBRL instance document, te controleren ten opzichte van vooraf gedefinieerde validatieregels. Deze validatieregels zijn in de vorm van XBRL formulas opgenomen in het geselecteerde entrypoint van de KvK taxonomie. Voor meer informatie over de business rules verwijzen wij u naar de Informatiegids voor de KvK taxonomie.

De meeste validatieregels worden op dit moment niet ‘hard’ afgedwongen in de KvK taxonomie. Het zijn zodoende vooral waarschuwingen en geen fouten. Dat is bewust gedaan zodat het proces van deponeren niet onnodig verzwaard wordt. Het opnemen van de business rules in de taxonomie, ondanks dat deze niet worden afgedwongen, waarschuwt u wel over mogelijk onjuiste invoer tijdens het proces van opstellen. Het doornemen van de uitkomsten en het verhelpen van de terechte meldingen verhoogt zodoende de kwaliteit van de informatie in de jaarrekening.

Een deel van de software gebruikt de in de taxonomie opgenomen validatieregels ook als basis voor invoercontroles tijdens het invoeren van de gegevens.

5.5 Render het XBRL instance document t.b.v. review

Het XBRL instance document is een technisch document bedoeld voor verwerking door computers. Het renderen van het XBRL instance document maakt de jaarrekening in XBRL formaat dus leesbaar voor mensen. Dit renderen kan op verschillende manieren, maar het meest zuiver is om dit te doen aan de hand van de Consistente Presentatie. Met de Consistente Presentatie wordt een instance

48

document op een consistente manier leesbaar gemaakt, ongeacht de gehanteerde software. Zie ook hoofdstuk 22 voor een inhoudelijke beschrijving van de Consistente Presentatie specificatie.

Op basis van de rendering kunt u een inhoudelijke review van het document uitvoeren om vast te stellen of de invoer van de gegevens heeft geleid tot het gewenste resultaat. Indien er onjuistheden in de jaarrekening in XBRL formaat zijn opgenomen, kunt u deze aanpassen. Deze reviewslag kan niet afgedwongen worden door de techniek, maar het uitvoeren hiervan leidt vaak wel tot het identificeren van onjuistheden in de jaarrekening in XBRL formaat die niet eerder zijn opgemerkt.

Het bestuur van de rechtspersoon is verantwoordelijk voor het opstellen van de jaarrekening. Dit geldt dus ook voor de jaarrekening in XBRL formaat, ongeacht of het instance document door een derde partij wordt opgesteld of gefaciliteerd. Dit betekent dat een rechtspersoon een proces in dient te richten waarbij het zich ervan verzekert dat de jaarrekening in XBRL formaat inderdaad de jaarrekening is die zij beoogt te deponeren. Enkele voorbeelden van zaken waar de rechtspersoon naar kan kijken in dit proces zijn:

• Geschiktheid van het geselecteerde entrypoint: Het geselecteerde entrypoint in de jaarrekening in XBRL formaat dient bij de aard van de rechtspersoon te passen. Zo is bijvoorbeeld een klein entrypoint niet geschikt voor een middelgroot rechtspersoon of is een entrypoint bestaande uit de wet- en regelgeving van het jaar 2016 niet per se geschikt voor een jaarrekening over het jaar 2017.

• Juistheid en volledigheid van de inhoud: In de jaarrekening in XBRL formaat dient informatie omtrent de financiële situatie van de rechtspersoon volledig en juist te zijn opgenomen.

• Juistheid en volledigheid van de ‘tags’: De informatie in de jaarrekening in XBRL formaat zijn juist en volledig opgenomen in de daarvoor geschikte ‘tags’.

• Geschiktheid van een preparer extension: Indien een preparer extension is toegepast, moet worden vastgesteld of het gebruik hiervan echt noodzakelijk is voor het te geven inzicht door de jaarrekening in XBRL formaat.

5.6 Stuur de jaarrekening in XBRL formaat naar uw accountant voor de

accountantscontrole

Na de review van de gerenderde versie van de jaarrekening in XBRL formaat – en eventuele aanpassingen die hieruit volgden – is het gereed voor de laatste stap in het proces van het opstellen van de jaarrekening. Indien u de jaarrekening wilt controleren door een accountant of als dit verplicht is, kunt u de jaarrekening in XBRL formaat doorzetten naar de controlerend accountant. Dit kan via e-mail of specifieke portaaloplossingen van de accountant.

Aangezien dit proces conceptueel niet anders loopt dan met de papier-georiënteerde jaarrekening, gaan we hier niet verder op in.

5.7 Veelgestelde vragen en antwoorden omtrent het opstellen van de jaarrekening

Is de KvK taxonomie een checklist of stelsel van verslaggeving? De KvK taxonomie is een representatie van de relevante wet- en regelgeving rond financiële verslaggeving die in Nederland van toepassing is voor het deponeren van een jaarrekening bij de Kamer van Koophandel. De KvK taxonomie maakt het mogelijk om te rapporteren in lijn met deze

49

wet- en regelgeving, maar dwingt dit niet als zodanig af. De KvK taxonomie mag derhalve niet worden beschouwd als een checklist van wet- en regelgeving. Om dezelfde reden mag de KvK taxonomie ook niet worden beschouwd als een algemeen aanvaard stelsel van verslaggeving. Het is een gestandaardiseerd raamwerk voor een jaarrekening dat zich kenmerkt door de wijze van structureren en representeren van gegevens en die uit te breiden is door de opsteller, indien gewenst.

Hoe moet ik omgaan met de jaarrekening bij de ontbinding van een onderneming? De onderneming dient een jaarrekening te deponeren over de periode tot aan de ontbinding. De hiervoor te gebruiken versie van de KvK taxonomie is de meest recente definitieve versie van de KvK taxonomie.

Voorbeeld

Een organisatie wordt als gevolg van een faillissement op 29 juni 2017 ontbonden. Het financiële boekjaar van de organisatie is gelijk aan een kalenderjaar. De taxonomie die voor de jaarrekening per 29 juni 2017 eigenlijk gebruikt zou moeten worden is de KvK taxonomie (NT12), aangezien de startdatum van de periode op 1 januari 2017 ligt. Op 29 juni 2017 was de definitieve versie van de KvK taxonomie (NT12) echter nog niet beschikbaar. In dit geval dient de organisatie dus de meest recente definitieve versie van de KvK taxonomie, de KvK taxonomie (NT11), te gebruiken om de jaarrekening op te stellen.

Hoe moet ik omgaan met de jaarrekening bij de start van een onderneming gedurende het jaar? Na de oprichting van een onderneming moet voor het eerst een jaarrekening worden gedeponeerd. Omdat het een nieuwe onderneming betreft zijn er logischerwijs geen vergelijkende cijfers beschikbaar. De vergelijkende cijfers hoeft u daarom niet te rapporteren.

Voor de juiste technische werking van verloopoverzichten is het van belang dat, ondanks het niet beschikbaar zijn van de vergelijkende cijfers, in de jaarrekening in XBRL formaat wordt aangegeven wat de einddatum van de voorgaande financiële rapportageperiode is. Dit oogt wellicht vreemd, aangezien de onderneming feitelijk toen nog niet bestond. Dit is echter alleen nodig in die incidentele situaties waarin nieuw opgerichte ondernemingen verloopoverzichten hanteren in hun eerste jaarrekening.

Voorbeeld

Een onderneming is opgericht op 1 februari 2017. Bij de financiële rapportage voor 2017 met als einddatum 31 december 2017 wordt in de jaarrekening in XBRL formaat het volgende opgegeven:

Startdatum van de huidige financiële rapportageperiode: 1 februari 2017 Einddatum van de huidige financiële rapportageperiode: 31 december 2017 Einddatum van de voorgaande financiële rapportageperiode: 31 januari 2017

50

6. Deponeren van de jaarrekening

De ondernemer is verantwoordelijk voor het deponeren van de jaarrekening met SBR bij de Kamer van Koophandel. Dit hoofdstuk gaat nader in op de wijze waarop u een jaarrekening in XBRL formaat kunt deponeren met SBR.

Onderstaand stappenplan helpt u bij het deponeren van de jaarrekening met SBR bij de Kamer van Koophandel.

Figuur 5 – Stappenplan deponeren van de jaarrekening

In de volgende paragrafen werken we deze stappen nader uit.

6.1 Ontvang de gewaarmerkte jaarrekening en accountantsverklaring van uw

accountant

Nadat de accountant de werkzaamheden heeft verricht, geeft de accountant een accountantsverklaring af. Deze accountantsverklaring wordt ondertekend met de digitale handtekening van de accountant. Deze digitale handtekening is opgenomen in een apart bestand; het detached signature bestand. De techniek achter de digitale handtekening is ook gebruikt om de jaarrekening in XBRL formaat te waarmerken. Zowel de ondertekening van de accountantsverklaring als het waarmerk van de door de ondernemer opgestelde jaarrekening is opgenomen in dit detached signature bestand. Het verschil tussen de ondertekening en het waarmerk is geëxpliciteerd in het detached signature bestand op basis van het SBR ondertekeningsbeleid.

U ontvangt van de controlerend accountant de volgende documenten retour:

• Het instance document met de jaarrekening;

• Een eventuele preparer extension;

• Het instance document met de accountantsverklaring; en

• Het detached signature bestand.

U heeft al deze bestanden nodig om de jaarrekening met accountantsverklaring te kunnen deponeren.

51

6.2 Vul de relevante gegevens aan in de jaarrekening ten behoeve van de

deponering

Voor het deponeren van de jaarrekening in XBRL formaat dient u ook aan te geven of de jaarrekening is vastgesteld of niet. Hiervoor is het concept “Jaarrekening vastgesteld (J/N)” beschikbaar in de KvK taxonomie. Hierin kunt u met de waarden ‘Ja’ of ‘Nee’ aangeven of de jaarrekening is vastgesteld. Indien de jaarrekening is vastgesteld moet u ook de datum van vaststelling vermelden. Hiervoor is het concept “Datum van vaststelling” beschikbaar, waarmee u de betreffende datum opgeeft.

Als u aangeeft dat de cijfers van het huidige boekjaar zijn vastgesteld, wordt ervan uit gegaan dat dit ook van toepassing is voor de vergelijkende cijfers. U hoeft niet apart aan te geven of de vergelijkende cijfers ook zijn vastgesteld.

Het opgeven of veranderen van deze twee vaststellingsconcepten in de jaarrekening in XBRL formaat verandert de inhoud van de jaarrekening. Dit kan in potentie problemen geven bij het waarmerken van de jaarrekening door de accountant, aangezien voor het waarmerken een hash waarde berekend wordt over de inhoud van de jaarrekening. De twee vaststellingsconcepten houdt de accountant expliciet buiten de hash-berekening, zodat u deze na het afgeven van de accountantsverklaring nog kunt wijzigen.

In sommige gevallen kunt u voor het deponeren gebruik maken van een portaal dat beschikbaar is gesteld door de accountant. In deze functionaliteit is vaak ook mogelijk om de datum van vaststelling toe te voegen of te wijzigen voordat u de documenten daadwerkelijk deponeert.

6.3 Stuur de jaarrekening in naar Digipoort

Het deponeren van de eerder genoemde documenten gebeurt via Digipoort. In hoofdstuk 4 is besproken welke voorbereidingen nodig zijn om daadwerkelijk een bericht in te sturen naar Digipoort. Hier wordt ervanuit gegaan dat dit reeds gebeurd is, waardoor het insturen naar Digipoort met software over het algemeen een kwestie is van de bestanden selecteren, eventueel nog wat metagegevens invoeren en de documenten insturen.

6.4 Verkrijg de bevestiging van ontvangst en verwerking

Nadat het bericht is ingestuurd ontvangt de software een ontvangstbevestiging en een uniek kenmerk voor identificatiedoeleinden. Op basis van dit kenmerk vraagt de software de status op van de verwerking van de aangeleverde documenten in Digipoort en bij de Kamer van Koophandel.

Indien de verwerking niet op de juiste manier kan plaatsvinden, komt in de opgevraagde statusupdate van de aanlevering de terugkoppeling dat er een fout is opgetreden, inclusief een beschrijving van wat er precies verkeerd gaat. Deze fouten moet u corrigeren en daarna de documenten opnieuw insturen naar Digipoort.

Als de documenten zowel door Digipoort als door de KvK goed verwerkt kunnen worden, ontvangt u de status dat de aangeleverde documenten succesvol zijn verwerkt en dat de jaarrekening is gedeponeerd in het Handelsregister.

52

De verwerking van zowel Digipoort als de KvK gaat bij een eenvoudige jaarrekening zeer snel, waardoor het lijkt alsof er direct een terugkoppeling komt. Bij een jaarrekening met accountantsverklaring en/of preparer extension kan deze verwerking wat langer duren.

6.5 Ontvang een gerenderde versie van de jaarrekening per e-mail

De documenten die succesvol zijn aangeleverd bij de KvK, worden hier ook gerenderd op basis van de Consistente Presentatie. Deze rendering wordt vervolgens in .pdf formaat zowel naar u verstuurt als in het Handelsregister opgenomen.

Deze rendering wordt per e-mail verstuurd naar het e-mailadres dat in het instance document is opgegeven in het concept “E-mailadres van de contactpersoon voor deze rapportage”. Dit e-mail adres wordt overigens niet opgenomen in de rendering van de jaarrekening. Vanuit privacyoverwegingen verwijdert de KvK deze informatie uit het XBRL instance document dat in het Handelsregister wordt opgenomen. Zodoende laat de accountant bij het waarmerken van de jaarrekening ook dit concept buiten de reikwijdte van de hash berekening.

De rendering in .pdf formaat is de voor de mens eenvoudig leesbare versie van de jaarrekening die beschikbaar is in het Handelsregister.

53

DEEL C - ACCOUNTANTS

54

7. De rol van de accountant bij de jaarrekening in XBRL formaat

In dit deel wordt de relevante informatie opgenomen over de rol van de accountant in het kader van de werkzaamheden inzake de jaarrekening in XBRL formaat. Dit deel is bewust beperkt gehouden, aangezien de Koninklijke Nederlandse Beroepsorganisatie van Accountants (NBA) een uitgebreid document - in de vorm van een groenboek - heeft opgesteld dat hier expliciet op ingaat. Zodoende richt dit deel zich uitsluitend op de informatie die relevant is voor accountants, maar die (nog) niet beschikbaar is in de meest recente versie van het groenboek.

7.1 Groenboek “De accountant in een SBR-omgeving”

Alle relevant informatie voor accountant omtrent de toepassing van SBR is door de NBA beschreven in het NBA-Groenboek De accountant in een SBR-omgeving van 28 juni 2017 dat door de werkgroep SBR van de NBA is opgesteld.

Dit Groenboek geeft een brede inleiding op de toepassing van SBR door accountants en is vooral bedoeld voor de openbaar accountant en zijn accountantseenheid die een digitale accountantsverklaring moet afgeven bij een SBR rapportage. Het Groenboek beoogt daarnaast om heel concreet aan te geven wat accountants en accountantseenheden moeten doen om goed voorbereid te zijn op de verplichting om de jaarrekening te deponeren bij de KvK met SBR.

7.2 Veelgestelde vragen en antwoorden omtrent de rol van de accountant bij de

jaarrekening in XBRL formaat

In deze paragraaf zijn de veelgestelde vragen en antwoorden omtrent de rol van de accountants opgenomen. Deze vragen zijn aanvullingen op de informatie die reeds is opgenomen in de laatste versie van het NBA Groenboek.

Vragen en antwoorden omtrent het persoonsgebonden beroepscertificaat

Staat de eIDas verordening het gebruik van een (interne) HSM toe voor de opslag van gekwalificeerde PKIo persoonsgebonden beroepscertificaten?

Het korte antwoord is: Ja, maar alleen wanneer de QTSP de verantwoordelijkheid draagt voor de (interne) HSM.

Hieronder wordt in meer detail op dit vraagstuk ingegaan:

De eIDas verordening interpreteert twee methoden voor de opslag van persoonsgebonden beroepscertificaten; 1. Gebruik van een token. De token moet op een beveiligde USB stick of smartcard staan. 2. Gebruik van een ‘hardware security module’ (HSM). Bij gebruik van een HSM staat het certificaat centraal op een beveiligde omgeving opgeslagen, onder toezicht van de TSP.

55

De eerste methode is niet in alle gevallen werkbaar is voor accountants. Het gebruik van USB sticks past soms niet in het (security-)beleid van verschillende organisaties, waardoor het gebruik van een token niet werkbaar is. Hier zijn wel technische oplossingen voor, zoals het wel toestaan van USB tokens terwijl USB opslag niet wordt toegestaan of het gebruik van hardware met ingebouwde smartcardlezer. Een ander bezwaar voor het gebruik van een token is dat organisaties eigen controle willen uitoefenen op het gebruik van deze certificaten voor organisatiedoeleinden. Hierdoor is de eerste methode niet voor alle gevallen een oplossing. Deze organisaties hebben dan vaak een voorkeur voor de tweede methode, waarbij ze de HSM het liefst intern willen opzetten.

Het intern opzetten van een HSM past echter niet hoe de eIDas verordening is geformuleerd. De verordening lijkt te eisen dat, voor een gekwalificeerde handtekening, de certificaten onder beheer van een TSP (Trusted Service Provider) moeten staan. Voor sommige accountantskantoren is het gebruik van een ‘cloud’ oplossing echter niet werkbaar, omdat zij de certificaten (vanuit organisatieperspectief) intern willen beheren.

Het Agentschap Telecom heeft, in een speciale bijeenkomst van de SBR Expertgroep Processen & Techniek van 21 juni 2017, aangegeven dat het intern opzetten van HSM een mogelijkheid is op het moment dat TSP hiervoor de verantwoordelijk draagt2. Dit betekent in de praktijk dat de desbetreffende organisaties de HSM in eigen beheer hebben, onder toezicht van de TSP. De TSP dient, bij een mogelijke audit, aan te kunnen tonen dat de TSP daadwerkelijk in control is.

In aanvulling op het standpunt van het Agentschap Telecom heeft de Policy Authority van PKIoverheid nog de mogelijkheid heeft om aanvullende eisen te stellen aan het gebruik van een interne HSM voor de opslag van PKIo persoonsgebonden beroepscertificaten. De Policy Authority van PKIoverheid geeft aan zich te kunnen vinden in de interpretatie van het Agentschap Telecom, aangezien de eIDAS verordening ruimte biedt om het veilig middel (b.v. een HSM) van een abonnee (b.v. een accountantskantoor) door een derde te laten beheren. Dit beheer vindt dan plaats onder de verantwoordelijkheid van- c.q. door de QTSP. Op de QTSP rust dus de verantwoordelijkheid dat het geheel aan de regels voldoet.

De normen waaraan gekwalificeerde middelen moeten voldoen worden door de Commissie via uitvoeringshandelingen vastgesteld (art. 29, lid 2 eIDAS). In Uitvoeringsbesluit 2016/650 worden deze normen gespecificeerd. Deze normen zijn echter van toepassing op een middel dat in een volledig door de gebruiker beheerde omgeving is opgenomen. De Commissie heeft nog geen lijst met normen voor de certificering van veilige middelen die onder de verantwoordelijkheid van- c.q. door een gekwalificeerde verlener van vertrouwensdiensten wordt beheerd.

Door Agentschap Telecom is in het SBR Expertgroep Processen & Techniek overleg van 21 juni 2017 de positie van de Commissie weergegeven dat normen c.q. standaarden kunnen worden gebruikt om eIDAS conformiteit aan te tonen, maar dat het gebruik van normen c.q. standaarden niet verplicht is. Het ontbreken van normen c.q. standaarden mag dus geen reden zijn om te concluderen dat iets niet mag. De eIDAS verordening is bepalend.

Kortom: eIDAS geeft de mogelijkheid om het veilig middel van de abonnee onder de verantwoordelijk c.q. door een QTSP te laten beheren. De eIDAS verordening is hierbij nl. bepalend. Echter, op dit moment is het niet precies duidelijk aan welke normen het extern beheert veilig middel moet voldoen.

2 Het Agentschap Telecom heeft met enige regelmaat overleg met de toezichthouders van andere EU-lidstaten. Agentschap Telecom heeft

aangegeven dat de hierboven beschreven situatie op hoofdlijnen overeenkomt met de manier waarop er in de andere lidstaten naar

gekeken wordt. Het is dus niet te verwachten dat er vanuit EU perspectief op korte termijn nog aanvulling wordt gegeven op de

verordening.

56

Op de vraag of PKIoverheid, nu de normen c.q. standaarden nog ontbreken, zelf aanvullende eisen zal stellen wordt het volgende aangeven: Zodra de betreffende normatief definitief is en wordt gepubliceerd, hierbij wordt gedoeld op de CEN EN/TS 419 241 standaarden, is PKIoverheid voornemens deze in haar Programma van Eisen (PvE) op te nemen, waarmee deze verplichtend worden voor de QTSP’s. Vanzelfsprekend zal de PKIoverheid t.z.t. in afstemming met haar TSP’s en met name de auditor van de TSP’s, beoordelen hoe deze standaarden het beste in het PvE kunnen worden verwerkt.

Als de QTSP’s nú al willen overgaan tot een extern beheerd veilig middel: 1. dan is het nuttig om al zoveel mogelijk rekening te houden met de CEN EN/TS 419 241

standaarden. De betreffende standaarden zijn al (deels) in een draft versie beschikbaar; 2. dan is het noodzakelijk dat er een goede afstemming plaatsvindt tussen de abonnee, de

QTSP’s en de TSP auditor; deze afstemming brengt mogelijk met zich mee dat de QTSP ook contractuele afspraken moet maken met de abonnee over onder meer aansprakelijkheid en compliance d.m.v. onafhankelijke audits en toetsing.

57

DEEL D – SOFTWAREONTWIKKELAARS

58

8. Software voor het deponeren van de jaarrekening met SBR

Ondernemers moeten hun jaarrekening met SBR deponeren bij de Kamer van Koophandel. SBR is de Nederlandse standaard voor het digitaal verantwoorden van bedrijfsinformatie. Om dit mogelijk te maken is de beschikbaarheid van goede software een randvoorwaarde. De rol van de softwareontwikkelaars is dus van groot belang om het deponeren met SBR door ondernemer te faciliteren.

Een model van de verschillende fasen die een softwareontwikkelaar zal moeten doorlopen om een jaarrekening te deponeren met SBR is in de onderstaande figuur opgenomen.

Figuur 6 – Te doorlopen fasen voor het deponeren van de jaarrekening met SBR

In de bovenstaande figuur zijn de fasen die de softwareontwikkelaar over het algemeen zal doorlopen opgenomen. De fasen ‘Realiseer de functionaliteit’ en ‘Beschikbaar stellen van de functionaliteit’ zijn in het grijs opgenomen om te illustreren dat hier in dit document niet verder op zal worden ingegaan.

In de volgende paragrafen wordt kort ingegaan op de verschillende fasen van de bovenstaande figuur. Het doel hierbij is het opnemen van de relevante informatie omtrent de situaties waar een softwareontwikkelaar tegenaan kan lopen bij het ontwikkelen van software ten behoeve van het deponeren van de jaarrekening met SBR.

8.1 Bepaal de te ondersteunen functionaliteit

Er zijn verschillende functionaliteiten te onderkennen in het kader van het deponeren van de jaarrekening met SBR. De onderkende functionaliteiten zijn:

• Opstellen van de jaarrekening in XBRL formaat

• Opstellen van een preparer extension

• Opstellen van de accountantsverklaring in XBRL formaat

• Renderen van de documenten

• Ondertekenen en waarmerken

• Deponeren van de jaarrekening

Een softwareontwikkelaar zal moeten bepalen of en zo ja, hoe deze (een deel van) de bovengenoemde functionaliteit wil gaan ondersteunen in de software. In dit kader is het natuurlijk ook van belang dat de softwareontwikkelaar een keuze maakt welke berichtstromen deze wil gaan ondersteunen. De bovengenoemde functionaliteiten zijn niet in alle omstandigheden nodig om een jaarrekening te deponeren. Een overzicht van welke functionaliteit van toepassing is voor welke berichtstroom is in de onderstaande tabel opgenomen.

59

Op

ste

lle

n

jaar

reke

nin

g

Op

ste

lle

n

pre

par

er

ext

en

sio

n

Op

ste

lle

n

acco

un

tan

ts-

verk

lari

ng

Ren

de

ren

van

de

do

cum

ente

n

On

de

rte

ken

en

e

n w

aarm

erk

en

De

po

ne

ren

van

d

e ja

arre

ken

ing

Jaarrekening Ja - - Ja - Ja

Jaarrekening met preparer extension

Ja Ja - Ja - Ja

Jaarrekening met accountantsverklaring

Ja - Ja Ja Ja Ja

Jaarrekening met preparer extension en accountantsverklaring

Ja Ja Ja Ja Ja Ja

Tabel 5 – Overzicht van functionaliteit per berichtstroom

Uit de bovenstaande tabel blijkt dat voor het ondersteunen van alleen de berichtstroom ‘Jaarrekening’ de minste functionaliteit benodigd is, terwijl voor de berichtstroom ‘Jaarrekening met preparer extension en accountantsverklaring de meeste functionaliteit benodigd is.

De keuzes die een softwareontwikkelaar zal moeten maken richten zich op de te ondersteunen functionaliteit. Hierbij kan het een bewuste keuze zijn om slechts een of enkele van de functionaliteiten te ondersteunen in plaats van alle functionaliteiten die van toepassing zijn binnen een berichtstroom. Dit zal afhankelijk zijn van de strategische overwegingen van de betreffende softwareontwikkelaar.

Tip: Begin eenvoudig en breid de functionaliteit desgewenst uit met de complexere onderdelen

Wanneer een softwareontwikkelaar op termijn alle functionaliteit en berichtstromen wil ondersteunen, is het verstandig dit gefaseerd op te bouwen. Start met het ondersteunen van de berichtstroom ‘Jaarrekening’ en als alle functionaliteit in dit kader werkt, begin dan pas met de volgende.

Start hierbij altijd met de eenvoudigste berichtsoort ‘Jaarrekening’, alvorens door te gaan naar respectievelijk de berichtstromen ‘Jaarrekening met preparer extension’, ‘Jaarrekening met accountantsverklaring’ en ‘Jaarrekening met preparer extension en accountantsverklaring’

Op elke bovengenoemde functionaliteit zal in een apart hoofdstuk verder worden ingegaan. De volgende hoofdstukken zijn te onderkennen: Hoofdstuk 9: Opstellen van de jaarrekening in XBRL formaat Hoofdstuk 10: Opstellen van een preparer extension Hoofdstuk 11: Opstellen van de accountantsverklaring in XBRL formaat Hoofdstuk 12: Renderen van de documenten Hoofdstuk 13: Ondertekenen en waarmerken Hoofdstuk 14: Deponeren van de jaarrekening

60

8.2 Neem kennis van de specificaties

Voor softwareontwikkelaars zijn de relevante specificaties van groot belang. Deze specificaties beschrijven de wijze waarop de jaarrekening moet worden opgesteld en gedeponeerd bij de KvK. In deel E van dit document zijn de relevante SBR specificaties en de specifieke toepassing hiervan in het kader van het deponeren van de jaarrekening bij de KvK opgenomen. Dit zou de softwareontwikkelaar al moeten helpen bij een generieke implementatie van de functionaliteit.

In aanvulling hierop worden in de hoofdstukken 9 tot en met 14 ook voor nagenoeg elke functionaliteit praktijkvoorbeelden uitgewerkt en op basis van deze specificaties. De verschillende onderdelen van de specificaties worden op deze manier overzichtelijk uitgelegd.

Aansluitpakket Wanneer een softwareontwikkelaar direct een volledige set van voorbeelden wil bekijken, zonder toelichting, kan deze gebruik maken van de KvK aansluitpakketten. Aansluitpakketten zijn ‘doe het zelf-pakketten’ bestaand uit een set van documenten die softwareontwikkelaars helpen bij het implementeren van de relevante functionaliteiten. Voor het deponeren van de jaarrekening bij de KvK zijn de volgende aansluitpakketten beschikbaar:

• Aansluitpakket KvK - Jaarrekening

• Aansluitpakket KvK - Jaarrekening met preparer extension

• Aansluitpakket KvK - Jaarrekening met accountantsverklaring

• Aansluitpakket KvK - Jaarrekening met preparer extension en met accountantsverklaring

De inhoud van elk aansluitpakket bestaat onder meer uit de volgende zaken:

• Statussen & foutcodes

• Voorbeeldberichten

• Servicebeschrijvingen

• XSDs en WSDLs

De meest recente versies van de KvK aansluitpakketten zijn te vinden op: https://aansluiten.procesinfrastructuur.nl

8.3 Testen van de functionaliteit

Voor het testen van ontwikkelde functionaliteit kan een softwareontwikkelaar gebruik maken van twee verschillende faciliteiten. De eerste faciliteit is de Aansluitsuite en de tweede is de preproductie-omgeving waarop een ketentest uitgevoerd kan worden.

Aansluitsuite Digipoort De Aansluitsuite faciliteert helpt organisaties met het aansluiten op Digipoort en het opstellen en uitwisselen van berichten middels SBR. De Aansluitsuite heeft in dit kader als primair doel de softwareontwikkelaar te ondersteunen bij de ontwikkeling van systeemkoppelingen met Digipoort. In dit kader zijn op de Aansluitsuite ook de relevante aansluitpakketten opgenomen met alle benodigde documentatie en specificaties per berichtstroom. Belangrijker is echter dat de Aansluitsuite de testfaciliteiten bevat waarmee zowel de koppelvlakimplementatie als inhoudelijke berichten getest en gevalideerd worden.

Middels deze testfaciliteiten worden de softwareontwikkelaars ondersteund in het gebruik van SBR. Zij kunnen hier zowel individuele testen uitvoeren, bijvoorbeeld op het gebied van XBRL validiteit of

61

de validiteit van een digitale handtekening, maar ook de aanlevering testen op basis van vooraf gedefinieerde testscenario’s.

De Aansluitsuite Digipoort is te vinden via de volgende link: https://aansluiten.procesinfrastructuur.nl/

Preproductie-omgeving De preproductie-omgeving is een kopie van de productieomgeving van zowel de KvK i-processen in Digipoort als de verwerking in de backoffice van de Kamer van Koophandel. De preproductie-omgeving is de plaats waar nieuwe functionaliteit geaccepteerd wordt voor een release naar de productieomgeving. Voor de KvK stromen wordt deze omgeving ook ingezet om aanleverende partijen in staat te stellen om integrale ketentesten uit te voeren.

Meer informatie over het aanleveren op de preproductie-omgeving is opgenomen in de KvK aansluitpakketten.

Tip: Gebruik vooral de Aansluitsuite om te testen

Het is verstandig om in eerste instantie vooral de Aansluitsuite te hanteren om testen uit te voeren op de ontwikkelde functionaliteit. De uitkomsten van een test in de Aansluitsuite zijn beduidend sneller beschikbaar dan de uitkomsten van een test in de preproductie-omgeving.

Voer de testen voor de individuele functionaliteiten vooral uit op de Aansluitsuite. Gebruik de preproductie-omgeving uitsluitend voor het uitvoeren van een integrale ketentest op het einde van het testproces.

62

9. Opstellen van de jaarrekening in XBRL formaat

9.1 Relevante specificaties

In het kader van het opstellen van een jaarrekening in XBRL formaat is het van belang om kennis te nemen van de specificaties op het gebied van SBR taxonomieën en instance documenten. In deze specificaties wordt nader ingegaan op de toepassing van XBRL binnen SBR. Zie hiervoor ook hoofdstuk 16 in ‘Deel E – Specificaties’.

De toepassing van XBRL binnen SBR maakt gebruik van verschillende XBRL specificaties voor het tonen van informatie in een XBRL instance document aan gebruikers. Binnen SBR wordt in dit kader gebruik gemaakt van de XBRL 2.1 en Table Linkbase specificatie. Een andere veelgebruikte specificatie voor het presenteren van informatie is de Inline XBRL specificatie. Een Inline XBRL document is een XHTML bestand dat met elke browser bekeken kan worden en waarin de XBRL tags zijn opgenomen. Op basis van een vast algoritme kan hieruit een XBRL instance document gegenereerd worden. Inline XBRL is vermoedelijk het formaat waarmee beursgenoteerde ondernemingen in Europa hun jaarrekening moeten insturen naar de betreffende toezichthouders. Dit hoofdstuk zal worden uitgebreid indien de toepassing van Inline XBRL ook mogelijk zal worden voor het deponeren van een jaarrekening met SBR bij de Kamer van Koophandel.

In dit hoofdstuk wordt een bepaalde mate van technische kennis van XBRL verondersteld. Het is niet bedoeld als inleiding in XBRL, maar als uitleg omtrent de toepassing van XBRL bij het opstellen van de jaarrekening in XBRL formaat.

9.2 Een jaarrekening in XBRL formaat nader uiteengezet

De jaarrekening wordt vastgelegd in een XBRL instance document. Een XBRL instance document is een bestand dat door de computer kan worden verwerkt. Het bestand bevat de (financiële) informatie die opgenomen is in de jaarrekening van een onderneming met behulp van zogenaamde ‘tags’ die verwijzen naar concepten uit de jaarverslaggeving taxonomie. De taxonomie bevat de instructies voor de geautomatiseerde verwerking van deze informatie (waaronder de data types, balanceTypes en andere data attributen) en de definities van de concepten met een link naar relevante wet- en regelgeving. Het instance document bevat de inhoud van de rapportage, oftewel de feiten die gerapporteerd worden, evenals de contextuele gegevens die benodigd zijn om de feiten op een gestructureerde en consistente wijze te kunnen interpreteren.

De structuur van een instance document bestaat veelal uit de volgende onderdelen:

• XML processing instruction

• XML comment

• XBRL/Schema sectie

• Entrypoint sectie

• Context sectie

o Entiteit

o Period

o Segment/scenario

• Unit sectie

63

• Inhoud/feiten sectie

• Afsluiting

De volgende sub-paragrafen gaan nader in op deze onderdelen van een instance document.

9.2.1 XML declaration

Aangezien XBRL volledig is gebaseerd op XML, dient ook elk XBRL-bestand te beginnen met de XML declaration. Hier wordt vermeld welke versie van XML is gehanteerd (in een XBRL bestand is dit altijd 1.0) en de gebruikte tekencodering, in dit geval UTF-8. Andere opties in de XML declaration zijn mogelijk, maar worden in XBRL instance documenten niet gebruikt.

Voorbeeld <?xml version="1.0" encoding="UTF-8" standalone=”yes”?>

(..)

9.2.2 XML comment

Een XML comment kan meta data over het bestand bevatten die in principe alleen bedoeld is voor de menselijke lezer, zoals versienummer, applicatie waarmee het bestand is gemaakt, datum van creatie, copyright en dergelijke. Het opnemen van een XML comment in een instance document is niet verplicht. In de praktijk wordt het vaak gebruikt door softwareleveranciers om aan te geven dat het instance document met hun software is gemaakt. Een XML comment mag maar één keer voorkomen in een instance document en geen inhoudelijke rapportagefeiten bevatten.

Voorbeeld (..)



(..)

9.2.3 XBRL/Schema sectie

De XBRL/Schema sectie in het instance document begint met het root element. Op basis van de XBRL specificatie is dit altijd <xbrl>. Dit element heeft meestal de prefix ‘xbrli’ aangezien dit de standaard prefix is voor het schema http://www.xbrl.org/2003/instance waarin element dit is gedeclareerd. Daarnaast worden er nog meer schema’s gedefinieerd. Elk element in het instance document heeft een prefix dat verwijst naar de voor het element geldende namespace.

Voorbeeld (..)

<xbrli:xbrl xml:lang="nl"

64

xmlns:link="http://www.xbrl.org/2003/linkbase" xmlns:xbrli="http://www.xbrl.org/2003/instance" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:iso4217="http://www.xbrl.org/2003/iso4217" xmlns:kvk-i="http://www.nltaxonomie.nl/nt12/kvk/20171213/dictionary/kvk-data" >

(..)

9.2.4 Entrypoint sectie

De KvK taxonomie definieert de concepten en haar relatie(s) met andere concepten, terwijl het instance document de daadwerkelijke feiten bevat. Hierbij dient een koppeling te bestaan tussen het instance document en het betreffende entrypoint uit de taxonomie. Deze koppeling wordt gemaakt door middel van een referentie naar een entrypoint in het instance document. Deze koppeling is noodzakelijk omdat dit de validatie van het instance document mogelijk maakt. Bij het valideren van een instance document dient de validatiesoftware het discovery proces uit te voeren. Dit proces ontdekt de relevante taxonomie en valideert het instance document hiertegen. Zonder deze referentie kan het discovery proces niet plaatsvinden en is het instance document niet in overeenstemming met de XBRL 2.1 specificatie.

Voorbeeld (..)

<link:schemaRef xlink:type="simple" xlink:href="http://nltaxonomie.nl/nt12/kvk/20171213/entrypoints/kvk-rpt-jaarverantwoording-2017-nlgaap-middelgroot-publicatiestukken.xsd"/>

(..)

9.2.5 Context sectie

In een instance document definieert de combinatie van context en concept de feiten of waardes in een financiële rapportage. Een context bevat informatie omtrent:

• De rapporterende entiteit;

• De periode waarover gerapporteerd wordt;

• De assen waarlangs de feiten worden gesegregeerd;

• De domeinleden die feiten categoriseren langs elke as.

Contexten zijn van toepassing op zowel numerieke als niet-numerieke concepten. Een context geeft een unieke naam aan elke combinatie van informatie omtrent entiteit, periode, as en domein die nodig is op de individuele feiten in een jaarrekening te kunnen interpreteren. Voor elke unieke combinatie dient een aparte context opgenomen te worden in het instance document.

De entiteit De eerste stap in het opstellen van een instance is het definiëren van de unieke omschrijving van de entiteit. Hiervoor wordt de <xbrli:identifier> gebruikt. Voor het deponeren van de jaarrekening bij het handelsregister is het verplicht dat de <xbrli:identifier> het KvK-nummer bevat van de rechtspersoon die de jaarrekening deponeert. Dit moet ook een bestaand KvK-nummer zijn. Alle <xbrli:identifier> elementen in een instance dienen dezelfde inhoud te hebben.

Voorbeeld

65

<xbrli:context id="FY17d "> <xbrli:entity> <xbrli:identifier scheme="http://www.kvk.nl/kvk-id">30267975</xbrli:identifier> </xbrli:entity>

(..)

</xbrli:context>

De periode De periode informatie bepaalt of de context verwijst naar feiten die gemeten worden op een bepaald moment in de tijd (instant) of over een periode van tijd (duration) en de bijbehorende datum(s). Voor het periodType ‘duration’ zal er zowel een start- als een einddatum zijn. In XBRL wordt een datum alleen gehanteerd in het formaat JJJJ-MM-DD (de XML notatie), oftewel een code die begint met de vier cijfers van het jaar, gevolgd door de twee cijfers voor de maand en ten slotte de twee cijfers voor de dag. Dezelfde datum mag niet voorkomen als einddatum in de ene context en als startdatum in een andere context. De XBRL 2.1 specificatie interpreteert een startdatum in de context als “middernacht aan het begin van” en bij een einddatum in de context als “middernacht aan het einde van” die dag. Hierdoor sluiten de contexten dus altijd op elkaar aan.

In de KvK taxonomie wordt het periodType ‘instant’ uitsluitend gebruikt voor balansposten en voor nadere (cijfermatige) uiteenzettingen van balansposten. Voor alle overige concepten wordt het periodType ‘duration’ gehanteerd. Het is dus van belang om hier rekening mee te houden bij het bepalen van de geschikte contexten.

Voorbeeld <xbrli:context id="FY17d "> <xbrli:entity> <xbrli:identifier scheme="http://www.kvk.nl/kvk-id">30267975</xbrli:identifier> </xbrli:entity> <xbrli:period> <xbrli:startDate>2017-01-01</xbrli:startDate> <xbrli:endDate>2017-12-31</xbrli:endDate> </xbrli:period>

(..)

</xbrli:context>

De assen en domeinleden Een context kan twee technische elementen bevatten: het segment en scenario element. Het segment element wordt niet gebruikt in de KvK taxonomie en is dus ook niet toegestaan in een instance document die gedeponeerd gaat worden bij het handelsregister. Het scenario element is het deel van de context waarin de informatie omtrent de assen en domeinleden is opgenomen. De KvK taxonomie onderkent geen default dimensies waardoor elk gerapporteerd feit dus aan een specifieke as gekoppeld dient te worden wanneer gebruik gemaakt wordt van een dimensionale structuur.

Er zijn twee varianten van dimensies te onderkennen binnen XBRL: explicit dimensions en typed dimensions.

Explicit dimensions

66

Bij een explicit dimension is de waarde van het domeinlid (member) dat gebruikt wordt door de taxonomie-auteur vooraf expliciet gedefinieerd. In het onderstaande voorbeeld komt dit onder meer naar voren in de as ‘Type grondslag’ (BasisOfPreparationAxis) waarbij de waarde van het domeinlid ‘Commercieel’ (CommercialMember) is.

Voorbeeld <xbrli:context id="FY17d_explicit"> <xbrli:entity> <xbrli:identifier scheme="http://www.kvk.nl/kvk-id">30267975</xbrli:identifier> </xbrli:entity> <xbrli:period> <xbrli:startDate>2017-01-01</xbrli:startDate> <xbrli:endDate>2017-12-31</xbrli:endDate> </xbrli:period> <xbrli:scenario> <xbrldi:explicitMember dimension="venj-bw2-dim:BasisOfPreparationAxis">venj-bw2- dm:CommercialMember</xbrldi:explicitMember> <xbrldi:explicitMember dimension="venj-bw2-dim:FinancialStatementsTypeAxis">venj-bw2- dm:SeparateMember</xbrldi:explicitMember> </xbrli:scenario> </xbrli:context>

Typed dimensions Bij een typed dimension is de waarde van het domeinlid (member) dat gebruikt wordt door de taxonomie-auteur vooraf niet te definiëren. Door de toepassing van een typed member kan dit dus door de opsteller van het instance document zelf gedaan worden. Het gebruik van typed dimensions is dus bedoeld voor het categoriseren van aspecten van een concept, met een domein met veel of onbekende waarden die semantisch betekenisvol zijn. In het onderstaande voorbeeld is de naam van de bestuurder Jan Jansen de waarde van het domeinlid (member).

Voorbeeld <xbrli:context id="FY17d_typed"> <xbrli:entity> <xbrli:identifier scheme="http://www.kvk.nl/kvk-id">30267975</xbrli:identifier> </xbrli:entity> <xbrli:period> <xbrli:startDate>2017-01-01</xbrli:startDate> <xbrli:endDate>2017-12-31</xbrli:endDate> </xbrli:period> <xbrli:scenario> <xbrldi:typedMember dimension="venj-bw2-dim:ManagingOrSupervisoryDirectorNamesAxis"> <venj-bw2-dm:ManagingOrSupervisoryDirectorTypedMember>Jan Jansen</venj-bw2- dm:ManagingOrSupervisoryDirectorTypedMember> </xbrldi:typedMember> </xbrli:scenario> </xbrli:context>

Naamgeving van contexten Elk feit in een instance document wordt gekoppeld aan een context. Zelfs de meest eenvoudige jaarrekening heeft gegevens die gebruik maken van meerdere contexten. Dit proces kan echter steeds ingewikkelder worden als gevolg van de grote hoeveelheid contexten die een volledige jaarrekening met zich meebrengt. Het is daarom van belang om een duidelijke en consistente naamgevingconventie te hanteren voor de context ID, zodat het eenvoudiger wordt om de juiste

67

context aan een feit te koppelen. De context ID is een unieke identifier die begint met een alfabetisch karakter (verplicht volgens de XBRL 2.1 specificatie) en die in voldoende mate een omschrijving geeft om de periode en andere onderscheidende aspecten van de betreffende context weer te geven.

De naamgeving van het context ID in een XBRL instance document staat partijen geheel vrij. Een mogelijke conventie is om de periode en het periodType te betrekken in de naamgeving. In het onderstaande voorbeeld is ‘17’ het boekjaar waarop de context betrekking heeft en de ‘d’ staat voor duration en de ‘i’ staat voor een instant, oftewel een specifieke datum.

Voorbeeld Periode Context ID Boekjaar 2017 FY17d Einde van boekjaar 2017 FY17i Begin van boekjaar 2017 FY16i Boekjaar 2017 op commerciële grondslagen FY17d_Commercial Einde van boekjaar 2017 in de enkelvoudige jaarrekening op commerciële grondslagen

FY17i_Commercial_Separate

9.2.6 Unit sectie

Elke numerieke waarde in een instance document dient een unit te hebben. Dit kan zowel een eenvoudige enkele meeteenheid zijn als een ratio van verschillende meeteenheden. Een voorbeeld van een eenvoudige unit is EUR (Euro’s), shares, meters of kilogrammen. Een voorbeeld van een ratio van meeteenheden is de winst per aandeel (teller: EUR, noemer: shares).

De toegestane units zijn opgenomen in het Units Registry 1.0 (https://specifications.xbrl.org/work-product-index-registries-units-registry-1.0.html) van XBRL international. Hierbij zijn er wel beperkingen in de toegestane units voor specifieke item types:

• Elementen met een monetaryItemType of daarvan afgeleid datatype moeten een unit type hanteren die erkend is door ISO standaard 4217;

• Elementen met een shareItemType moeten de unit ‘xbrli:shares’ hanteren;

• Indien de unit niet te bepalen is kan een zogenaamde pureItemType worden gehanteerd.

In een instance document is het niet toegestaan om identieke units op te nemen. Het is ook niet toegestaan om ongebruikte units te definiëren in een instance document.

Het is aan te raden om elke unit ID in een instance document zo te noemen dat het verwijst naar de technische werking hiervan. Hieronder is een voorbeeld weergegeven van mogelijke naamgeving conventies. De opsteller is echter vrij in het bepalen van de unit ID.

Voorbeeld <xbrli:unit id="EUR"> <xbrli:measure>iso4217:EUR</xbrli:measure> </xbrli:unit> <xbrli:unit id="shares"> <xbrli:measure>xbrli:shares</xbrli:measure> </xbrli:unit> <xbrli:unit id="pure"> <xbrli:measure>xbrli:pure</xbrli:measure> </xbrli:unit>

68

9.2.7 Inhoud sectie

De inhoud sectie is het deel van het instance document waar daadwerkelijke feiten staan. De feiten, oftewel de waardes die aan de relevante concepten in de taxonomie moeten worden toegekend, kunnen zowel numeriek (bijvoorbeeld het datatype ‘monetary’, ‘decimal’ en ‘shares’) als non-numeriek (bijvoorbeeld het datatype ‘string’) zijn. De wijze waarop getallen opgenomen kunnen worden in een instance document kent restricties. XBRL verbiedt het gebruik van komma’s, procent tekens, dollar tekens en andere non-numerieke tekens met uitzondering van het minusteken.

Op basis van de tagging dienen de waardes van de betreffende concepten in de jaarrekening te worden opgenomen in het instance document. Hierbij is het van belang dat de tags in het instance document gebruik maken van de juiste elementnaam en namespace prefix in lijn met de taxonomie.

Een instance document moet dezelfde informatie bevatten die in een papieren jaarrekening opgenomen zou worden. Een instance document mag geen feiten bevatten die normaliter niet voorkomen in een jaarrekening. De financiële rapportage concepten die gehanteerd worden om feiten te rapporteren dienen consistent gebruikt te worden. Oftewel, dezelfde tags dienen gehanteerd te worden voor verschillende periodes in een instance document. Wanneer er een keuze bestaat tussen verschillende elementen die gebruikt kunnen worden in een taxonomie op basis van hun definitie, dient het element met de nauwste definitie gehanteerd te worden.

Voorbeeld(..)

<venj-bw2-i:Inventories contextRef="FY17i" unitRef=“EUR” decimals=“0”>50000</venj-bw2-i:Inventories> <venj-bw2-i:Inventories contextRef="FY16i" unitRef=“EUR” decimals=“0”>25000</venj-bw2-i:Inventories> <venj-bw2-i:Receivables contextRef="FY17i" unitRef=“EUR” decimals=“0”>100000</venj-bw2-i:Receivables> <venj-bw2-i:Receivables contextRef="FY16i" unitRef=“EUR” decimals=“0”>50000</venj-bw2-i:Receivables> <venj-bw2-i:Securities contextRef="FY17i" unitRef=“EUR” decimals=“0”>10000</venj-bw2-i:Securities> <venj-bw2-i:Securities contextRef="FY16i" unitRef=“EUR” decimals=“0”>5000</venj-bw2-i:Securities>

(..)

De mogelijke waardes van het @decimals attribuut variëren per situatie. In de onderstaande tabel zijn de toegestane waarden van het @decimals voor bedragen gedefinieerd:

Accuratesse van het gerapporteerde feit Waarde van het @decimals

Exact bedrag INF

Bedrag nauwkeurig in miljarden -9

Bedrag nauwkeurig in miljoenen -6

Bedrag nauwkeurig in duizenden -3

Bedrag nauwkeurig in eenheden 0

Bedrag nauwkeurig in centen 2

Tabel 6 - Toegestane waarde van het @decimals

9.2.8 Afsluiting

De laatste regel in een instance document is de afsluiting van het rootelement dat begonnen is in de XBRL/Schema sectie.

69

(..)

</xbrli:xbrl>

9.3 Bijzonderheden uit de praktijk

In de vorige paragraaf is de jaarrekening in XBRL formaat in de vorm van een XBRL instance document uiteengezet op basis van de inhoud van de verschillende documenten. In deze paragraaf gaan we nader in op een aantal bijzonderheden vanuit de praktijk waar softwareontwikkelaars tegen aan kunnen lopen bij het realiseren van de functionaliteit van het opstellen van de jaarrekening.

9.3.1 Naamgeving van het instance document

De opsteller van het instance document is vrij in de benaming hiervan. Uit hoofde van de uniciteit van de instance documenten in het handelsregister bestaat er wel een aanbevolen naamgeving conventie voor jaarrekeningen. De aanbevolen naamgeving conventie voor instance documenten is als volgt:

{document}-{naam}-{datum}.{extensie}

Het {document} geeft een korte beschrijving van de aard van het document. De {naam} bestaat uit de naam (of afkorting) van de organisatie. De {datum} betreft de einddatum van de rapportage periode waarop de instance betrekking heeft. De {extensie} heeft voor XBRL instance documenten altijd de waarde “xbrl”. Een voorbeeld van de naamgeving van een XBRL instance document is in de onderstaande tabel opgenomen:

Voorbeeld

Jaarrekening-ABC-BV-20171231.xbrl

Tip: Gebruik geen spaties in de bestandsnaam

Het is op basis van de SBR Filing Rules vanwege technische redenen niet wenselijk om een spatie op te nemen in de bestandsnaam. Gebruik dus geen spaties in de bestandsnaam, maar hanteer in plaats van een spatie een verbindingsstreepje (-) of een underscore (_).

9.3.2 Taal van de jaarrekening

Een jaarrekening mag in vier talen worden gedeponeerd bij het handelsregister van de Kamer van Koophandel, namelijk in het Nederlands, Engels, Frans of Duits. De keuze van de taal dient op basis van de SBR Filing Rules in het instance document opgenomen te worden in de root node met behulp van het @xml:lang attribuut. Indien de Nederlandse taal is gekozen dient de waarde “nl” opgenomen te worden. Voor de Engelse taal is deze waarde “en”, voor de Franse taal “fr” en voor de Duitse taal “de”.

70

9.3.3 Geconsolideerde of enkelvoudige jaarrekening

In de praktijk worden de geconsolideerde en enkelvoudige jaarverantwoording over het algemeen in één document opgenomen. Dit is ook de wijze waarop dit in een XBRL instance document opgenomen moet worden. In dit kader is in de KvK taxonomie de dimensie ‘type jaarrekening’opgenomen die twee mogelijke domeinleden (members) heeft, namelijk de domeinleden (members) ‘geconsolideerd’ en ‘enkelvoudig’.

Om het verschil tussen de geconsolideerde en enkelvoudige cijfers kenbaar te maken wordt gebruik gemaakt van de aanwezige dimensies in het <xbrli:scenario> element van de context. Hierbij heeft de opsteller de mogelijkheid om uitsluitend het domeinlid (member) ‘enkelvoudig’ te hanteren in het geval van een enkelvoudige jaarverantwoording, evenals het domeinlid (member) ‘geconsolideerd’in het geval van een geconsolideerde jaarverantwoording. In het geval van een gecombineerde jaarrekening kunnen beide domeinleden (members) gebruikt worden. Het is van groot belang dat de jaarrekening in XBRL formaat het juiste domeinlid (member) toepast, aangezien dit bepaalt of de feiten in de geconsolideerde of enkelvoudige jaarrekening worden opgenomen en getoond.

9.3.4 Jaarrekening op basis van commerciële of fiscale waarderingsgrondslagen

Onder de Nederlandse wet- en regelgeving kan een jaarrekening worden opgesteld op basis van fiscale waarderingsgrondslagen of op basis van de commerciële waarderingsgrondslagen. Het toepassen van fiscale grondslagen is alleen mogelijk voor rechtspersonen in de bedrijfsklasse micro- en kleine rechtspersonen.

In de KvK taxonomie is de dimensie ‘Type grondslag’ opgenomen die twee mogelijke domeinleden (members) heeft, namelijk ‘commercieel’ en ‘fiscaal’. Door het beschikbaar maken van deze dimensie zijn rechtspersonen in staat om voor dezelfde entiteit een jaarrekening op verschillende grondslagen op te stellen. In het XBRL instance document wordt gebruik gemaakt van het <xbrli:scenario> element van het context element om aan te geven of de inhoud betrekking heeft op de commerciële of fiscale grondslagen. Hierbij dient de opsteller dus het domeinlid (member) ‘Commercieel’ te hanteren in het geval van commerciële waarderingsgrondslagen, evenals het domeinlid (member) ‘fiscaal’ in het geval van fiscale waarderingsgrondslagen.

Het is niet toegestaan om meerdere waarderingsgrondslagen in een XBRL instance document op te nemen. Oftewel, de gehele jaarrekening is of opgesteld op basis van commerciële waarderingsgrondslagen of op basis van fiscale waarderingsgrondslagen, maar een combinatie mag niet. Het is ook hier van groot belang dat het juiste domeinlid (member) wordt gehanteerd bij het opstellen van de jaarrekening om onduidelijkheid te voorkomen.

De jaarrekening van rechtspersonen in de bedrijfsklasse middelgrote en grote rechtspersonen kan uitsluitend op commerciële grondslag worden opgesteld. Dit betekent dat het toepassen van de dimensie ‘Type grondslag’ voor middelgrote en grote rechtspersonen altijd met het domeinlid ‘Commercieel’ gebeurt. Vanuit het oogpunt van consistentie is deze dimensie wel in de entrypoints van zowel middelgrote als grote rechtspersonen opgenomen.

9.3.5 De toepassing van een preparer extension bij het opstellen van de jaarrekening

In hoofdstuk 10 wordt ingegaan op de functionaliteit voor het opstellen van een preparer extension. Bij het opstellen van het instance document komt de preparer extension ook al naar voren, aangezien de in de preparer extension gedefinieerde elementen ook gebruikt kunnen worden in het

71

instance document. Hierbij zit er technisch weinig verschil tussen het opstellen van een jaarrekening op basis van de KvK taxonomie of het opstellen van een jaarrekening op basis van een preparer extension. De verschillen zijn beperkt tot het aanroepen van het preparer extension schema als entrypoint (inclusief alle hiermee aangeroepen linkbases) en het gebruik van de ‘tags’ die gedefinieerd zijn in de preparer extension. Een softwareontwikkelaar die alleen de toepassing van een preparer extension wil faciliteren (en dus niet het opstellen van een preparer extension) dient rekening te houden met deze verschillen.

In plaats van het betreffende entrypoint van de KvK taxonomie op nltaxonomie.nl dient het (lokale) preparer extension schema gehanteerd te worden als entrypoint bij het @schemaRef.

Voorbeeld (..)

<link:schemaRef xlink:type="simple" xlink:href="pe-20170322-12345678-test.xsd"/>

(..)

Daarnaast zal het verschil zitten in de identificatie van het schema waarin het element is gedefinieerd middels de namespace en namespace prefix. Hier dient in geval van de in de preparer extension gedefinieerde elementen de namespace (en prefix) gehanteerd worden van het preparer extension schema.

Voorbeeld (..)

xmlns:pe-12345678="http://www.naamorganisatie.nl/pe-20171231-12345678”

(..)

<pe-12345678:Airplanes contextRef="FY17i_Commercial_Separate" unitRef="EUR" decimals="INF">500000</pe-12345678:Airplanes>

(..)

9.3.6 Verloopoverzichten

Het verloopoverzicht in een jaarrekening is een vast patroon waarin zowel een beginstand, een eindstand en de mutaties hiertussen worden opgenomen. Indien een eindstand en de mutaties worden opgenomen dient ook de beginstand vermeld te worden. De onderstaande tabel is een voorbeeld van een verloopoverzicht

Voorbeeld

Aandelenkapitaal Overige reserves TotaalEigen vermogen aan het begin van de periode 20.000 205.000 225.000

Allocatie van het resultaat - 220.000 220.000 Dividenduitkeringen - -10.000 -10.000

Mutatie in eigen vermogen - 210.000 210.000

Eigen vermogen aan het einde van de periode 20.000 415.000 435.000

72

Bij het realiseren van dit verloopoverzicht in het instance document moet gebruik worden gemaakt moet worden van negen verschillende contexten, één context voor elke unieke combinatie van domeinlid en periode. In het volgende voorbeeld is de context voor ‘Aandelenkapitaal aan het begin van de periode uitgewerkt’

Voorbeeld

<xbrli:context id="FY17i_Commercial_Separate_EquityMovement_ReservesOther"> <xbrli:entity>

<xbrli:identifier scheme="http://www.kvk.nl/kvk-id">12345678</xbrli:identifier> </xbrli:entity> <xbrli:period>

<xbrli:instant>2017-12-31</xbrli:instant> </xbrli:period> <xbrli:scenario> <xbrldi:explicitMember dimension="venj-bw2-dim:BasisOfPreparationAxis">venj-bw2- dm:CommercialMember</xbrldi:explicitMember> <xbrldi:explicitMember dimension="venj-bw2-dim:FinancialStatementsTypeAxis">venj-bw2- dm:SeparateMember</xbrldi:explicitMember> <xbrldi:explicitMember dimension="venj-bw2-dim:ClassesOfEquityAxis">venj-bw2- dm:ShareCapitalMember</xbrldi:explicitMember> </xbrli:scenario> </xbrli:context>

In het onderstaande voorbeeld staat het deel van het verloopoverzicht inzake de overige reserves opgenomen in XBRL formaat.

Voorbeeld (..)

<venj-bw2-i:Equity contextRef="FY16i_Commercial_Separate_ReservesOther" unitRef="EUR" decimals="-3">205000</venj-bw2-i:Equity>

<venj-bw2-i:EquityResultAllocation contextRef="FY17d_Commercial_Separate_ReservesOther" unitRef=“EUR” decimals=“-3”>220000</venj-bw2-i:EquityResultAllocation> <venj-bw2-i:EquityDividendDistribution contextRef="FY17d_Commercial_Separate_ReservesOther" unitRef=“EUR” decimals=“-3”>10000</venj-bw2-i:EquityDividendDistribution> <venj-bw2-i:EquityMovement contextRef="FY17d_Commercial_Separate_ReservesOther" unitRef=“EUR” decimals=“-3”>210000</venj-bw2-i:EquityMovement>

<venj-bw2-i:Equity contextRef="FY17i_Commercial_Separate_ReservesOther" unitRef="EUR" decimals="-

3">415000</venj-bw2-i:Equity>

(..)

9.3.7 Gebruik van ‘nil’ waardes in het instance document

Een waarde ‘nil’ houdt in dat er geen waarde bestaat voor een feit, bijvoorbeeld omdat de waarde niet te bepalen is. Bij het opstellen van een XBRL instance document op basis van de KvK taxonomie dient er geen feit opgenomen te worden indien de waarde hiervan ‘nil’ is. Er moet een reden zijn om het feit op te nemen in het XBRL instance document.

73

9.3.8 Technische validatie van het instance document

Het valideren van het opgestelde instance document is van groot belang. De jaarrekening in XBRL formaat dient valide te zijn ten opzichte van de van toepassing zijnde XBRL specificatie(s), de Filing Rules en de specifieke business rules die zijn opgesteld door de Kamer van Koophandel.

Valideren ten opzichte van de XBRL specificaties Het instance document dient XBRL valide te zijn. Hiervoor dient dit document gevalideerd te worden ten opzichte van de XBRL specificatie(s). Door middel van deze validatie methode kunnen onder meer onjuistheden in de gegevensinvoer worden geconstateerd. Zo zal het bijv. niet mogelijk zijn om een tekst (‘string’) op te nemen in een concept dat bestemd is voor een bedrag. Hetzelfde geldt ook voor het gebruiken van een ‘duration’ context voor een concept met een periodType ‘instant’. Het is van belang dat een instance document volledig voldoet aan de eisen die gesteld worden in de XBRL specificaties. Invalide instance documenten worden niet goedgekeurd door Digipoort voor verdere verwerking.

Valideren ten opzichte van Filing Rules Het XBRL instance document dient te voldoen aan de eisen in de Filing Rules. De Filing Rules zien toe op de gewenste syntax van een XBRL instance document. Het betreffen dus regels die voortvloeien uit de keuzes in de wijze hoe de XBRL specificatie wordt toegepast. Het instance document dient zowel te voldoen aan de generieke SBR Filing Rules als aan de KvK specifieke Filing Rules. De SBR Filing Rules, inclusief de relevante KvK Filing Rules zijn opgenomen in het document SBR Filing Rules. Indien een XBRL instance document niet voldoet aan de Filing Rules komt deze niet voor verdere verwerking in aanspraak.

In de SBR Filing Rules zijn ook zogenaamde SBR Filing guidelines opgenomen. Dit zijn best practices voor het opstellen van een XBRL instance document. Deze worden momenteel nog niet afgedwongen, waardoor het niet naleven hiervan geen gevolgen heeft. Het advies is om het XBRL instance document te laten voldoen aan deze guidelines.

In het kader van het deponeren van de jaarrekening bij de KvK zijn de volgende Filing Rules en Filing Guidelines actief in Digipoort:

Filing Rule / Guideline ActiefFR-NL-1.01 VFR-NL-1.02 VFR-NL-1.03 VFR-NL-1.04 -FR-NL-1.05 VFR-NL-1.06 -FR-NL-2.01 -FR-NL-2.02 -FR-NL-2.03 VFR-NL-2.04 VFR-NL-2.05 VFR-NL-2.06 VFR-NL-2.07 VFR-NL-3.01 VFR-NL-3.02 VFR-NL-3.03 V

74

FR-NL-3.04 VFR-NL-4.01 VFR-NL-4.02 VFR-NL-5.01 VFR-NL-5.02 VFR-NL-5.03 VFR-NL-5.04 VFR-NL-5.05 VFR-NL-5.06 VFR-NL-5.07 -FR-NL-5.08 -FR-NL-5.09 -FR-NL-5.10 VFR-NL-5.11 -FR-NL-5.12 VFR-NL-6.01 V

FG-NL-01 VFG-NL-02 VFG-NL-03 VFG-NL-04 VFG-NL-05 VFG-NL-06 -FG-NL-07 -FG-NL-08 -FG-NL-09 -FG-NL-10 -FG-NL-11 VFG-NL-12 -

FR-KVK-1.01 VFR-KVK-2.01 VFR-KVK-2.02 VFR-KVK-2.03 -FR-KVK-5.01 VFR-KVK-5.02 V

Valideren ten opzichte van Business Rules Business rules hebben tot doel om de inhoud van een jaarverantwoording, zoals opgenomen in het XBRL instance document, verder in te kaderen. De business rules worden door de KvK grotendeels beschikbaar gesteld in de KvK taxonomie in de vorm van XBRL formulas. Voor meer informatie over deze business rules wordt verwezen naar de Informatiegids voor de KvK taxonomie.

De Kamer van Koophandel valideert daarnaast op een aantal regels die niet door de business rules in de vorm van XBRL formulas kunnen worden gevalideerd ten behoeve van verwerking in het handelsregister. Deze business rules worden gepubliceerd in een apart document onder de titel KvK Business Rules. Het instance document wordt niet verder verwerkt indien niet aan deze KvK business rules wordt voldaan.

Tip: Gebruik de Aansluitsuite als hulpmiddel bij de technische validatie

75

Het is verstandig om de Aansluitsuite als hulpmiddel te gebruiken bij het technische valideren van een XBRL instance document. Op de Aansluitsuite kunnen alle technische validaties worden uitgevoerd, met uitzondering van het valideren van de KvK business rules.

76

10. Opstellen van een preparer extension


In het kader van het opstellen van een preparer extension is het van belang om kennis te nemen van de specificatie op het gebied van SBR preparer extensions. In deze specificatie wordt nader ingegaan op de toepassing van preparer extensions binnen SBR. Zie hiervoor ook hoofdstuk 21 in ‘Deel E –Specificaties’.

In dit hoofdstuk wordt ervanuit gegaan dat de lezer kennis en ervaring heeft met de technische werking van XBRL.

10.2 Een preparer extension nader uiteengezet

Er zijn verschillende scenario’s denkbaar waarvoor een preparer extension kan worden toegepast. In deze paragraaf zijn een aantal van deze scenario’s uitgewerkt ter illustratie van de technische implementatie van een preparer extension.

10.2.1 Importeren van een bestaand entrypoint uit de KvK taxonomie

Voor elke preparer extension geldt dat het schema van de preparer extension (hierna: PE schema) een import moet doen van een bestaand entrypoint uit de KvK taxonomie. Hiervoor wordt in de onderstaande scenario’s het entrypoint voor de middelgrote publicatiestukken als basis genomen. De URL van dit entrypoint is: http://www.nltaxonomie.nl/nt12/kvk/20171213/entrypoints/kvk-rpt-jaarverantwoording-2017-nlgaap-middelgroot-publicatiestukken.xsd.

Voorbeeld In preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-rpt.xsd

(..)

<xs:import namespace="http:// http://www.nltaxonomie.nl/nt12/kvk/20171213/entrypoints/kvk-rpt-jaarverantwoording-2017-nlgaap-middelgroot-publicatiestukken" schemaLocation="http://www.nltaxonomie.nl/nt12/kvk/20171213/entrypoints/kvk-rpt-jaarverantwoording-2017-nlgaap-middelgroot-publicatiestukken.xsd"/>

(..)

10.2.2 Uitzetten van elementen

Het uitzetten van elementen in de presentation of definition linkbase zorgt ervoor dat deze elementen niet langer kunnen worden gerapporteerd. Hiervoor zal de preparer extension de presentation of definition linkbase van de KvK taxonomie moeten aanpassen.

Om een element uit te zetten in de presentatie, wordt eerst onderzocht in welke extended linkrole (hierna: ELR) deze presentatie wordt gedefinieerd in de KvK taxonomie. In het onderstaande

77

voorbeeld is het de bedoeling om het concept rj-i_PaymentsEmployees uit te zetten in de ELR “urn:kvk:linkrole:cash-flow-statement”. Dit is de ELR van het (enkelvoudige) kasstroomoverzicht. In de presentation linkbase van de KvK taxonomie is te zien dat binnen deze ELR het concept dat we uit willen zetten (rj-i_PaymentsEmployees) met ordernummer 2 is gekoppeld middels een parent-child relatie aan het concept kvk-abstr_CashFlowOperatingActivitiesTitle. Dit concept is opgenomen in de kvk-cash-flow-statement-direct_m_g_pre.xml:

Voorbeeld In KvK taxonomie bestand: kvk-cash-flow-statement_m_g-pre.xml

<link:presentationLink xlink:role="urn:kvk:linkrole:cash-flow-statement" xlink:type="extended">

(..)

<link:loc xlink:href="kvk-abstracts.xsd#kvk-abstr_CashFlowOperatingActivitiesTitle" xlink:label="kvk-abstr_CashFlowOperatingActivitiesTitle_loc" xlink:type="locator"/>

<link:loc xlink:href="../../../rj/20171213/dictionary/rj-data.xsd#rj-i_PaymentsEmployees" xlink:label="rj-i_PaymentsEmployees_loc" xlink:type="locator"/>

<link:presentationArc order="2" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="kvk-abstr_CashFlowOperatingActivitiesTitle_loc" xlink:to="rj-i_PaymentsEmployees_loc" xlink:type="arc"/>

(..)

</link:presentationLink>

In de presentation linkbase van de preparer extension wordt dezelfde ELR aangeroepen middels een roleRef. Daarna kunnen binnen deze ELR de aanpassingen van de preparer extension worden vastgelegd. In het onderhevige voorbeeld wordt de hierboven vermelde presentationArc opgenomen, waarbij het @use="prohibited" attribuut meegegeven wordt. Hierdoor wordt de bestaande presentatierelatie in de KvK taxonomie uitgezet.

Voorbeeld In preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-pre.xml

(..)

<link:roleRef roleURI="urn:kvk:linkrole:cash-flow-statement" xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/dictionary/kvk-linkroles.xsd#kvk-lr_CashFlowStatement" xlink:type="simple"/>

(..)

<link:presentationLink xlink:role="urn:kvk:linkrole:cash-flow-statement" xlink:type="extended">

<link:loc xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/presentation/kvk-abstracts.xsd#kvk-abstr_CashFlowOperatingActivitiesTitle" xlink:label="kvk-abstr_CashFlowOperatingActivitiesTitle_loc" xlink:type="locator"/>

<link:loc xlink:href="http://www.nltaxonomie.nl/nt12/rj/20171213/dictionary/rj-data.xsd#rj-i_PaymentsEmployees" xlink:label="rj-i_PaymentsEmployees_loc" xlink:type="locator"/>

78

<link:presentationArc order="2" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="kvk-abstr_CashFlowOperatingActivitiesTitle_loc" xlink:to="rj-i_PaymentsEmployees_loc" use="prohibited" xlink:type="arc"/>


Uit de bovenstaande voorbeelden blijkt dat een verwijzing naar elementen uit de KvK taxonomie altijd door middel van absolute paden dient te gebeuren in een preparer extension. Een preparer extension kan alleen naar preparer extension bestanden verwijzen middels relatieve paden.

Om het geheel werkend te krijgen dient in het PE schema uiteraard een linkbaseRef opgenomen te worden naar de presentation linkbase van de preparer extension:

VoorbeeldIn preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-rpt.xsd

(..)

<link:linkbaseRef xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="pe-[jjjjmmdd]-[kvknummer]-pre.xml" xlink:role="http://www.xbrl.org/2003/role/presentationLinkbaseRef" xlink:type="simple"/>

(..)

Uitzetten van abstracte elementen Het scenario ‘uitzetten van elementen’ is uitgelegd aan de hand van een het uitzetten van een niet-abstract element, namelijk het concept rj-i_PaymentsEmployees. Het is echter ook mogelijk om abstracte elementen uit te zetten. Het meest gangbaar is het uitzetten van een domeinlid (sbr:domainMemberItem) die veelal als kolom zal functioneren binnen een tabel. Voor het uitzetten van een domeinlid kunnen dezelfde stappen worden gevolgd als bij het uitzetten van niet-abstracte elementen, waarbij de veranderingen niet plaats moeten vinden in de presentation linkbase maar in de definition linkbase.

Het is ook mogelijk om een sbr:presentationItem uit te zetten. Dit gebeurt op dezelfde wijze als hierboven beschreven. Het uitzetten van een presentationItem heeft echter ook gevolgen voor de children van dit presentationItem. De children moeten dan ook uitgezet of verplaatst worden.

10.2.3 Veranderen van de presentatievolgorde van concepten

Het is mogelijk om presentatievolgorde van concepten te veranderen met behulp van de presentation linkbase. In het onderstaande voorbeeld gaan hier we op in.

Om een bestaande presentatie volgorde te veranderen, wordt eerst onderzocht in welke extended linkrole (hierna: ELR) deze presentatie wordt gedefinieerd in de KvK taxonomie. In het onderstaande voorbeeld is het de bedoeling om de volgorde van concepten te veranderen in de ELR “urn:kvk:linkrole:income-statement”. Dit is de ELR van de (enkelvoudige) winst- en verliesrekening. Het gaat hier om de verandering in de presentatievolgorde van de concepten venj-bw2-i_ChangesInventoriesWorkInProgress met ordernummer 3 en venj-bw2-i_CapitalisedProductionCosts met ordernummer 5. De presentatievolgorde van deze concepten zijn opgenomen in het bestand: kvk-income-statement_m_g-pre.xml:

79

Voorbeeld In KvK taxonomie bestand: kvk-income-statement_m-pre.xml

<link:presentationLink xlink:role="urn:kvk:linkrole:income-statement-medium" xlink:type="extended">

(..)

<link:loc xlink:href="kvk-abstracts.xsd#kvk-abstr_IncomeStatementTitle" xlink:label="kvk-abstr_IncomeStatementTitle_loc" xlink:type="locator"/> <link:loc xlink:href="../../../venj/20171213/dictionary/venj-bw2-data.xsd#venj-bw2-i_CapitalisedProductionCosts" xlink:label="venj-bw2-i_CapitalisedProductionCosts_loc" xlink:type="locator"/> <link:loc xlink:href="../../../venj/20171213/dictionary/venj-bw2-data.xsd#venj-bw2-i_ChangesInventoriesWorkInProgress" xlink:label="venj-bw2-i_ChangesInventoriesWorkInProgress_loc" xlink:type="locator"/>

<link:presentationArc order="3" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="kvk-abstr_IncomeStatementTitle_loc" xlink:to="venj-bw2-i_ChangesInventoriesWorkInProgress_loc" xlink:type="arc"/>

<link:presentationArc order="5" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="kvk-abstr_IncomeStatementTitle_loc" xlink:to="venj-bw2-i_CapitalisedProductionCosts_loc" xlink:type="arc"/>

(..)


In de presentation linkbase van de preparer extension wordt dezelfde ELR aangeroepen middels een roleRef. Daarna kunnen binnen deze ELR de aanpassingen van de preparer extension worden vastgelegd. In het onderhevige voorbeeld wordt de hierboven vermelde concepten opgenomen waarvan de volgorde wordt veranderd. Dit gebeurd door aan de presentationArc andere order nummers te geven. Aangezien deze presentationArcs al een keer bestaan in dezelfde ELR dient eerst de bestaande presentationArc een @use=”prohibited” attribuut te krijgen. Hierdoor wordt de bestaande relatie in de KvK taxonomie uitgezet. Vervolgens kan een nieuwe presentationArcgemaakt worden tussen dezelfde concepten met een nieuw order nummer.

Aangezien het niet XML valide is om in één linkbase twee keer dezelfde presentationArc te hebben, moet er een nieuwe locator aangemaakt worden. Hiermee wordt de nieuwe presentationArc uniek. In het voorbeeld zijn daarom de extra locators venj-bw2-i_CapitalisedProductionCosts1_loc en venj-bw2-i_ChangesInventoriesWorkInProgress1_loc aangemaakt.

In preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-pre.xml

(..)

<link:roleRef roleURI="urn:kvk:linkrole:income-statement-medium" xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/dictionary/kvk-linkroles.xsd#kvk-lr_IncomeStatementMedium" xlink:type="simple"/>

(..)

80


<link:loc xlink:href="http://www.nltaxonomie.nl/nt12/venj/20171213/dictionary/venj-bw2-data.xsd#venj-bw2-i_CapitalisedProductionCosts" xlink:label="venj-bw2-i_CapitalisedProductionCosts_loc" xlink:type="locator"/> <link:loc xlink:href="http://www.nltaxonomie.nl/nt12/venj/20171213/dictionary/venj-bw2-data.xsd#venj-bw2-i_ChangesInventoriesWorkInProgress" xlink:label="venj-bw2-i_ChangesInventoriesWorkInProgress_loc" xlink:type="locator"/> <link:loc xlink:href="http://www.nltaxonomie.nl/nt12/venj/20171213/dictionary/venj-bw2-data.xsd#venj-bw2-i_CapitalisedProductionCosts" xlink:label="venj-bw2-i_CapitalisedProductionCosts1_loc" xlink:type="locator"/> <link:loc xlink:href="http://www.nltaxonomie.nl/nt12/venj/20171213/dictionary/venj-bw2-data.xsd#venj-bw2-i_ChangesInventoriesWorkInProgress" xlink:label="venj-bw2-i_ChangesInventoriesWorkInProgress1_loc" xlink:type="locator"/> <link:loc xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/presentation/kvk-abstracts.xsd#kvk-abstr_IncomeStatementTitle" xlink:label="kvk-abstr_IncomeStatementTitle_loc" xlink:type="locator"/>

<link:presentationArc order="3" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="kvk-abstr_IncomeStatementTitle_loc" xlink:to="venj-bw2-i_ChangesInventoriesWorkInProgress_loc" use="prohibited" xlink:type="arc"/> <link:presentationArc order="5" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="kvk-abstr_IncomeStatementTitle_loc" xlink:to="venj-bw2-i_CapitalisedProductionCosts_loc" use="prohibited" xlink:type="arc"/>

<link:presentationArc order="5" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="kvk-abstr_IncomeStatementTitle_loc" xlink:to="venj-bw2-i_ChangesInventoriesWorkInProgress1_loc" xlink:type="arc"/> <link:presentationArc order="3" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="kvk-abstr_IncomeStatementTitle_loc" xlink:to="venj-bw2-i_CapitalisedProductionCosts1_loc" xlink:type="arc"/>


Om het geheel werkend te krijgen dient in het PE schema uiteraard een linkbaseRef opgenomen te worden naar de presentation linkbase van de preparer extension, zoals ook reeds bij het scenario ‘uitzetten van elementen’ is opgenomen.

De presentatievolgorde van members (domeinleden) kan ook gewijzigd worden. Het aanpassen van de presentatievolgorde van domeinleden is vergelijkbaar met die van reguliere concepten. Het verschil is echter dat deze aanpassing alleen in de definition linkbase plaats moet vinden met behulp van een generic preferred label.

10.2.4 Veranderen van de presentatievolgorde van tabellen

Het veranderen van de presentatievolgorde van tabellen kan plaatsvinden door de presentation hierarchy te veranderen. De presentation hierarchy is een aparte generic linkbase waarin de gewenste presentatievolgorde van extended linkroles (ELRs) is opgenomen in de vorm van parent-child relaties. Aangezien elke tabel in een aparte ELR opgenomen moet worden, zorgt het aanpassen van de presentation hierarchy ervoor dat de presentatievolgorde van tabellen veranderd wordt. In de presentation hierarchy zijn soms meerdere tabellen ondergebracht onder één titel. In technische zin betekent dit dat bij een dergelijke groepering is dat één sbr:presentationItem de parent is van meerdere ELRs. De indeling van deze ELRs mag gewijzigd worden middels een preparer extension.

81

Om een bestaande presentatievolgorde te veranderen, moet eerst onderzocht worden welke ELRs van volgorde moeten veranderen. In het onderstaande voorbeeld is duidelijk dat de geconsolideerde balans eerst is opgenomen in de presentatievolgorde, gevolgd door de geconsolideerde winst- en verliesrekening. Dit gaan we met een preparer extension omdraaien.

Voorbeeld: In KvK taxonomie bestand: kvk-linkrole-presentation-hierarchy_g_k_m.xml

<gen:link xlink:role="http://www.xbrl.org/2008/role/link" xlink:type="extended">

(..)

<link:loc xlink:href="kvk-abstracts.xsd#kvk-abstr_ConsolidatedFinancialStatementTitle" xlink:label="kvk-abstr_ConsolidatedFinancialStatementTitle_loc" xlink:type="locator"/> <link:loc xlink:href="kvk-abstracts.xsd#kvk-abstr_ConsolidatedBalanceSheetTitle" xlink:label="kvk-abstr_ConsolidatedBalanceSheetTitle_loc" xlink:type="locator"/> <link:loc xlink:href="kvk-abstracts.xsd#kvk-abstr_ConsolidatedIncomeStatementTitle" xlink:label="kvk-abstr_ConsolidatedIncomeStatementTitle_loc" xlink:type="locator"/>

<gen:arc gpl:preferredLabel="http://www.xbrl.org/2008/role/terseLabel" order="1" xlink:arcrole="http://www.xbrl.org/2013/arcrole/parent-child" xlink:from="kvk-abstr_ConsolidatedFinancialStatementTitle_loc" xlink:to="kvk-abstr_ConsolidatedBalanceSheetTitle_loc" xlink:type="arc"/> <gen:arc gpl:preferredLabel="http://www.xbrl.org/2008/role/terseLabel" order="2" xlink:arcrole="http://www.xbrl.org/2013/arcrole/parent-child" xlink:from="kvk-abstr_ConsolidatedFinancialStatementTitle_loc" xlink:to="kvk-abstr_ConsolidatedIncomeStatementTitle_loc" xlink:type="arc"/> (..)

</gen:link>

Net als bij het veranderen van de presentatievolgorde van concepten moet hiervoor eerst de bestaande arc een @use=”prohibited” attribuut krijgen, om deze arc daarna van een nieuw order nummer te voorzien.

Voorbeeld: In preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-hie.xml

<gen:link xlink:role="http://www.xbrl.org/2008/role/link" xlink:type="extended">

(..)

<link:loc xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/presentation/kvk-abstracts.xsd#kvk-abstr_ConsolidatedFinancialStatementTitle" xlink:label="kvk-abstr_ConsolidatedFinancialStatementTitle_loc" xlink:type="locator"/> <link:loc xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/presentation/kvk-abstracts.xsd#kvk-abstr_ConsolidatedBalanceSheetTitle" xlink:label="kvk-abstr_ConsolidatedBalanceSheetTitle_loc" xlink:type="locator"/> <link:loc xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/presentation/kvk-abstracts.xsd#kvk-abstr_ConsolidatedIncomeStatementTitle" xlink:label="kvk-abstr_ConsolidatedIncomeStatementTitle_loc" xlink:type="locator"/> <link:loc xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/presentation/kvk-abstracts.xsd#kvk-abstr_ConsolidatedBalanceSheetTitle" xlink:label="kvk-abstr_ConsolidatedBalanceSheetTitle1_loc" xlink:type="locator"/>

82

<link:loc xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/presentation/kvk-abstracts.xsd#kvk-abstr_ConsolidatedIncomeStatementTitle" xlink:label="kvk-abstr_ConsolidatedIncomeStatementTitle1_loc" xlink:type="locator"/>

<gen:arc gpl:preferredLabel="http://www.xbrl.org/2008/role/terseLabel" order="1" xlink:arcrole="http://www.xbrl.org/2013/arcrole/parent-child" xlink:from="kvk-abstr_ConsolidatedFinancialStatementTitle_loc" xlink:to="kvk-abstr_ConsolidatedBalanceSheetTitle_loc" use="prohibited" xlink:type="arc"/> <gen:arc gpl:preferredLabel="http://www.xbrl.org/2008/role/terseLabel" order="2" xlink:arcrole="http://www.xbrl.org/2013/arcrole/parent-child" xlink:from="kvk-abstr_ConsolidatedFinancialStatementTitle_loc" xlink:to="kvk-abstr_ConsolidatedIncomeStatementTitle_loc" use="prohibited" xlink:type="arc"/>

<gen:arc gpl:preferredLabel="http://www.xbrl.org/2008/role/terseLabel" order="2" xlink:arcrole="http://www.xbrl.org/2013/arcrole/parent-child" xlink:from="kvk-abstr_ConsolidatedFinancialStatementTitle_loc" xlink:to="kvk-abstr_ConsolidatedBalanceSheetTitle1_loc" xlink:type="arc"/> <gen:arc gpl:preferredLabel="http://www.xbrl.org/2008/role/terseLabel" order="1" xlink:arcrole="http://www.xbrl.org/2013/arcrole/parent-child" xlink:from="kvk-abstr_ConsolidatedFinancialStatementTitle_loc" xlink:to="kvk-abstr_ConsolidatedIncomeStatementTitle1_loc" xlink:type="arc"/>

(..)

</gen:link>

Uiteraard dient deze linkbase ook aangeroepen te worden in het PE schema, net zoals eerder het geval was bij de presentation linkbase.


(..)

<link:linkbaseRef xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="pe-[jjjjmmdd]-[kvknummer]-hie.xml" xlink:role="http://www.xbrl.org/2008/role/link" xlink:type="simple"/>

(..)

10.2.5 Toevoegen van reeds bestaande elementen aan het entrypoint

Naast het veranderen van de presentatievolgorde is het ook mogelijk om bestaande elementen (zowel venj-bw2, rj en kvk) toe te voegen wanneer deze niet worden gebruikt door het geselecteerde entrypoint.

Om complicaties te voorkomen met de tabellen en formules is het aan te raden om elementen altijd toe te voegen op eenzelfde of onderliggend niveau als waar andere bestaande rapporteerbare elementen gepresenteerd zijn. Conceptueel ziet dit er als volgt uit:

• Bestaand abstract element (sbr:presentationItem) o Bestaand rapporteerbaar element o Nieuw rapporteerbare element 1 (aanbevolen)

• Nieuw rapporteerbare element 2 (af te raden)

83

Het nieuwe rapporteerbare element 1 staat op hetzelfde niveau als een bestaand rapporteerbaar element. Dit element is op het juiste niveau toegevoegd. Het nieuwe rapporteerbare element 2 staat op hetzelfde niveau als het bestaande abstract element. Op dit niveau staan geen andere rapporteerbare elementen. Het is daarom het af te raden om op dit niveau nieuwe elementen toe te voegen, aangezien dit niet goed zal tonen.

Hieronder gaan we nader in op een voorbeeld waarin de baten uit loterijen wordt toegevoegd aan de bedrijfsopbrengsten met behulp van een preparer extension. Hiervoor is het concept rj-i_LotteriesIncome beschikbaar in het RJ schema.

De eerste stap van het toevoegen van dit concept vindt plaats op basis van de presentation linkbase. Dit concept gaat worden toegevoegd binnen de ELR van de winst- en verliesrekening. Hiervoor moet in de presentation linkbase van de winst- en verliesrekening opgezocht worden welk ordernummer de concepten hebben waar het nieuwe concept tussen geplaatst gaat worden. Dit blijken de ordernummers ‘18’ en ‘19’ te zijn. Het nieuwe ordernummer hoeft geen geheel getal te vormen; het getal mag doormiddel van een punt een decimaal getal vormen. Hierdoor hoeven de ordernummers van de twee bestaande presentationArcs niet veranderd te worden. We hanteren dus het ordernummer ‘18.5’. Er moet daarom alleen een nieuwe presentationArc toegevoegd te worden naar het LotteriesIncome concept:


(..)

<link:roleRef roleURI="urn:kvk:linkrole:income-statement-medium" xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/dictionary/kvk-linkroles.xsd#kvk-lr_IncomeStatementMedium" xlink:type="simple"/>

(..)


<link:loc xlink:href="http://www.nltaxonomie.nl/nt12/rj/20171213/dictionary/rj-data.xsd#rj-i_LotteriesIncome" xlink:label="rj-i_LotteriesIncome_loc" xlink:type="locator"/> <link:loc xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/presentation/kvk-abstracts.xsd#kvk-abstr_IncomeStatementTitle" xlink:label="kvk-abstr_IncomeStatementTitle_loc" xlink:type="locator"/>

<link:presentationArc order="18.5" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="kvk-abstr_IncomeStatementTitle_loc" xlink:to="rj-i_LotteriesIncome_loc" xlink:type="arc"/>

(..)


De tweede stap van het toevoegen van dit concept vindt plaats op basis van de definition linkbase. Aangezien het element nog niet voorkwam in het entrypoint, komt dit element ook nog niet in een dimensionele structuur voor. Het is van belang om dit element toe te voegen aan de dimensionele structuur, aangezien dit anders niet met de juiste context gerapporteerd kan worden. Het element met dus aan de bestaande dimensionele structuur van de betreffende tabel worden gekoppeld. Dit kan plaatsvinden door het element rj-i_LotteriesIncome te verbinden aan de dimensionele structuur door middel van een definitionArc tussen sbr-dim_ValidationLineItems en rj-i_LotteriesIncome. Het

84

ordernummer is hier minder relevant, maar is het kader van consistentie gelijk gehouden aan die van de presentation linkbase.

Voorbeeld In preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-def.xml

(..)

<link:roleRef roleURI="urn:kvk:linkrole:income-statement-medium" xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/dictionary/kvk-linkroles.xsd#kvk-lr_IncomeStatementMedium" xlink:type="simple"/> <link:arcroleRef arcroleURI="http://xbrl.org/int/dim/arcrole/domain-member" xlink:href="http://www.xbrl.org/2005/xbrldt-2005.xsd#domain-member" xlink:type="simple"/>

(..)

<link:definitionLink xlink:role="urn:kvk:linkrole:income-statement-medium" xlink:type="extended">

<link:loc xlink:href="http://www.nltaxonomie.nl/2013/xbrl/sbr-dimensional-concepts.xsd#sbr-dim_ValidationLineItems" xlink:label="sbr-dim_ValidationLineItems_loc" xlink:type="locator"/> <link:loc xlink:href="http://www.nltaxonomie.nl/nt12/rj/20171213/dictionary/rj-data.xsd#rj-i_LotteriesIncome" xlink:label="rj-i_LotteriesIncome_loc" xlink:type="locator"/>

<link:definitionArc order="18.5" xlink:arcrole="http://xbrl.org/int/dim/arcrole/domain-member" xlink:from="sbr-dim_ValidationLineItems_loc" xlink:to="rj-i_LotteriesIncome_loc" xlink:type="arc"/>

</link:definitionLink>

Uiteraard dienen zowel de presentation als definition linkbases aangeroepen te worden in het PE schema.


(..)


<link:linkbaseRef xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="pe-[jjjjmmdd]-[kvknummer]-def.xml" xlink:role="http://www.xbrl.org/2003/role/definitionLinkbaseRef" xlink:type="simple"/>

(..)

Ook bestaande members (domeinleden) kunnen toegevoegd worden. Indien een bestaand domeinlid (sbr:domainMemberItem) wordt toegevoegd middels de preparer extension worden dezelfde stappen toegepast als bij het toevoegen van bestaande niet-abstracte concepten, met als uitzondering het toevoegen aan de presentation linkrole. Voor domeinleden is het toevoegen aan de relevante definition linkbases voldoende. In dit geval is het ordernummer wel relevant.

85

10.2.6 Toevoegen van nieuwe elementen

Indien er een element nodig is welke nog niet bestaat in de KvK taxonomie, mag een opsteller zelf een nieuw element aanmaken. Hiervoor dienen een aantal stappen doorlopen te worden:

• Het element dient aangemaakt te worden in het PE schema;

• Het element dient een standaard label te krijgen in de taal van het instance document;

• Het element dient een documentation label te krijgen in de taal van het instance document;

• Het element dient toegevoegd te worden in een presentation linkbase;

• Het element dient toegevoegd te worden aan een dimensionele structuur;

• Het element dient door middel van een general-special relatie aan een bestaand concept uit de NT verbonden te worden;

• Het element kan (optioneel) een referentie meegegeven worden.

In deze paragraaf gaan we uit van het scenario waarin we een nieuw element gaan toevoegen aan de balans.

Element aanmaken in het PE schema Het element dient aangemaakt te worden in het PE schema. Als voorbeeld wordt het element NewPreparerExtensionElement aangemaakt. Voor elementnamen geldt onder andere dat deze in UpperCamelCase gegeven moet worden (elk nieuw woord een hoofdletter, geen spaties tussen woorden). De elementnaam moet in de Engels taal gegeven worden en de elementnaam dient zelf verklarend te zijn.

Voorbeeld In preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-rpt.xsd

(..)

<xs:element abstract="false" id="pe-[kvknummer]_NewPreparerExtensionElement" name="NewPreparerExtensionElement" nillable="false" substitutionGroup="xbrli:item" type="nl-types:nonNegativeMonetaryNoDecimalsItemType" xbrli:balance="debit" xbrli:periodType="instant"/>

(..)

Standaard label toevoegen Aan elk nieuw aangemaakt element in de preparer extension dient een standaardlabel toegevoegd te worden. Dit label moet worden opgenomen in dezelfde taal als waar het instance document in aangeleverd wordt. Labels mogen in extra talen aangeleverd worden. De labels worden per taal gescheiden in linkbases.

Voorbeeld In preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-lab-nl.xml

<link:labelLink xlink:role="http://www.xbrl.org/2003/role/link" xlink:type="extended">

(..)

<link:loc xlink:href="pe-[jjjjmmdd]-[kvknummer]-rpt.xsd#pe-[kvknummer]_NewPreparerExtensionElement" xlink:label="NewPreparerExtensionElement_loc" xlink:type="locator"/>

86

<link:label id="pe-[kvknummer]_NewPreparerExtensionElement_label_nl" xlink:label="pe-[kvknummer]_NewPreparerExtensionElement_label_nl" xlink:role="http://www.xbrl.org/2003/role/label" xlink:type="resource" xml:lang="nl">Nieuw element in de preparer extension</link:label>

<link:labelArc xlink:arcrole="http://www.xbrl.org/2003/arcrole/concept-label" xlink:from="NewPreparerExtensionElement_loc" xlink:to="pe-[kvknummer]_NewPreparerExtensionElement_label_nl" xlink:type="arc"/>

(..)

</link:labelLink>

Documentation label toevoegen Aan nieuwe elementen moet ook een documentation label toegevoegd worden. Verschillende soorten labels komen wel in één linkbase voor. Dit houdt in dat het standaard label en de documentation label in één linkbase opgenomen worden.

Voorbeeld In preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-data-lab-nl.xml

<link:labelLink xlink:role="http://www.xbrl.org/2003/role/link" xlink:type="extended">

(..)

<link:label id="pe-[kvknummer]_NewPreparerExtensionElement_documentation_nl" xlink:label="pe-[kvknummer]_NewPreparerExtensionElement_documentation_nl" xlink:role="http://www.xbrl.org/2003/role/documentation" xlink:type="resource" xml:lang="nl">Dit is een documentation label van NewPreparerExtensionElement</link:label>

<link:labelArc xlink:arcrole="http://www.xbrl.org/2003/arcrole/concept-label" xlink:from="NewPreparerExtensionElement_loc" xlink:to="pe-[kvknummer]_NewPreparerExtensionElement_documentation_nl" xlink:type="arc"/>

(..)

</link:labelLink>

Toevoegen in de presentation linkbase Het nieuwe element moet toegevoegd worden aan de presentation linkbase in de ELR van de balans. Het element moet opgenomen worden als child van venj-bw2-i_AssetsNoncurrent met een order nummer van ‘3.5’, aangezien het tussen ‘3’ en ‘4’ in moet komen.


(..)

<link:roleRef roleURI="urn:kvk:linkrole:balance-sheet" xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/dictionary/kvk-linkroles.xsd#kvk-lr_BalanceSheet" xlink:type="simple"/>

(..)

<link:presentationLink xlink:role="urn:kvk:linkrole:balance-sheet" xlink:type="extended">

87

(..)

<link:loc xlink:href="pe-[jjjjmmdd]-[kvknummer]-rpt.xsd#pe-[kvknummer]_NewPreparerExtensionElement" xlink:label="pe-[kvknummer]_NewPreparerExtensionElement_loc" xlink:type="locator"/> <link:loc xlink:href="http://www.nltaxonomie.nl/nt12/venj/20171213/dictionary/venj-bw2-data.xsd#venj-bw2-i_AssetsNoncurrent" xlink:label="venj-bw2-i_AssetsNoncurrent_loc" xlink:type="locator"/>

<link:presentationArc order="3.5" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="venj-bw2-i_AssetsNoncurrent_loc" xlink:to="pe-[kvknummer]_NewPreparerExtensionElement_loc" xlink:type="arc"/>

(..)


Toevoegen aan dimensionele structuur Elk nieuw gedefinieerd element dient in een dimensionele structuur opgenomen te worden. In de KvK taxonomie hebben de dimensionele linkbases over het algemeen dezelfde ELRs als de presentation linkbase. Het element kan verbonden worden aan de dimensionele structuur door een definitionArc te leggen tussen sbr-dim_ValidationLineItems en het nieuw aangemaakte element in de definition linkbase:

Voorbeeld In preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-def.xml

(..)

<link:roleRef roleURI="urn:kvk:linkrole:balance-sheet" xlink:href="http://www.nltaxonomie.nl/nt12/kvk/20171213/dictionary/kvk-linkroles.xsd#kvk-lr_BalanceSheet" xlink:type="simple"/> <link:arcroleRef arcroleURI="http://xbrl.org/int/dim/arcrole/domain-member" xlink:href="http://www.xbrl.org/2005/xbrldt-2005.xsd#domain-member" xlink:type="simple"/>

(..)

<link:definitionLink xlink:role="urn:kvk:linkrole:balance-sheet" xlink:type="extended">

(..)

<link:loc xlink:href="http://www.nltaxonomie.nl/2013/xbrl/sbr-dimensional-concepts.xsd#sbr-dim_ValidationLineItems" xlink:label="sbr-dim_ValidationLineItems_loc" xlink:type="locator"/> <link:loc xlink:href="pe-[jjjjmmdd]-[kvknummer]-rpt.xsd#pe-[kvknummer]_NewPreparerExtensionElement" xlink:label="pe-[kvknummer]_NewPreparerExtensionElement_loc" xlink:type="locator"/>

<link:definitionArc order="19.1" xlink:arcrole="http://xbrl.org/int/dim/arcrole/domain-member" xlink:from="sbr-dim_ValidationLineItems_loc" xlink:to="pe-[kvknummer]_NewPreparerExtensionElement_loc" xlink:type="arc"/>

(..)


Toevoegen van general-special relatie (definition link)

88

Naast het opnemen van het element in een dimensionele structuur, moet het nieuwe element ook gekoppeld worden aan een bestaand element uit de KvK taxonomie waar het nieuwe element een verbijzondering van is. De koppeling wordt gemaakt met behulp van een general-special relatie. Deze relatie wordt gelegd in dezelfde definition linkbase als de dimensionele structuur, maar wel in een andere linkrole.

In preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-def.xml

(..)

<link:definitionLink xlink:role="http://www.xbrl.org/2003/role/link" xlink:type="extended">

<link:loc xlink:href="pe-[jjjjmmdd]-[kvknummer]-rpt.xsd#pe-[kvknummer]_NewPreparerExtensionElement" xlink:label="pe-[kvknummer]_NewPreparerExtensionElement_loc" xlink:type="locator"/> <link:loc xlink:href="http://www.nltaxonomie.nl/nt12/venj/20171213/dictionary/venj-bw2-data.xsd#venj-bw2-i_AssetsNoncurrent" xlink:label="venj-bw2-i_AssetsNoncurrent_loc" xlink:type="locator"/>

<link:definitionArc xlink:type="arc" xlink:from="venj-bw2-i_AssetsNoncurrent_loc" xlink:to="pe-[kvknummer]_NewPreparerExtensionElement_loc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/general-special"/>

(..)


Toevoegen van referenties (optioneel) Het is optioneel mogelijk om naast een label ook nog een referentie te geven aan nieuwe elementen. Hiervoor dient een reference linkbase aangemaakt te worden. Er mag een referentie gegeven worden naar bestaande rj en venj-bw2 referenties. Een andere mogelijkheid is om zelf een referentiebron op te geven.

Voorbeeld In preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-ref.xml

(..)

<link:loc xlink:href="pe-[jjjjmmdd]-[kvknummer]-rpt.xsd#pe-[kvknummer]_NewPreparerExtensionElement" xlink:label="pe-[kvknummer]_NewPreparerExtensionElement_loc" xlink:type="locator"/>

<link:referenceArc xlink:arcrole="http://www.xbrl.org/2003/arcrole/concept-reference" xlink:from="pe-[kvknummer]_NewPreparerExtensionElement_loc" xlink:to="pe-[kvknummer]_titel_1_1_ref" xlink:type="arc"/>

<link:reference id="pe-[kvknummer]_titel_1_1_ref" xlink:label="pe-[kvknummer]_titel_1_1_ref" xlink:role="http://www.xbrl.org/2003/role/reference" xlink:type="resource"> <ref:Name>Titel van bron voor eigen referentie</ref:Name> <ref:Chapter>1</ref:Chapter> <ref:Paragraph>1</ref:Paragraph> </link:reference>

(..)

Ten slotte moeten natuurlijk alle relevante linkbases worden aangeroepen door het PE schema.

89

Voorbeeld: In preparer extension bestand: pe-[jjjjmmdd]-[kvknummer]-rpt.xsd

(..)


<link:linkbaseRef xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="pe-[jjjjmmdd]-[kvknummer]-def.xml" xlink:role="http://www.xbrl.org/2003/role/definitionLinkbaseRef" xlink:type="simple"/>

<link:linkbaseRef xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="pe-[jjjjmmdd]-[kvknummer]-ref.xml" xlink:role="http://www.xbrl.org/2003/role/referenceLinkbaseRef" xlink:type="simple"/>

<link:linkbaseRef xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="pe-[jjjjmmdd]-[kvknummer]-lab-nl.xml" xlink:role="http://www.xbrl.org/2003/role/labelLinkbaseRef" xlink:type="simple"/>

(..)

10.2.7 Toevoegen van formulas

Het is mogelijk om formulas toe te voegen middels een preparer extension, aangezien het toevoegen van nieuwe elementen een impact kan hebben op de werking van de formulas. Het is aan te raden om eerst te testen of een formula al werkt, alvorens een formula linkbase op te nemen in de preparer extension. Wanneer nieuwe elementen op eenzelfde of een onderliggend niveau gepresenteerd worden als bestaande rapporteerbare elementen, zullen de meeste formulas deze nieuwe elementen automatisch meenemen. Het is niet mogelijk om een bestaande formula uit te zetten.

90

11. Opstellen van de accountantsverklaring in XBRL formaat

Het opstellen van de accountantsverklaring in XBRL formaat is technisch niet anders dan het opstellen van een jaarrekening in XBRL formaat. Hierdoor wordt verwezen naar hoofdstuk 9 voor de belangrijkste onderdelen van een XBRL instance document.

De bijzonderheden bij het opstellen van een accountantsverklaring in XBRL formaat zijn door de NBA uiteengezet in het document Handleiding bij de NBA Taxonomie 2.0. Zodoende wordt voor deze bijzonderheden verwezen naar dit document.

91

12. Renderen van de documenten

12.1 Renderen van de jaarrekening

Het renderen van de jaarrekening dient plaats te vinden op basis van de Consistente Presentatie specificatie (zie ook hoofdstuk 22). De Consistente Presentatie specificatie bevat de regels waaraan softwareontwikkelaars zich dienen te houden bij het realiseren van een rendering, waarbij zoveel als mogelijk gebruik gemaakt wordt van de beschikbare presentatiestructuren uit de KvK taxonomie. Deze regels zijn binnen SBR in Nederland opgesteld met het doel om alle gebruikers van een jaarrekening in staat te stellen om een eenduidig en voor mensen leesbaar beeld te krijgen van de gestructureerde gegevens in het XBRL instance document.

De technische wijze waarop de rendering tot stand komt is niet gedefinieerd in de Consistente Presentatie specificatie. Dit is aan elke softwareontwikkelaar om voor zichzelf te bepalen. Dit geldt ook voor het output formaat van de rendering. Dit staat een softwareontwikkelaar vrij. Een softwareontwikkelaar mag alleen de stelling innemen dat deze de Consistente Presentatie specificatie ondersteund, indien aan alle regels uit de Consistente Presentatie specificatie is voldaan.

12.2 Renderen van de accountantsverklaring

Ook bij de rendering van een accountantsverklaring in XBRL formaat is het noodzakelijk dat deze altijd op dezelfde (consistente) wijze wordt gerenderd. De Consistente Presentatie specificatie kan hiervoor echter niet zonder meer gebruikt worden. De Consistente Presentatie specificatie gaat namelijk uit van de beschikbaarheid van tabellen in een taxonomie. De NBA taxonomie bevat echter geen tabellen, waardoor aanvullende regels nodig zijn. De NBA heeft deze aanvullende regels opgesteld waarmee de Consistente Presentatie specificatie wel van toepassing wordt op de accountantsverklaring. Deze aanvullende regels zijn opgenomen in het document Handleiding bij de NBA taxonomie.

Deze aanvullende regels dienen in acht genomen te worden bij het renderen van een accountantsverklaring in XBRL formaat.

92

13. Ondertekenen en waarmerken


In het kader van het opstellen van een preparer extension is het van belang om kennis te nemen van de specificaties op het gebied van ondertekenen, met name SBR Linking & Signing en het SBR ondertekeningsbeleid. Zie hiervoor ook hoofdstukken 19 en 20 in ‘Deel E – Specificaties’.

Op basis van SBR Linking & Signing zal een digitale handtekening worden gezet met behulp van de XAdES (XML Advanced Electronic Signature) standaard. De techniek achter de elektronische handtekening wordt zowel gebruikt om een document te ondertekenen als het digitale equivalent van een ‘natte’ handtekening als om een document te waarmerken. In het kader van het deponeren van de jaarrekening bij de KvK betekent dit dat de accountant de accountantsverklaring zal ondertekenen en de jaarrekening (en eventuele preparer extension) zal waarmerken met dezelfde techniek. De elektronische handtekening is opgenomen in een zogenaamde ‘detached’ signature: een apart bestand waarin de handtekening op basis van de XAdES standaard is opgenomen. In het signature bestand wordt middels een hash de jaarrekening gewaarmerkt. In ditzelfde bestand wordt de accountantsverklaring ondertekend. Het verschil hiertussen zal de accountant expliciet aangeven op basis van het SBR ondertekeningsbeleid.

In dit hoofdstuk gaan we nader in op de handtekening op basis van de XAdES standaard. Hierbij wordt een bepaalde mate van technische kennis van XAdES verondersteld. Het is niet bedoeld als inleiding in XAdES, maar als uitleg omtrent de toepassing van XAdES bij het opstellen van de detached signature.

13.2 Ondertekenen en waarmerken nader uiteengezet

Op hoofdlijnen is de wijze waarop de detached signature tot stand komt te verdelen in de volgende stappen:

93

Figuur 7 – Stappen van totstandkoming detached signature

In de onderstaande paragrafen worden deze stappen nader uiteengezet

13.2.1 Selectie van de jaarrekening en de bijbehorende accountantsverklaring

De eerste stap bestaat uit de selectie van de jaarrekening en de accountantsverklaring. De naamgeving moet geplaatst worden als URI en moet gelijk zijn aan de naamgeving van de documenten zoals deze in het SOAP-request zijn opgenomen.

Voorbeeld <?xml version="1.0" encoding="UTF-8"?>

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ds:SignedInfo> <ds:Reference URI="#xmldsig-signedproperties"> (..) </ds:Reference> <ds:Reference Id="xmldsig-ref0" URI="#jaarrekening.xbrl"> (..) </ds:Reference> <ds:Reference Id="xmldsig-ref1" URI="#accountantsverklaring.xbrl"> (..) </ds:Reference> (..)

13.2.2 Buitensluiten van de vaststellings- en contactgegevens

De volgende stap betreft het buitensluiten van de gegevens in de jaarrekening die geen onderdeel vormden van de door de accountant uitgevoerde controle. Dit zullen doorgaans de vaststellingsgegevens zijn. Omdat de vaststelling van de jaarrekening over het algemeen na het

94

waarmerken van de jaarrekening plaatsvindt, is het mogelijk dat de jaarrekening in XBRL formaat waarnaar verwezen wordt in de detached signature, hierdoor wijzigt na het waarmerken. Dit heeft als gevolg dat de hash-waarde veranderd. Om dit te voorkomen zullen de elementen die betrekking hebben op de vaststelling van de jaarrekening geen invloed moeten hebben op de hash-berekening.

Daarnaast is het voor de KvK vanuit privacy overwegingen noodzakelijk het e-mailadres van de contactpersoon voor de rapportage niet mee bij de publicatie in het handelsregister. Zodoende verwijdert de KvK dit element uit het ontvangen XBRL instance document. Zodoende moet ook dit element, net als de vaststellingsgegevens, buitengesloten worden:

Dit buitensluiten is mogelijk door het gebruik van een transform mechanisme. Dit mechanisme faciliteert de toepassing van XPath, waarmee delen van een XBRL instance document geselecteerd kunnen worden. Het maakt hier gebruik van pad expressies om te navigeren binnen een XBRL instance document. Met een XPath-filter is het dan mogelijk om een subset van het XBRL instance document te bepalen. Met het XPath filter ‘subtract’ worden deze gegevens, tijdens het proces om tot een unieke digest (hash) te komen van de inhoud van XBRL instance, niet meegenomen.

De volgende elementen dienen buitengesloten worden in de detached signature door middel van een XPath filter:

• DocumentAdoptionDate

• DocumentAdoptionStatus

• EmailAddressContact

Een voorbeeld van dit XPath filter is: Filter="subtract">/xbrli:xbrl/*[local-name()='DocumentAdoptionStatus'

or local-name()='DocumentAdoptionDate' or local-name()='EmailAddressContact'] | //text()[normalize-space()='']

De bovenstaande query ziet er ingewikkeld uit. Als we de query opbreken in delen wordt het echter

een stuk eenvoudiger:

Onderdeel Uitleg/xbrli:xbrl/ Binnen het root-element xbrli:xbrl/*[] Wil ik alle top-level elementenlocal-name()='DocumentAdoptionStatus' or local-name()='DocumentAdoptionDate' or local-name()='EmailAddressContact'

Met de naam DocumentAdoptionStatus OFDocumentAdoptionDate OFEmailAddressContact

//text()[normalize-space()='']

Selecteer alle tekstNormaliseer de spaties

Voorbeeld (..)

<ds:Reference Id="xmldsig-ref0" URI="#jaarrekening.xbrl"> <ds:Transforms> (..) <ds:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"> <dsig-xpath:XPath xmlns:dsig-xpath="http://www.w3.org/2002/06/xmldsig-filter2" xmlns:xbrli="http://www.xbrl.org/2003/instance" Filter="subtract">/*/*[local-name()='DocumentAdoptionStatus' or local-name()='DocumentAdoptionDate' or local-name()=' EmailAddressContact'] | //text()[normalize-space()='']</dsig-xpath:XPath> </ds:Transform> </ds:Transforms>

95

</ds:Reference>

(..)

Het is ook mogelijk om in het filter de elementen te voorzien van prefix’en zodat eventuele naamgevingsconflicten kunnen worden voorkomen. Dit risico kan ontstaan bij het gebruik van preparer extensions, waarbij elementen worden toegevoegd met namen die ook aanwezig zijn in de KvK taxonomie.

Om ervoor te zorgen dat de elektronische handtekening op elk IT-systeem kan worden gecontroleerd, is het noodzakelijk dat de fysieke toestand van de bestanden (oftewel de eenduidige technische interpretatie) op alle IT-systemen gelijk is. Om dit te bereiken wordt gebruik gemaakt van een methodiek genaamd ‘canonicalisatie’.

Voor het zetten van een elektronische handtekening over XML-content geldt de best practice om canonicalisatie zonder comments te doen. Dit is de default toepassing in de XML DSIG specificatie en ook in de meeste libraries. Het toepassen van ‘with comments’ is overigens ook toegestaan.

De canonicalisatie wordt in deze stap zowel toegepast op de jaarrekening (nadat het subtract filter de relevante elementen heeft buitengesloten) en de accountantsverklaring.

Voorbeeld (..)

<ds:Reference Id="xmldsig-ref0" URI="#jaarrekening.xbrl"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></ds:Transform> <ds:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"> <dsig-xpath:XPath xmlns:dsig-xpath="http://www.w3.org/2002/06/xmldsig-filter2" xmlns:xbrli="http://www.xbrl.org/2003/instance" Filter="subtract">/*/*[local-name()='DocumentAdoptionStatus' or local-name()='DocumentAdoptionDate' or local-name()=' EmailAddressContact'] | //text()[normalize-space()='']</dsig-xpath:XPath> </ds:Transform> </ds:Transforms> (..) </ds:Reference>

(..)

13.2.3 Creatie van een unieke hash van de jaarrekening en de accountantsverklaring

In deze stap wordt op basis van de cryptografische functie SHA 256 (of hoger) van de gecanonicaliseerde documenten (jaarrekening en accountantsverklaring) een unieke digest (hash) gemaakt. Hiermee kan achteraf de integriteit van de documenten worden gecontroleerd en dient als basis voor de ondertekening.

Voorbeeld (..)

<ds:Reference Id="xmldsig-ref0" URI="#jaarrekening.xbrl"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></ds:Transform>

96

<ds:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"> <dsig-xpath:XPath xmlns:dsig-xpath="http://www.w3.org/2002/06/xmldsig-filter2" xmlns:xbrli="http://www.xbrl.org/2003/instance" Filter="subtract">/*/*[local-name()='DocumentAdoptionStatus' or local-name()='DocumentAdoptionDate' or local-name()=' EmailAddressContact'] | //text()[normalize-space()='']</dsig-xpath:XPath> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod> <ds:DigestValue>IU6vt3yHtBlTw3BpyaltKzHIo8/Pq0QfnRx2u1+bKKg=</ds:DigestValue> </ds:Reference>

(..)

13.2.4 Toevoegen van unieke object identificaties aan de hashes van de jaarrekening en de

accountantsverklaring

In stap 4 wordt de complete set (inhoud tuple ds:Reference) gekoppeld aan een unieke object identificatie. Dit gebeurt voor de jaarrekening en de accountsverklaring.

Voorbeeld (..)

<ds:Reference Id="xmldsig-ref0" URI="#jaarrekening.xbrl"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></ds:Transform> <ds:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"> <dsig-xpath:XPath xmlns:dsig-xpath="http://www.w3.org/2002/06/xmldsig-filter2" xmlns:xbrli="http://www.xbrl.org/2003/instance" Filter="subtract">/*/*[local-name()='DocumentAdoptionStatus' or local-name()='DocumentAdoptionDate' or local-name()=' EmailAddressContact'] | //text()[normalize-space()='']</dsig-xpath:XPath> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod> <ds:DigestValue>IU6vt3yHtBlTw3BpyaltKzHIo8/Pq0QfnRx2u1+bKKg=</ds:DigestValue> </ds:Reference>

<ds:Reference Id="xmldsig-ref1" URI="accountantsverklaring.xbrl"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod> <ds:DigestValue>afwbT6MQkeV/zBp2Zm2wdxX+FW/py08R/uqqm/qoGR0=</ds:DigestValue> </ds:Reference>

(..)

13.2.5 Beschrijvingen opnemen van de jaarrekening en de accountantsverklaring en deze koppelen

aan de unieke object identificaties

De XAdES standaard adviseert (MAY) om de ontvangende partij te informeren over de type bestanden die worden ontvangen. De standaard biedt hiervoor een aantal mogelijkheden. Hoewel het de verzendende partij vrij staat in de keuze hoe de ontvangende partij te informeren, wordt geadviseerd om minimaal de omschrijvingen van de jaarrekening en accountantsverklaring op te

97

nemen bij het element xades:DataObjectFormat. De gedefinieerde dataobjecten moeten via een identifier verwijzen naar de unieke object identificaties, zoals bepaald in stap 4. Hiermee wordt de informatie over een document gekoppeld aan het juiste document.

Voorbeeld (..)

<xades:SignedDataObjectProperties> <xades:DataObjectFormat ObjectReference="#xmldsig-ref0"> <xades:Description>Een jaarrekening in XBRL formaat</xades:Description> <xades:ObjectIdentifier> <xades:Identifier>jaarrekening.xbrl</xades:Identifier> </xades:ObjectIdentifier> <xades:MimeType>text/xml</xades:MimeType> <xades:Encoding>UTF-8</xades:Encoding> </xades:DataObjectFormat>

(..)

</xades:SignedDataObjectProperties>

(..)

13.2.6 Selectie van het ondertekeningsbeleid

In deze stap wordt het ondertekeningsbeleid op basis van een URN geselecteerd. De URN is als identifier in het XML-bestand van het SBR ondertekeningsbeleid opgenomen. Om de integriteit van het ondertekeningsbeleid te controleren wordt, na canonicalisatie, op basis van de cryptografische functie SHA 256 een unieke digest gemaakt.

Voorbeeld (..)

<xades:SignaturePolicyIdentifier> <xades:SignaturePolicyId> <xades:SigPolicyId> <xades:Identifier>urn:sbr:signature-policy:xml:2.0</xades:Identifier> </xades:SigPolicyId> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"> XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2" Filter="subtract">/*/*[local-name()='SignPolicyDigest']</XPath> </ds:Transform> <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></ds:Transform> </ds:Transforms> <xades:SigPolicyHash> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod> <ds:DigestValue>sVHhN1eqNH/PZ1B6h//ehyC1OwRQOrz/tJ3ZYaRrBgA=</ds:DigestValue> </xades:SigPolicyHash> </xades:SignaturePolicyId> </xades:SignaturePolicyIdentifier>

(..)

98

13.2.7 Opnemen van de commitments en deze koppelen aan de unieke object identificaties

In deze stap worden de commitments (de semantische waarde van de handtekening) opgenomen. De teksten dienen exact te voldoen aan de gespecifieerde teksten in het SBR ondertekeningsbeleid (signature policy). De commitment verwijst via de ObjectReference naar de unieke object identificaties.

Voorbeeld (..)

<xades:SignedDataObjectProperties> (..) <xades:CommitmentTypeIndication> <xades:CommitmentTypeId> <xades:Identifier>urn:sbr:signature-policy:proof-of-integrity-of-the-object-for-which-the-practitioner-expresses-an-opinion</xades:Identifier> </xades:CommitmentTypeId> <xades:ObjectReference>#xmldsig-ref0</xades:ObjectReference> </xades:CommitmentTypeIndication> <xades:CommitmentTypeIndication> <xades:CommitmentTypeId> <xades:Identifier>urn:sbr:signature-policy:proof-of-intent-of-practitioner-to-express-an-opinion</xades:Identifier> </xades:CommitmentTypeId> <xades:ObjectReference>#xmldsig-ref1</xades:ObjectReference> </xades:CommitmentTypeIndication> </xades:SignedDataObjectProperties> (..)

13.2.8 Creatie van een unieke hash van de ondertekeningseigenschappen

In deze stap worden de complete ondertekeningseigenschappen (beschrijvingen, ondertekeningsbeleid en commitments), inclusief het moment van ondertekenen (SigningTime) gecanonicaliseerd. Het gecanonicaliseerd resultaat wordt op basis van de cryptografische functie SHA 256 omgezet in een unieke digest (hash). Met deze digest kan de integriteit van de ondertekeningseigenschappen worden gecontroleerd en dient als basis voor de ondertekening (creatie SignatureValue).

Voorbeeld (..)

<ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#SignedProperties-123"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod> <ds:DigestValue>MY9srwqxf6XTv/Dgfsq+KKdaNipV0R7OVe+/pmt7FME=</ds:DigestValue> </ds:Reference>

(..)

99

13.2.9 Op basis van de drie hashes met behulp van de private sleutel van het persoonsgebonden

beroepscertificaat de digitale handtekening maken

In de laatste stap wordt met de private sleutel van het persoonsgebonden beroepscertificaat de SignatureValue berekend op basis van de 3 digests (hashes) uit stap 3 en 8.

Voorbeeld (..)

<ds:SignatureValue> LsAlH7oVGzzqSMYi6ARSGvRc1fKTky3+SQmssr557OaEvP4frkTg3W/zANsUX6b4WbnUZpHYb2hzayVV/Xz5sb5BmViuincqNxfqE4XA7CDfEx6zkPvjQDuSoNJyxsGvKl/megBag2oz/t+lJ4ZtOqtOYIdm0JOBumMundgl5nLzCppxGliUDuViu+0Cnnt7MRJJew7irHvT74xKua+uvMPfByXE3iJ5v8lHatbjj7xGNkvZi5r9v0X0LbpyGRlLYkaoT6OphmNf210t6OoPkyfGEWMX/apDzai1ggnoFh0ily9wkhZVo8XRrX0lVDR9mg/TnpCgZakU4fxPiN/XLw== </ds:SignatureValue>

(..)

Eveneens wordt in de detached signature onder X509Certificate de publieke sleutel van het persoonsgebonden beroepscertificaat opgenomen. Hiermee kan de SignatureValue worden gecontroleerd. In het onderstaande voorbeeld is een ingekorte (en niet langer valide) versie van de certificaatinformatie opgenomen.

Voorbeeld (..)

<ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIF/zCCA+egAwIBAgIGEgABICVIMA0GCSqGSIb3DQEBCwUAMDsxCzAJBgNVBAYTF4lZ4GwOBVN72HdOugptPnDkQmxTlRMc/KA9ymdeaV1Zo6PqwYacixMsit+i3g/uzFjb </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo>

(..)

13.3 Bijzonderheden uit de praktijk

In de vorige paragraaf is de detached signature op basis van de XAdES standaard uiteengezet op basis van een voorbeeld. In deze paragraaf gaan we nader in op een aantal bijzonderheden vanuit de praktijk waar softwareontwikkelaars tegen aan kunnen lopen bij het realiseren van de functionaliteit van het waarmerken en ondertekenen.

13.3.1 Waarmerken van een preparer extension

Wanneer een jaarrekening is opgesteld met behulp van een preparer extension, maken deze ook deel uit van de jaarrekening. Dit betekent dat de accountant alle bestanden van de preparer extension ook zal moeten waarmerken. Dit moet op dezelfde wijze plaatsvinden als het waarmerken van de jaarrekening, met uitzondering van het feit dat het XPath filter niet gebruikt hoeft te worden.

100

Voorbeeld (..)

<SignedDataObjectProperties> <DataObjectFormat ObjectReference="#xmldsig-ref0"> <Description>20171231-12345678-jaarrekening.xbrl</Description> </DataObjectFormat> <DataObjectFormat ObjectReference="#xmldsig-ref1"> <Description>pe-20171231-12345678-def.xml</Description> </DataObjectFormat> <DataObjectFormat ObjectReference="#xmldsig-ref2"> <Description>pe-20171231-12345678-lab-nl.xml</Description> </DataObjectFormat> <DataObjectFormat ObjectReference="#xmldsig-ref3"> <Description>pe-20171231-12345678-pre.xml</Description> </DataObjectFormat> <DataObjectFormat ObjectReference="#xmldsig-ref4"> <Description>pe-20171231-12345678-rpt.xsd</Description> </DataObjectFormat> <DataObjectFormat ObjectReference="#xmldsig-ref5"> <Description>20171231-12345678-controleverklaring.xbrl</Description> </DataObjectFormat> <CommitmentTypeIndication> <CommitmentTypeId> <Identifier>urn:sbr:signature-policy:proof-of-integrity-of-the-object-for-which-the-practitioner-expresses-an-opinion</Identifier> </CommitmentTypeId> <ObjectReference>#xmldsig-ref0</ObjectReference> </CommitmentTypeIndication> <CommitmentTypeIndication> <CommitmentTypeId> <Identifier>urn:sbr:signature-policy:proof-of-integrity-of-the-object-for-which-the-practitioner-expresses-an-opinion</Identifier> </CommitmentTypeId> <ObjectReference>#xmldsig-ref1</ObjectReference> </CommitmentTypeIndication> <CommitmentTypeIndication> <CommitmentTypeId> Identifier>urn:sbr:signature-policy:proof-of-integrity-of-the-object-for-which-the-practitioner-expresses-an-opinion</Identifier> </CommitmentTypeId> <ObjectReference>#xmldsig-ref2</ObjectReference> </CommitmentTypeIndication> <CommitmentTypeIndication> <CommitmentTypeId> <Identifier>urn:sbr:signature-policy:proof-of-integrity-of-the-object-for-which-the-practitioner-expresses-an-opinion</Identifier> </CommitmentTypeId> <ObjectReference>#xmldsig-ref3</ObjectReference> </CommitmentTypeIndication> <CommitmentTypeIndication> <CommitmentTypeId> <Identifier>urn:sbr:signature-policy:proof-of-integrity-of-the-object-for-which-the-practitioner-expresses-an-opinion</Identifier> </CommitmentTypeId> <ObjectReference>#xmldsig-ref4</ObjectReference>

101

</CommitmentTypeIndication> <CommitmentTypeIndication> <CommitmentTypeId> <Identifier>urn:sbr:signature-policy:proof-of-intent-of-practitioner-to-add-a-copy-of-the-opinion</Identifier> </CommitmentTypeId> <ObjectReference>#xmldsig-ref5</ObjectReference> </CommitmentTypeIndication> </SignedDataObjectProperties>

(..)

13.3.2 Valideren van een detached signature

Naast het correct opstellen van de detached signature is het ook relevant dat ook een controle plaatsvindt op de technische en inhoudelijke correctheid van de detached signature. Een deel van de controles die uitgevoerd kunnen worden zijn hieronder uiteengezet:

• Verifieer dat de detached signature voldoet aan de XAdES-standaard en onderliggende technieken en standaarden.

o Controleer of de syntax van de detached signature correct is. o Controleer of het juiste versie van de XAdES-standaard gebruikt is.

• Verifieer dat de detached signature voldoet aan de eisen met betrekking tot het toepassen van het ondertekeningsbeleid.

o Controleer op de aanwezigheid van een verwijzing naar een signature policy. o Stel vast of de gebruikte signature policy van toepassing is. o Controleer bij de verwijzing naar de signature policy op het toepassen van dezelfde

filters als in de signature policy zelf gebruikt zijn, en op de juistheid van de hashwaarde.

o Controleer of de in de detached signature toegepaste commitment types voorkomen binnen de signature policy.

o Controleer of het juiste soort commitment types gebruikt is.

• Verifieer dat de detached signature voldoet aan de eisen met betrekking tot de verwijzing naar externe documenten waar de detached signature betrekking op heeft.

o Controleer dat alle externe documenten waar in de detached signature naar verwezen wordt ook voorhanden zijn.

o Controleer dat voor de verwijzing naar externe documenten volgens de methode #bestandsnaam gebruikt wordt.

o Controleer dat voor het bepalen van de hashwaarde van externe documenten alleen hashalgoritmen gebruikt worden welke zijn toegestaan.

o Controleer dat de opgegeven hashwaarden bij de verwijzingen naar externe documenten correct zijn.

o Controleer dat het gebruik van filters voldoet aan de wensen of afspraken.

• Verifieer dat de detached signature is getekend middels een juist en valide certificaat. o Controleer op de aanwezigheid van de publieke sleutel. o Controleer dat het gebruikte certificaat afkomstig is van een intermediate CA welke

erkend is. o Controleer dat het gebruikte certificaat beschikt over een juiste functietitel. o Controleer dat het certificaat geldig was op het moment van ondertekenen. o Controleer dat het certificaat geldig is tijdens moment van controle. o Controleer dat het gebruikte certificaat op moment van ondertekenen niet op de CRL

aanwezig was.

102

o Controleer dat het gebruikte certificaat op moment van controle niet op de CRL aanwezig is.

103

14. Deponeren van de jaarrekening


In het kader van het deponeren van een jaarrekening is het van belang om kennis te nemen van de specificaties ‘SBR koppelvlakken’. ‘SBR i-processen’ en ‘KvK backoffice’. Zie hiervoor ook hoofdstukken 17, 18 en 23 in ‘Deel E – Specificaties’.

In dit hoofdstuk gaan we nader in op het deponeren bij Digipoort. Dit deponeren vindt plaats op basis van een SOAP (Simple Object Access Protocol) bericht. Dit is het protocol dat door SBR gebruikt wordt voor communicatie tussen verschillende systemen. We veronderstellen een bepaalde mate van technische kennis van SOAP voor het aanleveren van berichten bij Digipoort.

14.2 Deponeren nader uiteengezet

Het proces van het deponeren van een jaarrekening start met het aanleveren van een aanleververzoek (aanleverRequest). Het aanleververzoek is te zien als een geadresseerde envelop met inhoud. Bij ontvangst van het aanleververzoek zal Digipoort een aantal controles uitvoeren. Dit kan resulteren in een terugkoppeling van foutcodes en/of statussen. Op basis van deze terugkoppeling is op te maken of de aanlevering succesvol is en of de jaarrekening ook correct is gedeponeerd bij de KvK.

In deze paragraaf gaan we eerst uitgebreid in op het aanleververzoek en daarna een terugkoppeling vanuit Digipoort en de KvK.

14.2.1 Aanleververzoek

Het aanleververzoek is opgenomen in de ‘body’ van een SOAP envelop op basis van het koppelvlak WUS2.0 voor bedrijven v1.2. Voor meer gedetailleerde informatie hieromtrent verwijzen we naar de specificatie van de SBR koppelvlakken in hoofdstuk 17. In het onderstaande voorbeeld is opgenomen waar het aanleververzoek zich binnen de SOAP envelop bevind.

Voorbeeld <soapenv:Envelope xmlns:ns="http://logius.nl/digipoort/koppelvlakservices/1.2/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">

(..)

</soapenv:Header> <soapenv:Body wsu:Id="id-5B52204EC3428E2A811506688080138140" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <ns:aanleverRequest>

(..)

</ns:aanleverRequest> </soapenv:Body> </soapenv:Envelope>

104

In de specificatie van een aanleververzoek (aanleverRequest) zijn verschillende onderliggende elementen beschreven. Het is afhankelijk van de berichtstroom of een onderliggend element verplicht, optioneel of niet toegestaan is. Ook de waarde van het element kan afhankelijk zijn van de berichtstroom.

Berichtsoort Het element ‘berichtsoort’ beschrijft het soort verwerkingsproces dat met een aanleververzoek wordt geïnitieerd. De waarde van het element berichtsoort moet van een type zijn dat binnen Digipoort bekend is. Voor de aanlevering van een jaarrekening bij de KvK zijn de berichtsoorten voor respectievelijk de jaarrekening, de jaarrekening met preparer extension, de jaarrekening met acocuntantsverklaring en de jaarrekening met preparer extension en accountantsverklaring:

• Jaarrekening

• Jaarrekening_PE

• Jaarrekening_AV

• Jaarrekening_AV_PE

Voorbeeld (..)

<ns:aanleverRequest> <ns:berichtsoort>Jaarrekening_AV</ns:berichtsoort> (..)

</ns:aanleverRequest>

(..)

Aanleverkenmerk Het aanleverkenmerk bevat een eigen kenmerk dat door de aanleverende partij aan het aanleververzoek is meegegeven. Dit optionele kenmerk blijft het verdere proces onveranderd en stelt de aanleveraar in staat retourberichten te relateren aan het aanleververzoek. Het is aan de aanleverende partij om hier een eigen kenmerk aan te geven.

Voorbeeld (..)

<ns:aanleverRequest> <ns:berichtsoort>Jaarrekening_AV</ns:berichtsoort> <ns:aanleverkenmerk>Een kenmerk van de jaarrekening</ns:aanleverkenmerk> (..)


(..)

IdentiteitBelanghebbende De identiteit van de belanghebbende is een nummer waarmee degene op wie de inhoud van het bedrijfsdocument betrekking heeft (of die verantwoordelijk is voor het kennisnemen daarvan) kan worden geïdentificeerd. Dit is altijd het KvK-nummer van de deponerende rechtspersoon.

Voorbeeld

105

(..)

<ns:aanleverRequest> <ns:berichtsoort>Jaarrekening_AV</ns:berichtsoort> <ns:aanleverkenmerk>Een kenmerk van de jaarrekening</ns:aanleverkenmerk> <ns:identiteitBelanghebbende> <ns:nummer>12345678</ns:nummer> <ns:type>KvK</ns:type> </ns:identiteitBelanghebbende>

(..)


(..)

rolBelanghebbende Een aanduiding van de rol van de belanghebbende in het verwerkingsproces. Hier bestaat de keuze uit de volgende mogelijkheden: Software ontwikkelaar, Intermediair, Servicebureau of Verantwoordingsplichtige.

Voorbeeld (..)

<ns:aanleverRequest> <ns:berichtsoort>Jaarrekening_AV</ns:berichtsoort> <ns:aanleverkenmerk>Een kenmerk van de jaarrekening</ns:aanleverkenmerk> <ns:identiteitBelanghebbende> <ns:nummer>12345678</ns:nummer> <ns:type>KvK</ns:type> </ns:identiteitBelanghebbende> <ns:rolBelanghebbende>Verantwoordingsplichtige</ns:rolBelanghebbende>

(..)


(..)

berichtInhoud De berichtinhoud is het hoofddocument en moet altijd het XBRL instance document van de jaarrekening bevatten. De berichtinhoud bestaat uit een drietal onderliggende elementen. In het element mimeType dient het mimetype ‘application/xml’ of ‘text/xml’ opgenomen te worden. In het element bestandsnaam de naam van de jaarrekening. Deze naam moet ook gelijk zijn aan de naam die de jaarrekening heeft gekregen in een eventuele detached signature. In het element inhoud is de Base64-encoded versie van de jaarrekening in XBRL formaat opgenomen.

Voorbeeld (..)

<ns:aanleverRequest> <ns:berichtsoort>Jaarrekening_AV</ns:berichtsoort> <ns:aanleverkenmerk>Een kenmerk van de jaarrekening</ns:aanleverkenmerk> <ns:identiteitBelanghebbende>

106

<ns:nummer>12345678</ns:nummer> <ns:type>KvK</ns:type> </ns:identiteitBelanghebbende> <ns:rolBelanghebbende>Verantwoordingsplichtige</ns:rolBelanghebbende> <ns:berichtInhoud> <ns:mimeType>application/xml</ns:mimeType> <ns:bestandsnaam>jaarrekening.xbrl</ns:bestandsnaam> <ns:inhoud>PD94bWwgdmVyc2lvbj0iMS4</ns:inhoud> </ns:berichtInhoud>

(..)


(..)

De maximale grootte van de bericht inhoud is 20 MB (base64-gecodeerd). Dit is de totale grootte van de berichten inclusief mogelijke bijlagen.

berichtBijlagen In sommige gevallen moet er meer worden ingestuurd naar de KvK dan alleen het XBRL instance document van de jaarrekening. Dit is het geval bij het deponeren van een jaarrekening met preparer extension, jaarrekening met accountantsverklaring of jaarrekening met preparer extension en accountantsverklaring. De aanvullende documenten zijn in dit geval de verschillende bestanden van een preparer extension en/of de accountantsverklaring in XBRL formaat en de detached signature.

Deze bestanden dienen elk te worden toegevoegd in het aanleververzoek als berichtBijlage. Er komen daarom meerdere berichtBijlage elementen voor in een aanleververzoek. Net als bij de berichtInhoud, bestaat een berichtBijlage ook uit de elementen mimeType, bestandsnaam en inhoud.

Bij een jaarrekening met accountantsverklaring zijn de accountantsverklaring en de detached signature als berichtBijlage opgenomen. Het element mimeType heeft de waarde ‘application/xml’. Het element bestandsnaam bevat de naam van het betreffende bestand. Voor de accountantsverklaring moet dit gelijk zijn aan de naam die de accountantsverklaring heeft gekregen in de detached signature. Het element inhoud bevat de Base64-encoded versie van de accountantsverklaring in XBRL formaat of de Base64-encoded versie van de detached signature.

Voorbeeld (..)

<ns:aanleverRequest> <ns:berichtsoort>Jaarrekening_AV</ns:berichtsoort> <ns:aanleverkenmerk>Een kenmerk van de jaarrekening</ns:aanleverkenmerk> <ns:identiteitBelanghebbende> <ns:nummer>12345678</ns:nummer> <ns:type>KvK</ns:type> </ns:identiteitBelanghebbende> <ns:rolBelanghebbende>Verantwoordingsplichtige</ns:rolBelanghebbende> <ns:berichtInhoud> <ns:mimeType>application/xml</ns:mimeType> <ns:bestandsnaam>jaarrekening.xbrl</ns:bestandsnaam> <ns:inhoud>PD94bWwgdmVyc2lvbj0iMS4</ns:inhoud>

107

</ns:berichtInhoud> <ns:berichtBijlagen> <ns:bijlage> <ns:mimeType>application/xml</ns:mimeType> <ns:bestandsnaam>accountantsverklaring.xbrl</ns:bestandsnaam> <ns:inhoud>PD94bWwgdmVyc2lvb=</ns:inhoud> </ns:bijlage> <ns:bijlage> <ns:mimeType>application/xml</ns:mimeType> <ns:bestandsnaam>detached_signature.xml</ns:bestandsnaam> <ns:inhoud>FdfgHVyZT4=</ns:inhoud> </ns:bijlage> </ns:berichtBijlagen> </ns:aanleverRequest>

(..)

Bij een jaarrekening met preparer extension zijn de verschillende bestanden van de preparer extension als berichtBijlage opgenomen. Het element mimeType heeft altijd de waarde ‘application/vnd.sbr.pe’ om te identificeren dat het preparer extension bestanden zijn. Het element bestandsnaam bevat de naam van het betreffende bestand. Deze moeten gelijk zijn aan de namen die binnen de preparer extension gehanteerd worden. Het element inhoud bevat de Base64-encoded versie van de preparer extension bestanden.

Voorbeeld (..)

<ns:aanleverRequest> <ns:berichtsoort>Jaarrekening_AV</ns:berichtsoort> <ns:aanleverkenmerk>Een kenmerk van de jaarrekening</ns:aanleverkenmerk> <ns:identiteitBelanghebbende> <ns:nummer>12345678</ns:nummer> <ns:type>KvK</ns:type> </ns:identiteitBelanghebbende> <ns:rolBelanghebbende>Verantwoordingsplichtige</ns:rolBelanghebbende> <ns:berichtInhoud> <ns:mimeType>application/xml</ns:mimeType> <ns:bestandsnaam>jaarrekening.xbrl</ns:bestandsnaam> <ns:inhoud>PD94bWwgdmVyc2lvbj0iMS4</ns:inhoud> </ns:berichtInhoud> <ns:berichtBijlagen> <ns:bijlage> <ns:mimeType>application/vnd.sbr.pe</ns:mimeType> <ns:bestandsnaam>pe-[jjmmdd]-[kvknummer]-pre.xml</ns:bestandsnaam> <ns:inhoud>PD94bxpbmtiYXNlPg==</ns:inhoud> </ns:bijlage> <ns:bijlage> <ns:mimeType>application/vnd.sbr.pe</ns:mimeType> <ns:bestandsnaam>pe-[jjmmdd]-[kvknummer]-rpt.xsd</ns:bestandsnaam> <ns:inhoud>PD94bWwgdmVyc2lvbj0iMS4wIiBlbm=</ns:inhoud> </ns:bijlage> </ns:berichtBijlagen> </ns:aanleverRequest>

(..)

108

In het geval van een jaarrekening met preparer extension en accountantsverklaring worden de bovenstaande bijlagen opgenomen in het aanleververzoek.

14.2.2 Terugkoppeling vanuit Digipoort en de KvK

Bij ontvangst van het aanleververzoek zal Digipoort een bevestiging van ontvangst retourneren voorzien van een ontvangstkenmerk waarmee het bericht uniek geïdentificeerd kan worden. De specificaties hiervan zijn opgenomen in de Servicebeschrijving Digipoort WUS 2.0 Bedrijven Aanleveren Koppelvlakversie 1.2.

Na de bevestiging van de ontvangst zal Digipoort een aantal controles uitvoeren op de aangeleverde documenten alvorens de documenten door te sturen naar de Kamer van Koophandel. De validaties die hier plaatsvinden variëren per berichtstroom. Deze validaties zijn beschreven in hoofdstuk 18 ‘SBR i-processen’.

Indien de aangeleverde documenten alle validaties in Digipoort succesvol heeft doorlopen, worden deze naar de KvK gestuurd. De documenten doorlopen ook in bij de KvK diverse validaties alvorens in het handelsregister gedeponeerd te worden. Deze validaties zijn beschreven in hoofdstuk 22 ‘KvK backoffice’.

De terugkoppeling vanuit Digipoort en de KvK bestaat uit foutcodes en/of statussen. Op basis van deze terugkoppeling is op te maken of de jaarrekening is gedeponeerd bij de KvK of dat er ergens in het proces iets is misgegaan. Voor alle checks zijn foutcodes gedefinieerd welke teruggegeven worden mocht de fout zich voordoen.

De specificaties voor het opvragen van de status zijn opgenomen in het document Servicebeschrijving Digipoort WUS 2.0 Bedrijven Statusinformatie Koppelvlakversie 1.2.

109

DEEL E - SPECIFICATIES

110

15. Deponeren van de jaarrekening via Digipoort

Het deponeren van de jaarrekening met SBR bij het handelsregister van de Kamer van Koophandel verloopt via Digipoort. Digipoort is de procesinfrastructuur die overheidspartijen gebruiken om verantwoordingsrapportages in een gestructureerd formaat te ontvangen. In de basis werkt Digipoort in drie stappen:

1. Een organisatie stuurt een envelop met adresgegevens (elektronisch bericht) waar documenten aan zijn toegevoegd, naar Digipoort.

2. Digipoort sorteert de documenten uit het bericht, voert eventuele validaties uit en kijkt voor welke overheidsinstelling ze bestemd zijn.

3. Digipoort levert het bericht met de juiste documenten af bij de juiste ontvanger(s).

Deze drie stappen zijn gevisualiseerd in de onderstaande figuur:

Figuur 8 – SBR oplossing (bron: De Keten Uitgedaagd)

In de bovenstaande figuur leveren organisaties A, B en C een verantwoordingsrapportage aan bij Digipoort via de relevante koppelvlakken. De aanleveraars ontvangen hierbij een ontvangstbevestiging met een kenmerk waarmee zij de status van de aanlevering kunnen opvragen. Het aangeleverde bericht doorloopt de verschillende verwerkingsservices die zijn beschreven in de processpecificaties. Na succesvolle validatie wordt het aanleverde bericht afgeleverd bij de betreffende uitvragende partij via de relevante koppelvlakken. De verrichtingen in het verantwoordingsproces die worden uitgevoerd door Digipoort noemen we ook wel het i-proces. Na de ontvangst vanuit Digipoort voert uitvragende partij I in de bovenstaande figuur waar nodig aanvullende validaties uit en geeft hierover terugkoppeling via Digipoort.

De relevante specificaties voor dit proces zijn gebaseerd op de afspraken in het SBR afsprakenstelsel. Het SBR afsprakenstelsel beschrijft welke specificaties en standaarden moeten worden toegepast bij het inrichten van een SBR-verantwoordingsketen.

111

Specifieke toepassing ten behoeve van het deponeren bij de KvK Het deponeren van de jaarrekening bij de KvK werkt in overeenstemming met het bovenstaande. Een rechtspersoon verstuurt een elektronisch bericht bestaande uit de jaarrekening, eventuele preparer extension en/of accountantsverklaring en digitale handtekening naar Digipoort. De jaarrekening en eventuele bijbehorende documenten worden gevalideerd en, indien valide, doorgestuurd naar de Kamer van Koophandel voor verdere verwerking.

In het SBR afsprakenstelsel zijn de relevante specificaties opgenomen waarmee de informatieketen voor het deponeren van de jaarrekening tot stand is gekomen. Hierbij maken de specifieke specificaties voor SBR-verantwoordingen vaak gebruik van internationale standaarden, zoals XBRL, SOAP, XAdES en BPMN. Deze sectie gaat niet zelfstandig in op deze standaarden, maar richt zich uitsluitend in op de SBR-specifieke specificaties.

Ten behoeve van het deponeren van de jaarrekening bij de Kamer van Koophandel zijn de volgende specificaties te onderkennen:

Specificaties Jaarrekening Jaarrekening & preparer extension

Jaarrekening & accountants-verklaring

Jaarrekening & preparer extension & accountants-verklaring

SBR instances & taxonomieën V V V V

SBR koppelvlakken V V V V

SBR i-processen V V V V

SBR linking & signing - - V V

SBR ondertekeningsbeleid - - V V

SBR Preparer Extensions - V - V

SBR Consistente Presentatie V V V V

KvK backoffice V V V V

Tabel 7 – Relevante specificaties voor het deponeren bij de KvK

Deze specificaties worden in de komende hoofdstukken toegelicht.

112

16. SBR instances & taxonomieën

16.1 Algemene toepassing

Binnen SBR speelt de XBRL standaard een belangrijke rol. Het is hierbij van belang om te beseffen dat de toepassing van XBRL gebaseerd is op een gelaagd model waarbij voor elke laag specificaties beschikbaar zijn. De basislaag is XML en elk daarboven liggende specificatielaag beperkt de functionaliteit c.q. breidt de functionaliteit uit van de onderliggende laag. De specificatielagen waarop XBRL instances en taxonomieën zijn gebaseerd, is op de volgende wijze schematisch weer te geven.

Figuur 9 - Schematische weergave van de XBRL toepassing binnen SBR

In algemene zin zorgt de toepassing van XBRL voor transparantie (semantiek, presentatie, onderlinge relaties) en consistentie (structuur en syntax) in de communicatie van de gegevenselementen. Deze eigenschappen van XBRL komen tot stand door het gebruik van diverse XML-standaarden.

XML-laag De basislaag is de XML laag. Dit betekent dat alle XBRL instances en taxonomieën volledig op XML zijn gebaseerd en om deze reden ook aan de eisen van de specificatie Extensible Markup Language (XML) 1.0 (Fifth Edition), met de releasedatum 26 november 2008, moeten voldoen. De normatieve locatie (vindplaats) voor de XML specificatie is: http://www.w3.org/TR/2008/ REC-xml-20081126/

De structuur en syntax worden vastgelegd met XML Schema Definition (XSD) specificatie. Deze specificatie van de basislaag is verdeeld in drie afzonderlijke delen:

• De primer, XML Schema Part 0: Primer Second Edition met de releasedatum 28 oktober 2004, dat de basisconcepten voor structuur en syntax behandelt. De primer is te vinden op de normatieve locatie: http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/

XBRL-laag

XBRL 2.1

SBR laag Architectuur NT SBR Filing Rules

KvK laag KvK Filing Rules

XML

XSD

XML-laag

XPointer XLink

Dimensions Formula Table

KvK Business Rules

113

• De structures, XML Schema Part 1: Structures Second Edition, met de releasedatum 28 oktober 2004, is het deel dat nader ingaat hoe structuren gedefinieerd dienen te worden in een XML-document en op welke wijze dat kan worden afgedwongen. Dit deel is te vinden op de volgende normatieve locatie: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/

• Het laatste deel, datatypes, XML Schema Part 2: Datatypes Second Edition, met een releasedatum 28 oktober 2004, behandelt op welke wijze de syntax van de afzonderlijke XML elementen vastgelegd dient te worden. De datatypes specificatie is te vinden op de normatieve locatie: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

De XML Linking Language (XLink) Version 1.0 specificatie met releasedatum 27 januari 2001 wordt gebruikt binnen de XBRL toepassing bij de creatie van extended linkroles. De extended linkroles zijn binnen de taxonomie verantwoordelijk voor het vastleggen van semantiek, presentatie en onderlinge relaties. De normatieve locatie voor de XLink specificatie is: http://www.w3.org/TR/2001/REC-xlink-20010627/

De XPointer Framework specificatie, met een releasedatum van 25 maart 2003, wordt gebruikt om vanuit de extended linkroles een verbinding te maken met de concepten in de XML schema’s. In de extended linkroles wordt dan een koppeling gemaakt tussen een concept en een specifieke definitie, zoals een presentatielabel. De normatieve locatie voor de XPointer Framework is http://www.w3.org/TR/2003/REC-xptr-framework-20030325/

Alle XML-lagen vallen onder de verantwoordelijkheid van de World Wide Web Consortium (W3C).

XBRL laag De tweede laag bestaat uit de XBRL specificatie. Deze specificatie beschrijft op een generieke wijze hoe, met de diverse XML standaarden, een taxonomie en een instance voor het rapporteren van financiële feiten vervaardigd dient te worden. De XBRL specificatie beperkt enerzijds de functionaliteit van de onderliggende XML standaarden en voegt anderzijds nieuwe functionaliteit toe. Beperking van functionaliteit bestaat bijvoorbeeld uit het negeren van attributen. Toevoegen van nieuwe functionaliteit is bijvoorbeeld het vervangen van alle standaard datatypes door nieuwe XBRL datatypes met additionele attributen. Hiermee wordt bijvoorbeeld afgedwongen dat elke monetaire waarde in een instance altijd gekoppeld is aan een valutasoort en een precisie indicatie.

Een overzicht van de laatste versies van de formele XBRL specificaties is gegeven op https://specifications.xbrl.org/specifications.html.

De formele XBRL specificatie is de Extensible Business Reporting Language (XBRL) 2.1 Recommendation 31 December 2003 with errata corrections to 20 February 2013 . De normatieve locatie voor de XBRL 2.1 specificatie is http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02-20.html.

De formele Dimensions specificatie is de XBRL Dimensions 1.0 Recommendation 18 September 2006 with errata corrections to 25 January 2012. De normatieve locatie voor de Dimensions specificatie is http://www.xbrl.org/specification/dimensions/rec-2012-01-25/dimensions-rec-2006-09-18+corrected-errata-2012-01-25-clean.html

De formele Tables specificatie is de Table Linkbase 1.0 Recommendation 18 March 2014 with errata corrections to 09 March 2016. De normatieve locatie voor de Table specificatie is

114

http://www.xbrl.org/Specification/table-linkbase/REC-2014-03-18/table-linkbase-REC-2014-03-18+corrected-errata-2016-03-09.html

De formele Formula specificatie is de Formula 1.0 Recommendation 22 June 2009. De normatieve locatie voor de Formula specificatie is https://specifications.xbrl.org/work-product-index-formula-formula-1.0.html

De XBRL specificatie wordt onderhouden door XBRL International.

SBR laag Specifiek voor de Nederlandse Taxonomie en de XBRL instances gebaseerd op de Nederlandse Taxonomie zijn aanvullende architectuurrichtlijnen en eisen opgesteld. In deze generieke gebruikerslaag zijn modeleringsregels vastgelegd voor de taxonomie en de instances.

De XBRL specificatie beschrijft, zoals hiervoor vermeld, op een generieke wijze hoe XML kan worden gebruikt voor het rapporteren van bedrijfsmatige feiten. Het rapporteren van bedrijfsmatige feiten kan vanuit meerdere invalshoeken gebeuren. Voor elke invalshoek kunnen specifieke architectuurgrondslagen aanwezig zijn.

Voor de Nederlandse Taxonomie zijn bovenop de XBRL specificaties aanvullende architectuurregels opgesteld. Deze regels zijn overgenomen in de Nederlandse Taxonomie Architectuur (NTA) regels. Het overzicht van deze regels is te vinden op de normatieve locatie: https://www.wikixl.nl/wiki/sbr/

De NTA geeft onder meer de afspraken weer over constructies die binnen de Nederlandse Taxonomie worden gebruikt. Een voorbeeld hiervan is de generic-linkrole order en de presentation hierarchy. Deze Nederlandse toevoeging zorgt ervoor dat linkroles gestructureerd kunnen worden. Deze extra constructies zijn vast gelegd in de NTA omdat de XBRL specificatie hier tot op heden geen specificatie voor heeft.

Voor de instances zijn ook aanvullende regels vastgelegd. De Filing rules bevatten de aanvullende eisen voor alle XBRL instances gebaseerd op de Nederlandse Taxonomie. De eisen zijn generiek voor alle rapportages. Bij elke uitlevering van een nieuwe Nederlandse Taxonomie worden de nieuwe Filing Rules gepubliceerd.

KvK laag De KvK stelt ook zelf nog aanvullende specifieke eisen aan een XBRL rapportage. Om deze reden zijn ook KvK specifieke Filing Rules en Business Rules opgemaakt. Deze worden net als de reguliere Filing rules bij elke nieuwe versie van de Nederlandse Taxonomie opgeleverd. De Filing Rules leggen regels vast die toezien op de gewenste syntax van een XBRL instance document. Het betreffen dus regels die voortvloeien uit de keuzes in de wijze hoe de XBRL specificatie wordt toegepast. Dit wijkt nadrukkelijk af van business rules die tot doel hebben om de inhoud van een jaarrekening zoals opgenomen in het XBRL instance document verder in te kaderen. Voorbeelden hiervan zijn verplichte elementen en optellingen.

De laatste versie van deze documenten zijn te vinden op de SBR website.

115

16.2 Specifieke toepassing ten behoeve van het deponeren bij de KvK

In aanvulling op hetgeen reeds opgenomen bij de algemene toepassing, is het relevant om kort in te gaan op de verschillende taxonomieën. Voor het deponeren van de jaarrekening bij de KvK zijn twee taxonomieën te onderkennen: de KvK taxonomie en de NBA taxonomie (NBAT).

16.2.1 KvK taxonomie

De KvK taxonomie bevat verschillende entrypoints waarin het raamwerk van de jaarrekening voor een specifieke situatie en/of rechtspersoon is opgenomen. Op basis van de inhoud van de KvK taxonomie kan een jaarrekening in XBRL formaat worden opgesteld. De gebruiker van de taxonomie mag erop vertrouwen dat de taxonomie een naar de stand van de wet- en regelgeving juiste en volledige set van begrippen bevat.

De ontwikkeling van de taxonomie voor de jaarverslaggeving kent een vaste jaarlijkse cyclus, met controle op inhoudelijke en technische kwaliteit, consultatie van de markt en publicatie. In dit kader verricht de Raad voor de Jaarverslaggeving jaarlijks specifiek overeengekomen werkzaamheden gericht op de geschiktheid van de Nederlandse Taxonomie voor het deponeren van de jaarrekeningen die zijn opgesteld in overeenstemming met de wettelijke bepalingen inzake de jaarrekening en de normen die in het maatschappelijk verkeer als aanvaardbaar worden beschouwd. Eventuele onjuistheden, onduidelijkheden, inconsistenties of omissies die als onderdeel van dit proces naar voren komen, worden door de Raad in de vorm van aanbevelingen gerapporteerd aan de Kamer van Koophandel, die verantwoordelijk is voor correctie en vervolmaking van de taxonomie.

De meest recente versie van de KvK taxonomie is versie 20171213 in de NT12; bedoeld voor de jaarrekening over boekjaren die aanvangen vanaf 1 januari 2017.

Meer informatie over de KvK taxonomie is te vinden op de SBR website: www.sbr-nl.nl

16.2.2 NBA taxonomie

De NBA taxonomie bevat verschillende entrypoints waarin het raamwerk van de accountantsverklaring is opgenomen. Op basis van de NBA taxonomie kan een accountantsverklaring in XBRL formaat worden opgesteld. Dit raamwerk structureert de verklaring, maar schrijft geen bewoordingen voor. De specifieke bewoordingen worden meestal door accountants bepaald met behulp van een verklaringengenerator.

De NBA taxonomie wordt beheerd door de Nederlandse Beroepsorganisatie van Accountants De meest recente versie van de NBA taxonomie is versie 2.0.

Meer informatie over de NBA taxonomie is te vinden op de NBA website: www.nba.nl/themas/ict/nba-taxonomie/

116

17. SBR koppelvlakken


De koppelvlakservices zijn de technische applicaties die berichten kunnen aannemen of bij een andere koppelvlakservice kunnen afleveren. Het kan gaan over inhoudelijke berichten of berichten waarin de status van de verwerking van een bericht is opgenomen. Omdat de koppelvlakservices voor de buitenwereld aanspreekbaar zijn bevatten zij de belangrijke controles voor toegangsbeveiliging. Binnen SBR is een standaard beveiligingsprotocol voor system-to-system verkeer gekozen. Er wordt op basis van een x.509 certificaat een dubbelzijdige beveiligde verbinding opgezet tussen een aanleverende partij en de koppelvlakservice. Tevens moet met eenzelfde soort certificaat het bericht verzegeld worden.

Het technische uitwisselingsprotocol binnen SBR is WUS (acroniem voor WSDL, UDDI en SOAP) 2.0 voor Bedrijven versie 1.2. Kort samengevat gebruikt het koppelvlak WUS voor Bedrijven 2.0 SOAP (Simple Object Access Protocol) als basis en vereist het een aantal aanvullende WS-specificaties, waaronder WS-security. WUS voor Bedrijven is gericht op verschillende aanleverende partijen met één endpoint; dat van Digipoort. Hierbij vindt authenticatie plaats op basis van een PKIoverheid (services) certificaat. Er gelden hierbij afspraken over de invulling van verplichte en verboden velden in het SOAP-bericht, er zijn eisen aan de gebruikte certificaten en er is een maximum berichtgrootte opgelegd. Alle afspraken met betrekking tot het elektronische berichtenverkeer via Digipoort middels WUS zijn opgenomen in het document Koppelvlakbeschrijving WUS 2.0 voor Bedrijven versie 1.2 van 20 april 2015.

De koppelvlakservices binnen SBR omvatten de aanleverservice, de afleverservice en de statusinformatieservice.

17.1.1 Aanleverservice

De aanleverservice stelt vast of het verantwoord is een aangeleverd bericht te accepteren. Via de koppelvlakken wordt de aanleverservice aangesproken door de aanleverende partij. De aanleverservice doorloopt per aangeleverd bericht een aantal handelingen. Deze handelingen zijn in te delen in berichtcontrole, procesinitiatie en feedback.

De eerste stap die de aanleverservice doorloopt, is de berichtcontrole. Het koppelvlak kent een aantal specificaties – eisen – waaraan de aangeleverde berichten moeten voldoen. De basiscontrole bestaat uit de volgende elementen:

• Controle op aanwezigheid van een bekende berichtsoort. Zonder berichtsoort weet de aanleverservice bij de procesinitiatie niet welke configuratie doorlopen moet worden.

• Controle op maximale berichtgrootte. De omvang van de aangeleverde berichten is gelimiteerd tot 20 MB om de performance van Digipoort te garanderen.

• Controle op aanwezigheid van verplichte elementen en afwezigheid van verboden elementen in het aanleverrequest.

• Controle op geldigheid van het gebruikte PKIoverheid certificaat.

Indien het bericht aan de specificaties van de basiscontrole voldoet, volgt de procesinitiatie. Het doel van de procesinitiatie is dat het bericht verder zal worden verwerkt door Digipoort en het af te leveren aan de uitvragende partij. Ten eerste wordt een berichtkenmerk aangemaakt om de

117

verwerking van het bericht te kunnen traceren. Op basis van de berichtsoort wordt het juiste type proces aangesproken. Het bericht wordt overgedragen voor verdere verwerking.

De laatste stap in de aanleverservice is de feedback. De aanleverservice geeft ook direct feedback aan de aanleverende partij omtrent de controle op aanleverspecificaties. De directe feedback houdt in, dat wordt aangegeven of het aangeleverde bericht verder wordt verwerkt of dat er een fout is opgetreden. Bij een fout wordt een toelichting gegeven, zodat de aanleverende partij gericht acties kan ondernemen om een bericht aan te leveren dat wel geaccepteerd wordt. De status van de verdere verwerking moet apart worden opgehaald.

Het adres van de aanleverservice (endpoint) van Digipoort is:

Pre-productieomgeving: https://preprod-dgp.procesinfrastructuur.nl/wus/2.0/aanleverservice/1.2

Productieomgeving https://dgp.procesinfrastructuur.nl/wus/2.0/aanleverservice/1.2

Een gedetailleerde beschrijving van het aanleveren van gestructureerde elektronische berichten via Digipoort is opgenomen in versie 1.1 van het document Servicebeschrijving Digipoort WUS 2.0 Bedrijven Aanleveren Koppelvlakversie 1.2 van 27 maart 2015.

17.1.2 Statusinformatieservice

Door middel van de statusinformatieservice kan een aanleverende partij van elk aangeleverd bericht de actuele status opvragen. Voor het opvragen van de status worden dezelfde koppelvlakken gebruikt als bij het aanleveren. De statusinformatieservice wordt wel via een ander endpoint aangesproken.

De aanleverende partij heeft bij het aanleveren van een bericht dat aan de aanleverspecificaties voldeed, een berichtkenmerk ontvangen. Onder dit kenmerk is ook de statusinformatie en audit trail binnen Digipoort opgeslagen. De respons van de statusservice is de statushistorie, ofwel een lijstje van de relevante handelingen (services) die het bericht heeft doorlopen alsmede het resultaat daarvan. De gebruiker van Digipoort kan hieruit het volgende concluderen:

• Het bericht is door de uitvragende partij geaccepteerd.

• Het bericht bevindt zich momenteel nog ergens in het i-proces.

• Ergens in het i-proces is een fout geconstateerd, met een toelichting op de inhoud van de fout.

Een gedetailleerde beschrijving van het aanleveren van gestructureerde elektronische berichten via Digipoort is opgenomen in versie 1.1 van het document Servicebeschrijving Digipoort WUS 2.0 Bedrijven Statusinformatie Koppelvlakversie 1.2 van 28 april 2015.

17.1.3 Afleverservice

De afleverservice levert de berichten af aan de uitvragende partij die bij de berichtsoort hoort. Enkel gevalideerde berichten worden verstuurd. Hiermee wordt vervuiling – in de vorm van onverwerkbare of kwaadaardige berichten – van de systemen van de uitvragende partij geweerd. De afleverservice betreft het koppelvlak tussen Digipoort en de uitvragende partij.

118


Voor het deponeren van de jaarrekening bij de KvK worden de koppelvlakken gehanteerd conform hetgeen hierboven beschreven.

De Kamer van Koophandel onderkent een viertal berichtstromen:

• Jaarrekening

• Jaarrekening met preparer extension

• Jaarrekening met accountantsverklaring

• Jaarrekening met preparer extension en accountantsverklaring

In het KvK aansluitpakket zijn voor deze berichtstromen nadere berichtstroomspecificaties beschikbaar.

119

18. SBR i-processen


Een i-proces is het geheel van de verrichtingen in het verantwoordingsproces die worden uitgevoerd door Digipoort. Deze verrichten bestaan uit en tweetal belangrijke onderdelen:

• processpecificaties

• verwerkingsservices

De processpecificaties geven een beschrijving van de wijze waarop de uitvragende partij de ontvangen gegevens zal verwerken. Een deel van de verwerking wordt door de generieke procesinfrastructuur (Digipoort) uitgevoerd. Deze activiteiten worden altijd in de open standaard Business Process Modeling Notation (BPMN) beschreven.

De verwerkingsservices zijn de te onderscheiden applicaties die onderdelen van het i-proces geautomatiseerd afhandelen. Op basis van de processpecificaties bepaalt de procesengine welke verwerkingsservices met het bericht aan de slag moeten en in welke volgorde dit moet gebeuren. Een van de belangrijkste verwerkingsservices is de XBRL (instance) validatieservice. Hierbij wordt op basis van de specificaties uit de taxonomie voor iedere aangeleverde verantwoording vastgesteld of het voldoet aan de eisen die er door de taxonomie aan gesteld zijn.


De processpecificaties beschrijven de verschillende configuraties van koppelvlakservices en verwerkingsservices die de Kamer van Koophandel hanteert voor het ontvangen van jaarrekening. Er worden vier verschillende berichtstromen onderscheiden:

• Jaarrekening

• Jaarrekening met accountantsverklaring

• Jaarrekening met preparer extension

• Jaarrekening met preparer extension en accountantsverklaring

De mogelijke toepassing van deze berichtstromen per type rechtspersoon is in de onderstaande tabel opgenomen:

Berichtstromen Berichtsoort Micro- en Klein Middelgroot en Groot

Jaarrekening Jaarrekening V -

Jaarrekening & Preparer Extension Jaarrekening_PE Optioneel -

Jaarrekening & Accountantsverklaring Jaarrekening_AV Optioneel V

Jaarrekening & Preparer Extension & Accountantsverklaring

Jaarrekening_AV_PE Optioneel V

Tabel 8 – Processpecificaties aangeduid naar type rechtspersoon

Voor elke berichtstroom bestaat het i-proces uit een aantal te doorlopen services. Deze services zijn in de onderstaande tabel uiteengezet voor de verschillende berichtstromen:

120

Service Jaarrekening Jaarrekening_PE Jaarrekening_AV Jaarrekening_AV_PE

Aanlever service Ja Ja Ja Ja

Blacklist service Ja Ja Ja Ja

Bijlage consistentie controle service

- Ja Ja Ja

Taxonomie validatie service

- Ja - Ja

Architectuur controle service

- Ja - Ja

Validatie service XBRL

Ja Ja Ja Ja

Filing Rule validatie service

Ja Ja Ja Ja

Validatie service XML

- - Ja Ja

Handtekening controle service

- - Ja Ja

Certificaat controle service

- - Ja Ja

Aflever service Ja Ja Ja Ja

Tabel 9 – Services naar berichtsoort

De inhoudelijke aspecten van deze berichtsoorten komen uitgebreid aan de orde in het KvK aansluitpakket. Het aansluitpakket is een .zip bestand met daarin onder meer een visualisatie van de betreffende berichtsoorten onder de naam ‘Statussenflow’. Deze visualisatie geeft aan welke services binnen de berichtsoorten worden aangeroepen en welke status- en foutcodes op kunnen treden. Deze status- en foutcodes zijn vervolgens uitgebreid beschreven in de ‘Statussen en foutcodes van Digipoort’. Voor meer informatie omtrent de specificaties van de i-processen verwijzen we naar dit aansluitpakket.

121

19. SBR linking & signing


SBR Linking & Signing kenmerkt zich door het gebruik van XML Signature techniek op basis van de XAdES standaard in de vorm van een detached signature.

XAdES XAdES staat voor XML Advanced Electronic Signature. Het definieert een XML-standaard voor het toepassen van geavanceerde en gekwalificeerde elektronische handtekeningen. De XAdES standaard is een aanvulling op XML Signatures (XML-DSIG), een algemeen kader voor het digitaal ondertekenen van documenten. XAdES bevat aanvullende specificaties voor het gebruik van een advanced electronic signature in de context van de “Electronic Signatures Directive (1999/93/EC)” van de Europese Unie zoals deze in het Burgerlijk Wetboek verwekt is. XAdES heeft als doel het oplossen van problemen rondom onweerlegbaarheid en validaties van elektronische handtekeningen in XML formaat op de lange termijn.

XAdES kent zes verschijningsvormen. Elke verschijningsvorm brengt additionele functionaliteiten ten opzichte van zijn voorganger. De onderstaande tabel geeft de functionaliteit weer per vorm.

Provides digital signature

Includes reference to signature policy

Includes timestamp on signature

Includes complete validation data

Includes timestamp on validation data

Includes extended validation data for long term

Includes timestamp on archiving signatures

XAdES-BES Yes No No No No No No

XAdES-EPES Yes Yes No No No No No

XAdES-T Yes Yes Yes No No No No

XAdES-C Yes Yes Yes Yes No No No

XAdES-X Yes Yes Yes Yes Yes No No

XAdES-X-L Yes Yes Yes Yes Yes Yes No

XAdES-A Yes Yes Yes Yes Yes Yes Yes

Tabel 10 – Functionaliteiten binnen verschillende vormen van XAdES

Binnen XAdES kan gekozen worden voor een enveloping, of een detached signature. Dit is het verschil tussen de signature als apart bestand (detached) of als onderdeel van een te ondertekenen document (enveloping). Binnen SBR is gekozen voor het gebruik van een detached signature. Dit voorkomt een ongewenste mix van syntax tussen XML en XBRL.

Detached signature De detached signature is een losstaande XML-instance bestaande uit een Signature element in de http://www.w3.org/2000/09/xmldsig# namespace. Waarbij in het signature object element gebruik

wordt gemaakt van een XAdES QualifyingProperties element in de http://uri.etsi.org/01903/v1.3.2#namespace. Dit document bevat de unieke verwijzing naar de te waarmerken en/of te ondertekenen documenten, geeft aan wat de juridische context van de ondertekening is en de digitale handtekening. De opbouw in hoofdlijnen van de detached signature is in het voorbeeld hieronder weergegeven. De elementen SignedInfo, SigningCertificate, SignaturePolicyIdentifier, DataObjectFormat enCommitmentTypeIndication zijn in de overige voorbeelden verder uitgewerkt.

Voorbeeld

122

Element Bevat ds:Signature

ds:SignedInfo Bevat de informatie over en de hash-waarden van de te waarmerken/ondertekenen documenten en de xades:SignedProperties

ds:SignatureValue Bevat de binaire base64 encoded handtekening.

ds:KeyInfo Bevat de unieke informatie van het certificaat waarmee getekend is. Minimaal de publieke sleutel.

ds:Object Bevat de vereiste XAdES elementen.

xades:QualifyingProperties

xades:SignedProperties Bevat de informatie welke onderdeel is van de ondertekening.

xades:SignedSignatureProperties

xades:SigningTime Bevat de tijdstempel van het zetten van de digitale handtekening

xades:SigningCertificate Bevat de informatie van het certificaat waarmee de digitale handtekening is gezet.

xades:SignaturePolicyIdentifier Bevat de verwijzing naar, en de hash-waarde van de signature policy

xades:SignedDataObjectProperties

xades:DataObjectFormat xades:SigningCertificate

Bevat de verwijzing naar één of meer te waarmerken/ondertekenen document(en).

xades:CommitmentTypeIndication Bevat de koppeling tussen een document en de juridische context uit de signature policy. Moet voor elk bestand een keer voorkomen (uit DataObjectFormat).

De gebruikte namespaces zijn:

• ds=”http://www.w3.org/2000/09/xmldsig#”

• xades="http://uri.etsi.org/01903/v1.3.2#"

• dsig-xpath="http://www.w3.org/2002/06/xmldsig-filter2"

Voorbeeld – beschrijving van het ds:SignedInfo element

123

Element Bevatds:SignedInfo

ds:CanonicalizationMethod Als parameter de xml-canonicalisatie methode van de digitale handtekening.

ds:SignatureMethod Als parameter de xml-encryptie methode van de digitale handtekening.

ds:Reference Als parameters de id voor dit element en de URI met de bestandsnaam waar deze referentie betrekking op heeft.

Dit element komt minimaal twee keer voor. Ten behoeve van een te waarmerken/onderteken document en van het xades:SignedProperties element.

ds:Transforms

ds:Transform Als parameter xml-xpath methode van het ingesloten xpath-filter.

dsig-xpath:XPath Indien van toepassing bevat het een filter op het brondocument (URI) op basis waarvan de hash-waarde is bepaald.

ds:Transform Als parameter de xml-canonicalisatie methode van de hash-waarde bepaling.

ds:DigestMethod Als parameter het algoritme van de hash-waarde bepaling.

ds:DigestValue De hash-waarde, binair base64 encoded.

Voorbeeld - Beschrijving van het xades:SigningCertificate element

Element Bevatxades:SigningCertificate Bevat de informatie over het certificaat waarmee de

digitale handtekening is gezet.

xades:Cert

xades:CertDigest



xades:IssuerSerial

ds:X509IssuerName De informatie over de verstrekker van het certificaat. (Common Name, Organisation, Country etc)

ds:X509SerialNumber Het serialnummer van het certificaat.

Voorbeeld - Beschrijving van het xades:SignaturePolicyIdentifier element

124

Element Bevatxades:SignaturePolicyIdentifier Bevat de verwijzing naar, en de hash-waarde van de

signature policy.

xades:SignaturePolicyId

xades:SigPolicyId

xades:Identifier Bevat de URN van de betreffende signature policy. Bijv. urn:sbr:signature-policy:xml:2.0

xades:Description

xades:SigPolicyHash De hash-waarde van de signature policy.

ds:Transforms3ds:Transform Als parameter xml-xpath methode van het ingesloten xpath-

filter.

dsig-xpath:XPath Indien van toepassing bevat het een filter op het signature policy document op basis waarvan de hash-waarde is bepaald.

ds:Transform Als parameter de xml-canonicalisatie methode van de hash-waarde bepaling.



Voorbeeld - Beschrijving van het xades:DataObjectFormat element

Element Bevatxades:DataObjectFormat Als parameter ObjectReference

de verwijzing naar de id van het ds:reference element waar het betrekking op heeft.

xades:Description Bestandsnaam of omschrijving van het bestand.

xades:ObjectIdentifier

xades:Identifier Verwijzing naar het ds:reference URI element.

xades:MimeType Mime type beschrijving van het bestand. Bv. tekst/xml

xades:Encoding Karakter encoding van het bestand. Bv. UTF-8

Voorbeeld - Beschrijving van het xades:CommitmentTypeIndication element

Element Bevatxades:CommitmentTypeIndication Bevat de koppeling tussen een document en de juridische

context uit de signature policy.

xades:CommitmentTypeId

xades:Identifier Bevat de URN van de betreffende commitmenttype.

xades:ObjectReference Bevat een verwijzing naar de id van het ds:reference element waar deze commitmenttype betrekking op heeft.

Bovenop de specificaties van XAdES zijn er voor gebruik binnen SBR in Nederland een aantal spelregels opgezet ten behoeve van standaardisatie en het voldoen aan de minimale requirements.

XAdES versie en verschijningsvorm

3 Let op: Hiervoor geldt dat dezelfde filters toegepast dienen te zijn als in het ondertekeningsbeleid waar naar gerefereerd wordt.

125

ETSI TS 101 903 (V1.3.2): "XML Advanced Electronic Signatures (XAdES)" is momenteel de gebruikte XAdES versie. Binnen SBR is gekozen voor het toepassen van XAdES-EPES, oftewel een digitale handtekening waarbij expliciet naar een ondertekeningsbeleid (signature policy) moet worden verwezen. Dit betekent dat XAdES-BES niet is toegestaan.

Canonicalisatie Op meerdere plekken in de signature dient een hashing waarde berekend te worden. Alvorens wordt een canonicalisatie uitgevoerd over het bestand of bestandsdeel waarover de hash berekend wordt. De aanbevolen canonicalisatie met betrekking tot het bepalen van de hash-waarden is (vastgelegd in het ds:Transform element):

• http://www.w3.org/TR/2001/REC-xml-c14n-20010315

Hiernaast wordt bij het bepalen van de SignatureValue de volgende canonicalisatie aanbevolen (vastgelegd in het ds:Canonicalization element):

• http://www.w3.org/2001/10/xml-exc-c14n

Hashingalgoritmen Voor het berekenen van hash-waardes kunnen de volgende algoritmen worden gebruikt (vastgelegd in het ds:DigestMethod element):

• http://www.w3.org/2001/04/xmlenc#sha256

• http://www.w3.org/2001/04/xmlenc#sha512

Binnen SBR zijn geen andere hashingalgoritmen toegestaan.

Signature algoritmen Voor het berekenen van de SignatureValue worden de volgende algoritmen aanbevolen (vastgelegd in het ds:DigestMethod element):

• http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

• http://www.w3.org/2001/04/xmldsig-more#rsa-sha512

Ondertekeningsbeleid Het is verplicht om in de handtekening te refereren aan een geaccepteerde versie van het SBR ondertekeningsbeleid (signature policy). Zie ook hoofdstuk 20 voor meer informatie hieromtrent.


De toepassing van SBR Linking & Signing ten behoeve van het deponeren van een jaarrekening (eventueel inclusief een preparer extension) met accountantsverklaring bij het handelsregister van de KvK is vergelijkbaar met de algemene toepassing.

De enige aanvulling op de algemene toepassing is het sterk aanbevolen gebruik van een XPath filter om een aantal elementen buiten de hash berekening te houden van de jaarrekening in XBRL formaat. Een voorbeeld van dit XPath filter is: Filter="subtract">/xbrli:xbrl/*[local-name()='DocumentAdoptionStatus' or local-name()='DocumentAdoptionDate' or local-name()='EmailAddressContact'] | //text()[normalize-space()='']

Dit filter zorgt ervoor dat alle XML-elementen met de local names DocumentAdoptionStatus, DocumentAdoptionDate en EmailAddressContact buiten de instance worden gehouden tijdens het berekening van de hash-waarde. Het is ook mogelijk om dit met andere filters te realiseren, maar uit

126

recente ervaringen is gebleken dat de berekende hashes van een jaarrekening, voor en na het toevoegen van de vaststellingsgegevens, bij ander gebruik van het XPath filter ‘subtract’ of bij toepassing van het filter ‘intersect’ niet altijd identiek zijn als gevolg van minimale wijzigingen aan het instance document binnen de keten. Als dit gebeurt, dan wordt de detached signature afgekeurd en kan er niet gedeponeerd worden. Om de ketencomptabiliteit te kunnen waarborgen is besloten om uitsluitend het eerder vermelde XPath filter te benoemen.

127

20. SBR ondertekeningsbeleid


Het SBR ondertekeningsbeleid (in het Engels ook wel de SBR signature policy genoemd) is een in XML-formaat opgestelde normatieve set van regels om elektronische handtekeningen te creëren en te verifiëren. Hiermee wordt de intentie van het zetten van de elektronische handtekening expliciet gemaakt. Het SBR ondertekeningsbeleid duidt de intentie van degene die de elektronische handtekening heeft gezet in de context van Standard Business Reporting in Nederland.

Het SBR ondertekeningsbeleid is van toepassing op alle gekwalificeerde elektronische handtekeningen die betrekking hebben op SBR rapportages in Nederland en zijn opgesteld op basis van de XAdES standaard en gezet worden met behulp van een gekwalificeerd persoonsgebonden (beroeps)certificaat vallend onder het stelsel van PKIoverheid.

Meer achtergrondinformatie is te vinden in het document Toelichting op het SBR ondertekeningsbeleid. De belangrijkste aspecten van het ondertekeningsbeleid zijn in de onderstaande paragrafen opgenomen:

20.1.1 Ondersteunde versie(s)

Het SBR ondertekeningsbeleid gaat in vanaf de vermelde ingangsdatum en is geldig tot de vermelde einddatum. De meest recente versie van het SBR ondertekeningsbeleid is versie 2.0. De karakteristieken van deze versie zijn hieronder opgenomen:

SBR ondertekeningsbeleid versie 2.0

Versie: 2.0Object ID: urn:sbr:signature-policy:xml:2.0Emittent: SBR programmaIngangsdatum: 1 november 2017Einddatum: -Beschrijving: Het SBR ondertekeningsbeleid beschrijft de voorwaarden waaronder

elektronische handtekeningen binnen de context van Standard Business Reporting in Nederland worden gebruikt, evenals de voorwaarden wanneer deze handtekeningen als geldig worden beschouwd. In dit kader richt het SBR ondertekeningsbeleid zich op de precieze aard van de verantwoordelijkheid die ondertekenen met zich meebrengt door het expliciteren van de verschillende verplichtingen (‘commitments’) die elektronische handtekeningen beogen.

Normatieve versie: http://www.nltaxonomie.nl/sbr/signature_policy_schema/v2.0/SBR-signature-policy-v2.0.xml

Niet langer ondersteunende versies van het ondertekeningsbeleid

Versie: 1.0Object ID: urn:sbr:signature-policy:xml:1.0

128

Emittent: SBR programmaIngangsdatum: 7 juli 2016Einddatum: 31 december 2017Normatieve versie: http://www.nltaxonomie.nl/sbr/signature_policy_schema/v1.0/SBR-

signature-policy-v1.0.xml

20.1.2 Typen verplichtingen (‘commitments’)

Het SBR ondertekeningsbeleid definieert verschillende typen verplichtingen (‘commitments’), waarbij de semantiek van deze verplichtingen op nauwkeurige wijze is beschreven. Door het beschrijven van de verplichtingen kan een ondertekenaar in de elektronische handtekening expliciet verwijzen naar een verplichting. Om dit te realiseren verwijst de ondertekenaar naar de identifier van de verplichting die met de elektronische handtekening wordt beoogd. Bij de aanvaarding van een geverifieerde handtekening impliceert de opname van een expliciete verplichting in de elektronische handtekening dus ook aanvaarding van de semantiek die dit type verplichting met zich meebrengt. Als een elektronische handtekening is voorzien van een type verplichting die afwijkt van de typen verplichtingen die zijn gedefinieerd in het ondertekeningsbeleid wordt deze verplichting als nietig beschouwd.

Het SBR ondertekeningsbeleid onderkent de volgende typen verplichtingen: 1. Ondertekenen verklaring (indien er sprake is van het oorspronkelijke object van onderzoek) 2. Ondertekenen verklaring (indien het object waarbij een kopie van de verklaring wordt

afgegeven een afgeleide is van het oorspronkelijk object van onderzoek) 3. Waarmerken

Deze typen verplichtingen worden in de onderstaande paragrafen nader uiteengezet.

1. Ondertekenen verklaring (indien er sprake is van het oorspronkelijk object van onderzoek)

Object ID urn:sbr:signature-policy:proof-of-intent-of-practitioner-to-express-an-opinion

Beschrijving Dit type verplichting geeft aan dat de ondertekenaar de integriteit, authenticiteit en onweerlegbaarheid van de afgegeven verklaring erkent en in dit kader bevestigt de afgegeven verklaring uit vrije wil te hebben opgesteld en vrijgegeven.

Toepassingsgebied Dit type verplichting kan worden toegepast op alle situaties in Nederland binnen de reikwijdte van het SBR ondertekeningsbeleid, waar een verklaring in een digitaal formaat wordt afgegeven door de ondertekenaar.

Semantiek De betekenis van dit type verplichting is dat de ondertekenaar het volgende bevestigt: - een verklaring bij een gerenderd object te hebben afgegeven; - deze verklaring te hebben opgesteld en vrijgegeven; - dit ook nadrukkelijk op deze wijze heeft beoogd te doen om verantwoordelijkheid te nemen voor de gerenderde inhoud van deze verklaring.

De rendering, voor de mens leesbaar gemaakt, dient plaats te vinden volgens de voor het domein van toepassing zijnde presentatieafspraken.

129

2. Ondertekenen verklaring (indien het object waarbij een kopie van de verklaring wordt afgegeven een afgeleide is van het oorspronkelijke object van onderzoek)

Object ID urn:sbr:signature-policy:proof-of-intent-of-practitioner-to-add-an-copy-of-the-opinion

Beschrijving Dit type verplichting geeft aan dat de ondertekenaar heeft bevestigd dat dit een kopie is van de afgegeven verklaring. En in dit kader de integriteit, authenticiteit en onweerlegbaarheid van dit afschrift erkent en deze uit vrije wil te hebben opgesteld en vrijgegeven.

Toepassingsgebied Dit type verplichting kan worden toegepast op alle situaties in Nederland binnen de reikwijdte van het SBR ondertekeningsbeleid, waar een afschrift van een verklaring in een digitaal formaat wordt afgegeven door de ondertekenaar.

Semantiek De betekenis van dit type verplichting is dat de ondertekenaar het volgende bevestigt: - een kopie van de verklaring bij een gerenderd object van onderzoek te hebben afgegeven; - dit gerenderde object is een afgeleide van het oorspronkelijke object van onderzoek; - deze verklaring te hebben opgesteld en vrijgegeven; - dit ook nadrukkelijk op deze wijze heeft beoogd te doen om verantwoordelijkheid te nemen voor de inhoud van deze verklaring; - dat de gerenderde verklaring ook mag worden bijgevoegd bij een gerenderd object zoals benoemd in de type verplichting voor waarmerken.

De rendering, voor de mens leesbaar gemaakt, dient plaats te vinden volgens de voor het domein van toepassing zijnde presentatieafspraken.

3. Waarmerken

Object ID urn:sbr:signature-policy:proof-of-integrity-of-the-object-for-which-the-practitioner-expresses-an-opinion

Beschrijving Dit type verplichting geeft aan dat de ondertekenaar het object waar de verklaring betrekking op heeft waarmerkt om de integriteit van het object te waarborgen.

Toepassingsgebied Dit type verplichting kan worden toegepast op alle situaties in Nederland binnen de reikwijdte van het SBR ondertekeningsbeleid waar ondertekenaars de integriteit willen of moeten waarborgen van een object waar een door hen afgegeven verklaring betrekking op heeft.

Semantiek De betekenis van dit type verplichting is dat de ondertekenaar het volgende bevestigt: - dit is het object waarbij de ondertekenaar een verklaring heeft afgegeven zoals benoemd in de type verplichtingen voor het ondertekenen van verklaringen.

Door het toepassen van dit type verplichting ontstaat een onweerlegbare relatie tussen het object en de hierbij afgegeven verklaring.

20.1.3 Aanvullende voorschriften vanuit het SBR ondertekeningsbeleid

130

Ten behoeve van het creëren en valideren van een elektronische handtekening definieert het SBR ondertekeningsbeleid aanvullende voorschriften die die gevolgd moeten worden.

Voorschriften bij het creëren van een elektronische handtekening Naast het creëren van een elektronische handtekening dient de ondertekenende partij ook een initiële verificatie uit te voeren van de handtekening en alle validatiegegevens te verstrekken die nodig zijn om daaropvolgend de onweerlegbaarheid van de elektronische handtekening vast te stellen.

Op basis van het SBR ondertekeningsbeleid is de ondertekenende partij verplicht om bij de creatie de volgende gegevens toe te voegen aan de elektronische handtekening (als signed qualifying properties):

• De identifier van het toegepaste ondertekeningsbeleid (SignaturePolicyIdentifier) • De identifiers van het relevante type toezeggingen (CommitmentTypeIndication) • Informatie over de externe bestanden waarnaar verwezen wordt (DataObjectFormat)

De ondertekende partij dient de publieke sleutel op te nemen van het certificaat van de eindgebruiker dat gebruikt is voor het ondertekenen.

Partijen die de geldigheid van een elektronische handtekening bij een SBR rapportage willen verifiëren kunnen dit doen na het verkrijgen van de relevante documenten. Zij kunnen deze verificatie uitvoeren op basis van de validatie gegevens die onderdeel zijn van de elektronische handtekeningen die daar door de ondertekenaars zijn geplaatst.

Voorschriften inzake het vertrouwen in certificaten De enige certificaten die geaccepteerd worden voor het creëren van elektronische handtekeningen binnen het SBR ondertekeningsbeleid zijn gekwalificeerde certificaten die onder de persoonlijke controle staan van de betreffende ondertekenaar. Deze gekwalificeerde certificaten zijn X.509 certificaten uit het PKIoverheid (Public Key Infrastructure voor de overheid) stelsel. Het gekwalificeerd certificaat dient te zijn uitgegeven door een PKIoverheid erkende Trust Service Provider (TSP) en minimaal van de tweede generatie te zijn (G2).

Bij het verifiëren van een beroepscertificaat is het van belang dat naast de geldigheidsdatum ook wordt gecontroleerd dat tijdens het ondertekenen het beroepscertificaat niet was ingetrokken. De lijst met ingetrokken certificaten (ook wel: certificate revocation list of CRL genoemd) wordt beschikbaar gesteld door de CSP dat het certificaat heeft verstrekt.

Voorschriften inzake het vertrouwen in tijdstempels (‘timestamps’) De huidige versie van het SBR ondertekeningsbeleid maakt geen gebruik van tijdstempels (‘timestamps’) die worden afgegeven door een externe partij in de rol van Time Stamping Authority (TSA).

Voorschriften inzake beperkingen op algoritmenUitsluitend de volgende algoritmes en bijbehorende minimale sleutellengtes mogen gebruikt worden voor het creëren van elektronische handtekeningen binnen de reikwijdte van het SBR ondertekeningsbeleid.

• http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 / 2048 bits • http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 / 2048 bits • http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 / 2048 bits

131


De toepassing van het SBR ondertekeningsbeleid ten behoeve van het deponeren van een jaarrekening (eventueel inclusief een preparer extension) met accountantsverklaring bij het handelsregister van de KvK is vergelijkbaar met de algemene toepassing.

De toepassing van de verschillende verplichtingen (‘commitments’) is wel specifiek ingericht voor het deponeren bij de KvK. Hieronder is een overzicht opgenomen van welke verplichting gehanteerd dient te worden voor elk document vanuit het perspectief van de accountant.

Toepassing van de verschillende verplichtingen door een accountant:

Document Verplichting (‘commitment’) URNJaarrekening Waarmerken urn:sbr:signature-policy:proof-of-

integrity-of-the-object-for-which-the-practitioner-expresses-an-opinion

Preparer extension Waarmerken urn:sbr:signature-policy:proof-of-integrity-of-the-object-for-which-the-practitioner-expresses-an-opinion

Accountantsverklaring (bij een publicatiestuk dat gelijk is aan het inrichtingsstuk)

Ondertekenen verklaring (indien er sprake is van het oorspronkelijk object van onderzoek)

urn:sbr:signature-policy:proof-of-intent-of-practitioner-to-express-an-opinion

Accountantsverklaring (bij een publicatiestuk dat niet gelijk is aan het inrichtingsstuk)

Ondertekenen verklaring (indien het object waarbij een kopie van de verklaring wordt afgegeven een afgeleide is van het oorspronkelijke object van onderzoek)

urn:sbr:signature-policy:proof-of-intent-of-practitioner-to-add-an-copy-of-the-opinion

De verplichting ‘Waarmerken’ moet door de accountant worden toegepast bij het ondertekenen van de jaarrekening en – indien beschikbaar – de preparer extension. De accountant is niet verantwoordelijk voor de inhoud van de jaarrekening, maar wil met behulp van de techniek van de elektronische handtekening uitsluitend de integriteit van de jaarrekening waarborgen. Dit is van belang om er zeker van te zijn dat de jaarrekening waar een door hem afgegeven verklaring betrekking op heeft niet gewijzigd is. Dit realiseert de accountant door de toepassing van een elektronische handtekening op de jaarrekening en preparer extension te voorzien van de verplichting ‘waarmerken’.

De verplichting ‘Ondertekenen verklaring’ moet door de accountant worden toegepast bij het ondertekenen van de accountantsverklaring. Hierbij zijn twee varianten te onderkennen:

1. De accountantsverklaring wordt afgegeven bij een publicatiestuk dat niet afwijkt van het inrichtingsstuk, zoals bij een jaarrekening van een grote rechtspersoon.

2. De accountantsverklaring wordt afgegeven bij een publicatiestuk dat is afgeleid van het inrichtingsstuk, bijvoorbeeld bij een jaarrekening van een middelgrote rechtspersoon die gebruik maken van de vrijstellingen van artikel 2:397 BW.

In het geval de accountantsverklaring wordt afgegeven bij een publicatiestuk dat niet afwijkt van het inrichtingsstuk, dient de verplichting “Ondertekenen verklaring (indien er sprake is van het

132

oorspronkelijk object van onderzoek)” te worden gehanteerd. De accountant geeft met deze verplichting aan dat hij de integriteit, authenticiteit en onweerlegbaarheid van de afgegeven verklaring erkent en in dit kader bevestigt de afgegeven verklaring uit vrije wil te hebben opgesteld en vrijgegeven. Hiermee neemt de accountant nadrukkelijk de verantwoordelijkheid voor de inhoud van zijn verklaring, zoals dit voorheen met een handgeschreven handtekening het geval was. Door deze verplichting krijgt de handtekening dezelfde (juridische) status als een handgeschreven handtekening.

In het geval de accountantsverklaring wordt afgegeven bij een publicatiestuk dat is afgeleid van het inrichtingsstuk, dient de verplichting “Ondertekenen verklaring (indien het object waarbij een kopie van de verklaring wordt afgegeven een afgeleide is van het oorspronkelijke object van onderzoek)” te worden gehanteerd. Hiermee neemt de accountant ook de verantwoordelijkheid voor de inhoud van zijn verklaring en krijgt de handtekening dezelfde (juridische) status als een handgeschreven handtekening. Daarnaast geeft de accountant met deze verplichting aan dat hij heeft bevestigd dat dit een kopie is van de afgegeven verklaring bij het inrichtingsdocument dat het oorspronkelijk object van onderzoek is.

133

21. SBR Preparer Extensions


Een uitvragende partij maakt binnen een informatieketen haar informatie-uitvraag kenbaar via een XBRL taxonomie. Deze uitvragende partij kan de opstellers van een verantwoordingsrapportage de mogelijkheid geven om aanvullende begrippen – die niet in (het entrypoint van) de taxonomie van de uitvragende partij zijn opgenomen – toe te passen in de verantwoordingrapportage of hen de mogelijkheid geven om de presentatiestructuren aan te passen. Dit soort wijzigingen door een opsteller van een rapportage noemen we een preparer extension. Van een preparer extension is sprake wanneer een opsteller concepten, definities of relaties toepast en/of wijzigt die niet door uitvragende partij beschikbaar zijn gesteld in het betreffende entrypoint.

Veelal zal een preparer extension bestaan uit nieuwe concepten welke door een opsteller wordt aangemaakt en gebruikt in een instance document. Het kan echter ook voorkomen dat een opsteller gebruik maakt van concepten uit andere (door de betreffende uitvragende partij) toegestane schema’s en alleen deze concepten gebruikt in het instance document. Een preparer extension geeft een opsteller de mogelijkheid om aanvullende gestructureerde informatie te verstrekken in een verantwoordingsrapportage. De toepassing van een preparer extension vindt zijn oorsprong in het feit dat het praktisch gezien niet altijd mogelijk om alle relevante concepten in alle situaties voor alle rechtspersonen beschikbaar te stellen in een taxonomie.

Een opsteller dient zoveel als mogelijk gebruik te maken van reeds bestaande concepten uit de onderliggende taxonomieën in plaats van zelf concepten aan te maken. Het gebruik van bestaande concepten bevordert de vergelijkbaarheid van de verantwoordingsrapportages.

21.1.1 Architectuur van een preparer extension

In de onderstaande figuur is de technische architectuur van een preparer extension weergegeven.

Figuur 10 – Architectuur van een preparer extension

134

In de verantwoordingsrapportage – het XBRL instance document – verwijst de opsteller door middel van een schemaRef naar een nieuw, door de opsteller aangemaakt, preparer extension schema. Deze verwijzing komt in de plaats van een verwijzing naar een entrypoint uit de betreffende taxonomie, aangezien de taxonomie aangepast wordt door de opsteller. Het preparer extension schema heeft hierdoor onder meer als taak om als entrypoint voor de preparer extension te dienen.

Het preparer extension schema importeert een bestaand entrypoint uit de taxonomie. Deze importis van belang om de inhoud van het betreffende entrypoint te hergebruiken, aangezien de preparer extension een uitbreiding moet zijn op dit entrypoint. Als gevolg van deze import worden de elementen, maar ook de verschillende relaties tussen deze elementen hergebruikt.

De elementen die een opsteller wil aanmaken worden ook gedefinieerd in het preparer extension schema. Hierbij worden alle typen elementen in het preparer extension schema opgenomen. Dit houdt in dat zowel nieuwe concepten, abstracte presentatie items, datatypes, tuples en domeinen en domeinleden in hetzelfde schema gedefinieerd worden.

Het preparer extension schema verwijst door middel van een linkbaseRef naar verschillende soorten linkbases. Dit is de standaard methode voor het aanroepen van linkbases en sluit derhalve naadloos aan bij de taak van het preparer extension schema als entrypoint.

Er zijn twee verschillende typen linkbases te onderkennen: 1. Linkbases waarin relaties tussen elementen zijn opgenomen: de presentation linkbase,

presentation hierarchy linkbase, definition linkbase en formula linkbase; 2. Linkbases met aanvullende informatie omtrent elementen: de label linkbase en reference

linkbase.

Linkbases met relaties tussen elementen De linkbases waarin relaties tussen elementen kunnen worden opgenomen, maken het mogelijk om relaties uit het bestaande entrypoint uit te zetten en om nieuwe relaties tussen elementen toe te voegen. Alle typen linkbases moeten in een apart bestand worden opgenomen. Hierdoor zijn dus aparte bestanden te onderkennen voor de presentation linkbase, presentation hierarchy linkbase, definition linkbase en formula linkbase. Elk element dat door een opsteller in het preparer extension schema is gedefinieerd dient in een van deze linkbases te worden opgenomen.

In de presentation linkbase van de preparer extension zijn de presentatie relaties opgenomen die de opsteller heeft uitgezet en/of toegevoegd. In de presentation linkbase worden zogenaamde Extended Linkroles (ELRs) gebruikt om verschillende onderdelen van een rapportage technisch van elkaar te (onder)scheiden. De aanpassingen die de opsteller in de presentation linkbase van de preparer extension maakt, zullen waarschijnlijk meerdere ELRs raken. Alle aanpassingen dienen opgenomen te worden in hetzelfde bestand, ongeacht het aantal ELRs dat hierdoor geraakt worden.

De presentation hierarchy linkbase van de preparer extension is een generic linkbase die de onderlinge hiërarchie van ELRs definieert. Hiermee wordt de presentatie volgorde en hiërarchie van ELRs aangegeven door middel van zogenaamde parent-child relaties. Hierdoor ontstaat een boomstructuur voor de gewenste presentatie van de ELRs die overeenkomst met de wijze waarop de presentation linkbase de presentatievolgorde van concepten definieert.

In de definition linkbase van de preparer extension zijn de dimensionele validatiestructuren opgenomen voor elk element. Voor elke toevoeging van een element binnen een ELR dient de bijbehorende dimensionele validatiestructuur gedefinieerd te worden. Net als bij de presentation

135

linkbase worden ELRs gebruikt om verschillende dimensionele structuren van elkaar te (onder)scheiden en dienen alle aanpassingen hierin opgenomen te worden in hetzelfde bestand.

De definition linkbase dient niet uitsluitend voor het opnemen van de dimensionele structuren, maar wordt in de preparer extension ook gebruikt voor het vermelden van een of meer semantische relaties omtrent elk gedefinieerd element. Hierbij wordt een semantische relatie gelegd (direct of indirect) tussen het nieuwe element en een bestaand element uit de taxonomie door de toepassing van een zogenaamde general-special definition link. Deze methodiek wordt ook wel ‘anchoring’genoemd. Dit is een gangbare manier om de semantiek voldoende bruikbaar te definiëren. Het zorgt ervoor dat via deze gestructureerde relatie het element altijd een semantische betekenis meekrijgt ten opzichte van een ander element, waardoor dit ook geautomatiseerd verwerkt kan worden.

Het is eventueel ook mogelijk om een formula linkbase op te nemen in de preparer extension. Hiermee kunnen aanvullende berekeningen worden uitgevoerd op de in de preparer extension gedefinieerde elementen. Het gebruik van de formula linkbase zal slechts in incidentele gevallen noodzakelijk zijn. De taxonomie is zodanig opgezet dat de meeste formulas gebruik maken van de relaties in de presentation of definition linkbase als basis voor de berekening. Hierdoor zal deze functionaliteit voor de meeste preparer extensions niet noodzakelijk zijn. Het toevoegen van een formula in de preparer extension is een complexe exercitie en zou alleen plaats moeten vinden wanneer het echt noodzakelijk is.

In de architectuur van de preparer extension is geen table linkbase opgenomen. In de taxonomie zijn meerdere tabellen opgenomen om de gewenste presentatiestructuren te realiseren. Een tabel wordt gedefinieerd in een table linkbase. Voor elke ELR kan er één tabel worden gedefinieerd. De table linkbases in de taxonomie zijn dusdanig opgezet dat zij worden gevoed door de relaties in de betreffende ELR van de presentation of definition linkbase. Dit betekent dus ook dat de table linkbase automatisch wordt aangepast wanneer de inhoud van de presentation of definition linkbase wordt aangepast. Er hoeft derhalve geen mogelijkheid te zijn om de table linkbase zelf aan te passen. Dit is dan ook niet toegestaan in een preparer extension.

Linkbases met aanvullende informatie omtrent elementen Er zijn een aantal verschillende linkbases te onderkennen met aanvullende informatie omtrent elementen, namelijk de label linkbase en de reference linkbase. Wanneer nieuwe elementen, in het bijzonder concepten, domeinen, domeinleden, abstracte presentatie items, data types en tuples door de opsteller zijn gedefinieerd in het preparer extension schema, verwijst dit schema ook naar een label linkbase en eventueel een reference linkbase.

Voor elk in de preparer extension gedefinieerd element dient in de label linkbase ten minste een standaard label en een documentation label opgenomen te worden. Het standaard label is het unieke label dat gebruikt wordt om het element te identificeren, terwijl het documentation label een beschrijving geeft van de semantiek van het element. Het is mogelijk om andere typen labels, zoals terseLabel, verboseLabel of totalLabel op te nemen in de label linkbase, mits deze labels aangeroepen worden in de presentation of definition linkbase. De verschillende type labels moeten worden opgenomen in hetzelfde bestand.

Het is mogelijk om labels op te nemen in meerdere talen. Voor elk element in de preparer extension dient minimaal een label in dezelfde taal als het instance document meegeleverd te worden, aangezien dit de taal is waarin de verantwoordingsrapportage zal worden bekeken. Wanneer labels in verschillende talen worden opgenomen in een preparer extension dienen deze per taal in een apart bestand te worden opgenomen.

136

Het is mogelijk voor de opsteller om een referentie toe te voegen aan een in de preparer extension gedefinieerd element. Deze referenties worden opgenomen in de reference linkbase. Het toevoegen van een referentie is niet verplicht, aangezien dit niet altijd mogelijk zal zijn voor een in de preparer extension gedefinieerd element. Wanneer het mogelijk is om een zinnige referentie toe te voegen, wordt er aanbevolen om dit op te nemen in de reference linkbase. Hierbij dienen de verschillende soorten referenties, waaronder een standaard referentie, presentationRef of disclosureRef, in hetzelfde bestand te worden opgenomen.

21.1.2 Architectuurregels voor een preparer extension

De architectuur van een preparer extension is sterk ingekaderd door middel van een groot aantal specifieke regels. De architectuurregels voor preparer extension zijn opgesteld in lijn met de reguliere architectuurregels voor taxonomieën die zijn opgenomen in de Nederlandse Taxonomie Architectuur (NTA). Hierbij wordt alleen afgeweken van de bestaande NTA regels als dit noodzakelijk is. Deze architectuurregels voor preparer extensions (ook wel NTA voor Preparer Extensions genoemd) controleren of een preparer extension wel aan alle hieraan gestelde eisen voldoet. Indien een preparer extensie niet aan alle eisen voldoet, zal de verantwoordingsrapportage niet geaccepteerd worden door de betreffende uitvragende partij.

De meest recente versie van de NTA voor Preparer Extensions is versie 1.3.1. In het document ‘NTA voor Preparer Extensions’ is de architectuur beschreven in de vorige paragaaf nader uitgewerkt in een groot aantal architectuurregels.


De toepassing van SBR preparer extensions ten behoeve van het deponeren bij het handelsregister van de KvK is identiek aan de algemene toepassing. Dit is ook niet verwonderlijk, aangezien het deponeren bij het handelsregister van de KvK de eerste use-case van de methodiek van preparer extensions. De reden hiervan is helder; de KvK taxonomie kan praktisch gezien simpelweg niet alle relevante elementen voor alle rechtspersonen opnemen.

In aanvulling op de NTA-PE zijn er specifieke naamgevingsconventies gedefinieerd ten behoeve van de deponering bij de KvK. In deze naamgevingsconventies staan de regels waaraan de benamingen van de elementen, namespaces en bestanden moeten voldoen. De prefixes worden niet aan de hand van een naamgevingsconventie afgedwongen. In onderstaand schema is de naamgevingsstructuur uitgewerkt.

XBRL document Naamgevingsstructuur Voorbeeld

Schema pe-[datum]-[kvknummer]-rpt.xsd

pe-[jjjjmmdd]-[kvknummer]-rpt.xsd

Presentation Linkbase pe-[datum]-[kvknummer]-pre.xml

pe-[jjjjmmdd]-[kvknummer]-pre.xml

Definition Linkbase pe-[datum]-[kvknummer]-def.xml

pe-[jjjjmmdd]-[kvknummer]-def.xml

Formula Linkbase pe-[datum]-[kvknummer]-for.xml

pe-[jjjjmmdd]-[kvknummer]-for.xml

Label Linkbase (NL) pe-[datum]-[kvknummer]-data-lab-nl.xml

pe-[jjjjmmdd]-[kvknummer]-data-lab-nl.xml

137

Reference Linkbase pe-[datum]-[kvknummer]-data-ref.xml

pe-[jjjjmmdd]-[kvknummer]-data-ref.xml

Formula Label Linkbase (NL) pe-[datum]-[kvknummer]-generic-for-lab-nl.xml

pe-[jjjjmmdd]-[kvknummer]-generic-for-lab-nl.xml

Formula Reference Linkbase pe-[datum]-[kvknummer]-generic-for-ref.xml

pe-[jjjjmmdd]-[kvknummer]-generic-for-ref.xml

Message Linkbase pe-[datum]-[kvknummer]-generic-msg.xml

pe-[jjjjmmdd]-[kvknummer]-generic-msg.xml

Presentation Hierarchy Linkbase

pe-[datum]-[kvknummer]-hie.xml

pe-[jjjjmmdd]-[kvknummer]-hie.xml

Tabel 11 – Naamgevingsconventies voor een preparer extension

138

22. SBR Consistente Presentatie


Een verantwoordingsrapportage in de vorm van een XBRL instance document is meestal voor een mens niet of nauwelijks leesbaar. Om de gerapporteerde informatie door te nemen, te doorgronden en te controleren, dient de verantwoordingsrapportage voor de mens leesbaar gemaakt te kunnen worden. Het voor de mens leesbaar maken van het XBRL instance document – ook wel renderen genoemd - moet op een consistente wijze worden uitgevoerd. Dit is van belang om te borgen dat het beeld dat de opsteller van de verantwoordingrapportage beoogt te geven door middel van de verstrekte gegevens, niet verandert wanneer het XBRL instance document door een andere partij leesbaar wordt gemaakt. Hierbij is het niet noodzakelijk dat de gerenderde versies van de verantwoordingsrapportage identiek zijn aan elkaar, aangezien deze op details van elkaar zullen afwijken, bijvoorbeeld door het gebruik van verschillende softwareapplicaties. Het is echter wel van belang dat de gerenderde versies van de verantwoordingsrapportage een consistente interpretatie waarborgen.

Om deze consistente interpretatie te kunnen waarborgen is de SBR Consistente Presentatie (CP) specificatie opgesteld. De Consistente Presentatie specificatie beoogt om alle gebruikers van een verantwoordingsrapportage in staat te stellen om een eenduidig, voor mensen leesbaar beeld te vervaardigen van de gestructureerde gegevens in het XBRL instance document. Het is een vorm van renderen die altijd, ongeacht de gebruikte software, tot een vergelijkbare weergave van de verantwoordingsrapportage zal leiden; oftewel een consistente presentatie.

Een rendering conform de Consistente Presentatie is gebaseerd op de in de XBRL taxonomie beschikbare presentatiestructuren en de aanvullende afspraken die zijn opgenomen in de SBR Consistente Presentatie specificatie. Deze afspraken zijn zodanig specifiek dat zij niet in de taxonomie konden worden opgenomen. Denk hierbij vooral aan zaken als de rangschikking van de verschillende onderdelen van een verantwoordingsrapportage.

De totstandkoming van een rendering conform de Consistente Presentatie is in de onderstaande figuur gevisualiseerd.

Figuur 11 – Conceptuele totstandkoming van een rendering conform de consistente presentatie

De input voor het proces van renderen is altijd het XBRL instance document; oftewel de verantwoordingsrapportage. Tijdens het proces van renderen worden de presentatiestructuren uit

139

de XBRL taxonomie en de afspraken in de Consistente Presentatie specificatie gebruikt om de rendering te realiseren. De output van het proces van renderen is dan ook een rendering conform de Consistente Presentatie. Het is niet voorgeschreven in welk formaat de rendering opgesteld dient te worden. Dit kan derhalve in verschillende formaten plaatsvinden, zoals HTML of .pdf.

De meest recente versie van de SBR Consistente Presentatie specificatie is versie 1.3.


De eerste toepassing van de SBR Consistente Presentatie specificatie is bij het deponeren van een jaarrekening bij het Handelsregister van de Kamer van Koophandel. Op basis van de Consistente Presentatie specificatie kan de jaarrekening in de vorm van een XBRL instance document leesbaar worden gemaakt, zodat deze door het bestuur kan worden opgesteld, door de accountant kan worden gecontroleerd, door de Algemene Vergadering kan worden goedgekeurd en door het maatschappelijk verkeer kan worden begrepen.

Het is in dit kader van groot belang dat het mogelijk om de jaarrekening in de vorm van een XBRL instance document op dezelfde wijze leesbaar te (kunnen) maken als de opsteller heeft beoogd. Dit voorkomt het risico dat het ‘getrouwe beeld’ dat de opsteller of accountant voor ogen heeft, afwijkt van het beeld van een gebruiker. Dit is uiteraard alleen het geval wanneer deze gebruiker het XBRL instance document ook leesbaar maakt op basis van de Consistente Presentatie. Dit hoeft geen identiek beeld op te leveren, maar wel een beeld dat een consistente interpretatie waarborgt.

140

23. KvK backoffice

In de backoffice van de KvK vinden verschillende stappen plaats alvorens de deponering van de jaarrekening bij het handelsregister heeft plaatsgevonden. In de onderstaande figuur worden deze stappen uiteengezet:

Figuur 12 – Proces van verwerking jaarrekening in KvK backoffice

Deze stappen worden hieronder kort besproken:

1. Ontvangst van de documenten vanuit Digipoort De eerste stap is het ontvangen van de documenten van Digipoort. Digipoort heeft deze documenten reeds gevalideerd op naleving ten opzichte van de meeste specificaties, waaronder XBRL validatie en de validatie van de Filing Rules. De business rules die in de vorm van XBRL formulas in de KvK taxonomie zijn opgenomen zijn ook reeds door Digipoort gevalideerd.

2. Validatie van de ontvangen documenten De KvK voert zelf ook XBRL validatie uit op de ontvangen documenten. De KvK valideert niet meer op de Filing Rules, aangezien deze al in Digipoort zijn gecontroleerd. De KvK valideert wel expliciet op de naleving van de KvK Business Rules. Deze regels zijn beschreven in het document ‘KvK Business Rules’. De naleving van deze regels zijn van groot belang voor het deponeren bij het handelsregister.

3. Rendering van de ontvangen documenten Nadat de ontvangen documenten valide zijn bevonden, worden deze gerenderd op basis van de Consistente Presentatie specificatie. Het bestandsformaat van deze rendering is .pdf. Dit geldt ook voor de jaarrekening. In het geval van een preparer extension worden de aanpassingen die de opsteller heeft gemaakt ook meegenomen in de rendering. In de rendering wordt het feit ‘e-mailadres voor de contactpersoon van deze rapportage’ niet meegenomen vanuit privacy-overwegingen.

141

4. Realiseren van de juiste identificatie van documenten t.b.v. registratie in het handelsregister De documenten worden in een tijdelijk archief geplaatst om de juiste identificatie van de bestanden te faciliteren. In deze stap wordt ook de tag voor het concept ‘E-mailadres voor de contactpersoon van deze rapportage’ uit het XBRL instance document verwijderd vanuit privacy-overwegingen. Zodra de juiste identificatie is gerealiseerd, gaan deze documenten naar het handelsregister.

5. Validatie en registratie van de deponering door het handelsregister Het handelsregister voert eigen (inhoudelijke) validatie uit op de te deponeren documenten en registreert deze documenten ter deponering in het handelsregister.

6. Definitief maken van de deponering in het handelsregister Zodra de deponering in het handelsregister definitief is, wordt een terugkoppeling gegeven aan Digipoort dat de aanlevering succesvol is verwerkt.

7. Versturen e-mail naar aanleverende partij met een rendering van de documenten De laatste stap in dit proces is het per e-mail versturen van de in stap 3 gemaakte rendering naar de aanleverende partij op basis van de waarde van het concept ‘E-mailadres voor de contactpersoon van deze rapportage’ uit het oorspronkelijke instance document.

142

Appendix A – Verklarende woordenlijst

In dit document komen verschillende begrippen voor die voor de lezer wellicht onbekend zijn. In het onderstaande overzicht is een verklarende woordenlijst opgenomen die de verschillende begrippen nader uiteenzet.

Begrip Beschrijving

@decimals Het @decimals attribuut geeft de accuratesse van het gerapporteerde feit aan. Hiermee kan worden aangegeven op welk niveau de opgenomen cijfers zijn afgerond.

Abstract Dit is een concept waarover niet gerapporteerd kan worden, maar gebruikt wordt om de presentatierelaties vorm te geven.

Built-in jaarrekeningproces

Dit proces kenmerkt zich door de situatie waarin het publicatiestuk gelijktijdig met het inrichtingsstuk tot stand komt. Dit is mogelijk wanneer de XBRL-tags direct in de applicaties van het jaarrekeningproces zijn geïntegreerd.

Bolt-on jaarrekeningproces

Dit proces kenmerkt zich door de situatie dat het publicatiestuk (het XBRL instance document) wordt opgesteld op basis van het inrichtingsstuk.

Business rules Deze controleren de inhoud van een jaarrekening, zoals opgenomen in het XBRL instance document, ten opzichte van vooraf gedefinieerde validatieregels. Deze validatieregels zijn in de vorm van XBRL formulas opgenomen in het geselecteerde entrypoint van de KvK taxonomie.

Concepten Dit zijn de rapporteerbare elementen van een taxonomie. Deze elementen zijn gedefinieerd op basis van de van toepassing zijnde wet- en regelgeving.

Consistente Presentatie

Een vorm van renderen die altijd, ongeacht de gebruikte software, tot een vergelijkbare weergave zal leiden. Het resultaat van de rendering is gebaseerd op de presentatiedefinities zoals opgenomen in de taxonomie en aanvullende regels zoals opgenomen in de SBR Consistente Presentatie specificatie.

Detached signature bestand

Dit bestand bevat zowel de ondertekening van de accountantsverklaring als het waarmerk van de door de ondernemer opgestelde jaarrekening. Het verschil tussen de ondertekening en het waarmerk is geëxpliciteerd in dit bestand op basis van het SBR ondertekeningsbeleid.

Digipoort Digipoort is een onderdeel van de 'procesinfrastructuur' van de Nederlandse overheid. De ontvangst, verwerking en aflevering van elektronische berichten, zoals het publicatiestuk, die ondernemers naar verschillende overheidsorganisaties verzenden loopt via Digipoort. Digipoort verzorgt ook het retourverkeer naar de inzender. Digipoort biedt een beveiligde verbinding, waarin ook autorisatie en authenticatie plaatsvindt middels certificaten.

Dimensionele linkbase

De dimensionele linkbase geeft de dimensionele relaties weer tussen concepten binnen een ELR.

ELR (extended linkrole)

ELR is een technisch scheidingsmechanisme dat voor verschillende doeleinden gebruikt kan worden. Het dient om een groep aan elementen bij elkaar te clusteren in een logische set.

Entrypoint De ingang naar de betreffende XBRL taxonomie.

143

Formeel buitenlandse vennootschap

Een naar een ander dan Nederlands recht opgerichte, rechtspersoonlijkheid bezittende kapitaalvennootschap, die haar werkzaamheid geheel of nagenoeg geheel in Nederland verricht en voorts geen werkelijke band heeft met de staat waarbinnen het recht geldt waarnaar zij is opgericht.

Inrichtingsstukken De jaarrekening die een onderneming dient op te stellen voor haar eigen administratie.

KvK taxonomie De KvK taxonomie is dat deel van de Nederlandse Taxonomie dat zich richt op het deponeren van verantwoordingsrapportages bij het handelsregister van de Kamer van Koophandel via SBR.

Label Elk concept in de KvK taxonomie heeft een Nederlandstalig, Engelstalig Duitstalig en Franstalig standaard label. Een standaard label moet altijd uniek zijn. Hierdoor beschrijft het eenduidig het element. Voor presentatie-doeleinden komen soms ook andere soorten labels voor in een taxonomie. In de KvK taxonomie komen naast het standaard label ook documentation labels, terse, verbose, period-start, period-end en total labels voor. Terse labels zijn labels die het uitgebreide standaard label verkorten naar een overzichtelijkere, kortere variant. Verbose labels geven een uitgebreider label weer dan in het standaard label is sopgenomen. Dit vloeit meestal voort uit een iets andere verwoording van hetzelfde concept. Period-start labels geven aan dat het een waarde aan het begin van een periode betreft. Period-end labels geven aan dat het een waarde aan het einde van een periode betreft. Total labels kunnen worden toegepast wanneer een concept te beschouwen is als een totaal van een optelling.

Nederlandse Taxonomie

De Nederlandse Taxonomie (NT) is de XBRL taxonomie die gezamenlijk is opgesteld door verschillende overheidsorganisaties binnen het SBR programma in Nederland ten behoeve van informatie-uitwisseling in de verantwoordingsketens.

Online service Zelf Deponeren Jaarrekening

Met de online service Zelf Deponeren Jaarrekening kunt u de jaarrekening van uw rechtspersoon in bedrijfsklasse micro of klein invoeren en deponeren bij de KvK.

PKIoverheid (services) certificaat

PKIoverheid (services) certificaat is het beveiligingscertificaat dat een organisatie moet gebruiken om te kunnen communiceren met Digipoort. In sommige gevallen mag er met Digipoort gecommuniceerd worden met een verzamelcertificaat. Dit betekent dat meerdere organisaties gebruik maken van hetzelfde certificaat. De Kamer van Koophandel staat voor het deponeren het gebruik van een verzamelcertificaat toe.

Preparer extension Preparer extension betreft een middel om de KvK taxonomie aan te vullen met eigen begrippen en/of de presentatiestructuren van de KvK taxonomie aan te passen om meer in lijn te komen met de gewenste presentatiewijze.

Presentation hierarchy

Presentation hierarchy koppelt een ELR aan abstracts om zodoende een logische presentatieboom te realiseren. Hierbij wordt gebruik gemaakt van de parent-child arcrole, waarbij een order op deze arcs geplaatst worden. De abstracts kunnen gebruikt worden als titel voor de rendering van de onderliggende tabel(len).

Presentation linkbase

De presentation linkbase geeft de presentatierelaties weer tussen concepten binnen een ELR. Deze presentatierelaties zijn hiërarchisch van aard en hanteren hiervoor een parent-child arc. Hierdoor ontstaat een zogenaamde ‘boomstructuur’ die de volgorde van de verschillende concepten bepaalt. In de KvK taxonomie wordt de presentation linkbase

144

gebruikt om verschillende concepten binnen een ELR op de volgorde op te nemen die verwacht kan worden van een jaarverantwoording.

Publicatiestukken De jaarrekening die een onderneming dient te deponeren bij het handelsregister van de Kamer van Koophandel binnen (uiterlijk) 12 maanden na het einde van het boekjaar. Publicatiestukken voor rechtspersonen in bepaalde bedrijfsklassen (micro-, kleine als middelgrote rechtspersonen) zijn minder uitgebreid dan de inrichtingsstukken als gevolg van de vrijstellingen uit artikelen 2:395a, 396 en 397 BW.

Referentie De koppeling van elementen in de KvK taxonomie naar de relevante wet- en regelgeving.

Rendering Rendering betreft, in deze context, de omzetting van een XBRL instance document naar een leesbare vorm. Een XBRL instance document is een bestand dat door de computer kan worden verwerkt en is voor de mens over het algemeen niet makkelijk te interpreteren. Om een XBRL instance voor de mens begrijpelijk te maken wordt deze, op basis van vastgelegde definities in de taxonomie, omgezet naar een leesbare vorm.

SBR Standard Business Reporting (SBR) is de internationale verzamelterm voor de initiatieven die als doel hebben verantwoordingsinformatie-uitwisseling te vereenvoudigen en op deze wijze de maatschappelijke lasten van verantwoording te verminderen.

SBR-filingrules Regels die door de betreffende uitvragende partij(en) worden gesteld aan de XBRL instance documenten.

Tabel Een tabel in de table linkbase kent in de KvK taxonomie altijd een x-as en een y-as. Een as van een tabel wordt vaak gevoed vanuit de bestaande presentatierelaties in de presentation linkbase. Regelmatig worden ook de dimensionele constructies uit dimensionele linkbases gehanteerd als bron voor de vulling van de as van een tabel. Veelal worden dan de verschillende members (al dan niet in een bepaalde hiërarchische verhouding) op een as geplaatst. Een voorbeeld hiervan is bij een verloopoverzicht.

Tool Opstellen XBRL

Met deze tool kunt u de jaarrekening van uw rechtspersoon in de bedrijfsklasse middelgroot in XBRL-formaat opstellen en deponeren bij de KvK.

Trust Service Provider

Een partij die bevoegd is digitale certificaten te verstrekken.

Uitgevende instelling

Een natuurlijke persoon of een publiekrechtelijke of privaatrechtelijke juridische entiteit, met inbegrip van een staat, waarvan effecten tot de handel op een gereglementeerde markt zijn toegelaten.

XBRL XBRL is de afkorting voor eXtensible Business Reporting Language. XBRL is de internationale standaard die een gestandaardiseerde uitwisseling van financiële gegevens tussen geautomatiseerde systemen mogelijk maakt.

XBRL instance document

Een XBRL instance document is een bestand dat door de computer kan worden verwerkt. Het bevat de gegevens van de jaarverantwoording in de vorm zogenaamde ‘tags’ die verwijzen naar concepten uit de KvK taxonomie. Deze gegevens bestaan uit de feiten die gerapporteerd worden, evenals de contextuele gegevens die benodigd zijn om de feiten op een gestructureerde en consistente wijze te kunnen interpreteren.

Informatiegids voor het deponeren van een jaarrekening met SBR … · 2018-03-09 · 3 Voorwoord...

Documents

Transcript of Informatiegids voor het deponeren van een jaarrekening met SBR … · 2018-03-09 · 3 Voorwoord...