Moms- og omsætningsafgiftsmotorer håndterer forbrugertransaktioner. De rører ikke den spillespecifikke afgiftskaskade — anvendt pr. jurisdiktion, på GGR, NGR eller omsætning, med regler der ændrer sig efter ikrafttrædelsesdato — som reelt afgør, hvad du skylder myndighederne. Vi bygger den logik ind i NetSuite, inde i indtægtsflowet.
Fortæl os dine jurisdiktioner. Vi vender tilbage med en skriftlig vurdering af, hvor afgiften modelleres manuelt i dag — og hvad det koster dig i risiko og tid.
Værktøjerne bygget til moms og omsætningsafgift gør den ene opgave godt. Men spilleafgift er et helt andet problem — en separat skat med sit eget grundlag, sin egen sats og sine egne indberetningsregler på hvert marked, du opererer på. Modeller den manuelt, og du bærer både risikoen og afslutningstidsomkostningen hver eneste måned.
Afgiften lander på GGR i én jurisdiktion, NGR i en anden, omsætning i en tredje. Et enkelt satsfelt kan ikke repræsentere det.
Satsstigninger og regimeændringer gælder fra en dato — nogle gange midt i en periode. Manuelle modeller bryder sammen netop når der er mest på spil.
Afgift beregnet i regneark og derefter posteret ind. Ingen sporbarhed, intet revisionsspor og hensættelsestal, som ingen hurtigt kan forsvare.
Dette er matrixen, som en enkelt momssats ikke kan rumme — og den, vi modellerer nativt i NetSuite, med hver regel datostyret og hvert tal sporbart tilbage til kilden.
Illustrativt. Grundlag, behandlinger og satser konfigureres efter gældende regler for dine licenserede markeder og opdateres, efterhånden som regimerne ændrer sig.
Ikke en påsat konnektor — en beregning inde i GGR → NGR → indtægtsflowet, så tallet, der rammer hovedbogen, er tallet, du kan forsvare.
Spilleafgift på GGR, NGR eller omsætning — uanset hvad myndigheden bruger — modelleret marked for marked inden for én kontoplan.
Satsændringer og regimeskift gælder fra deres ikrafttrædelsesdato. Genkørsler er rene og idempotente; ændringer midt i en periode bryder ikke modellen.
Skattehensættelsesrapportering og de tal, som myndighedsindberetninger kræver, produceret ud fra bogførte transaktioner — ikke rekonstrueret bagefter.
Hvert afgiftstal kan spores tilbage til kildedata. Ren sporbarhed og myndighedsklare eksporter gør revisionsforberedelse fra et projekt til en tilstand.
"Spilleafgift er ikke et skatteværktøjsproblem. Det er et indtægtsflowproblem — hvilket er præcis dér, det hører hjemme i ERP'et."
Den er din at beholde, uanset om du nogensinde arbejder med os. Vi gør os fortjent til den næste samtale.
Anmod om en gennemgang →Spilleafgift kører inde i indtægtskaskaden, pr. jurisdiktion, datostyret og reviderbar.
Strukturerede, godkendte e-fakturaer pr. land — fakturacompliance, adskilt fra spilleafgift.
Hensættelse, land-for-land og transfer pricing — selskabsskat, ikke driftsafgift.