Fiscale aangiftesoftware: BAPI verdwijnt / XBRL komt

Transcriptie

1 Fiscale aangiftesoftware: BAPI verdwijnt / XBRL komt Onderzoeksbureau GBNED, Coevorden 26 oktober 2006 De toekomst van fiscale aangiftesoftware Veel fiscale intermediairs (accountantskantoren en belastingconsulenten) hebben de invoering van de elektronische winstaangifte (IB, VPB) achter de rug en op de rails. Zowel softwareleveranciers als intermediairs hebben de afgelopen twee jaar knap werk geleverd en de nodige energie gestoken in de elektronische aangifte via BAPI. Nu lijkt de elektronische aangifte in de huidige vorm via BAPI alweer te verdwijnen binnen enkele jaren en moet overgegaan worden naar aangiftes in XBRL formaat die via een nieuwe proces infrastructuur (er wordt gesproken over OTP overheidstransactiepoort - en nieuwe koppelvlakspecificaties), al dan niet via zgn service-providers, ingediend gaan worden bij onder meer de. Er wordt daarbij ook gesproken over DIGID als nieuw authenticatiemiddel. Een recent persbericht vanuit het Ministerie van Financiën luidt: "Ruim vennootschappen hoeven vanaf 2007 nog maar één jaarrekening in te dienen bij de KvK en. De fiscale jaarrekening dient hiervoor als basis. Als deze ondernemers een boekhoudprogramma gebruiken op basis van de Nederlandse XBRL-Taxonomie, kunnen ze tot de helft minder kosten verwachten". De vraag die wij ons kunnen stellen over welke kosten het Ministerie het eigenlijk heeft en wat ze precies onder boekhoudprogramma verstaan? Vanuit het sprookjesboek van minister Zalm gaan we even terug naar de werkelijkheid. Wat betekent de overgang van aangiftes naar XBRL, en het verzenden via de nieuwe proces infrastructuur, nu voor de elektronische winstaangifte en wanneer moeten softwareleveranciers en fiscaal intermediairs hier klaar voor zijn? Wij hebben in elk geval betrokken leveranciers van fiscale aangiftesoftware (AFAS, Elsevier, Kluwer, Montana, SDU, Tecknow en Unit 4 ) alvast gevraagd hun visie en antwoord te geven op de volgende zes vragen: 1. Wat is uw mening op de stelling dat boekhoudsoftware door XBRL de fiscale VPB aangiftesoftware gaat vervangen? (alleen een kwestie van boekhoudsoftware aanvullen met een paar JA/NEE vragen). 2. Wanneer denkt u dat de BAPI interface verleden tijd is? 3. Wanneer denkt u dat de aangifte volgens Edifact formaat verleden tijd is (zeg maar de elektronische aangifte in de huidige vorm)? 4. Bent u bezig met XBRL en zo ja, volgens welke planning? 5. Met welke service providers gaat u in zee om de XBRL aangifte uit te wisselen met de of gaat u zelf als service provider optreden (volgens proces infrastructuur NTP)? 6. Wanneer moeten accountants en fiscaal intermediairs volgens u voorbereid zijn op XBRL? De antwoorden van deze leveranciers zijn hierna opgesomd en we kunnen alvast verklappen dat er nog veel onduidelijk is. En lang niet alle leveranciers blijken over een visie te beschikken. In een volgend artikel gaan we in op antwoorden van de en enkele beroepsorganisaties. Tijdens het congres ICT Accountancy op 29 november a.s. wordt uitgebreid ingegaan op de consequenties van XBRL voor de elektronische winstaangifte. Zie voor meer informatie en mogelijkheid tot deelname. Onderzoeksbureau GBNED,

2 Vraag 1 Wat is uw mening op de stelling dat boekhoudsoftware door XBRL de fiscale VPB aangiftesoftware gaat vervangen? (Een kwestie van boekhoudsoftware aanvullen met paar JA/NEE vragen). VPB software is meer dan Geen Dat denken wij Daar zijn we het niet We verwachten Omdat de VPB Nee, de aangifte alleen een Balans en W&V mening niet. Aan de ene mee eens. Voor wat niet dat aangifte VEEL is veel meer dan en een paar ja/nee vragen. kant krijg je betreft de fiscale boekhoudpakketten de het aanleveren verder gaat dan alleen de Hoe zal je om moeten leveranciers die vermogensopstelling jaarstukken gaan met bijvoorbeeld een streven naar het en winstberekening zou VPB over gaan van een balans en (aandeelhouders, buitenlands verzorgen van de dat voor een nemen om de een resultatenrekening (bv: investeringen etc. belastingplichtige (VPB-C gehele keten enkelvoudige BV (Dus simpele reden etc.). Daarnaast biljet). Het feit dat er binnen een geen Fiscale eenheid) dat het VPB specificatie zijn er andere harmonisatie gaat softwareomgeving wel gevuld kunnen pakket wel wat aandeelhouders, functies gevraagd plaatsvinden tussen en die inderdaad worden, maar er zijn meer omvat dan investeringsaftrek) op het terrein van Jaarrekening Recht en kunnen volstaan meer punten. Denk het inlezen van is het niet voor de uitstelregeling, sommige fiscale regels wil met een paar aan: cijfertjes. Dat kan hand liggend dat schattingen, niet zeggen dat de extra ja/nee - Investeringsbijlage nu bij Tecknow een financieel management e.d. verschillen altijd weg vraagjes. Echter - Bijlage ook al vanuit elk pakket voldoende gewerkt kunnen worden. Er zijn altijd redenen (bedrijfseconomische redenen) om toch niet een fiscale jaarverslag te maken/deponeren. Willen de desbetreffende cliënten wel dat hun jaarrekening op fiscale grondslagen wordt gedeponeerd? Indien je de boekhoudsoftware gaat verrijken met mechanismen om toch af te kunnen wijken, een paar JA/NEE vragen toevoegen, een x aantal specificaties gaat toevoegen, etc. is men weer bezig om een fiscaal pakket te maken. Tevens vraag ik mij af wat er gedaan gaat worden met functionaliteit zoals; schatting, uitstel, EKA, verliesverrekening, dividendbelastingaangifte etc wat vandaag de dag de strategie 'bestof-breed' blijft staan, specialistische programma's om toch nét nog dat extra te verzorgen. dochtermaatschappijen - Bijlage aandeelhouders - Aangifte van een fiscale eenheid - Uitstelregeling - Schattingsregeling - Kopieaanslagen en opbouw van een kopieaanslagen dossier - Voortgangscontrole - Interne beveiliging, dus wie behandelt welke aangifte, wachtwoorden, selecties per behandelaar - Specificaties binnen de aangifte Allemaal punten die in een (goed) fiscaal programma geregeld moeten zijn. Bovendien bieden wij de mogelijkheid om ook nog de dividend aangifte met ons boekhoudpakket, dat in Nederland uitkomt. gegevens aan zal kunnen leveren om de fiscale software volledig te vervangen. onderdeel uitmaakt van de programma te fiscale pakketten. Tevens verzorgen. dient er nog een behoorlijke proces wijziging plaats te vinden binnen het accountantskantoor. De fiscalisten doen de aangifte en de Accountants doen de Jaarrekening en zijn meestal strikt gescheiden. Stel dat commercieel = fiscaal wie gaat dan de aangifte verzenden en wie gaat dan de jaarrekening verzenden en hoe is dit juridisch afgedicht. Kortom in de nabije toekomst zal nog een behoorlijke discussie ontstaan. Onderzoeksbureau GBNED,

3 Vraag 2 Wanneer denkt u dat de BAPI interface verleden tijd is? is Vanaf aangifte Onduidelijk Per Geen antwoord Geen antwoord 2009/2010 onze jaar 2007 gaan streefdatum. Dit wij werken met is voornamelijk de nieuwe afhankelijk van infrastructuur de snelheid van van OTP/GBO. implementatie Uiteraard zal (alle BAPI nog berichtstromen) bestaan voor via de OTP. het kunnen insturen van oudere aangiftes. Tenzij de belastingdienst het mogelijk gaat maken dat aangiftes van oudere jaren ook over de nieuwe lijntje kunnen. Dan zou dat dus al vanaf Indien dit niet mogelijk gemaakt wordt dan verwacht ik Vraag 3 Wanneer denk u dat de aangifte volgens Edifact formaat verleden tijd is (zeg maar de elektronische aangifte in huidige vorm)? Voor de winst aangiften is dit voor ons aangiftejaar 2007.(vpb en IB-O). Over de biljetten P, C, E en T zijn nog geen uitspraken over gedaan door de belastingdienst. Ik hoop dat dit natuurlijk ook vanaf aangifte jaar 2007 in XBRL kan. Onduidelijk Geen antwoord EDIfact kan in ieder geval nog voor belastingjaar We zijn voor de jaren 2007 en 2008 afhankelijk van de vorderingen en de mogelijkheden bij de. Niet interessant. Alles gaat al (alleen) in XML Geen antwoord 2009/2010 Onderzoeksbureau GBNED,

4 Vraag 4 Bent u bezig met XBRL en zo ja volgens welke planning? Onze aandacht gaat momenteel Geen antwoord vooral uit naar import mogelijkheden. JA, Jaarrekening 2006; aangifte IB-O en VPB (binnenlandse belastingplicht) aangiftejaar Infrasstructuur naar OTP/GBO wordt nu aangewerkt. Bij de verzending naar de zijn er voor ons op dit moment geen voordelen te behalen, dat tillen we dus in elk geval over de jaarwisseling heen. Ja, eerste kwartaal 2007 import en export XBRL voor de relevante stromen voor IB en VPB. De voorbereidingen zijn getroffen. De planning is dat de berichten voor belastingjaar 2007 in XBRL wordt geleverd. Zodra de alle biljetten in XBRL kan ontvangen gaan wij over van XML naar XBRL, vermoedelijk eerstens in 2008 (aangiften 2007). De heeft de IB-niet winst voor 2006 (helaas) niet in XBRL beschikbaar. Twee systemen naast/door elkaar is om meerdere redenen - niet wenselijk. Bezig met XBRL. Januari 2006 publicatiestukken KvK. Vraag 5 Met welke service providers gaat u in zee om de XBRL aangifte uit te wisselen met de of gaat u zelf als service provider optreden (volgens proces infrastructuur NTP)? Wij bouwen zelf de Wij gaan zelf Onduidelijk Zeer module waarmee de een service waarschijnlijk aangiftegegevens provider zelf. rechtstreeks kunnen structuur worden uitgewisseld opzetten. met de OTP. Daar kunnen wij nog geen duidelijkheid over geven, aangezien de dit zelf ook nog niet weet of aangegeven heeft. Wij zijn doorlopend in nauw overleg met de fiscus en wij mogen geen zaken uit dit overleg bekend maken. Wel kan ik zeggen dat XBRL voor ons geen enkel probleem is. Open standaarden en verder uitbreiding op ACP (Accountancy Cliënt Portal). Onderzoeksbureau GBNED,

5 Vraag 6 Wanneer moeten accountants en fiscaal intermediairs volgens u voorbereid zijn op XBRL? Dit is een geleidelijk Aangifte jaar Onduidelijk De accountants en Is voor de meeste Geen antwoord Vanaf januari proces. In eerste Nu te fiscaal intermediairs kantoren geen 2007 is dit instantie zal er geen kort dag om hoeven voor wat issue. De vraag operationeel. verschil merkbaar zijn over te gaan. betreft de fiscale komt wel met gewone aangiften, (ter voorkoming aangiften niet wanneer wordt en veelal is het ook een van taferelen voorbereid te zijn XBRL kip-ei probleem: je kunt zoals bij ELA op XBRL. In het ondersteund gegevens via XBRL en LH traject). fiscale programma (waarbij het importeren, maar waar worden gegevens antwoord luidt vandaan? En uitgewisseld met zoals hiervoor andersom. Men is dus andere software of aangegeven). afhankelijk van de met de sotwareleveranciers. in Vermoedelijk valt er een bepaald dus niet zoveel formaat. Dit was 'voorbereid te zijn voor bijv. EDIfact of XML de intermediairs. Zij zijn en dat wordt nu volledig afhankelijk van XBRL. De de softwareleveranciers intermediairs zijn om de lasten die XBRL wat dat betreft met zich meebrengt te afhankelijk van de minimaliseren, en de door hun gebruikte voordelen te fiscale software. maximaleren. Op onze vraag naar andere aandachtspunten over dit onderwerp kregen we de volgende reactie: Unit 4 : Ons inziens wordt er veel te eenvoudig gesproken over het mappen en structureren van de XBRLgegevens (koppelen van tags). Dat is in de praktijk een secuur werk wat niet voor 100% geautomatiseerd zal kunnen worden. En verkeerd koppelen geeft schijn optimalisatie. De juistheid van de cijfers, voor verzending naar de KvK, gaat voor de technische koppeling (accountant staat dus niet buitenspel). Onderzoeksbureau GBNED,