Intercompany i Business Central lyder ofte som en ren opsætningsopgave: opret et par partnere, map nogle konti, og send posteringer mellem selskaber. I praksis er det langt mere følsomt. Når intercompany fejler, er det sjældent selve funktionen, der er problemet. Det er næsten altid data, mapping, dimensioner eller et bogføringsflow, der ikke hænger sammen hele vejen.
Den tekniske side er vigtig her. Intercompany griber ind i kontoplan, dimensioner, dokumentflow, inbox/outbox og selve datamodellen bag bogføringen. Det er netop derfor, erfarne tekniske profiler som yzhums, hougaard, waldo og vjeko ofte peger på det samme mønster: man kommer længst ved at forstå strukturen bag posterne, ikke kun siderne i brugerfladen.
Intercompany i Business Central består af flere lag
Intercompany i Business Central bygger på mere end én enkelt opsætning. Den officielle opsætning samles i Intercompany Setup, men det er kun toppen af modellen. Her defineres blandt andet partnerrelationer, synchronisation partner, IC-kontoplan og mappings mellem selskaber. Den grundlæggende opsætning er beskrevet i opsætning af intercompany.
Det vigtige er, at Business Central ikke tænker i “samme konto i begge selskaber”, medmindre du aktivt har fortalt systemet det. Det gælder både finanskonti, dimensioner og dimensionværdier. Mange teams får lavet kontomapping, men glemmer at dimensionværdi-mapping er en særskilt del. Så ser alt rigtigt ud i opsætningen, indtil en konkret postering rammer inbox eller bogføring og falder på en manglende værdi.
Kernen i intercompany er dobbelt mapping: konto til IC-konto, dimension til IC-dimension og dimensionværdi til IC-dimensionværdi. Mangler ét led, knækker flowet.
Opsætning af intercompany i Business Central fra grunddata til partner
Den mest stabile opsætning starter med en bevidst beslutning om, hvilket selskab der skal være “master” for intercompany-strukturen. Business Central understøtter brug af en Synchronisation Partner, hvorfra man kan kopiere IC-kontoplan og IC-dimensioner. Det er en praktisk vej, hvis flere selskaber skal følge samme struktur og samme begreber på tværs.
Hvis selskaberne ligger i forskellige environments eller tenants, kommer der flere tekniske trin ind i billedet. Det er ikke nok, at selskaberne ligner hinanden funktionelt. Forbindelsen mellem parterne skal være sat korrekt op, før outbox kan sende til partnerens inbox. Den del er ofte overset, især når test og produktion blandes sammen i de tidlige faser.
En god opsætning følger som regel en fast rækkefølge:
- Opret virksomhedens egne intercompany-indstillinger i Intercompany Setup.
- Definér IC-partnere og forbind hvert selskab til korrekt partnerkode.
- Opret eller synkronisér IC-kontoplanen.
- Udfør mapping mellem lokal kontoplan og IC-kontoplan i begge retninger.
- Opret IC-dimensioner og udfør separat mapping af både dimensioner og dimensionværdier.
Det sidste punkt er det, der oftest bliver undervurderet. Mange antager, at når dimensionen “AFDELING” er mapppet, så følger værdier som “SALG”, “ADM” og “LAGER” automatisk med. Det gør de ikke. Intercompany Dimension Values Mapping skal være på plads, ellers får du fejl eller tomme dimensioner i modtagerselskabet.
Datamodel for intercompany: IC-kontoplan, mapping og Dimension Set ID
Den tekniske forståelse begynder med datamodellen. Intercompany arbejder ikke kun med visuelle felter på kort og journaler. Under overfladen er det relationer mellem konti, dimensioner, værdier og posteringer, der styrer, hvad der kan sendes og bogføres korrekt.
Når en postering bærer dimensioner, lagres kombinationen som et Dimension Set ID. Det er en central del af modellen i Business Central og er beskrevet i designet bag dimension set entries. Ét Dimension Set ID repræsenterer en unik kombination af dimensionværdier. Derfor kan to journaler med samme synlige dimensioner dele samme ID, mens en lille forskel skaber et nyt sæt.
Det har stor betydning i intercompany. Hvis afsenderselskabet sender en kombination, som modtagerselskabet ikke kan mappe eller ikke må bruge, stopper processen ikke nødvendigvis i afsendelsen. Fejlen kan først vise sig, når inbox-linjen accepteres, eller når journallinjen bogføres i modtagerselskabet.
I praksis er disse objekter de vigtigste at holde øje med:
- IC-partnere
- IC-kontoplan
- Intercompany Chart of Accounts Mapping
- IC-dimensioner
- Intercompany Dimension Values Mapping
- Dimension Set ID
- Inbox og Outbox
Den liste siger noget vigtigt om designet: intercompany er ikke én tabel og ikke ét flow. Det er et net af afhængigheder, hvor en fejl i ét lag først bliver synlig i et andet.
Bogføringsflow i intercompany-journaler og intercompany-dokumenter
Når en intercompany-journallinje bogføres i afsenderselskabet, oprettes der en tilsvarende linje i Intercompany Outbox. Herfra kan den sendes videre til partneren. Det flow er beskrevet i arbejde med intercompany-dokumenter og journaler.
I modtagerselskabet lander transaktionen i Intercompany Inbox. Her accepteres den, hvorefter systemet opretter dokument- eller journallinjer lokalt, som derefter bogføres. Det er en vigtig detalje: modtagelse er ikke det samme som bogføring. Mange afstemningsproblemer opstår, fordi et selskab har bogført afsendelsen, mens modtagerselskabet kun har modtaget posten i inbox uden at færdigbehandle den. Processen for inbox/outbox er nærmere beskrevet i håndtering af intercompany inbox.
Ved køb og salg kan flowet være dokumentbaseret. Hvis en kunde eller leverandør er knyttet til en intercompany partner code, kan salgs- og købsdokumenter skabe tilsvarende dokumenter i partnerfirmaet. Her bliver relationen mellem masterdata og intercompany ekstra vigtig. En fejl på kunde- eller leverandørkortet kan slå direkte igennem i dokumentoprettelsen.
Typisk journalflow: Bogfør i selskab A → linje oprettes i Outbox → send til selskab B → linje modtages i Inbox → accepter → lokal journallinje eller dokument oprettes → bogfør i selskab B.
Afstemning i intercompany: hvor kæden typisk knækker
Afstemning i intercompany handler ikke kun om saldi mellem selskaber. Det handler om, at begge selskaber ser samme forretningshændelse gennem hver deres kontoplan, dimensioner og dokumenthistorik. Hvis ét led halter, ser posterne ens ud i beløb, men ikke i struktur.
En klassisk fejl er timing. Selskab A bogfører og sender, men selskab B har endnu ikke accepteret eller bogført. I regnskabet ser det ud som en difference, selv om problemet blot er processtatus. Derfor bør afstemning altid starte med status på Outbox og Inbox, før man går i gang med kontospecifikationer.
En anden klassiker er asymmetrisk mapping. Kontoen kan være mapppet fra A til IC-konto, men ikke korrekt videre fra IC-konto til selskab B’s lokale konto. Resultatet bliver ofte fejl ved modtagelse, eller endnu værre, en postering på en forkert konto. Den type fejl er mere alvorlig, fordi transaktionen teknisk set kan være gennemført, men regnskabsmæssigt forkert.
Dimensioner i intercompany: mapping, kombinationer og rettelser
Dimensioner er næsten altid det mest sårbare område i intercompany. Det skyldes, at logikken er delt mellem flere lag: standarddimensioner på masterdata, krav på konti, tilladte kombinationer og selve IC-mappingen. Selv små forskelle mellem selskaber kan udløse fejl.
Business Central skelner mellem selve dimensionen og dens værdier. Du kan godt have mapppet dimensionen “AFDELING” korrekt og stadig få fejl, hvis værdien “PROJEKT-X” ikke findes eller ikke er mapppet i modtagerselskabet. Det er netop her mange intercompany-opsætninger fejler under test med realistiske data.
Fejltyperne er ret velkendte. Den officielle vejledning om fejlsøgning og rettelse af dimensioner beskriver blandt andet blokerede dimensioner og blokerede dimensionskombinationer. Hvis modtagerselskabet har en Blocked dimension combination, kan en postering med ellers korrekte værdier stadig blive afvist.
Det gør dimensionfejl ekstra frustrerende: alle enkeltdele kan se rigtige ud isoleret, mens kombinationen er ulovlig.
Når du fejlsøger dimensioner, er disse kontroller næsten altid relevante:
- Dimensionkode: Findes den i begge selskaber, og er den mapppet til samme IC-dimension?
- Dimensionværdi: Findes værdien, og er værdimapping udført særskilt?
- Blokering: Er dimensionen eller værdien blokeret i modtagerselskabet?
- Kombinationsregler: Er kombinationen tilladt, eller rammer den en blocked dimension combination?
- Standarddimensioner: Kommer der en automatisk værdi ind fra konto, kunde, leverandør eller vare, som ændrer kombinationen?
- Rettelser: Er der brugt dimension correction efter bogføring, så historikken ikke længere matcher forventningen?
Der er en vigtig nuance her. Hvis man retter dimensioner efter bogføring, kan det ændre analysevisninger og rapportering, men ikke altid på en måde der er hensigtsmæssig for store datamængder. Vejledningen nævner selv performancehensyn ved opdatering af analysis views. Det bør tænkes ind, før man bruger massekorrektion som standardløsning.
De 10 typiske fejl i intercompany i Business Central
De fleste fejl samler sig om få mønstre. Her er de ti, der går igen i tekniske gennemgange og i praktisk drift.
- Manglende mapping mellem lokal konto og IC-konto i afsenderselskabet.
- Manglende mapping fra IC-konto til lokal konto i modtagerselskabet.
- Dimensionen er mapppet, men dimensionværdierne er ikke.
- Samme dimensionsværdi har forskellig betydning i selskaberne og er mapppet forkert.
- Afsenderselskabet har sendt posten, men modtagerselskabet har ikke accepteret eller bogført fra inbox.
- Kunde eller leverandør mangler korrekt intercompany partner code ved dokumentflow.
- En standarddimension tilføjes automatisk i modtagerselskabet og skaber en ulovlig kombination.
- En dimension eller dimensionsværdi er blokeret i ét selskab.
- Testdata er oprettet manuelt i ét selskab, mens produktion bygger på synkroniseret IC-struktur, så mapping ser ens ud men peger forskelligt.
- Fejlsøgning sker kun i brugerfladen, uden kontrol af Dimension Set ID, inbox/outbox-status og de faktiske mappings bagved.
Punkt 10 er værd at tage alvorligt. Intercompany-fejl bliver tit behandlet som brugerfejl eller “mærkelig systemadfærd”, selv om årsagen ligger i datarelationer, som ikke kan ses direkte på ét skærmbillede.
Fejlsøgning i intercompany: en teknisk arbejdsgang
En stabil fejlsøgning starter med at placere fejlen i flowet. Sker den ved bogføring i afsenderselskabet, ved afsendelse fra outbox, ved modtagelse i inbox, ved accept af inbox-linje eller ved lokal bogføring i modtagerselskabet? Den opdeling sparer meget tid, fordi hvert trin peger på et bestemt sæt data.
Gå derefter baglæns fra den konkrete post. Find journal- eller dokumentlinjen, tjek partnerkode, konto, dimensioner og status i outbox/inbox. Sammenlign derefter mappingen i begge selskaber. Hvis posten bærer dimensioner, bør Dimension Set ID undersøges, så du ser den præcise kombination og ikke kun de felter, der tilfældigvis vises på siden.
Det er her den tekniske disciplin gør forskellen. I stedet for at “rette til og prøve igen” bør man validere strukturen trin for trin: eksisterer relationen, er den mapppet, er den tilladt, og er processen færdig hele vejen til bogført post. Når det greb bliver fast praksis, falder både antallet af intercompany-fejl og tiden brugt på afstemning mærkbart.