Dataflow er ikke koncernkontrol

Når ERP-systemer får bedre APIer, hurtigere importer og mere strukturerede data, er det let at tro, at koncernrapporteringen snart løser sig selv.

Det gør den sjældent.

Bedre dataflow er vigtigt. Det gør det lettere at hente kontoplaner, saldobalancer, dimensioner, transaktioner og bilag fra kildesystemerne. Det reducerer friktion i month-end. Det gør, at økonomiteamet slipper for nogle manuelle eksporter og importer.

Men dataflow er ikke det samme som koncernkontrol. Data kan flytte sig hurtigere uden, at koncernen får bedre svar på de vigtigste spørgsmål: Hvilke tal kan sammenlignes? Hvilke poster skal elimineres? Hvor ligger afvigelsen? Hvilket selskab, hvilken konto, hvilken dimension eller hvilket bilag forklarer ændringen?

For private grupper med flere selskaber er det ofte her skellet går. ERP- og regnskabssystemerne bliver bedre. Det giver bedre råmateriale. Men koncernlogikken skal stadig ejes af CFO, controller og økonomiteamet.

Kort svar: hvad er koncernkontrol?

Koncernkontrol er økonomiteamets evne til at samle, sammenligne, forklare og efterprøve tal på tværs af selskaber, regnskabssystemer, konti, dimensioner, transaktioner og bilag.

God koncernkontrol handler ikke kun om at hente data. Den kræver fælles rapporteringslogik, kontrollerbar mapping, tydelige elimineringer, sporbarhed fra koncerntal til underliggende detaljer og en rapporteringsproces, som flere end én person kan forstå.

Hvorfor bedre dataflow ikke er nok

Et API kan hente data. En import kan opdatere rapportgrundlaget. Et regnskabssystem kan gøre lokal bogføring, fakturaflow og afstemning mere struktureret.

Alt dette hjælper. Men intet af det afgør alene, hvordan lokal data skal blive til koncernrapportering.

Koncernrapportering kræver valg, som ofte ligger over kildesystemet:

• hvilke lokale konti der skal mappes til fælles rapportlinjer
• hvilke dimensioner der faktisk betyder det samme på tværs af selskaber
• hvordan interne transaktioner skal identificeres og elimineres
• hvilke selskaber, perioder og valutaer der skal indgå i rapportpakken
• hvordan afvigelser skal forklares for ledelse, bestyrelse eller ejere
• hvilke Excel-arbejdsflows der stadig skal bruges, og hvilke der bør flyttes til et kontrollag

Når disse valg ikke er tydelige, havner de ofte i Excel. Rapporten kan se ryddelig ud, mens koncernlogikken ligger i formler, manuelle justeringer og lokal viden hos én controller.

Et CFO-scenarie: seks selskaber og fire datakilder

Forestil dig en nordisk gruppe med seks selskaber. Moderselskabet bruger Business NXT. To datterselskaber bruger Tripletex. Et svensk selskab bruger Fortnox. Et opkøbt selskab sender stadig rapportpakke fra et andet regnskabssystem.

I løbet af året har flere af systemerne fået bedre eksport, API-adgang eller importmuligheder. Det er positivt. Controller kan hente mere data oftere, og month-end starter med færre manuelle filer end tidligere.

Alligevel står CFO med de samme koncernspørgsmål:

• Er salgsindtægterne klassificeret ens i alle selskaber?
• Er intern omsætning markeret, så eliminering kan spores?
• Betyder afdeling, projekt og omkostningssted det samme på tværs?
• Hvilke justeringer er lavet efter import?
• Kan vi forklare ændringen i EBITDA fra koncerntal ned til transaktioner og bilag?

Hvis svarene ligger i en Excel-fil ved siden af rapporteringen, er dataflowet blevet bedre, men koncernkontrollen er stadig sårbar.

APIer flytter data. Økonomi ejer logikken.

Pointen er enkel: dataadgang er en forudsætning, ikke et slutresultat.

For CFO og controller er spørgsmålet ikke kun, om systemerne kan tale sammen. Spørgsmålet er, hvad økonomiteamet gør med dataene, når de kommer ind.

Eksempler:

• En transaktion kan være hentet korrekt, men mappet til forkert koncernlinje.
• En dimension kan være tilgængelig, men ikke sammenlignelig på tværs af selskaber.
• En intern faktura kan være importeret, men ikke markeret, så elimineringen kan kontrolleres.
• Et bilag kan ligge i kildesystemet, men rapportbrugeren skal stadig kunne finde det fra koncernrapporten.

Bedre dataflow bør bruges til at styrke kontrollen, ikke til at gemme logikken dybere i rapporteringsmodellen.

ERP-rapportering stopper ofte ved systemgrænsen

Lokale ERP-rapporter er vigtige. De er ofte den bedste kilde til lokale tal, bilag, transaktioner og dimensioner.

Men ERP-rapportering er normalt bygget til selskabet eller systemet, hvor den findes. Gabet opstår, når CFO skal se på tværs af selskaber, systemer og rapporteringsstrukturer.

En lokal rapport kan være korrekt og stadig ikke være nok for koncernen. Den viser måske det rigtige resultat for ét selskab, men den siger ikke nødvendigvis, hvordan tallet skal sammenlignes med et andet selskab, hvordan intern handel skal elimineres, eller hvordan rapportlinjen hænger sammen med koncernens styringsmodel.

Det betyder ikke, at ERP-systemet er svagt. Det betyder, at koncernkontrol er et selvstændigt arbejde.

Når hurtigere import giver falsk tryghed

Hurtigere dataflow kan også give falsk tryghed. Når tallene opdateres oftere, kan rapporten føles mere kontrolleret, end den egentlig er.

CFO bør skelne mellem tre niveauer:

1. Data er hentet.
2. Data er struktureret.
3. Data er kontrolleret i en koncernlogik.

Mange grupper når niveau to og stopper der. De har saldobalancer, kontoplaner, dimensioner og transaktioner på plads. Men de mangler en fælles arbejdsflade til mapping, elimineringer, afvigelser, drilldown og godkendelse.

Det er ofte her Excel kommer tilbage. Ikke fordi økonomiteamet mangler systemer, men fordi koncernlogikken ikke har et tydeligt hjem.

Praktiske kontrolspørgsmål før næste rapportering

Før næste month-end bør CFO og controller spørge:

1. Hvilke data kommer direkte fra kildesystemerne, og hvilke indtastes manuelt?
2. Hvor ligger mappingen mellem lokale konti og koncernlinjer?
3. Hvilke dimensioner bruges i rapporteringen, og er de sammenlignelige?
4. Hvordan identificeres interne transaktioner?
5. Hvor dokumenteres elimineringer og manuelle justeringer?
6. Kan vi gå fra koncerntal til selskab, konto, transaktion og bilag, hvor data findes?
7. Hvem kan forklare rapporteringsmodellen, hvis nøglepersonen er væk?
8. Hvilke Excel-filer er stadig nødvendige, og hvilke bruges fordi kontrollaget mangler?

Svarene viser, om problemet først og fremmest er dataadgang, rapportstruktur eller koncernkontrol.

Hvordan et kontrollag hjælper

Et kontrollag for koncernøkonomien ligger over lokale ERP- og regnskabssystemer. Det skal ikke erstatte dem. Det skal gøre det muligt for økonomiteamet at arbejde med koncernlogikken ét sted.

For en privat gruppe med 3-20 selskaber betyder det ofte fælles rapportering på tværs af selskaber og systemer, mapping mellem lokale konti, dimensioner og koncernstruktur, kontrollerbare elimineringer og interne transaktioner, drilldown fra rapport til transaktion, bilag og vedhæftning, hvor data findes, og en rapporteringsproces, der ikke afhænger af én Excel-model.

Læs mere om koncernrapportering for private grupper, hvis du vil se, hvordan denne type kontrollag passer ind i en større rapporteringsmodel.

Sumledgers rolle

Sumledger er bygget til private nordiske grupper, der er vokset ud af Excel, men som ikke har brug for et tungt enterprise EPM-system.

Sumledger kobler til ERP- og regnskabssystemer og giver CFO og controller et fælles kontrollag til koncernrapportering, konsolidering, elimineringer, analyse og Excel-arbejdsflows. Hvor data findes, kan økonomiteamet arbejde fra koncerntal ned til konti, dimensioner, transaktioner, bilag og vedhæftninger.

Pointen er ikke kun at hente data hurtigere. Pointen er at gøre koncernlogikken synlig, kontrollerbar og mindre personafhængig.

Opsummering

Bedre APIer, importer og ERP-data er godt nyt for økonomiteamet. De giver bedre råmateriale og mindre manuelt arbejde.

Men koncernrapportering bliver ikke tryg, bare fordi data flyder bedre. CFO og controller skal stadig eje mappingen, elimineringerne, sammenligneligheden, afvigelserne og forklaringen.

Dataflow er starten. Koncernkontrol er arbejdet, der gør tallene nyttige.

Vil du se, hvordan Sumledger kan samle dataflow og koncernlogik i ét kontrollag? Book en kort demo.