Den första säsongen med obligatoriskt uppgiftslämnande i form av standardiserade räkenskapsutdrag (SRU) närmar sig sitt slut. Det är dags att summera erfarenheterna och ge både RSV och programutvecklarna tips om förbättringar till nästa år.
Klassificeringsproblemet
SRU kräver i stort att företagen avger en resultat och balansräkning där samtliga konton klassificerats i enlighet med de två första siffrorna enligt BAS.
Flertalet företag använder BAS i grunden men en majoritet av företagen torde ha företagsspecifika konton för att beskriva sin verklighet. Dessa avvikelser ger problem i de fall uppgifterna till SRU skall överföras maskinellt. En reaktion på detta har varit att några byråer uppmanat sina kunder att byta kontonummer och strikt följa BAS vilket i längden inte är vare sig önskvärt eller möjligt. I stället bör vi skapa hjälpmedel som ger möjlighet att klassificera kundens konton till rätt SRU-kod.
Detta kan göras på tre sätt. I redovisningsprogrammet kan kontoplanen förses med ett extra fält där SRU-koden anges för varje konto varpå informationen exporteras till skatteprogrammet. Denna metod ger olika lösningar för de olika redovisningsprogrammen med åtföljande underhålls- och utbildningsproblem.
En bättre metod hade varit att bygga in denna del i skatteprogrammet så att samma teknik kunde användas på samtliga företag. Eftersom revisionsbyråerna i praktiken endast arbetar med ett skatteprogram per byrå och regelmässigt biträder vid upprättandet av SRU så bör Akelius, Capitex och de övriga bygga in verktyg för omklassificering till nästa säsong.
Slutligen öppnas här en nisch för fristående program som importerar data från olika redovisningsprogram, förädlar informationen i olika analyser och exporterar data till exempelvis kalkylprogram och skatteprogrammen. Genom att Windows blivit så spritt bland företag och revisorer kan omklassificeringen ske med vanlig klicka-dra teknik både i MAC- och IBM-världen.
Teckenproblemet
Ett konto kan placeras vid olika SRU-koder beroende på om det är fråga om ett debet eller kreditbelopp. Denna typ av ändring genomfördes till årets taxering varför utskrifter av SRU inte kunde ske i den takt boksluten blev klara. Jag föreställer mig att RSV genomförde ändringen för att underlätta för personalen som registrerar hos myndigheten. Denna omtanke har ställt till problem genom att omöjliggöra ett rationellt arbete denna säsong och – vilket är än värre – tvingat alla programföretag att hitta nya lösningar på klassificeringsproblemen. Så blir det t.ex. omöjligt att styra ett enskilt konto till en SRU-kod. En rimlig lösning borde vara att RSV inte åsätter olika SRU-koder på transaktioner som normalt redovisas på ett kontonummer. Om RSV anser att vi som fyller i blanketten och de som registrerar den behöver olika rader för att skilja på upplösning av respektive avsatt till så kan gärna olika rader användas – men låt SRU-koden vara lika!
SRU har påverkat redovisningen redan och kommer att så göra i fortsättningen.
Ett likartat problem uppstår p.g.a. att det egna kapitalet i enskilda firmor skall brytas ned i ingående balans, insatt, uttaget och utgående balans på det sätt som bl.a. föreskrivs i BFL. Eftersom årets UB blir nästa års IB behöver denna inte anges separat. Egna insättningar och uttag nettoredovisas normalt och bör i SRU-sammanhang vara förändringen av kontot. Årets resultat bör dock särredovisas. Härmed blir det möjligt att överföra det egna kapitalet genom en automatisk överföring till SRU utan att väsentlig information förloras.
Dokumentationsproblemet
Som regel är det uppenbart vilka konton som ingår i beloppet för en viss SRU-kod men företagsspecifika konton ger problem att se var kontona summerats. Härav följer att programmen skall kunna göra en utskrift av de olika konton och belopp som ingår i SRU-summan.
Diskettproblemet
Skattemyndigheten bävar inför det arbete som de måste lägga ned för att registrera alla uppgifter och premierar dem som lämnar in data på diskett med längre uppskovstider. Jag kan inte tänka mig att någon inom överskådlig tid kommer att enbart leverera deklarationer på diskett utan att först skrivit ut och kontrollerat dem. Därmed blir det mest effektiva sättet för byrån att skicka en papperskopia så som vi alltid gjort. Jag känner mig inte övertygad om att myndigheten klarar av att hantera inskickade disketter på ett konfidentiellt sätt? Det är ju trots allt ganska enkelt att kopiera ned 100 företags alla uppgifter till en liten diskett och bära ut den från myndigheten utan att upptäckas. Om skada sker – vem betalar?
Export/Importproblemet
En revisionsbyrå kommer normalt i kontakt med ett stort antal redovisningssystem och datortyper. Detta begränsar möjligheten att hjälpa till med SRU till de system vars information kan läsas in i byråns dator. Under 1992 skapades en standard för överföring av data mellan olika program. Standarden kallas för SIE (Standard Import och
Export) Detta arbete har inte uppmärksammats i den utsträckning som förtjänas. Idén är utmärkt och öppnar möjligheter för programutvecklare att skapa lättanvända verktyg för revisorer. Det råder ingen tvekan om att standarden kommer att etableras eftersom Akelius snabbt stödde denna och majoriteten av redovisningsprogrammen då följde efter. I dagsläget är det bara de företag som redan till förra årets investerade i överföringsverktyg som inte har hakat på utvecklingen. SIE-standarden skapar en lättanvänd och tillräckligt effektiv möjlighet till datautbyte mellan program.
Till nästa säsong torde det vara svårare att sälja redovisningsprogram som inte kan exportera konto/belopp i SIE-format. Detta gäller i synnerhet de program som är avsedda att användas ute på de enskilda företagen. Däremot bör skatteprogrammen ta hand om klassificeringen till rätt SRU-kod (som ju är specifikt för deklarationer) och gärna med modern klicka-dra-teknik.
Hans Sjölund, auktor revisor, Norrtälje