Hoe lang kunnen we nog werken als de computer uitvalt?

Als je bij een organisatie werkt, die redelijk vergaand is gedigitaliseerd, zit het antwoord op deze vraag waarschijnlijk ergens in de reeks tussen de vijf minuten en een kwartier. Als het één computer is, die uitvalt, is het leed nog wel te overzien en redelijk eenvoudig op te lossen. Maar wat als de automatiseringsomgeving in een organisatie is gecentraliseerd en die centrale omgeving valt uit? Het lijkt me toch een verplichting tegenover klanten en medewerkers, om hier op een goed onderbouwde manier keuzes in maken en maatregelen nemen. Dit wil niet zeggen dat elk risico, koste wat het kost, moet worden uitgesloten, maar wel dat de risico’s op een goede manier in kaart worden gebracht en dat vervolgens passende maatregelen worden genomen.

Een voorbeeld: als bijna alle medewerkers kunnen telewerken, hoeven waarschijnlijk geen dubbel uitgevoerde verbindingen tussen de kantoorvestigingen en het datacenter met de centrale infrastructuur aanwezig te zijn. Bij uitval van de verbinding kan iedereen thuis verder werken.

Beslissingen op managementniveau en niet (alleen) door IT-afdeling
In dit artikel wil ik wat zaken noemen, waarover het management van een organisatie vooraf een beslissing moet nemen. Deze beslissingen zijn nodig om te kunnen bepalen welke maatregelen ‘passend’ zijn. De afdeling IT kan wel helpen om alle relevante informatie beschikbaar te krijgen en ook zal deze afdeling een groot deel van de uitvoering van de maatregelen, waartoe wordt besloten, voor zijn rekening nemen, maar de beslissingen horen echt op het hoogste niveau in de organisatie te worden genomen.

Maximale uitvaltijd (Recovery Time Objective)
Een van de eerste beslissingen, die moet worden genomen, betreft de maximale tijd waarbinnen de beschikbaarheid van een uitgevallen systeem moet worden hersteld (afgekort RTO). De waarde van de RTO is afhankelijk van de schade, die wordt verwacht bij uitval, in wat voor vorm dan ook, dus zowel financiële schade als bijv. imageschade moet worden beoordeeld. Dit laatste wordt o.a. beinvloed door het feit of klanten toegang hebben tot de systemen, via bijvoorbeeld een klantenportal op de website. Ook is telefonie steeds meer geïntegreerd in de datanetwerken, dus denk hierover ook goed na.

Let wel: dit betreft een beslissing over een uitgangspunt vooraf, die tijdens het maken van een ontwerp voor een passende infrastructuur of nog later mogelijk moet worden bijgesteld. Zeker als de RTO in hoofdzaak is afgeleid van de mogelijke financiële schade kan achteraf bijstellen nodig zijn als de kosten om schade te voorkomen niet in redelijke verhouding tot de schade door uitval blijken te staan.

Maximaal dataverlies (Recovery Point Objective)
Een tweede vereiste betreft het vaststellen van het maximaal toegestane dataverlies (RPO). Bij een storing kan de data, die is toegevoegd of gewijzigd sinds de laatste back-up, verloren gaan. In de wat traditionelere netwerken is deze RPO vaak 24 uur, omdat één keer per dag een back-up wordt gemaakt. Als dan aan het einde van de werkdag een systeem zou crashen, zou het werk van de hele dag verloren zijn. Dit wordt steeds minder acceptabel in moderne bedrijfsomgevingen. Het is belangrijk om de RPO per proces vast te stellen om onnodig investeren te voorkomen. Daarnaast moeten de mogelijkheden om de data na een crash te reconstrueren in overweging worden genomen: inkomende e-mail van buiten de organisatie is bijna niet te reconstrueren en tegenwoordig wel van zeer groot belang, dus mogelijk is de RPO voor e-mail één uur, terwijl die voor andere data twee of vier uur is of nog langer.

Combinatie van RTO en RPO
De combinatie van RTO en RPO moet ook worden beoordeeld. Als een storing optreedt, die binnen vier uur moet worden opgelost (RTO) en er mag maximaal vier uur data verloren gaan (RPO) is het nog steeds mogelijk om in bedrijfsprocessen een dag achterstand op te lopen (vier uur werk kwijt en vier uur niet benutte uren). Maar als medewerkers bij uitval van een proces andere werkzaamheden uit kunnen voeren, hebben we weer een heel andere situatie en telt eigenlijk alleen de RPO mee.

Maken ontwerp als infrastructuur niet aan eisen voldoet
Als (delen van) de infrastructuur niet aan de eisen voldoet, moet een ontwerp worden gemaakt voor een gewijzigde of nieuwe infrastructuur, die dat wel doet. Dit is vooral een technische aangelegenheid, waarover ik een andere keer nog wat hoop te schrijven. Aan de hand van dit ontwerp moet ook een inschatting worden gemaakt van de benodigde investeringen en kosten. Neem bij dit soort projecten ook een post ‘onvoorzien’ op, want die komt er vrijwel zeker aan. In mijn blog van 14 november heb ik kort overzicht gegeven van wat maatregelen, die ik in de loop van de jaren genomen heb zien worden bij een groeiende organisatie.

Controleren en eventueel bijstellen van RTO en RPO
Als het ontwerp gereed is, is het tijd om na te gaan of dit aan de RTO en RPO voldoet. Ook moet aan de hand van de inschatting van investeringen en kosten worden nagegaan, of de financiële component in de beslissing voor de waarden van de RTO en RPO in redelijke verhouding staat tot de investeringen en kosten. In een ‘urenfabriek’ is bijvoorbeeld de verhouding tussen enerzijds de gemiste omzet tijdens de uitval gecombineerd met het eventuele dataverlies en anderzijds de te maken kosten een goed uitgangspunt om dit te beoordelen.

Realisatie
De realisatie is, evenals het ontwerp, vooral een technische aangelegenheid. Zoals reeds genoemd, hoop ik daar een andere keer wat over te schrijven. Momenteel ben ik zelf bezig in zo’n project en als dat een stukje verder is in de uitvoering, heb ik vast weer genoeg te melden in een nieuwe blog.

Gebruik maken van ASP of Software as a Service (SaaS)
Als je gebruikt maakt van een ASP of SaaS lijkt het bovenstaande niet van toepassing, maar dat is niet helemaal het geval. Ga maar eens na of de ASP daadwerkelijk maatregelen heeft genomen om de afgeloten Service Level Agreement (SLA) na te komen. En vraag ook eens wat is geregeld voor het geval brand ontstaat in het datacenter in de vorm van een uitwijkscenario.

Tenslotte
Het bovenstaande is misschien niet het meest boeiende in een organisatie om je mee bezig te houden, maar in het kader van informatiebeveiliging wel van essentieel belang. Misschien goed om eens een IT audit uit te laten voeren op de eigen organisatie?

Advertenties

Verslag AFAS Open 2009 Accountancy

Gisteren ben ik samen met een paar collega’s naar de AFAS Open 2009 Accountancy geweest, de jaarlijkse gebruikersdag van AFAS. In deze blog wil ik wil ik een korte indruk geven hoe ik die dag heb ervaren.

Kort verslag
Het eerste deel was een openingssessie, waarin Piet Mars zijn visie op o.a. de recessie en MVO uiteenzette. In zijn visie op de recessie kan ik me aardig vinden, met MVO heb ik wat minder. Dat wil niet zeggen, dat ik duurzaamheid niet belangrijk vind (daarover later nog een keer meer), maar in mijn beleving is MVO vaak een samenvatting van allerlei zaken, die financieel of operationeel gunstig uitpakken en waar vervolgens ook nog een etiket op wordt geplakt met deze drie letters. Ik wil AFAS er zeker niet van beschuldigen, dat het daar zo werkt, want er werden veel goede dingen getoond, maar ik heb er om deze reden gewoon niet zo veel mee. De benaming duurzaamheid vind ik beter en heeft in mijn ogen en oren een minder marketingachtige uitstraling.

Hierna was Bas van der Veldt aan de beurt met eerst zijn visie op de toekomst van Profit en het gebruik ervan en een indruk van de verbeterde algemene functionaliteit in Profit 2011. Hierbij ligt duidelijk de nadruk op verbetering en vereenvoudiging van alle functionaliteit, die Profit al heeft en die door heel veel klanten maar beperkt wordt gebruikt. In de interface komen een behoorlijk aantal verbeteringen, waardoor het bijvoorbeeld mogelijk wordt om nog veel meer met het toetsenbord te doen en dus minder met de muis. Vooral voor de intensieve gebruiker van Profit, waar ik me zelf onder reken, levert dit best wel tijd op en werkt het gewoon veel prettiger. Ook de bijna 100% conversie, die is beloofd, lijkt me wel wat na de ervaringen van vorig jaar met de conversie van Profit 2005 naar 2008. Die is wel goed verlopen, maar kostte behoorlijk veel tijd.

Na de lunch waren de productmanagers HRM/Payroll en Accountancy aan de beurt. Zij gaven ons een goed overzicht van de functionele wijzigingen, verbeteringen en uitbreidingen, die ons te wachten staan. Die ga ik hier verder niet noemen, maar zagen er gewoon goed uit. In de loop van de middag kwamen er ook diverse zaken langs, die als wens van o.a. onze organisatie waren gerealiseerd, zowel naar aanleiding van ingediende supportincidenten als van de inspraaksessies in het voorjaar. Beide presentaties waren het beluisteren waard en beloofden veel goeds voor het komende jaar.

Wet van de remmende voorsprong
Een van de belangrijke ontwikkelingen in Profit is Profit 2Gether, het klantenportal, dat medio 2010 beschikbaar zal komen. Een terechte opmerking, die diverse keren werd gemaakt, is dat de interne organisatie eerst op orde moet zijn (horizontale ketenintegratie), voordat de contacten met de klant op deze manier kunnen gaan verlopen (verticale ketenintegratie). Het is alleen jammer, dat wij nu te maken krijgen met de wet van de remmende voorsprong: wij zijn intern in de organisatie namelijk al zo ver met de interne processen, dat we een klantportal op een zinvolle manier in kunnen zetten en ook graag in willen gaan zetten, maar AFAS is nog niet zover. Doordat weinig Profit-gebruikers zo ver zijn en AFAS alleen ontwikkelt, waar voldoende klanten om vragen, is het beschikbaar komen van dit klantenportal diverse malen uitgesteld. Nu komt het er dan gelukkig aan, maar AFAS moet wel oppassen om zijn klanten niet te veel de les te lezen, terwijl AFAS zelf de oplossingen nog niet beschikbaar heeft doordat de planning een paar keer is bijgesteld.

Dit laatste punt geldt ook voor de koppeling tussen AFAS Profit en CaseWare, die voor accountantskantoren erg praktisch is. Wij zijn daar al diverse keren mee aan het testen geweest, maar als het koppelen van een CaseWare-dossier aan een Organisatie in AFAS Profit CRM ongeveer een uur duurt, gaan we daar echt niet aan beginnen. Naar mijn mening wordt dit overigens veroorzaakt door de technische structuur van CaseWare en kan AFAS hier niet zo veel aan doen, maar dan moet ook niet worden benadrukt dat we dit echt moeten gaan gebruiken.

Deze twee kritiekpunten doen wat mij betreft verder niets af aan alle goede ontwikkelingen binnen Profit, maar het is wel jammer dat we dit soort mooie functionaliteiten (nog) niet kunnen gebruiken, doordat ze (net) niet af zijn. Het thema van de AFAS Open was “Profit More” en dat lijkt zeker waar te gaan worden.

Toekomst
Alles bij elkaar zie ik de nieuwe versie van Profit graag komen. Gezien het soort en aantal functionele verbeteringen wel jammer, dat het nog een half jaar duurt voor de eerste versie van Profit 2011 beschikbaar komt :-). Maar beter iets later en goed, dan eerder en bewerkelijker, dus dat hebben we er wel voor over. ‘k Heb zojuist gelijk maar een verzoek ingediend om in januari 2010 een keer naar het AFAS Quality Center te gaan om zelf Profit 2011 te gaan testen met een kopie van onze eigen database. Dan kan ik toch vast een keer zelf ervaren hoe het gaat werken. ‘k Ben benieuwd of dat in januari al kan.

Continuïteit van informatiesystemen

Bij informatiebeveiliging draait het om drie belangrijke zaken: vertrouwelijkheid, integriteit en beschikbaarheid. Alle drie moeten deze voldoende zijn gewaarborgd om van een passende informatiebeveiliging te kunnen spreken. Een van de hoofdpunten van het onderdeel beschikbaarheid is continuïteitsmanagement van de informatiesystemen en van dat onderdeel wil ik nu kort laten zien hoe ik dat sinds het begin van deze eeuw heb zien ontwikkelen. In dit artikel ga ik niet in op ontwikkelingen als ‘Sofware as a Service’ of meer recente ontwikkelingen als ‘cloud computing’, maar neem ik de eigen infrastructuur als uitgangspunt. Over die andere ontwikkelingen een andere keer vast nog wel meer.

Extra servers
Rond de eeuwwisseling, dus zo’n 10 jaar geleden, was een eerste stap het verdelen van data over meerdere servers en het dubbel uitvoeren van compenenten in de servers. Als deze maatregelen goed werden uitgevoerd, werd de beschikbaarheid wat hoger, omdat bij een probleem met een server iedereen nog wel verder kon werken. Applicaties die gebruik maakten van de andere servers, bleven dan gewoon werken. Overigens had toen elke bedrijfslocatie vaak nog z’n eigen servers en waren storingen daardoor niet zo veel omvattend. Ook werd ICT toen nog veel minder intensief gebruikt. Bij de organisatie, waar ik werk, was dit in 1999 de eerste stap toen we ons bewust werden, dat we toch wel redelijk afhankelijk aan het worden waren van computers.

Centralisatie
Eigenlijk hoort centralisatie niet thuis in het rijtje maatregelen, dat de continuïteit beter waarborgt. Door centralisatie wordt één locatie namelijk heel kritisch in de infrastructuur en worden de risico’s voor de continuïteit dus groter. Hierbij kun je denken aan de stroomvoorziening, brandveiligheid, maar ook bijv. de afhankelijkheid van de dataverbinding op de centrale locatie. Zo’n centralisatieslag heb ik zelf in 2003 uitgevoerd, omdat dit functioneel grote voordelen op ging leveren bij de implementatie van een ERP-applicatie.

Functioneel en beheerstechnisch gezien heeft centralisatie grote voordelen en door een aantal maatregelen kunnen de risico’s voor de continuïteit natuurlijk wel worden beperkt. Een praktische manier, die ik vaak zie,  is dat de centrale infrastructuur wordt verplaatst van een eigen serverruimte naar een professioneel datacenter, waardoor bijv. stroomvoorziening, brandveiligheid, koeling en dataverbindingen veel beter zijn geregeld, dan in de meeste interne serverruimtes in eigen kantoren.

Hogere beschikbaarheid bij centralisatie
In een gecentraliseerde omgeving is het wel beter mogelijk om een groot deel van de infrastructuur dubbel uit te gaan voeren en hierdoor een hogere beschikbaarheid te waarborgen. Doordat de apparatuur fysiek op
één locatie staat, is de benodigde apparatuur en/of software om hogere beschikbaarheid te regelen ook voor kleinere organisaties redelijk betaalbaar. Vaak wordt in dit stadium ook virtualisatie toegepast. De ruimte waar de apparatuur staat, blijft echter nog steeds net zo kritisch. De kans dat deze ruimte door een calamiteit wordt getroffen is misschien niet zo groot, de gevolgen zijn dat zeker wel.

In dit stadium heb ik zelf twee belangrijke trajecten uitgevoerd: in 2005 het invoeren van een databasecluster en het redundant uitvoeren van dataverbindingen. In 2007 hebben wij het grootste deel van de backend-servers gevirtualiseerd, waardoor aanzienlijk minder hardware nodig was en de beschikbaarheid toch hoger werd. Daarnaast werd door deze virtualisatieslag de recovery bij een eventuele calamiteit veel makkelijker. Na het virtualiseren van een groot deel van de servers hebben wij ook het volledige serverpark verplaatst vanuit een eigen serverruimte naar een professioneel datacenter.

Redundant datacenter of uitwijklocatie
Nog een stap verder in het waarborgen van de continuïteit is het gebruik maken van twee datacenters. Afhankelijk van de locatie van de datacenters en de beschikbare verbindingen tussen de twee datacenters zijn hiervoor twee opties.

Uitwijklocatie
De eerste optie is het opzetten van een uitwijklocatie: een ingerichte infrastructuur in een tweede datacenter, dat alleen wordt gebruikt bij een calamiteit in het eerste. Het voordel hiervan is, dat de verbinding tussen de twee locaties alleen nodig is om de data regelmatig te dupliceren. Het nadeel hiervan is dat de apparatuur op de tweede locatie in principe nooit wordt gebruikt, ofwel een erg hoge verzekeringspremie wordt betaald. Een rekenvoorbeeld: als bij uitval van de hooflocatie nog 80% van de capaciteit moet kunnen worden gebruikt, is totaal 180% nodig (100% productie plus 80% uitwijk). Daarnaast is beheertechnisch het risico best groot, dat de applicatieversies e.d. op de uitwijklocatie achterlopen op de productielocatie.

Redundant datacenter
De gunstigere optie, waarvoor wel een aanzienlijk betere verbinding tussen de datacenters nodig is, is het verdelen van de apparatuur over beide locaties, waarbij alle apparatuur actief wordt gebruikt. Bij uitval van één locatie blijft dan nog de helft van de capaciteit beschikbaar. Als dit te weinig is, hoeft in verhouding minder te worden toegevoegd dan bij de optie van de uitwijklocatie. In hetzelfde rekenvoorbeeld is dan maar 80% nodig op beide locaties, dus totaal 160%. Als beide locaties actief zijn, kan worden geprofiteerd van 160% capacteit, terwijl bij uitval van één locatie nog voldoende overblijft. Uiteraard komt er bij deze optie nog veel meer kijken, maar als ik dat allemaal ga noemen, wordt dit artikel nog drie keer zo lang. Als ik tijd en zin heb, ga ik me daar overigens nog wel een keer aan wagen in een redelijk technisch artikel.

Momenteel ben ik bezig met de uitbreiding van onze infrastructuur naar een tweede datacenter. In een bijna volledig gedigitaliseerde omgeving is dit nodig om voldoende waarborgen te hebben voor de continuïteit van de geautomatiseerde infrastructuur. Overigens zullen wij het grootste deel van de apparatuur in een active/active configuratie verdelen over de twee locaties, maar niet alles. Hoe mooi dit technisch ook mogelijk zou zijn, de kosten moeten nog steeds in redelijke verhouding staan tot de risico’s en dan is niet alles te verdedigen.

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.

Geautomatiseerd verwerken van facturen (3)

In dit artikel wil ik weer een update geven van onze ervaringen tijdens het selectieproces van een geschikte oplossing voor het geautomatiseerd verwerken van facturen. Na een eerste demo door vier potentiële leveranciers hebben we er uiteindelijk voorlopig één uitgenodigd voor een tweede demo.

Die hebben we onlangs gehad en daarbij hebben we geconstateerd, dat het toch nog wat meer voeten in de aarde heeft op enkele punten, dan we naar aanleiding van de eerste demoronde hadden ingeschat. Dit speelt overigens vooral in de wat complexere administraties en dan met name bij de faturen, die moeten worden geboekt op meerdere grootboekrekeningen en/of kostenplaatsen. Meestal staat er namelijk geen kostenplaatscode op de factuur vermeld, maar bijv. een vestigingsplaats, medewerkernaam of kenteken. De te behalen efficiency is echter wel voor een behoorlijk deel afhankelijk van de mate waarin dit soort facturen automatisch worden verwerkt, omdat dit handmatig de meeste tijd kosten.

Verder is de koppeling naar het financiële pakket ook van wezenlijke invloed op het verwerkingsproces. Tijdens de demo constateerden we bijv. dat het tijdens de demo gebruikte pakket de BTW-code gebruikte en aan de hand daarvan het BTW-bedrag zelf berekende. Met het BTW-bedrag van de factuur werd dus niets gedaan. Als deze BTW-bedragen niet overeenkwamen, kon de boeking niet worden gemaakt, omdat deze niet in evenwicht was. Dit gaat fout in de volgende situaties:

  • BTW-bedrag wordt per factuurregel berekend: doordat de afronding dan ook per regel plaatsvindt, kan het totaal van de regelbedragen, zeker bij veel factuurregels (bijv. brandstofnota) afwijken van de totaalberekening. In het voorbeeld ging het om € 0,41 op de 180 factuurregels;
  • Gedeelte van de factuur is vrijgesteld van BTW: er staat dan maar één BTW-bedrag op de factuur, maar dat is geen 19% van het totaalbedrag excl. BTW;
  • Bedrag excl. BTW staat op de factuur niet gesplitst in grondslag tegen hoog en grondslag tegen laag tarief, maar het BTW-bedrag wel.

In het financiële pakket was afwijking wel mogelijk, door dit aan te vinken in een speciaal daarvoor bedoeld veld. De koppeling moet dus ook zo worden aangepast, dat de controle wel blijft, maar dat het mogelijk is om het BTW-bedrag af te laten wijken van wat het op basis van de gekozen code zou moeten zijn, eventueel binnen ingestelde grenzen.

Het te behalen resultaat is dus voor een heel groot deel afhankelijk van de kwaliteit van de facturen. Op zich een open deur, maar zeker in een traject als dit, blijkt dat overduidelijk. Eén van de dingen die we bijv. voor het handmatig verwerken al hebben gedaan, is het op de factuur laten vermelden van de kostenplaats op de brandstofnota. Voor het automatisch verwerken blijkt dit nu niet alleen handig te zijn, maar zelfs cruciaal om handmatig werk te voorkomen. Dit moeten we dus nog door (veel) meer crediteuren laten doen.

Aan de hand van de niet in één keer volledig herkende facturen gaan we nu onze crediteurenadministratie op een aantal punten nog verder analyseren vóór we definitief een beslissing nemen over de te kiezen oplossing en de wijze van implementatie.

Verder hebben we tijdens de demo ook een stukje van het proces van het scannen, scheiden van meerdere facturen uit één bestand, e.d. gezien, waardoor mijn beeld van de logistiek rondom de facturen (met name voor administraties van cliënten) weer een stuk duidelijker is geworden. Tijdens de demo duurde dit deel eigenlijk iets te lang, doordat de techniek ons een beetje in de steek liet, maar inhoudelijk was het mij die tijd wel waard.

%d bloggers liken dit: