XML Auditfile verlicht administratieve lasten

Fiscus en SRA ontwikkelen standaard voor data-uitwisseling salarissystemen

De Belastingdienst en accountantsvereniging SRA ontwikkelen een op XML gebaseerde standaard voor het uitwisselen en analyseren van gegevens in salarissystemen. 'XML Auditfile Salaris' moet een bijdrage leveren aan de gewenste administratieve lastenverlichting binnen de overheid en het bedrijfsleven.

Planning 2 juli 2003 Kick-off bijeenkomst 15 augustus 2003 Alle betrokkenen leveren commentaar en geven aanvullingen op een concept voor de inrichting van 'auditfile salaris' 22 augustus 2003 Oplevering eerste ontwerp van de standaard 4 september 2003 Bespreking eerste ontwerp September 2003 Uitwerken commentaar, afstemmen Oktober 2003 Vaststellen Salaris Data Model + XML Auditfile Salaris November 2003 Vaststellen beheerprocedures November 2003 Afleiden andere berichten van Salaris Data Model Vanaf november 2003 Implementatie XML Auditfile Salaris

XML Auditfile Salaris moet de koppeling vergemakkelijken tussen salarisadministraties en bijvoorbeeld boekhoudpakketten, en met administraties van andere partijen, zoals de Belastingdienst, het CBS, loonservicebureaus, verzekeraars en pensioenfondsen. De Belastingdienst en het SRA (samenwerkende registeraccountants & accountants-administratieconsulenten) hebben zich opgeworpen als kartrekkers van de standaard, maar er zijn meerdere belanghebbenden die inmiddels ook aan de 'ontwikkeltafel' zijn aangeschoven. Onder hen bevinden zich onder meer het Centraal Bureau voor de Statistiek (CBS), Ernst & Young, Pinkroccade, Logica CMG, Exact Software, Shell en Akzo Nobel.

Datamodel

Eind dit jaar moet de standaard een feit zijn. Begin 2004 worden de eerste toepassingen met de standaard op de markt verwacht. De Belastingdienst en Uitvoering Werknemers Verzekeringen (UWV) worden de eerste gebruikers. Zij willen de standaard inzetten bij het opvragen van salarisgegevens voor looncontroles.
De standaard wordt als volgt ontwikkeld. Om het koppelvlak tussen salarisadministraties bij bedrijven en diverse andere administraties te kunnen standaardiseren, moeten afspraken worden gemaakt op verschillende hiërarchische niveaus. In eerste instantie stellen de ontwikkelaars een Salaris Data Model op. Dit model legt de semantiek van de uit te wisselen gegevens vast. Het gegevensmodel vormt de basis van de standaard, die systematisch beschrijft welke gegevens worden gebruikt om bedrijfsprocessen op het gebied van 'salaris' goed te laten verlopen.
Dit gegevensmodel kan bijvoorbeeld de volgende elementen bevatten: inhoudingsplichtige (zoals naam of loonbelastingnummer), vaste gegevens van werknemers (bijvoorbeeld persoonsnummer, sofi-nummer en geboortedatum), variabele gegevens van werknemers (zoals tariefgroep, loonbelastingtabel, burgerlijke staat en salarisgroep), looncomponenten (omschrijving, de wijze van belasting), loonbetaling (aantal dagen, het tijdvak) en de loonbetalingcomponent (code en waarde van component, grootboekrekening).

Bouwstenen

Het Salaris Data Model is onderverdeeld in een objectenmodel en meerdere transactiemodellen. Het objectenmodel bevat een verzameling bouwstenen, zonder dat er relaties tussen de verschillende bouwstenen worden gedefinieerd. De verschillende transactiemodellen zorgen voor die onderlinge relaties tussen de bouwstenen en brengen hiërarchische structuren aan in de bouwstenen binnen het objectenmodel.
Van het transactiemodel binnen het Salaris Data Model zijn vervolgens meerdere berichten (views), ofwel deelverzamelingen, voor verschillende partijen af te leiden. Alle belanghebbenden, zoals Belastingdienst, CBS, pensioenfondsen en verzekeraars, zullen namelijk hun eigen informatiebehoeften hebben. De specifieke berichten hebben steeds dezelfde structuur als een transactiemodel, maar inhoudelijk kunnen ze van elkaar verschillen. Berichten als uitdiensttreding, wijziging dienstverband, ziek- en herstelmelding, mutatie salaris, verlof- of ziekte-uren, atv-dagen, autovergoeding, een journaalpost, een jaaropgave of een andere standaard zijn van het transactiemodel af te leiden.
Aan elk van deze berichten afzonderlijk wordt een technische specificatie gekoppeld in de vorm van een XML-schema, die de uitwisseling mogelijk maakt met applicaties van een andere administratie. Een laag waarin ketenspecifieke afspraken worden vastgelegd vult het geheel aan. Voorbeelden hiervan zijn de ketenspecifieke afstemming tussen bedrijven en Belastingdienst en de afstemming tussen bedrijven en een Arbodienst.

Administratieve lastendruk

Als het Salaris Data Model goed en logisch wordt opgezet, maakt dit het uiteindelijke beheer van de salarisstandaard eenvoudiger. De initiatiefnemers van de standaard hopen daarom dat zoveel mogelijk belanghebbende partijen hun input zullen geven voor dit model. De berichtspecificaties krijgen in dat geval zoveel mogelijk gestandaardiseerde vormen en de samenhang tussen de afzonderlijke functionele berichten blijft er beter door gewaarborgd. Verder biedt het een stabielere basis voor systeemontwikkeling en verdere ontwikkeling van de standaard zelf.
In eerste instantie maken de Belastingdienst en het UWV hun informatiebehoeften kenbaar en brengen ze die in de standaard in, zodat beide organisaties vervolgens een eigen deelverzameling eruit kunnen halen. Ondernemers zullen vervolgens een salarispakket moeten hebben met daarin een auditfile-exportmodule, zodat zij de Belastingdienst of het UWV elektronisch inzicht kunnen geven in hun salarisadministratie. Een voordeel voor ondernemers zou kunnen zijn dat het aanleveren van informatie op deze manier de bewaarplicht van de salarisadministratie mogelijkerwijs afdekt. Men is hier echter nog niet helemaal over uit en een juridisch kader ontbreekt op dit moment nog.
Het idee achter de ontwikkeling van de standaard is om uiteindelijk de administratieve lastendruk in de samenleving te verlichten. Na Belastingdienst en UWV is het wachten op het CBS, pensioenfondsen, verzekeraars en arbodiensten, totdat ook zij hun input geven voor de standaard en hun gegevens elektronisch gaan opvragen. Dan wordt het voor bedrijven pas echt interessant; als ze moeten investeren in de benodigde software is het economischer om gelijk de gehele administratieve lastendruk aan te pakken.

Teveel standaarden

Een standaard voor salarissystemen is het vervolg op de vorig jaar door Belastingdienst en SRA ontwikkelde XML-standaard voor financiële systemen, 'XML Auditfile Financieel'. Deze standaard gebruikt de Belastingdienst nu bij het geautomatiseerd controleren van financiële administraties bij ondernemers. Inmiddels hebben zo'n dertig softwareleveranciers die financiële standaard in hun pakketten opgenomen. Beheerder van de standaard XML Auditfile Financieel is ABZ Branche Initiatieven, dat tevens de huidige ontwikkeling van XML Auditfile Salaris coördineert. ABZ heeft veel ervaring op dit terrein en stond eveneens aan de basis van de ontwikkeling van de standaarden binnen de verzekeringsbranche.
Een beheerorgaan als ABZ is nodig om het gevaar van XML te ondervangen. XML is zo flexibel dat iedereen in wilde weg labels kan uitdelen. Het gevaar is dan dat bedrijven bilateraal labels gaan afspreken en de standaard zelf dus een rommeltje wordt. ABZ beheert de standaard en zal deze op afroep uitbreiden volgens een aantal spelregels. De initiatiefnemers denken op dit moment aan een maandelijks 'vrijgaveritme' voor tussentijdse uitbreiding van de standaard.
Sommigen denken misschien: alweer een nieuwe standaard? Er zijn in Nederland al zoveel standaarden. "Te veel", erkent Gerhard Gerritsen, manager standaardisatie & certificatie bij ABZ. "Maar we houden zoveel mogelijk rekening met andere standaarden die al gedefinieerd zijn. Waar we heel nadrukkelijk naar kijken, is het Suwi Gegevens-Register (ontwikkeld ten behoeve van de gegevensuitwisseling in de Suwi-keten, waaronder het Centrum voor Werk en Inkomen (CWI), de gemeentelijke sociale diensten en Uitvoering Werknemers Verzekeringen (UWV), red.). Wij willen rekening houden met de bouwstenen die daar gedefinieerd zijn."

Voortgang Over de voortgang van de ontwikkeling van XML Auditfile Salaris communiceren de Belastingdienst en accountantsvereniging SRA via de website http://www.softwarepakketten.nl. Dit is de site van consultancybureau Gbned, die eveneens bij de ontwikkeling van de standaard betrokken is.

De salarisstandaard wordt in ieder geval ook afgestemd op Pana, een parallel initiatief van het UWV. Pana staat voor Premie Afdrachtsystematiek op basis van Nominatieve Aangifte. Via dit systeem moeten werkgevers vanaf 2006 gegevens aanleveren aan het UWV. Het gaat dan vooral om het aanleveren van salarisgegevens voor de premieafdracht. De twee standaarden zullen elkaar voor een groot deel overlappen. Het streven is daarom om berichten voor Pana en voor Auditfile Salaris af te leiden uit hetzelfde model. Om een en ander af te stemmen, zit UWV ook aan de ontwikkeltafel van XML Auditfile Salaris.

Xbrl-formaat

In de toekomst wordt de standaard mogelijk ook Xbrl-enabled, afhankelijk van hoe de acceptatie van Xbrl zich verder ontwikkelt. Xbrl, ontwikkeld in de Verenigde Staten, is een open standaard voor het automatisch verzamelen, publiceren en uitwisselen van financiële informatie. Het is een eveneens op XML gebaseerde standaard die met 'financiële rapportage' een heel specifiek domein voor zijn rekening neemt. Xbrl heeft speciale technieken in zich, specifiek voor financiële rapportagestromen.
Xbrl gaat verder dan bijvoorbeeld XML Auditfile Financieel, maar kan tegelijkertijd een aantal dingen niet die de auditfile wel kan. De auditfile gaat tot op boekingsniveau en kan bijvoorbeeld een administratie overzetten vanuit Exact in Unit4, waarna die administratie gewoon verder kan draaien. Met Xbrl kan dat niet, omdat daar verdichte informatie in zit, vergelijkbaar met het niveau van een jaarrekening. In een administratie moet je tot op boekingsniveau kunnen gaan en bij Xbrl mis je een aantal gegevens, zoals de rekeningnummers.
Aan de andere kant bevat Xbrl veel extra's. Het levert meer achtergrondinformatie en is nog meer gestandaardiseerd. Als een bepaalde balanspost een samenstelling is van een aantal rekeningen, wordt aangegeven hoe die formule tot stand is gekomen. Er zitten dus meer controles in. Verder kan binnen XML Auditfile Financieel een rekeningomschrijving bijvoorbeeld twee verschillende termen door elkaar gebruiken, zoals 'cash' en 'kas'. In Xbrl spreek je af dat 'kas' voortaan 'cash' heet.
Voor een in- of uitdiensttreding, of een ziek/betermelding zal het niet zo interessant zijn om deze in Xbrl-formaat te kunnen overzetten van een salarissysteem naar een ander administratiesysteem. In de toekomst is het misschien wel handig om bepaalde andere onderdelen uit het salarissysteem via Xbrl geschikt te maken voor financiële rapportage doeleinden.< BR>