Tre krav på webbaserade redovisningsprogram
I filmen ovan berättar Mattias Elfgren om tre viktiga punkter för koncernredovisare som inte alltid får tillräcklig vikt vid utvärderingen av redovisningsprogram. Dessa punkter är:
1. Kravställ och testa API för export av data
Ett API (”Application Program Interface”) är en funktionalitet för att kunna hämta ut data från er del av leverantörens system. På Tiego tycker vi att man alltid ska försöka hämta ut transaktionerna som bas i koncernrapporteringen varför en uppkoppling till datat krävs. Om ni inte har det kravet så är det ändå rätt vanligt att ha någon form av tredjepartsprogramvara för analys av data, till exempel Qlik eller Power BI.
Vanligtvis krävs någon form av autentisering och någon programmering för att kunna koppla upp sig – därmed kan det vara svårt att testa detta innan ni fattar ett beslut om vilket system ni väljer, fråga då om en referens som löst datahämtningen. Förr när databasen var ”on premise” så var det enklare då den kunde nås direkt genom att ansluta till databasen lokalt, till exempel med standardtekniker såsom ODBC (”Open Database Connectivity”), men även då krävdes programmering och kunskap om databasens struktur. Nuförtiden med moderna webbaserade system finns ofta standardiserade API’er. Fördelen med dessa är att de kräver betydligt mindre kunskap om hur systemet är uppbyggt och gör det därmed enklare att hämta data från dessa, MEN API:er kan vara rätt olika utformade. Exempelvis är det så att ett API som endast tillåter hämtning av enstaka transaktioner kan visa sig rätt långsamt om mycket data ska hämtas. Ett annat begrepp att känna till är ”inkrementell uppdatering” – och det handlar om att API’et eller databasen bör kunna leverera endast det som är uppdaterat i huvudboken oavsett vilket datum som den som bokfört angivit. På detta sätt kan man hämta mycket mindre information än att tvingas hämta allt från årets början. Det gör det möjligt att köra synkronisering ofta och därmed ha så aktuella data som möjligt.
2. Se till att få med motpart i kontosträngen
Det är inte alltid så att avstämning av interna mellanhavanden är tidskrävande i koncernbokslut, särskilt om man inte har så mycket mellanhavanden och separerar externa och interna saldon på olika konton inför bokslut. Jag skulle säga att det fungerar rätt väl upp till 10-15 bolag men kan vara tidskrävande även med få bolag om transaktionsvolymen inom koncernen är stor.
Om ni ändå ska byta system kan det dock vara läge att kravställa att det ska finnas stöd för motpart som en dimension i kontosträngen. På detta sätt så slipper man att göra något jobb med att speca mellanhavandet då inläsning till koncernredovisningsprogrammet inkluderar motpart. Nackdelen (eller fördelen) är ju dock att det ställer högre krav på att vara rätt bokfört i huvudboken, annars blir det till att korrigera i koncernsystemet.
3. Ställ krav på att kunna ange förändringstyp för balansposter som kräver flödesanalys
Jag har genom åren träffat många programvaruleverantörer och frågat varför de inte vidareutvecklar sina system och erbjuder kunder att ange VAD som hänt på konton som kräver flödesanalys i årsredovisningen. Alla världens bolag behöver ju förr eller senare under året hämta in information om vad som hänt på kontona anläggningstillgångar, finansiella tillgångar och skulder, eget kapital och reserver. Varför inte bokföra det direkt när transaktionen sker?
Om man jobbar med Tiego och vårt TGA så kompletterar vi i och för sig lätt detta som en del i varje bolags inrapportering, men det skulle ju vara ännu bättre om informationen fanns redan i redovisningen. Då skulle vi närma oss det helautomatiska bokslutet! För med korrekt angiven information så har du inte bara det som behövs till notförteckningens flödesanalyser, men också en indirekt kassaflödesanalys automatiskt varje månad.
Ha gärna med dig dessa tre råd – men ett generellt råd är också att söka experthjälp – det finns många duktiga där ute som kan hjälpa till.
Se gärna filmen med Mattias som berättar mer.