Van ‘uren x tarief’ naar ‘prijs per product’: hoe doe je dat?

Dit artikel is gepubliceerd in Accountancynieuws op 17 juni 2011

In Accountancynieuws is regelmatig te lezen dat accountantskantoren bezig zijn om productprijzen in te voeren ter vervanging voor het tot nu toe veelgebruikte systeem van ‘uren x tarief’. In het betoog van Steef Visser tijdens Accountancynieuws Trends op 31 mei jl. kwam dit ook aan de orde. Het doel hiervan is tweeledig. In de eerste plaats vragen cliënten om vaste prijzen – zeker voor standaardproducten – en die willen kantoren aanbieden. In de tweede plaats willen accountantskantoren en andere dienstverleners hun rendement borgen met verdergaande efficiencyverbeteringen.

In veel berichten over dit onderwerp krijgt het eerste doel de meeste nadruk. Het tweede lijkt mij echter de belangrijkste veroorzaker te zijn van de ‘sense of urgency’, die nu echt is ontstaan na jaren van denken en praten over dit onderwerp. Ontwikkelingen zoals SBR versterken dit gevoel. In de praktijk is deze ontwikkeling lastiger te implementeren dan het op het eerste gezicht lijkt. De systematiek van ‘uren x tarief’ zorgt bijvoorbeeld voor aanzienlijke verschillen in gefactureerde bedragen voor dezelfde werkzaamheden. Zelfs bij een al vergaand gestandaardiseerde werkwijze. Daarom in dit artikel een beknopte uitwerking van dit onderwerp.

Spagaat

Bij de huidige systematiek van ‘uren x tarief’ verkeren de professionals nogal eens in een spagaat. Om een hoger bedrag dan op deze manier berekend door te kunnen berekenen aan de cliënt, zijn er maar twee mogelijkheden: een hoger aantal uren schrijven dan daadwerkelijk is besteed aan de werkzaamheden of een hoger tarief berekenen. Het eerste voelt niet goed, niet integer, want die uren zijn niet gemaakt. Het tweede is steeds vaker een onhaalbare oplossing, omdat bij echt goed automatiseren van routinematige werkzaamheden het tarief wel heel drastisch moet worden verhoogd. Met tariefdifferentiatie voor verschillende werkzaamheden is hier wel een mouw aan te passen, maar dan moet de cliënt niet om een specificatie vragen…..

Productprijs

Het werken met een ‘prijs per stuk’, ofwel een productprijs, lijkt een betere oplossing te zijn. Bij goed gebruik hiervan wordt recht gedaan aan de belangen van zowel de cliënt als de dienstverlenende organisatie. In het kader van dit artikel bedoel ik met producten de standaardproducten van accountants en belastingadviseurs, zoals jaarrekeningen, aangiften en de verwerking van de financiële en salarisadministratie. Voor overige (advies)diensten kan wel een prijsafspraak worden gemaakt.

‘Een productprijs zorgt er voor dat een accountantskantoor er belang bij krijgt om efficiënter te gaan werken. Dat was tot nu toe zelden het geval.’

Belang voor de cliënt

Op korte termijn krijgt de cliënt waar hij om vraagt: een vaste prijs voor een duidelijk omschreven dienst. Het risico van minder efficiënt werken is voor rekening van de dienstverlener. Daar staat tegenover dat efficiënter werken voordeel oplevert voor de dienstverlener, dus dat lijkt op korte termijn minder gunstig voor de cliënt. Op wat langere termijn is dit laatste voor de cliënt wel gunstig. Een productprijs zorgt er namelijk voor dat een accountantskantoor er belang bij krijgt om efficiënter te gaan werken, iets wat tot nu toe zelden het geval is geweest. Bij het werken op basis van ‘uren x tarief’ zorgt een efficiencyverbetering meestal voor meer kosten (opleiding, software, enz.) en tegelijkertijd voor minder omzet (minder uren). Bij productprijzen verandert dit naar gelijke omzet en minder kosten. Hierdoor kan voor standaardproducten meer worden geconcurreerd op prijs zonder in te leveren op kwaliteit.

Belang voor de dienstverlener

Het belang voor het accountantskantoor is groot: bij de huidige ontwikkelingen in de markt, zoals SBR, is het essentieel om een ander prijsmodel te gaan hanteren om het rendement van de organisatie op een acceptabel niveau te houden. De invoering van de relevante aspecten van zulke externe ontwikkelingen in de interne processen brengt vaak kosten van (de implementatie van) software met zich mee en is daarnaast vaak tijdsintensief. Deze kosten moeten op een redelijke manier worden terugverdiend om ook in de toekomst cliënten van dienst te kunnen zijn met kwalitatief hoogwaardige diensten.

Voorbereiding

Gedurende het traject van invoering van productprijzen is het op meerdere momenten gewenst om inzicht te hebben in de huidige urenbesteding aan de bijbehorende werkzaamheden. Dat is in de praktijk vaak minder eenvoudig dan het lijkt, omdat de benodigde detaillering voor dit doel afwijkt van hetgeen nodig is voor het declareren op basis van ‘uren x tarief’. Een voorbeeld om dit duidelijk te maken (zie kader).

Huidige situatie vs. gewenste situatie

Huidige situatie

De verwerking van de salarisadministratie vindt nu plaats op basis van bestede uren. Hierin zijn diverse werkzaamheden opgenomen, zoals het aanmaken van nieuwe medewerkers in het salarispakket, het verwerken van de mutaties, het doen van de loonaangifte, enz. Voor het registreren van de uren zijn voor deze werkzaamheden afzonderlijke urencodes beschikbaar, maar op de factuur worden al deze codes gegroepeerd tot één factuurregel. Het registreren van uren op verkeerde codes heeft geen consequenties, waardoor sommige medewerkers gemakshalve alle uren registreren op de urencode ‘Salarisverwerking’.

Gewenste situatie

Om een zuiver uitgangspunt te hebben voor het bepalen van productprijzen is een juiste registratie ineens wel van groot belang geworden, zoals blijkt uit de volgende twee urenstaatjes:

Voorbeeld 1

2,50 uur        Klant X        Salarisverw. 50 stroken

Voorbeeld 2

1,75 uur        Klant X        Salarisverw. 50 stroken
0,50 uur        Klant X        Aanmaken 3 nwe. mdw.
0,25 uur        Klant X        Loonaangifte periode x

In de eerste situatie is er geen betrouwbare basis beschikbaar om de huidige kosten per product te berekenen. Als de registratie wel wordt gebruikt, is het risico op een te hoge, niet concurrerende, prijs, heel reëel. In de tweede situatie zijn de huidige kosten redelijk betrouwbaar te berekenen. Wel is het aan te bevelen om een voldoende uitgebreide set urenregels als uitgangspunt te nemen van verschillende klanten, medewerkers en vestigingen. Ook bij gestandaardiseerde processen kunnen hier nog relevante verschillen in voorkomen. Tijdig aandacht besteden aan de urenregistratie kan vertraging op een later moment voorkomen. Een juiste registratie gedurende enkele maanden is minimaal noodzakelijk. Overigens kan bij werkzaamheden die in bulk worden uitgevoerd, zoals het verwerken van aangiften loonheffing, worden volstaan met een totaal aantal uren in combinatie met het totaal aantal cliënten, waarvoor het werk is uitgevoerd.

Bepalen huidige kostprijs

De verkoopprijs van het product zal niet primair moeten worden bepaald op basis van de huidige kostprijs (onder huidige kostprijs moet in dit artikel worden verstaan: bestede uren x tarief). Toch is het verstandig om vooraf deze huidige kostprijs wel te bepalen, o.a. om inzicht te krijgen in de variabelen die van belang kunnen zijn bij de uiteindelijke bepaling van de productprijs. Grotere verschillen in kostprijs van werkzaamheden voor verschillende cliënten, medewerkers of vestigingen moeten worden geanalyseerd om een bruikbare kostprijs te verkrijgen. Verschillen ontstaan bijvoorbeeld doordat:

  • werk niet door de juiste medewerker wordt uitgevoerd (te hoog tarief);
  • werk niet voldoende is gestandaardiseerd of niet op de afgesproken wijze wordt uitgevoerd (te veel uren);
  • de urenregistratie niet juist is (zoals hiervoor beschreven).

Afhankelijk van het product en de huidige tariefstructuur binnen de organisatie, kan het nodig zijn om het benodigde aantal uren voor een bepaald product te bepalen en dat te vermenigvuldigen met het gemiddelde tarief van de medewerkers die dit werk in de gewenste situatie uit zouden moeten voeren. Het effect van een te hoog tarief door een minder optimale werkverdeling wordt dan verminderd.

Bepaling productprijs

Tot nu toe zijn enkele, voornamelijk cijfermatige, voorbereidingen aan de orde geweest, waar accountants geen moeite mee zullen hebben. Om een reële productprijs te bepalen, moet eerst worden bepaald wat het product precies inhoudt. Dit moet zo worden omschreven, dat het aan medewerkers en cliënten duidelijk uit te leggen is. Een paar voorbeelden van variabelen, die van belang kunnen bij de bepaling van productinhoud en -prijzen:

  • aangiften IB: wel of geen onderneming;
  • aangiften Vpb: wel of geen fiscale eenheid en aantal dochtermaatschappijen;
  • salarisverwerking: van toepassing zijnde CAO.

Vervolgens is het nodig om te weten welke prijs concurrerend is in het relevante gedeelte van de markt. Aangezien nog niet veel accountantskantoren hun prijzen op hun website vermelden, is hier verder onderzoek nodig en dat is niet altijd gemakkelijk. Een aanknopingspunt kan worden gezocht in de uitgebrachte offertes die wel en niet zijn geaccepteerd in de afgelopen periode en de prijzen die daarin zijn aangeboden. Bij een product waar nog veel efficiencyvoordelen te behalen zijn, geeft de huidige prijs op basis van ‘uren x tarief’ mogelijk een redelijk beeld van de maximaal haalbare prijs. Bij een product waar alle efficiencyverbeteringen al zijn doorgevoerd, zal tussen de huidige kostprijs en de productprijs een duidelijk verschil zitten. Het zal verder van de eigen situatie afhangen hoe deze informatie kan worden verkregen.

Gevolgen voor declaraties

Nadat de productprijs is bepaald, kan worden berekend welk effect dit zal gaan krijgen op de declaraties aan cliënten. Aan een deel van de cliënten zal op deze manier mogelijk een hogere prijs worden doorberekend. Hierbij dient er rekening mee te worden gehouden, dat de prijsstijging niet altijd in één keer te realiseren is. Aan de declaraties van de cliënten die met een productprijs een lager bedrag doorberekend zullen krijgen, moet ook extra aandacht worden besteed. De belangrijkste vraag hierbij is of er sprake is van meerwerk, dus werkzaamheden die niet binnen de omschrijving van het product zijn opgenomen en die aanvullend moeten worden gefactureerd. Als de hiervoor genoemde effecten voor de declaraties aan cliënten in kaart zijn gebracht, is daarmee ook een redelijke indicatie beschikbaar van het effect op de omzet.

Moment van invoering

Een eenduidig moment van invoering kan de administratieve verwerking makkelijker maken. Hierbij kan bijvoorbeeld worden gedacht aan:

  • de aangiften IB en Vpb met ingang van een nieuw aangiftejaar, bijvoorbeeld alle aangiften over 2010;
  • de salarisverwerking vanaf 1 januari 2011, waarbij de aangiften over december 2010, die dus in januari worden gedaan, nog op de oude manier worden doorbelast;
  • alle pensioenberekeningen die vanaf 1 juli 2011 worden aangevraagd bij de interne pensioenafdeling.

Praktische randvoorwaarden

Wanneer eenmaal besloten is om over te gaan van ‘uren x tarief’ op ‘prijs per product’ moet er goed gekeken worden naar de praktische randvoorwaarden om dit ook echt mogelijk te kunnen maken:

  • houd rekening met de mogelijkheden en beperkingen van de in gebruik zijnde software. Pas de werkwijze daar zo praktisch mogelijk op aan, om zo weinig mogelijk administratieve overlast te creëren. Het is niet verstandig om ten koste van alles vast te houden aan de bestaande software voor uren/declaratie, maar net zo min om te gemakkelijk de software te vervangen;
  • zorg vanaf het begin van de invoering voor een passend systeem van bewaking van de gemaakte uren ten opzichte van de daadwerkelijk gefactureerde productprijzen. Maak eventueel onderscheid tussen een interne en externe productprijs, zodat de nacalculatie eenduidig kan worden vergeleken met de interne productprijs en eventuele inefficiency tijdig kan worden gedetecteerd;
  • ten slotte: standaardprijzen vragen om standaardproducten met een standaard verwerkingsproces. Besteed dus eerst aandacht aan standaardisatie van de werkwijze en ga daarna pas over tot het berekenen van standaardprijzen.
Advertenties

XBRL/SBR: is gemiddelde prioriteit goed genoeg?

Op www.accountancynieuws.nl stond onlangs een artikel met de titel “XBRL geen prioriteit voor accountants en belastingadviseurs”. Dit artikel is gepubliceerd naar aanleiding van een door de beroepsorganisaties gehouden onderzoek in januari 2010 onder een groot aantal leden. Deze titel geeft enerzijds kort maar krachtig de status van XBRL bij accountants en belastingadviseurs op dat moment weer, anderzijds lijkt deze titel ook de indruk te willen wekken, dat het wel prioriteit zou moeten hebben. Of dat hoge, gemiddelde of lage prioriteit zou moeten zijn, staat er helaas niet bij.

Zelf werk ik gelukkig bij een organisatie, waar het belang van XBRL/SBR al een tijd wordt onderkend en daar ook naar wordt gehandeld. Wij zijn er nu ongeveer een jaar concreet mee bezig (eerst richting softwareleveranciers, nu intern en richting cliënten) en inmiddels zijn we een aardig eind op weg. In een eerdere blog heb ik een tijdspad beschreven, wat mij op dat moment realistisch leek en nu achteraf gezien, klopt dat best aardig. Daarom in dit artikel een vervolg met een actuele status en ideeën voor het vervolg.

Gemiddelde prioriteit is ook prioriteit
Naar mijn mening moeten we XBRL zeker niet laten liggen, maar moeten we er ook niet zo’n hoge prioriteit aan toekennen, dat het ten koste gaat van andere ontwikkelingen. In elk geval moet er een duidelijke keuze worden gemaakt over de manier, waarop binnen een kantoor moet worden omgegaan met SBR en in dat licht is het weer typisch ‘des accountants’ dat uit het onderzoek blijkt, dat 84% van de organisaties, die de vragenlijst hebben ingevuld, nog helemaal geen beslissing heeft genomen over een ontwikkeling, die zo’n grote impact kan gaan hebben. Als ik kijk naar de belangrijkste redenen, waarom nog geen besluit is genomen, verbaast dat lijstje me niet:

  • De klanten vragen er (nog) niet om: dit komt niet echt proactief over, terwijl de meeste accountantsorganisaties dat volgens hun website wel zijn.
  • Onvoldoende informatie over het gebruik van XBRL en de mogelijkheden: wanneer weten we wel voldoende? Volgens mij is de enige manier om het echt te gaan begrijpen het gewoon aan de slag gaan met een pilot. Overigens is via http://www.xbrlvooraccountants.nl/ inmiddels een praktisch en goed leesbaar handboek beschikbaar, wat heel veel duidelijk kan maken.
  • Niet duidelijk of XBRL een succes wordt: we zouden er ook voor kunnen gaan als beroepsgroep om er een succes van de maken, maar dat klinkt wel eng en het resultaat is niet voor 100% gegarandeerd.

Samengevat geeft dit eigenlijk aan, dat accountants wel zeggen dat ze hun klanten willen helpen bij het ondernemen, maar dat ze geen beslissing durven nemen over hun eigen business. Een bewuste en duidelijke keuze is toch wel het minimum, wat cliënten van hun accountant mogen verwachten.

Zou deze afwachtende houding komen door de angst voor omzetverlies, omdat de efficiency hiermee bijna onvermijdelijk (drastisch) zal verbeteren? De klap zou wel eens het hardst kunnen zijn bij de kantoren, die efficiencyverbetering altijd hebben uitgesteld, terwijl het voor de al efficiënt werkende kantoren wel meevalt.

Nu beginnen!
Als we een tijdje gaan brainstormen, zijn er vast wel honderd en een redenen te bedenken, waarom we vooral niet met XBRL zouden moeten gaan beginnen en die redenen zullen ook altijd veel zekerder aanvoelen dat de mogelijke redenen om juist wel te beginnen. Een paar redenen om het toch wel te gaan doen:

  • Een ontwikkeling, die op iets langere termijn een heel reële kans op administratieve lastenverlichting in zich heeft, kan een beroepsgroep die zichzelf serieus neemt, niet laten gaan en moet dat ook niet willen. Op korte termijn zit het voordeel bij andere partijen (banken) als degenen die de meeste inspanning moeten doen (intermediairs), maar dit mag geen reden zijn om het dan maar niet te doen.
  • Als XBRL aan de kant van de banken goed werkt, zullen de banken aanlevering in deze vorm gaan eisen en/of nadelen gaan verbinden aan het aanleveren op papier (80% in 2012 is al genoemd als planning in dit kader, dus hoe lang zou de eis dan nog duren?). Afwachten lijkt me daarom een slechte keuze.
  • Steeds meer softwareleveranciers zijn er klaar voor, dus de kans dat het nog gaat ‘floppen’ door te weinig medewerking van die kant wordt steeds kleiner. Als we tijdig starten met de implementatie van XBRL kunnen we de benodigde extra gegevens t.b.v. bijvoorbeeld de banken tijdens het reguliere werk verzamelen en zullen de extra kosten zo laag mogelijk zijn. Tevens kan de implementatie in alle dagelijkse processen dan zo geleidelijk mogelijk worden uitgevoerd.

Hoe beginnen?
Aanleveren van rapportages in XBRL kan naar een aantal uitvragende partijen: de belastingdienst, de Kamer van Koophandel, de banken en het CBS. Uiteraard kan richting elk van deze vier partijen worden gestart met aanleveren, maar niet elke volgorde is even praktisch. Een mogelijke volgorde is:

1. Verkorte winstaangifte Vpb (vWIA) naar de belastingdienst
Als een organisatie of een intermediair een convenant Horizontaal Toezicht met de belastingdienst heeft afgesloten, kan gebruik worden gemaakt van de vWIA. Technisch en procedureel is dit een van de minst ingewikkelde aanleveringen in XBRL. Als de leverancier van de fiscale software de benodigde aanpassingen heeft doorgevoerd, moet eerst een digitaal certificaat worden aangevraagd bij DigiNotar of een andere partij. Daarna moet een overeenkomst worden aangegaan met een Autorisatie Service Provider (AuSP). Tenslotte moeten wat instellingen binnen de software worden gemaakt en daar is zo ongeveer alles wel mee gezegd.

Het nadeel is, dat hier de minste efficiencyvoordelen zijn te behalen, maar het is wel het makkelijkste startpunt en sommige softwareleveranciers zijn er al klaar voor. Na de vWIA Vpb zullen stapsgewijs een aantal andere belastingsoorten volgen.

2. Jaarrapportage naar een van de banken (Rabobank, ING of ABN AMRO)
Een tweede stap kan het aanleveren van een rapportage naar een van de deelnemende banken zijn. De leveranciers van rapportagesoftware zijn hier (bijna) gereed voor, dus een eerste aanlevering snel na de vakantieperiode moet mogelijk zijn. Door zo’n pilot wordt duidelijk welke gegevens nodig zijn, waar deze vandaan kunnen worden gehaald, welke gegevens nog niet beschikbaar zijn, enz.

Om inzicht te krijgen in de manier, waarop de informatie bij de bank binnenkomt en wordt geïnterpreteerd, is het praktisch om een afspraak te maken met een account manager en dit gewoon door te nemen. Ongetwijfeld zullen hier genoeg aandachtspunten uitkomen, dus op tijd beginnen is nodig.

En als dit aan beide kanten duidelijk is: gezamenlijk een informatiesessie beleggen voor de medewerkers van zowel het accountantskantoor als de bank. Goed om elkaar te begrijpen en tevens goed voor de contacten onderling. De banken vragen via de inhoud van de XBRL-berichten veel transparantie, dus dan mogen zij ook wel transparant zijn over de manier, waarop dit bij hen intern wordt afgehandeld.

3. Jaarrekening naar de Kamer van Koophandel
Het deponeren van een commerciële jaarrekening in XBRL-formaat is al langer mogelijk. Door het samenvaltraject commercieel-fiscaal is het nu ook toegestaan om een fiscale jaarrekening te publiceren. Of dit handig is, betwijfel ik stevig, omdat het dan maar de vraag is of leveranciers dit snappen. Bij kredietbeoordelaars zal dit na verloop van tijd wel goed gaan, net als bij de banken, maar of leveranciers die zelf een kredietbeoordeling uitvoeren, dit gaan snappen, is nog maar de vraag. Het risico is mijns inziens heel reëel, dat een leverancier kredietlimieten naar beneden bijstelt of zelfs intrekt als het resultaat in de laatste jaarrekening (bijv. door willekeurige afschrijving) heel laag of negatief is. Hier zal dus goed over moeten worden nagedacht, want de consequenties kunnen groot zijn.

4. Opgaven aan het CBS
De laatste en minst interessante stap voor accountantskantoren is het via XBRL versturen van opgaven aan het CBS, denk ik. Dit zal voor sommige cliënten vast toegevoegde waarde opleveren, maar gezien de impact van de genoemde stappen 2 en 3 zal dit vast geen of een hele lage prioriteit krijgen.

Tot slot: richt processen gelijk goed in!
Een belangrijk aandachtspunt tot slot: richt alle relevante processen goed in en probeer niet per definitie alles op te lossen door de bestaande processen aan te passen of uit te breiden. Het implementeren van XBRL/SBR is een mooi moment om alle betrokken processen grondig te beoordelen. En het zou wel eens nodig kunnen zijn om de processen van accountants en belastingadviseurs vergaand te integreren! En dat terwijl het nog maar vier jaar geleden is, dat die processen juist uit elkaar zijn getrokken in verband met de invoering van de WTA en de bijbehorende angst voor aansprakelijkheid van accountants voor fiscale werkzaamheden!

Succes!

Real-time = Realistisch?

“Standard Business Reporting (SBR) zorgt ervoor, dat iedereen altijd actueel inzicht kan hebben in de financiële gang van zaken bij een onderneming.”, dat is zo ongeveer de samenvatting van een aantal opmerkingen die ik de afgelopen weken heb gelezen en gehoord. SBR zou dus de oplossing zijn van alle problemen met (tijdig) rapporteren.

Gelukkig kwamen deze opmerkingen niet allemaal zomaar uit de lucht vallen. Bij wat nader onderzoek, bleek namelijk dat een van degenen, die hierover een opmerking maakte, er vanuit ging, dat het op orde hebben van de bedrijfsprocessen en de informatievoorziening daaromheen er ook voor zou zorgen, dat rapporteren in SBR op elk moment mogelijk zou zijn.

Hoe mooi het idee ook is, toch denk ik dat de praktijk iets weerbarstiger is. In eerste instantie gaat het rapporteren in SBR voor het MKB alleen om de jaarrapportage naar debanken, de Kamer van Koophandel en de Belastingdienst (de laatste in de vorm van de verkorte winstaangifte). Actuele informatie rapporteren in SBR komt pas daarna en zal waarschijnlijk als eerste gaan spelen richting de banken. Die verwachten dan toch een wat completere set gegevens dan alleen informatie vanuit de primaire bedrijfsprocessen. Om dan echt op elk moment te kunnen rapporteren, hebben we real-time inzicht nodig in alle gegevens, die nodig zijn om zo’n rapportageset te kunnen maken. Real-time is tegenwoordig een eis die vaak wordt gesteld aan managementinformatie, ook al zonder dat SBR in beeld was. Het lijkt zo simpel: computers zijn snel, transacties worden direct verwerkt, dus informatie is direct beschikbaar. Maar is het zo simpel als het lijkt? En hoe real-time moet informatie zijn om maximale waarde te hebben voor de gebruiker van de informatie?

Om met het laatste te beginnen: goed nadenken over de vraag hoe frequent en hoe snel informatie beschikbaar moet zijn, kan het stellen van zinloze eisen voorkomen. En het hierbij onderscheid maken tussen informatie, die dagelijks wordt gebruikt om bedrijfsprocessen te sturen, en informatie die veel minder frequent nodig is om de gang van zaken te bewaken, is ook een belangrijke stap. Uit deze opmerkingen is al op te maken, dat het op elk moment een complete rapportageset in SBR op kunnen of willen leveren, in veel gevallen niet reëel is.

Een eenvoudig voorbeeld: als elke dag een rapportage moet kunnen worden opgeleverd, betekent dit ook dat alle kosten per dag moeten worden toegerekend om een betrouwbaar overzicht te geven. En dat is heel wat anders dan dagelijk inzicht hebben in alle belangrijke bedrijfsprocessen. Dat laatste is uitermate belangrijk, maar of het eerste dat ook is, betwijfel ik.

Samengevat komt het er gewoon op neer, dat we nog steeds zullen blijven rapporteren met een maximale frequentie van maandelijks. Real-time lijkt me niet zinvol, maar met een hogere frequentie rapporteren dan in de papieren wereld lijkt me heel waarschijnlijk. Dan moet wel de informatie continu op orde zijn en daar komt voor accountants vast weer mooi werk uit: “continuous auditing“. Want “garbage in = garbage out” geldt hierbij ook nog steeds en dat willen we uiteraard niet, want dan wordt de digitale rapportagewereld een achteruitgang ten opzichte van de papieren wereld.

De échte status van Standard Business Reporting (SBR)

In een artikel op accountancyvisie.blogspot.com las ik, dat SBR (nieuwe naam voor XBRL) een van de thema’s voor  2010 zal zijn. Hier ben ik het voor 100% mee eens. Binnen onze organisatie hebben we onze plannen met betrekking tot SBR de afgelopen weken weer eens geactualiseerd, zoals we al een paar jaar lang regelmatig doen, en onze conclusie is ook zeker dat dit in 2010 echt wat zal gaan worden. Misschien dat de administratieve lasten voor ondernemers nu dan echt een stukje worden verlicht. En dan maar hopen dat de overheid niet weer allerlei andere administratieve lasten gaat bedenken omdat het ‘toch automatisch wordt geregeld’.

Al jaren denken wij en vele anderen dat het wat zal gaan worden als de banken mee gaan doen en dat halverwege dit jaar dan eindelijk een feit geworden. In de zoektocht naar de échte status van SBR op dit moment hebben wij wel geconstateerd, dat veel zaken langzamerhand concreter aan het worden zijn, maar dat ook van heel veel zaken wordt gecommuniceerd, dat het klaar is, terwijl de werkelijkheid nog wel eens tegenvalt. Daarover wil ik in dit artikel wat dingen noemen, zonder de pretentie volledig te zijn en het overal bij het rechte eind te hebben. Laat overigens wel duidelijk zijn, dat ik groot voorstander ben van dit soort ontwikkelingen.

SBR voor banken
Op http://www.sbr-nl.nl/ is een samenvatting van de bancaire roadmap inzake SBR te vinden. Als ik dit lees, krijg ik toch een wat ander beeld dan dat de Rabobank, ING en ABN AMRO er allemaal vanaf 1 april 2010 klaar voor zullen zijn: “Streefdatum is dat vanaf 1 april 2010 de generieke voorzieningen gereed zijn en dat ook één of meer banken op dat moment de kredietrapportages in XBRL formaat kunnen ontvangen.” Dus geen harde datum maar een streefdatum en “een of meer”.

Verder wordt in die bancaire roadmap ook het een en ander opgehangen aan de operationalisering van de verkorte winstaangifte (vWIA) door de belastingdienst, wederom in een voetnoot in kleine letters: “Om de beoogde resultaten te kunnen behalen moet de Belastingdienst zorg dragen voor een tijdige operationalisering van de vWIA’s VPB en IB.”. De pilot hiervan loopt volgens ditzelfde document nog tot 31 december 2010 en de planning is om deze vWIA definitief in gebruik te nemen vanaf 1 januari 2011 voor aangiften over 2010.

Zo zijn er nog wel meer punten te noemen, zoals het aansluiten van de banken op de Overheids Transactie Poort (OTP), wat nog wordt onderzocht, maar daarvoor kun je het best zelf het genoemde document lezen.

Belastingdienst en SBR: verkorte winstaangifte (vWIA)
Bij de belastingdienst loopt, zoals eerder al vermeld, een pilot vWIA, die nog tot 31 december 2010 duurt. De banken haken hier duidelijk op aan, wat overigens m.i. een goed uitgangspunt is. Vereiste voor de pilot vWIA is ook het hebben afgeloten van een convenant horizontaal toezicht met de belastingdienst. Voor mij is onduidelijk of de pilotgroep definitief is of dat daar nog extra intermediairs bij aan kunnen sluiten. Als dat laatste niet kan, zijn de plannen van de banken om tussen augustus 2010 en december 2011 de tweehonderd grootste intermediairs aan te sluiten weer een beetje vreemd, want daar zouden ze dan in januari 2011 pas mee kunenn starten.

SBR en softwareleveranciers
Bovenstaande informatie is voor mij reden om te veronderstellen, dat 2010 zeker het jaar zal worden, waarin SBR wat wordt, maar ik heb wel het idee, dat dit het jaar wordt om alles werkend te krijgen. De echte grote stroom SBR-berichten zal pas in 2011 op gang komen. Na contacten met onze softwareleveranciers inzake SBR heb ik ook geconstateerd, dat wel wel blij mogen zijn, dat niet per 1 april alles klaar hoeft te zijn. Opleverdata staan gepland voor eind maart en software, die precies op tijd wordt opgeleverd en dan ook gelijk nog redelijk probleemloos werkt, kom ik niet zo vaak tegen, zeker niet van onze belangrijkste leverancier op dit gebied. Daarnaast willen niet alle softwareleveranciers aan de gang met een beta-versie van een taxonomie (banken) of met een taxonomie, die wel definitief is, maar waarvan ‘nog niet bekend is of deze definitief in gebruik wordt genomen en wanneer (vWIA)’.

Wijziging in werkzaamheden voor accountants
De werkzaamheden voor accountants zullen (nog verder) gaan verschuiven van de jaarrekening naar een proces rondom het bewaken van de kwaliteit van de administratie gedurende het hele jaar. Als we zorgen, dat gedurende het hele jaar periodiek werkzaamheden worden verricht om de kwaliteit van de administratie op peil te houden in plaats van één keer in een jaar bij het maken van de jaarrekening de benodigde correcties te voeren, beschikt de ondernemer altijd over actuele en juiste informatie en kunnen we ook nog eens goed en tijdig rapporteren in SBR. Dan heeft de klant tenminste waar voor zijn geld. En wil de klant dan eigenlijk nog wel een jaarrekening?

Misverstanden rondom SBR
Rondom SBR bestaan ook nogal wat misverstanden, waarvan ik de belangrijkste wil noemen: SBR gaat veel kosten besparen. Volgens mij gaat SBR voor accountantskantoren en andere bedrijven, die hun processen al goed op orde hebben, niet zoveel opleveren voor de bestaande processen als vaak wordt gedacht. Er is vast wel wat voordeel te behalen, maar grote klappers zijn niet te verwachten als processen al goed op orde zijn. De banken zullen er waarschijnlijk het meest van profiteren. Eigenlijk is sprake van een lastenverschuiving van de banken naar o.a. accountantskantoren.

Uitdaging voor accountants
Nu deze ontwikkelingen echt definitiever vorm aan gaan nemen, zullen accountants als beroepsgroep ook eens iets moeten gaan vinden van de certificering van SBR ‘instance documenten’. Van de website van het NIVRA: “Omdat de huidige accountantsverklaring niet past bij de een jaarrekening in XBRL-formaat heeft het NIVRA al begin 2007 bekend gemaakt dat het op dit moment niet is toegestaan jaarrekeningen met een accountantsverklaring in XBRL-formaat te deponeren.”. Dat is inmiddels twee jaar geleden, maar de oplossing heb ik nog steeds niet kunnen vinden op diezelfde website. Gelukkig wordt hier inmiddels wel mee geëxperimenteerd door bijvoorbeeld Deloitte, dus het kan wel. Misschien dat we hier in 2010 meer over gaan horen?! Of zou iedereen dat zelf maar uit moeten zoeken?

Zelf een taxonomie bekijken?
Tenslotte: op de website van FINAN is een gratis viewer te downloaden, waarmee de actuele Nederlandse taxonomieën kunnen worden ingezien. Interessant om eens te zien wat er in een taxonomie is opgenomen.

%d bloggers liken dit: