SBR ASSURANCE VANUIT TECHNISCH PERSPECTIEF FLOWCHARTS EN TOELICHTING

SBR ASSURANCE VANUIT TECHNISCH PERSPECTIEF FLOWCHARTS EN TOELICHTING

DOEL VAN DIT DOCUMENT SBR Assurance is het afgeven van een accountantsverklaring in XBRL bij een verantwoording in XBRL. Onder accountantsverklaring wordt in dit kader een controle-, beoordeling- èn samenstelverklaring verstaan. De NBA ontwikkelt de hulpmiddelen die hiervoor nodig zijn en heeft een Groenboek, als voorloper op een handreiking geschreven voor het proces. Het groenboek is te vinden op www.nba.nl-sbr-assurance. Dit groenboek dekt de vaktechnische aspecten van SBR Assurance af. Dit document dekt alleen de technische aspecten van SBR Assurance af: de processtappen met de verschillende technische mogelijkheden per begin 2013 zijn uitgewerkt en ook komen de hulpmiddelen aan bod. Het is het resultaat van een stage-opdracht van Kevin Hakvoort van de Hogeschool van Amsterdam bij de NBA. Het doel is om kantoren een helpende hand te bieden bij het inrichten van de infrastructuur en procesgang van SBR Assurance. De NBA heeft hierbij niet de bedoeling om processen en procedures voor te schrijven of hier in enige mate een aanbeveling bij te doen. INTRO De accountant dient in het kader van SBR Assurance een verklaring in XBRL af te geven. In dit document worden de technische mogelijkheden van de 6 SBR Assurance processtappen uiteengezet. Figuur 1 - De SBR Assurance processtappen. Deze 6 stappen (Figuur 1 De SBR Assurance processtappen) worden in dit document uitgewerkt: 1: De ontvangst van een ; 2: Het (digitaal) ondertekenen door de onderneming; 3: Het opstellen van de verklaring in XBRL; 4: Het waarmerken van de en koppelen aan de verklaringen ; 5: Het digitaal ondertekenen door de accountant; 6: Het versturen naar de uitvragende door de onderneming of de accountant namens de onderneming. De mogelijkheden die in dit document beschreven staan, zijn aan de hand van interviews en enquêtes in het voorjaar van 2013 opgesteld. Niet alle mogelijkheden zijn beschreven; er is een selectie gemaakt op basis van de meest voorkomende mogelijkheden zoals aangegeven door de respondenten. Omdat het proces nog in ontwikkeling is, zullen waarschijnlijk in de toekomst meer mogelijkheden ontstaan. Aanlevering van 1

rapportages en verklaringen op papier is voorlopig (in het geval van deponering nog tot 2017) ook nog mogelijk, maar dit valt buiten de scope van dit document. In dit document komen begrippen voor als inhoudelijke validatie en technische validatie. Met inhoudelijke validatie of controle worden de reguliere accountantswerkzaamheden bedoeld, die door de accountant worden uitgevoerd om een controle-, beoordelings- of samenstelverklaring af te kunnen geven. Met technische validatie worden de werkzaamheden bedoeld die specifiek zijn voor het werken met XBRL. Als verantwoordingsdocument zal worden uitgegaan van een. STAP 1: ONTVANGST JAARREKENING INSTANCE De eerste stap in het SBR Assurance proces is het opstellen/ontvangen van een. Hierin zijn 3 mogelijkheden: (1) de klant genereert een, (2) de klant levert de in traditioneel format aan een accountant en de accountant converteert deze naar een of (3) een accountant voert de administratie voor de klant / stelt een samen en genereert de. TECHNISCHE MOGELIJKHEDEN: In deze stap zijn qua technische mogelijkheden geen verschillen in de drie manieren van ontvangen van het. Communicatie en aanlevering van documenten is mogelijk via een portal/cloud, USB stick of mail. De portal/cloud kan gescheiden zijn in twee domeinen. De portal/cloud kan gebruikt worden als communicatie middel tussen klant en het (extern) en de portal/cloud kan worden ingezet als workspace voor intern gebruik tussen accountants en medewerkers onderling. Hierbij zijn toegangsrechten in de portal/cloud voor de klant anders dan voor de accountants en medewerkers. 1.1. DE KLANT MAAKT EEN JAARREKENING INSTANCE De klant kan een genereren met behulp van een rapportgenerator, deze moet echter wel XBRL enabled zijn. Als de is gegenereerd, zal de klant controleren of de XML/XBRL en FRIS valide is. De klant kan dit controleren met eigen tooling of kan dit outsourcen. Als de valide is, zal de klant deze aan de accountant aanleveren. Als de niet valide is, zal de klant de moeten aanpassen en opnieuw valideren totdat deze valide is en kan worden aangeleverd aan de accountant. Na ontvangst van de zal de medewerker van het de technisch kunnen valideren via de Validatie en Normatieve Presentatie tool (VNP). Als de niet technisch valide is, zal de medewerker van het dit communiceren met de klant en zal deze de moeten aanpassen. Als deze wel technische valide is, zal de medewerker (waarschijnlijk) de naar een leesbare versie omzetten zodat hij de inhoudelijk kan beoordelen. Dit kan de medewerker doen door de te renderen of hij kan de importeren in zijn digitale dossier en hier de inhoudelijke controle uitvoeren. De medewerker kan de ook bekijken met de VNP. Ook is het mogelijk om een systeem gerichte controle uit te voeren op het proces van totstandkoming van de. De systeem gerichte controle is een controle op -creatie en hierdoor is het mogelijk dat de technische validatie zoals hierboven beschreven, reeds is uitgevoerd voorafgaand aan stap 1. Dit zou met name bij rapportages die frequent worden opgevraagd en van een verklaring voorzien, een optie zijn. 2

Accountant (Partner) Portal/Mail/USB Klant Als de, na inhoudelijke controle, niet correct (onjuist) of niet als voldoende (onvolledig) is beoordeeld, zal de medewerker dit communiceren met de klant en zal de klant de moeten aanpassen en opnieuw een moeten genereren. Als deze wel correct is, zal de partner (accountant) de ook inhoudelijk controleren zodat hij zijn eindverantwoordelijkheid voor het afgeven van de verklaring kan nemen. (NB: inhoudelijke controles behoren tot vaktechniek en vallen buiten de scope van dit document). Als deze naar zijn mening niet correct is, zal de terug gaan naar de klant om te laten corrigeren. Als deze wel correct is, zal de medewerker de naar de klant versturen voor formele ondertekening. N.B. bij samenstelopdrachten kan het tijdstip van tekenen door de onderneming afwijken. Deze procesgang kan als volgt worden weergegeven (Figuur 2 - Stap 1: De klant maakt een ): Financiële gegevens Rapport generator Valide? Technisch valide? Inhoudelijke controle Renderen/VNP Inhoudelijke controle Figuur 2 - Stap 1: De klant maakt een.. 1.2 KLANT LEVERT DE JAARREKENING IN TRADITIONEEL FORMAT AAN DE ACCOUNTANT AAN EN DE ACCOUNTANT CONVERTEERT DE JAARREKENING NAAR EEN JAARREKENING INSTANCE (CONVERSIE). 3

De klant stelt een in traditioneel format (Word of Excel) op en levert deze aan de accountant aan. De gewenste labelling (tagging) wordt in een spreadsheet aangeleverd. De medewerker zal de inhoudelijk controleren, als deze inhoudelijk niet correct is zal de klant de moeten aanpassen. Als de correct is, zal daarna de accountant de op inhoud controleren. Hierna zal de medewerker de converteren naar een. Dit zal gebeuren met een conversie tool. Bij deze stap is het van belang de onafhankelijkheidsvoorschriften / de wettelijke vereisten bij OOB s na te leven en bij relevante opdrachten een samenloop van controle en samenstellen te vermijden. Er zijn tientallen verschillende conversie tools (bijvoorbeeld: Altova MissionKit (Altova)) en bedrijven (bijvoorbeeld: WebFilings (Webfilings)) in Amerika en andere landen(voorbeeld Verenigd Koninkrijk: IRIS software (IRIS Software)) die zich gespecialiseerd hebben in het converteren van een spreadsheet, PDF of Word document naar een XBRL bestand. Deze bedrijven en conversie tools werken met de taxonomie uit het betreffende land. In Nederland zijn conversie tools beschikbaar die op basis van de NT bestanden omzetten in XBRL (bijvoorbeeld: Semansys). Bij de conversie is het mogelijk dat sommige onderdelen handmatig moeten worden toegevoegd, overgenomen of worden aangepast om een complete te genereren. Hierbij moet gedacht worden aan de tekstuele toelichtingen en bijvoorbeeld de waarderingsgrondslagen. De zal vervolgens technisch worden gevalideerd. Als deze niet correct is zal de medewerker van het de opnieuw moeten genereren. Als deze wel correct is, zal de medewerker van de accountant de aan de klant aanbieden. Deze procesgang kan als volgt worden weergegeven (Figuur 3 - Stap 1: Conversie.): Financiële gegevens Portal/Mail/USB Klant Accountant (Partner) Conversie Inhoudelijke controle Technisch Valide? Inhoudelijke controle Figuur 3 - Stap 1: Conversie. 4

Afhankelijk van de functionaliteit van beschikbare tooling en de bruikbaarheid hiervan op NT gebaseerde documenten, kan er ook voor gekozen worden eerst de te converteren en daarna de inhoudelijke controle uit te voeren. 5

Accountant (partner) Portal/Mail/USB Klant 1.3 DE ACCOUNTANT STELT DE JAARREKENING INSTANCE OP. Met de administratie van de klant als basis, kan de medewerker van de accountant via een rapportgenerator een opstellen. Deze zal hierna door de medewerker van de accountant technisch gevalideerd worden. Als de niet valide is, zal de medewerker van de accountant de moeten aanpassen. Als dit wel zo is, zal de vervolgens door collega s (van andere afdelingen van het ) worden gecontroleerd en/of beoordeeld. Hier kan worden gestart met optie 1 zoals beschreven in 1.1: De klant stelt een op, waarbij ervan wordt uitgegaan dat de gegenereerde (onder verantwoordelijkheid) van de klant is ontvangen. Deze procesgang kan als volgt worden weergegeven (Figuur 4 - Stap 1:De accountant stelt de op.): Financiële gegevens Financiële gegevens Administratie Rapport generator Gevalideerde Alle gegevens? Technisch valide? Naar stap 1 1.1 Figuur 4 - Stap 1: De accountant stelt de op. STAP 2: HANDTEKENING VAN DE ONDERNEMING De organisatie zal, voordat de accountant een verklaring opstelt, zijn handtekening voor het eigenaarschap van de moeten zetten. Idealiter gebeurt dit met een elektronische (ondernemings-)handtekening. Alternatieve oplossingen zoals een "natte" handtekening op een uitdraai van de of een "goedkeuringsproces" via een portal zijn ook mogelijk. 6

TECHNISCHE MOGELIJKHEDEN: In deze stap zijn twee technische mogelijkheden te onderscheiden. De klant gebruikt ondertekensoftware en verstuurt daarna het getekende document via de portal/cloud, USB stick of mail, of de klant zal een autorisatiestap in de portal/cloud gebruiken. 2.1 DE DIGITALE HANDTEKENING VAN DE ORGANISATIE Nadat de accountant de zowel technisch als inhoudelijk heeft gevalideerd, zal de organisatie over deze finale versie van de zijn goedkeuring moeten verlenen, bij voorkeur door het zetten van een digitale handtekening. Van de ondervraagde accountants verwacht een meerderheid dat voorlopig niet met een digitaal (ondernemings-)certificaat ondertekend zal worden. Om een digitale handtekening bij de te plaatsen, zal het bestuur (en indien van toepassing de Raad van Commissarissen) het eens moeten zijn over (een leesbare versie van) de. Indien een bestuurslid en/of Commissaris niet tekent, staat de reden hiervoor vermeld in de. Hierbij zal de organisatie de eerst naar een leesbare versie moeten omzetten, als dit nog niet is gebeurd in bijvoorbeeld de portal of bij het aanmaken van de. Het omzetten naar een leesbare versie van de kan worden geoutsourced of met een eigen (gecertificeerde) tool gedaan worden. Als het bestuur (en eventueel de Raad van Commissarissen) het eens is over de leesbare versie van de, zal de worden ondertekend met een persoonlijk organisatie-gebonden certificaat. Het persoonlijk organisatie-gebonden certificaat is gekoppeld, doormiddel van het KvK-nummer, aan de organisatie. Er zijn een aantal mogelijkheden om na te gaan of alle bestuursleden (en commissarissen) het eens waren over de leesbare versie van de. Het is bijvoorbeeld mogelijk dat dit wordt opgenomen in de notulen, ieder lid zou op een papieren versie van de kunnen tekenen en ieder lid zou een autorisatie/goedkeuring in de portal/cloud kunnen geven. N.B. de vaktechnische/juridische (detail)uitwerking van de omstandigheden valt buiten de scope van dit document. Als het bestuur (en eventueel de Raad van Commissarissen) het niet eens zijn over de leesbare versie van de, zal de (waarschijnlijk) aangepast worden. Hier kan worden teruggegaan naar Stap 1 in het proces. 7

Accountant (partner) Portal/Mail/USB Klant Deze procesgang kan als volgt worden weergegeven (Figuur 5 - Stap 2: De digitale handtekening van de organisatie.): Rendering Aanpassen (terug naar stap 1) Leesbare versie van Onderteken software Goedkeuring bestuur/rvc Digitaal ondertekende Digitaal ondertekende Figuur 5 - Stap 2: De digitale handtekening van de organisatie. 8

2.2 AUTORISATIE STAP IN DE PORTAL Om een autorisatie te geven over de, zal de klant de eerst moeten bekijken. Dit zou bijvoorbeeld kunnen door een (gecertificeerde) viewer (in de portal), door de te renderen met gecertificeerde renderingsoftware of doordat een gerenderde versie is meegeleverd (door de samensteller). De leesbare versie van de moet worden goedgekeurd door het bestuur (en eventueel de Raad van Commissarissen). Als het bestuur de afkeurt, zal de moeten worden aangepast en zal de (samenstellende) accountant hier bericht van krijgen. Als het bestuur de goedkeurt, zal het bestuur de autoriseren via de portal. Hiervoor zal worden ingelogd op de portal en wordt een autorisatie gegeven met een extra authenticatiemiddel 1 als een SMS-code of een token. Om na te gaan of alle leden het eens waren over de leesbare versie van de is het mogelijk dat dit zal worden opgenomen in de notulen of dat op de papieren getekend wordt. Een andere optie hierbij is dat alle leden (van zowel het bestuur als Raad van Commissarissen) de moeten bekijken en autoriseren in de portal. Als de is geautoriseerd door de organisatie, zal de accountant een melding krijgen. In de portal wordt een audit-trail bijgehouden. Deze registreert wanneer de bijvoorbeeld is geopend, opgehaald, bekeken, gedeeld met anderen en wanneer een goedkeuring/autorisatie is gegeven. Authenticatie van klanten is een belangrijk onderdeel in de portal. Voor de authenticatie zijn een aantal technische manieren om de identiteit van een klant vast te stellen. Deze manieren bieden verschillende niveaus van zekerheid, en lopen uiteen van een gebruiksnaam-wachtwoord tot een One Time Password (OTP) via SMS of hardware token. 1 Onder bepaalde voorwaarden is autorisatie via een portal juridisch gelijkgesteld aan het feitelijk ondertekenen. De accountant moet zich er dus wel van verzekeren dat autorisatie via het portal aan de relevante eisen voldoet. Dit is en vaktechnisch issue en valt verder buiten de scope van dit document. 9

Accountant (partner) Portal Klant Deze procesgang kan als volgt worden weergegeven (Figuur 6 - Stap 2: Autorisatie stap in de portal.): Rendering Papieren Goedkeuring bestuur/rvc Aanpassen (terug naar stap 1) Inloggen Autorisatie van de Geautoriseerde Figuur 6 - Stap 2: Autorisatie stap in de portal. 2.3 NATTE HANDTEKENING Om een goedkeuring te geven en het eigenaarschap te nemen over de, zal de organisatie de in een leesbare versie willen bekijken. Dit zou kunnen door een (gecertificeerde) viewer, een meegeleverde gerenderde versie of door bijvoorbeeld de zelf te renderen met tooling. De leesbare versie kan worden afgedrukt op papier en moet worden geaccepteerd en ondertekend door het bestuur (en eventueel de Raad van Commissarissen). Als de niet wordt geaccepteerd zal de aangepast moeten worden (door de samenstellende accountant). Als de leesbare versie van de is goedgekeurd, zullen de leden van het bestuur (en eventueel de leden van de Raad van Commissarissen) de papieren versie van de ondertekenen. De accountant zal een kopie van de getekende opnemen in zijn dossier. 10

Accountant (partner) Portal/Mail/USB Klant Deze procesgang kan als volgt worden weergegeven (Figuur 7 - Stap 2: Natte handtekening.): Papieren Rendering Goedkeuring bestuur/rvc ondertekenen Bestuur/RvC Aanpassen (terug naar stap 1) Ondertekende Figuur 7 - Stap 2: Natte handtekening. 11

STAP 3: VERKLARING OPSTELLEN IN XBRL FORMAT De accountant zal in deze stap een verklaring in XBRL genereren. Zoals de een entrypoint naar de Nederlandse Taxonomie gebruikt, zo gebruikt de verklaring een entrypoint naar de NBA Taxonomie. Ook andere assurance providers (zoals actuarissen of fiscalisten) kunnen met deze aanpak verklaringen of rapporten afgeven. Hier is wel een op hun werk toegesneden taxonomie voor nodig. TECHNISCHE MOGELIJKHEDEN: In deze stap zijn twee technische mogelijkheden. Een lokale verklaringengenerator (al dan niet in een rapportgenerator) en de mogelijkheid om een verklaring in de portal/cloud op te stellen. Uit onderzoek is gebleken dat de meeste accountantskantoren bij het opstellen van een verklaring, een lokale verklaringengenerator gebruiken. Er werden in de ondervraagde accountantskantoren verschillende soorten verklaringengeneratoren gebruikt. Enkele voorbeelden waren een eigen verklaringengeneratoren, een verklaringengenerator geïntegreerd in de rapportgenerator en de NBA verklaringengenerator. PROCESBESCHRIJVING: De accountant zal aan de hand van de een verklaring () opstellen. Voordat de accountant een verklaring gaat opstellen, moet eerst de NBA Taxonomie in de verklaringengenerator of portal worden gelezen. Dit gebeurt hetzelfde als met de NT via een URL. Hierna zal de accountant de keuze maken welke verklaring hij wil afgeven (goedkeurend, afkeurend, een verklaring met beperking of met oordeelonthouding). De verklaring bestaat uit verschillende elementen, deze elementen zullen getagged moeten worden (tenzij van een XBRL-enabled verklaringengenerator gebruik wordt gemaakt). Met elementen worden onderdelen van de verklaring zoals adressering, datering, de diverse tekstparagrafen van de verklaring en eventueel het hash-totaal bedoeld.. Als de medewerker van de accountant de verklaring heeft opgesteld, moet worden nagegaan of de verklaring inhoudelijk juist is en technisch valide is. De verklaring zal inhoudelijk door de accountant (partner) worden gecontroleerd en de medewerker zal controleren (of outsourcen) of de verklaringen technisch (FRIS, XML/XBRL) valide is. Volgens de Assurance rules (ARIS) moet de verklaringen voldoen aan inhoudelijke consistentieregels. Hierbij kan worden gedacht aan de aanwezigheid van bepaalde verplichte tekstblokken in combinatie met de aard van het oordeel dat wordt afgegeven. De (voorlopige) verklaringen zal door een medewerker of door de accountant beschikbaar worden gesteld aan de klant, zodat de klant het finale oordeel en bijbehorende bewoordingen kan bekijken. 12

Accountant (partner) Portal/Mail/USB Klant Deze procesgang kan als volgt worden weergegeven (Figuur 8 - Stap 3: opstellen in XBRL format.): verklaring NBA Taxonomie inlezen en generator Technisch valide? verklaring Inhoudelijk valide? Figuur 8 - Stap 3: opstellen in XBRL format. Het is mogelijk om de verklaring op te stellen in de portal. Dit proces werkt bijna op dezelfde manier als hiervoor is weergegeven. Deze optie is alleen mogelijk als de portal dit faciliteert. Voordat de verklaring kan worden gegenereerd, dient de in de portal te zijn geüpload. Als dit is gedaan, kan de medewerker of de accountant in de portal een leesbare versie van de bekijken en aan de hand hiervan een besluit nemen welke verklaring hij gaat opstellen (goedkeurend, afkeurend of met oordeelonthouding). Hierna zal de inhoud van de verklaring worden ingevuld. Als de verklaring volledig is ingevuld en de is gecreëerd, zal worden nagegaan of deze inhoudelijk en technisch valide is. Hierna is de verklaring () opgesteld. 13

Accountant (partner) Portal Klant STAP 4: WAARMERKEN In deze stap wordt de (getekende) gekoppeld aan de verklaring. PROCESBESCHRIJVING Naast een aantal koppelingen op basis van de kenmerken van de, is er ook een koppeling die de juiste versie van de authentiseert. De koppeling wordt gemaakt door het gebruik van een hash algoritme. Met het hash algoritme berekent de (medewerker van de) accountant een unieke reeks tekens op basis van de inhoud van de (exclusief de datum van vaststellen 2 ). Het resultaat van de berekende hash zal worden opgenomen in de verklaringen. Hiermee wordt de verklaring gekoppeld aan de gecontroleerde. De accountant (partner) zal, als eind verantwoordelijke, de berekende hash controleren. Dit kan hij doen door nogmaals de hash over de te berekenen. Om vast te stellen dat hij de juiste heeft ontvangen. De hash kan stand alone worden gebruikt, of als onderdeel van het aftekenen door de accountant (zie stap 5). In het laatste geval heeft de electronische handtekening het waarmerk doel. Beide methoden zijn per ultimo 2013 mogelijk en onderwerp van discussie. Deze procesgang kan als volgt worden weergegeven (Figuur 9 - Stap 4: Waarmerken.): Hash berekenen Hash opnemen in verklaring met hash met hash Hash controle Figuur 9 - Stap 4: Waarmerken. STAP 5: HANDTEKENING VAN ACCOUNTANT In deze stap zal de verklaring, met indien van toepassing hierin opgenomen het stand alone hash totaal, digitaal worden ondertekend door de accountant. Hiervoor zal een persoonsgebonden beroepscertificaat worden gebruikt. Een voorbeeld hiervan is het NBA beroepscertificaat. Bij het plaatsen van een digitale handtekening met een beroepscertificaat wordt de verklaringen versleuteld (met een persoonlijk geheime sleutel) en kan niets meer veranderd worden in de verklaring. 2 Het aangeven van de datum van vaststelling is nog onderwerp van discussie. Hier wordt over gediscussieerd waar deze geplaatst moet worden en wanneer in het proces. Want als een hash berekend is en hierna moet een datum van vaststelling worden toegevoegd, zal de berekende hash veranderen en zal deze opnieuw berekend moeten worden. 14

Accountant (partner) Portal/ USB/ mail Klant De NBA stelt het gebruik van het beroepscertificaat verplicht bij het afgeven van verklaringen s. Dit geldt voor zowel assurance opdrachten als non assurance opdrachten. Met het persoonsgebonden beroepscertificaat kan de ontvanger onomstotelijk vaststellen welke persoon ondertekend heeft en of deze een erkend beroep heeft. De ondertekening met een persoonsgebonden beroepscertificaat is, vanwege de eisen die gelden voor een dergelijk certificaat, wettelijk gezien gelijk gesteld aan een natte handtekening. Bij het tekenen wordt, afhankelijk van de gevolgde methode, een separaat bestand gecreëerd (signature file). TECHNISCHE MOGELIJKHEDEN Het digitaal ondertekenen van de verklaringen kan op twee manieren gedaan worden. (1) De accountant kan digitaal onderteken met ondertekensoftware en (2) de accountant kan digitaal ondertekenen met een ondertekenfaciliteit binnen een portal. 5.1 ONDERTEKENEN MET ONDERTEKENSOFTWARE Nadat de accountant de verklaring heeft beoordeeld, goedgekeurd en eventueel de hash heeft herberekend met de (nog in ontwikkeling zijnde) Validatie en Normatieve Presentatie tooling (VNP), zal de accountant de verklaringen gaan ondertekenen met zijn persoonsgebonden beroepscertificaat. De accountant zal met de software de verklaringen kunnen tonen. Eerst zal de accountant moet inloggen met gebruikersnaam en wachtwoord en vervolgens zal een ondertekenings-handeling plaatsvinden. Hierbij zal de accountant één of twee extra codes moeten invoeren om de ondertekening te bevestigen. Deze procesgang kan als volgt worden weergegeven (Figuur 10 - Stap 5: Ondertekenen met ondertekensoftware.): met hash met hash Inloggen op onderteken - software bekijken ondertekenen met extra code Figuur 10 - Stap 5: Ondertekenen met ondertekensoftware. Ondertekende verklaringen Ondertekende verklaringen 5.2 ONDERTEKENEN MET EEN ONDERTEKENFACILITEIT IN DE PORTAL De ondertekenfaciliteit staat geïnstalleerd op de portal, hiervoor dient de accountant in te loggen op de portal. Vervolgens zal de accountant de verklaring via de portal in de ondertekenfaciliteit kunnen laden en bekijken. Hiervoor dient de accountant wel eerst in te loggen op de ondertekenfaciliteit. Vervolgens vindt een ondertekenings-handeling plaats waarin de stappen bij aanloggen van de portal worden herhaald en zullen één of twee extra codes nodig zijn om deze handeling te bevestigen. 15

(partner) accountantskantoo Portal Klant r Accountant Deze procesgang kan als volgt worden weergegeven (Figuur 11 Stap 5: Ondertekenen met een ondertekenfaciliteit in de portal.): met hash bekijken Inloggen ondertekenfaciliteit ondertekenen met extra code Ondertekende verklaringen met hash Figuur 11 - Stap 5: Ondertekenen met een ondertekenfaciliteit in de portal. STAP 6: VERSTUREN NAAR DE ONDERNEMING OF NAAR UITVRAGENDE PARTIJEN DOOR DE ONDERNEMING OF DE ACCOUNTANT In deze stap worden de en de verklaring naar de onderneming gestuurd (en daarna via Digipoort/BIV naar de uitvragende ). VASTSTELLEN ALGEMENE VERGADERING (VAN AANDEELHOUDERS) (AV(A)) Bij veel organisatie wordt de na het opstellen in een aparte AV(A) vastgesteld. De s kunnen in een (SOAP) container of los, aan de AV(A) worden aangeleverd. Een container is een (SOAP) enveloppe waar de s ingaan. Dit is een soort Zipfile waardoor de afzonderlijke document bij elkaar blijven. De (geplande) datum van vaststellen zou conform NT in het document moeten worden meegestuurd. De feitelijke vaststelling is, conform de traditionele, een gegeven buiten de en zal waarschijnlijk separaat van beide s (als losse )worden toegestuurd aan uitvragende, al dan niet in de te gebruiken container. Als alternatief wordt de datum in de s opgenomen, maar valt dit element buiten de ondertekeningen van stap 2 en 5. Nadat de AV(A) de heeft vastgesteld, moet deze samen met het jaarverslag en overige gegevens (welke eveneens zijn opgenomen in de ) binnen 8 dagen bij het Handelsregister van de Kamer van Koophandel worden gedeponeerd ten behoeve van de openbaarmaking hiervan. Dit is de verantwoordelijkheid van het bestuur van de organisatie. Daarnaast kan de set (indien van toepassing op basis 16

van BT) door de ondernemer of de accountant naar een kredietverstrekker of andere belanghebbende worden gestuurd. DIGIPOORT/BIV De verklaring en de worden (opnieuw) gebundeld in een container. De container die gebruikt zal worden voor de aanlevering bij Digipoort is de SOAP- (Simple Object Access Protocol) of de WUS-(Web services met UDDI en SOAP) container. De accountant moet over de technische infrastructuur beschikken om deze verzending mogelijk te maken. Software (portal)leveranciers leveren de aansluiting op diverse aanleverkanalen. De drie grootbanken (Rabobank, ING en ABN-AMRO), verenigd in het Financiële Rapportages Coöperatief (FRC), streven ernaar om voor BIV dezelfde standaard te hanteren als Digipoort. De container wordt bij de uitvragende aangeleverd via Digipoort/BIV. Hiervoor dient eerst een verbinding te worden gelegd met behulp van een (kantoor- of ondernemings-)certificaat. Voor meer informatie over de technische aspecten, zie: www.sbr-nl.nl. Het certificaat zorgt voor 2 zaken, namelijk het ondertekenen van het bericht en het opzetten van een beveiligde verbinding. De verzender zal na aanlevering bij Digipoort/BIV vervolgens een bericht met de status van het bericht ontvangen. Als de verzender een bevestiging krijgt is de aanlevering voltooid. Als de verzender een foutmelding krijgt, is het bericht niet door de validatie gekomen en zal hij (na aanpassingen) de container opnieuw moeten te verzenden. Voor andere transportkanalen zullen andere technische alternatieven zijn. VERZENDING TECHNISCHE MOGELIJKHEDEN Voor (middel)grote organisaties kan de verzending van de en de verklaringen op vier manieren gebeuren en voor de kleine organisaties komen hier twee manieren bij. De mogelijkheden voor (middel)grote organisaties voor verzending van en de verklaringen kan gebeuren door: (1) de onderneming zelf met zijn eigen software, (2) door de ondernemer zelf via een eigen portal, (3) door de accountant met eigen software of (4) door de accountant via een portal. Voor kleine organisaties bestaan extra mogelijkheden. (5) De onderneming voert handmatig de rapportage gegevens in op een self service portal (Zelf Deponeren ) of (6) de accountant voert handmatig de rapportage gegevensgegevens in op een SSP (niet van toepassing voor aanlevering aan het Handelsregister). De laatste opties (5 & 6) vallen buiten de scope van dit document. Als de ondernemer de (s) verzendt met eigen software of handmatig invoert bij de self service portals van de overheid, dient de ondernemer in het bezit te zijn van een PKIoverheids servicecertificaat. Als de ondernemer de s verzendt via een portal, dient de onderneming in het bezit te zijn van een PKIoverheids servicecertificaat of het bestuur van de onderneming zal de portal leverancier moeten machtigen om de s te mogen verzenden (verzamelcertificaat). Als de accountant de (s) verzendt, dient het bestuur van de onderneming de accountant te machtigen om te mogen verzenden. Als de accountant de s verzendt met eigen software, dient de accountant/ in het bezit te zijn van een PKIoverheids servercertificaat. Als de accountant verzendt via een portal, dient de accountant/ in het bezit te zijn van een PKIoverheids servicecertificaat of de accountant dient op zijn beurt de portal leverancier te machtigen om de s te verzenden (verzamelcertificaat). 6.1 ONDERNEMING VERZENDT Als de onderneming zelf de verzending van de s verzorgt, zullen ze de en de verklaringen van de accountant ontvangen. Hierna zal een AV(A) plaatsvinden waarbij de wordt vastgesteld. Als deze niet wordt vastgesteld door de AV(A), zal de moeten worden 17

Accountan t (partner) Portal/ Mail/USB Klant aangepast, en start het proces weer bij stap 1.. Verder moet de accountant zijn cliënt machtigen om de verklaring op te nemen in de /SOAP container. 6.1.1 DE ONDERNEMING VERZENDT MET EIGEN SOFTWARE De en de verklaringen zullen in de software worden geladen. Hierna zal een technische handeling plaats vinden waarbij de verschillende s in de (SOAP) container worden geplaatst. Met het PKIoverheids servicecertificaat van de onderneming zal de onderneming de container ondertekenen waarna deze niet meer aangepast kan worden. Hierna wordt een beveiligde verbinding opgezet tussen de software en Digipoort. Met deze verbinding wordt de container naar Digipoort/BIV getransporteerd. Als het bericht verzonden is, zal de onderneming de statussen van de aanlevering moeten controleren totdat door Digipoort/BIV is vastgesteld dat het bericht verwerkbaar is. Deze proces gang kan als volgt worden weergegeven (Figuur 12 Stap 6: De onderneming verzendt met eigen software.): en Instances ingeladen in de software Technische handeling Container met s Ondertekenen met servercertificaat servercertificaat Verzenden naar Digipoort/BIV Verbinding maken met Digipoort/BIV en Figuur 12 - Stap 6: De onderneming verzendt met eigen software. 18

Accountant (partner) Portal Klant 6.1.2 DE ONDERNEMING VERZENDT VIA EEN EIGEN PORTAL De onderneming kan de s via een eigen portal naar de uitvragende sturen. Hiervoor dient de onderneming in het bezit te zijn van een eigen PKIoverheids servicecertificaat of de verzending kan plaatsvinden met een verzamel certificaat. Hiervoor dient het bestuur de portal leverancier te machtigen om de container te verzenden. De en de verklaringen kunnen door de accountant in een container worden geplaatst en geleverd worden aan de ondernemer of de ondernemer zal de en de verklaring in de portal in een (SOAP) container moeten plaatsen. Hiervoor zal een technische handeling plaatsvinden. Hierna zal middels het PKIoverheids servicecertificaat het bericht ondertekend worden en een beveiligde verbinding gemaakt worden met Digipoort. Als het bericht verzonden is, zal de onderneming de statussen van de aanlevering moeten controleren totdat door Digipoort/BIV is vastgesteld dat het bericht verwerkbaar is. Deze procesgang kan als volgt worden weergegeven (Figuur 13 Stap 6: De onderneming verzendt via een eigen portal.): Inloggen op portal Verzenden naar Digipoort/BIV Verbinding maken met Digipoort/BIV en Technische handeling Container met s Ondertekenen met servercertificaat service en Technische handeling Container met s Figuur 13 - Stap 6: De onderneming verzendt via een eigen portal. 19

Accountant (partner) Portal/Mail/USB Klant 6.2 DE ACCOUNTANT VERZENDT Nadat in de onderneming de is vastgesteld door de AV(A), kan de onderneming opdracht geven aan de accountant om de s te verzenden. 6.2.1 DE ACCOUNTANT VERZENDT MET EIGEN SOFTWARE De accountant zal de en de verklaringen in zijn software laden en zal door een technische handeling de s in een (SOAP) container plaatsen. Hierna zal de accountant met zijn PKIoverheids servicecertificaat het bericht ondertekenen en zal een beveiligde verbinding met Digipoort/BIV maken. Als het bericht verzonden is, zal de accountant de statussen van de aanlevering moeten controleren totdat door Digipoort/BIV is vastgesteld dat het bericht verwerkt is. Deze procesgang kan als volgt worden weergegeven (Figuur 14 Stap 6: de accountant verzendt met eigen software.): Verzenden naar Digipoort/BIV Verbinding maken met Digipoort/BIV en en Instances ingeladen in de software Technische handeling Container met 2 s Ondertekenen met servercertificaat servercertificaat Figuur 14- Stap 6: De accountant verzendt met eigen software. 20

Accountant (partner) Portal Klant 6.2.2 DE ACCOUNTANT VERZENDT MET EEN PORTAL Als de accountant de s naar de uitvragende via een portal wil versturen, zal het bestuur van de onderneming de accountant machtigen. De accountant kan met een eigen PKIoverheids servercertificaat of met een verzamelcertificaat van de portalleverancier de s verzenden. Als de accountant een verzamelcertificaat gebruikt, zal de accountant de portal leverancier moeten machtigen om de s te verzenden. Wanneer de AV(A) de heeft vastgesteld, kan de onderneming de datum van vaststellen invullen in de portal en de accountant autoriseren om de s naar de uitvragende te versturen of de onderneming zal middels een autorisatie stap in de portal, de accountant de goedkeuring geven. Door een technische handeling in de portal zullen de en de verklaringen in een (SOAP) container worden geplaatst. Hierna zal de accountant met zijn PKIoverheids certificaat het bericht ondertekenen en een beveiligde verbinding maken met Digipoort/BIV. Als het bericht verzonden is zal de accountant de statussen van de aanlevering moeten controleren totdat door Digipoort is vastgesteld dat het bericht verwerkbaar is. Deze procesgang kan als volgt worden weergegeven (Figuur 15 Stap 6: de accountant verzendt met een portal.): Verzenden naar Digipoort/BIV Verbinding maken met Digipoort/BIV en Technische handeling Container met s Ondertekenen met servercertificaat service Inloggen op portal Figuur 15 - Stap 6: De accountant verzendt met een portal 21

6.3 CONTROLE STATUSSEN AANLEVERING DIGIPOORT/BIV Nadat de container is verzonden, zal de ondernemer, de accountant of de software/de portal de statussen van de aanlevering moeten controleren. Het eerste bericht zal een automatisch respons bericht zijn, waarin het tijdstip van ontvangst bij de overheid vermeld staat. Het kan voorkomen dat door storing of andere oorzaak de portal tijdelijk niet bereikbaar is, hierdoor zal de verzending mislukken. Als na 72 uur na verzendingen geen bericht terug ontvangen is, kan ervan worden uitgegaan dat de verzending mislukt is. In geval dat wel een bericht is ontvangen, is het belangrijk dat actief gecontroleerd wordt of de afronding juist is geweest en dat geen foutmelding ontvangen wordt. Dit kan handmatig, maar ook door software gedaan worden. Als de technische controles goed zijn doorlopen en het bericht voldoet hieraan, wordt een geregistreerd tijdstip van ontvangst van het bericht ontvangen. Hiermee is vastgesteld dat het bericht verwerkbaar is en zal de desbetreffende uitvragende partij het bericht verder afhandelen. Als in deze fase blijkt dat technisch of inhoudelijk iets is mis gegaan, krijgt de ondernemer/accountant nogmaals een kans om het bericht aan te leveren. 22