Konsolidér flere selskaber – også i forskellige ERP-systemer

Få koncerner er designet fra begyndelsen. De vokser frem. Et selskab opkøbes, et andet startes i Norge, et tredje udskilles til en egen produktlinje. Hvert selskab tager sit ERP-system, sin kontoplan, sine varenumre og sine rutiner med sig.

Operativt fungerer det fremragende. Hvert selskab håndterer sin daglige drift i et system, der passer netop den forretning. Problemet opstår et niveau højere op, når nogen skal svare på spørgsmål, der handler om helheden:

Hvor meget sælger vi egentlig til denne kunde – i alt? Hvilken volumen har vi hos leverandøren, hvis vi tæller alle selskaber med? Hvilket selskab har den bedste bruttomargin på samme varegruppe, og hvorfor?

Når organisationer vokser gennem opkøb, international ekspansion eller omstrukturering, stiger kompleksiteten i den finansielle rapportering hurtigt: data skal indsamles fra flere selskaber, ofte med forskellige ERP-systemer, valutaer og rapporteringsprincipper (Attollo). I praksis håndteres det ofte manuelt i regneark eller via separate løsninger pr. selskab – tidskrævende, fejlbehæftet og svært at skalere (Evexo, 2026).

Det er værd at skelne mellem to ting, der ofte slås sammen.

Finansiel konsolidering

Koncernregnskabet. Elimineringer af transaktioner mellem koncernselskaber, ejerandele og minoritetsinteresser, omregning af udenlandske datterselskaber til koncernvalutaen efter K3 eller IFRS, og kravet om at koncernregnskabet udarbejdes efter fælles og ensartede principper (Koncernredovisning.biz).

Her findes der rigeligt med gode værktøjer på markedet. Vellox erstatter dem ikke og skal ikke gøre det.

Driftskonsolidering

Den anden slags konsolidering handler om det, der ligger under resultatopgørelsen: ordrer, fakturalinjer, varer, kunder, leverandører, indkøbspriser, lagerbeholdninger og marginer.

Det er her, de fleste værktøjer stopper, af en simpel grund: de tager udgangspunkt i finansbogholderiet eller SIE-filen. Finansbogholderiet ved, at koncernen solgte for 412 millioner. Det ved ikke, at 38 af dem gik til samme kunde – via tre forskellige selskaber, til tre forskellige prislister, med to forskellige rabatstrukturer.

At lægge tal sammen er trivielt. Det, der gør konsolidering på tværs af flere systemer svær, er, at samme virkelighed beskrives på forskellige måder i hvert selskab:

• Kontoplanen. Selskab A bogfører fragt på 4010, selskab B på 5710. Uden en fælles koncernkontoplan kan omkostningsarterne ikke sammenlignes.
• Kunden. Samme koncernkunde hedder forskellige ting og har forskellige kundenumre i tre systemer. Ingen ser den samlede forretning.
• Varen. Samme produkt har forskellige varenumre, forskellige enheder og forskellig varegruppeinddeling i hvert selskab.
• Valutaen. Selskaberne rapporterer i SEK, NOK og EUR. Indtægter og omkostninger skal omregnes til gennemsnitskurs og balanceposter til balancedagens kurs (Koncernredovisning.biz).
• Perioden. Forskudte regnskabsår, forskellig periodeinddeling, forskellige lukkerutiner.
• Definitionerne. I et selskab tælles salget, når det leveres, i et andet når det faktureres. Samme nøgletal, forskellig betydning.

Det er i denne mapning, at konsolideringsprojekter typisk går i stå – og det er samtidig det eneste arbejde, der er helt unikt for netop jeres koncern. Alt andet er tilbagevendende.

Udgangspunktet er, at modellen allerede findes. Vellox har færdige integrationer pr. ERP-system – Business Central, Jeeves, Monitor, Pyramid og Visma Business – og hver integration indlæser selskabets data i samme modelstruktur.

Det betyder, at et Jeeves-selskab og et Business Central-selskab ender i samme semantiske model, med samme begreber for kunde, vare, ordre og transaktion. Konsolideringen er ikke et ekstra lag oven på fem separate løsninger – den er måden, modellen er bygget på.

Oven på det ligger fire ting:

Selskab som dimension. Alt kan brydes ned på selskab. I starter på koncernniveau og klikker jer ned til selskab, kunde og vare uden at skifte rapport eller løsning.

Fælles begreber gennem mapning. Den lokale kontoplan mappes mod en koncernkontoplan, kundenumre knyttes til en fælles kundekoncern, varer til et fælles hierarki. Mapningen laves én gang og vedligeholdes løbende.

Valutahåndtering. Hvert selskabs beløb bevares i lokal valuta, samtidig med at koncernvalutaen beregnes, så en selskabsdirektør og en koncernledelse kan se på samme rapport og begge se det rigtige tal.

Intern handel markeret. Transaktioner mellem koncernselskaberne identificeres og kan filtreres fra, så koncernens eksterne salg ikke pustes op af intern fakturering.

Nøgletallene defineres én gang, på koncernniveau. Ændrer I definitionen af bruttomargin, slår det igennem i alle selskaber samtidig – hvilket er en forudsætning for, at sammenligningen mellem selskaberne betyder noget.

Den traditionelle vej til koncernfælles analyse på tværs af flere ERP-systemer ser stort set ens ud hver gang: en forundersøgelse, en kravspecifikation, et datavarehus der bygges fra grunden, kildesystemer der kortlægges ét ad gangen, en semantisk model der udvikles på bestilling. Måneders arbejde og et konsulentbudget, der ofte overstiger de fremtidige licensomkostninger med god margin.

Det er ikke mærkeligt, at det ser sådan ud. At bygge en integration til Monitors datamodel, forstå Jeeves' ordrestruktur eller håndtere Business Centrals værdiposter er reelt arbejde – første gang.

Pointen er, at det kun skal gøres én gang, ikke én gang pr. kunde. Når integrationerne og modelstrukturen allerede findes pr. ERP-system, forsvinder langt den største del af projektet. Tilbage bliver det, der faktisk kræver jeres viden om jeres koncern: hvordan kontoplanerne skal mappes, hvilke selskaber der skal indgå i hvilke strukturer, hvordan kundekoncernerne ser ud, og hvilke nøgletal ledelsen vil styre efter.

Det er forskellen mellem et udviklingsprojekt og en konfiguration.

Når selskaberne først ligger i samme model, åbnes spørgsmål, der tidligere krævede, at nogen sad en hel dag i Excel:

Den samlede kundeforretning. En kunde, der handler hos tre af jeres selskaber, ses som én kunde. I ser den samlede volumen, den samlede margin og hvem der faktisk tjener penge på relationen.

Forhandlingspositionen over for leverandøren. Samme leverandør leverer til flere selskaber, ofte uden at nogen har lagt volumen sammen. Det er svært at forhandle på et grundlag, I ikke har.

Sammenligning mellem selskaberne. Samme nøgletal, samme definition, samme periode. Selskaber, der ser forskellige ud i deres egen rapportering, bliver sammenlignelige – og forskellene bliver noget at undersøge i stedet for en strid om tallene.

Krydssalg. Hvilke kunder køber kun fra ét selskabs sortiment, selvom et søsterselskab sælger noget, de tydeligvis har brug for?

Lager og kapitalbinding i hele koncernen. Hvor ligger varerne, og ligger de rigtigt?

Dertil kommer muligheden for at spørge dataene direkte. Med Vellox MCP kobles Claude eller ChatGPT til den semantiske model, hvilket gør, at en koncerncontroller kan stille spørgsmål på almindeligt dansk og få svar, der bygger på de samme konsoliderede tal som rapporterne. Flere eksempler findes i ti spørgsmål du kan stille til dine egne forretningsdata.

Start med to selskaber i forskellige ERP-systemer – gerne de to, der er sværest at sammenligne i dag. Sæt integrationerne op, map kontoplan og kundestruktur, og kør en måned i drift. Derefter er hvert yderligere selskab i et system, I allerede har på plads, en brøkdel af arbejdet.

Book en demo eller kontakt os direkte, så ser vi på, hvordan netop jeres koncernstruktur ser ud.