Je hebt je game uitgebracht. Steam laat $42.000 aan totale verkopen zien. Je bankrekening laat $27.400 zien. Als je niet precies weet waar de overige $14.600 is gebleven, ben je niet de enige — en kijk je bovendien niet echt naar de financiële overzichten van je bedrijf, maar naar een winkeldashboard dat daar nooit voor bedoeld was.
Steams revenue share wordt vaak samengevat als "Valve neemt 30%", en voor de overgrote meerderheid van indie-developers klopt dat in grote lijnen. Maar die 30%-post is slechts één van vijf afzonderlijke inhoudingen tussen de prijs die een speler betaalt en het bedrag dat op je zakelijke betaalrekening belandt: platformcommissie, terugbetalingen, valutaomrekening, btw/omzetbelasting en — als je geen Amerikaanse belastingplichtige bent — federale bronbelasting. Elk van deze posten heeft een eigen regel in je boekhouding nodig, omdat elk voor belastingdoeleinden anders wordt behandeld. Ze op één hoop gooien is precies hoe developers eindigen met óf te veel betaalde kwartaalvoorlopige belastingaangiften, óf een onaangename verrassing van hun accountant in april.
Hieronder lees je hoe het geld daadwerkelijk beweegt, en hoe je het vastlegt zodat je boekhouding overeenkomt met de werkelijkheid in plaats van met je Steamworks-dashboard.
Steams gelaagde revenue share, en waarom die voor de meeste developers nauwelijks iets uitmaakt
Valves huidige structuur is gelaagd op basis van de totale omzet per titel:
- 30% platformkosten over de eerste $10 miljoen bruto-omzet (je houdt 70% over)
- 25% platformkosten over omzet tussen $10 miljoen en $50 miljoen (je houdt 75% over)
- 20% platformkosten boven $50 miljoen (je houdt 80% over)
Deze staffels zijn toegevoegd onder druk van grote uitgevers die dreigden hun grote budgettitels naar concurrerende winkels te verplaatsen — niet als een indie-vriendelijk gebaar. En de cijfers bevestigen dat: de mediane indiegame haalt ergens tussen $5.000 en $15.000 aan totale omzet, en zelfs een titel in de top 5% qua verkopen haalt zelden $1 miljoen. Tenzij je de volgende grote hit aan het bouwen bent, kun je je boekhouding het beste inrichten rond een vaste commissie van 30% — de staffels zijn een afrondingsverschil voor een game die nooit acht cijfers bereikt.
Dat gezegd hebbende: als je wél een titel hebt die richting $10 miljoen gaat, is dit precies het soort drempel dat je boekhouding in real time moet bewaken, niet iets wat je drie maanden later ontdekt bij het afstemmen van een uitbetalingsoverzicht. Een rekeningschema dat omzet per titel bijhoudt (in plaats van één grote "Steam-omzet"-rekening) laat je de naderende staffelovergang zien aankomen.
Netto-omzet: waarop Steam je daadwerkelijk uitbetaalt
Dit is het onderdeel waar developers die uit een eenvoudigere retail- of abonnementsbusiness komen, over struikelen: Steams commissie wordt niet berekend over de adviesprijs. Ze wordt berekend over de netto-omzet, wat gelijk is aan bruto-omzet minus toepasselijke correcties.
De bruto-omzet omvat btw en omzetbelasting die bij het afrekenen zijn geïnd. Toepasselijke correcties zijn onder meer:
- Terugbetalingen en chargebacks — de volledige aankoopprijs van elk terugbetaald exemplaar wordt eruit gehaald
- Btw/omzetbelasting — Steam-prijzen zijn in de meeste landen inclusief belasting, en Valve draagt die belasting rechtstreeks af aan de betreffende autoriteit; ze raakt nooit je revenue share-berekening
- Valutaomrekening — internationale verkopen worden afgewikkeld in USD tegen Valves omrekenkoers, die meebeweegt met de valutamarkten tussen de verkoopdatum en de uitbetalingsdatum
Pas nadat dit alles is verrekend, wordt de revenue share van 70/75/80% toegepast. In de praktijk betekent dit: je betaalt geen Steam-commissie over een terugbetaalde verkoop (fijn), maar je mag de adviesprijs ook nooit als je omzet boeken (belangrijk, want dit betekent dat je "bruto verkopen"-cijfer uit marketingdashboards altijd hoger zal zijn dan je boekhoudkundige bruto-omzet).
Boekhoudkundige aanpak: leg voor elke uitbetalingsperiode twee aparte cijfers vast — bruto platformomzet (na btw, vóór terugbetalingen) als je omzetregel, en terugbetalingen als een contra-omzetrekening die daarmee wordt verrekend op je resultatenrekening. Boek niet simpelweg het uiteindelijk gestorte bedrag als "Steam-omzet" — dan verlies je het inzicht in de trend van je terugbetalingspercentage, een van de nuttigste gezondheidsindicatoren die een indiestudio heeft.
Terugbetalingen zijn geen afrondingsverschil — houd het percentage bij, niet alleen de bedragen
Steams terugbetalingsbeleid stelt een speler in staat om binnen twee weken na aankoop een volledige terugbetaling aan te vragen, mits er minder dan twee uur is gespeeld. Dat is aanzienlijk royaler dan console- of mobiele winkels, en het bestaat om goede redenen (het maakt een groot deel van het "kopen, de DRM-vrije kopie piraten, terugbetalen"-misbruik onmogelijk en bouwt vertrouwen op bij kopers). Over het hele platform ligt het terugbetalingspercentage gemiddeld rond de 5% van de aankopen, maar korte verhalende games en titels die binnen twee uur "op het kritieke pad" kunnen worden uitgespeeld, zien vaak veel hogere percentages — developers rapporteren terugbetalingspercentages die oplopen tot dubbele cijfers voor titels die een speler in één sessie kan uitspelen voordat het venster van twee uur sluit.
Voor je boekhouding betekent dit:
- Behandel terugbetalingen als een terugkerende kostenpost van zakendoen op Steam, niet als een uitzondering. Begroot ze zoals een winkelier begroot voor voorraadverlies.
- Houd het terugbetalingspercentage in de gaten als KPI, niet alleen het totale terugbetaalde bedrag. Een percentage dat oploopt na een patch of marketingcampagne is een signaal — een bug, een misleidende winkelpagina, of (steeds vaker in 2026) misbruik van het terugbetalingsvenster gericht op korte games.
- Verantwoord de omzet van een verkoop nooit voordat het terugbetalingsvenster in redelijke mate is verstreken, als je formele omzetverantwoording toepast (ASC 606) — de meeste indiestudio's hoeven de verantwoording niet uit te stellen voor een venster van twee weken, gezien de korte duur en het statistisch voorspelbare percentage. Maar als terugbetalingen voor jouw titel materieel en volatiel zijn, is een maandelijkse terugbetalingsreserve/-voorziening een nauwkeuriger aanpak dan 100% van de bruto-verkopen verantwoorden en later een tegenvaller nemen.
Regionale prijsstelling en de valutaomrekening die je niet hebt gekozen
Steam ondersteunt prijsstelling in 35 valuta's, en Valves prijsupdate van 2026 ging verder dan eenvoudige wisselkoersomrekening door ook rekening te houden met lokale koopkracht en regionale normen voor entertainmentprijzen — wat betekent dat je Amerikaanse prijs van $19,99 in bijvoorbeeld Brazilië of Zuidoost-Azië kan vertalen naar een heel andere reële prijs, en die vertaling kan in de loop van de tijd verschuiven, zelfs als je zelf nooit aan je prijsinstellingen komt.
Twee gevolgen voor je boekhouding:
- Elke internationale verkoop is een USD-omrekening, geen vast getal. De gebruikte koers is Valves koers op het moment van rapportage, niet de koers op de dag dat de speler de game kocht. Als je omzet per regio bijhoudt voor belasting- of bedrijfsplanningsdoeleinden, haal de regionale uitsplitsing dan uit je Steamworks-verkooprapport in plaats van te proberen die terug te rekenen vanuit het gestorte totaalbedrag.
- Pas je regionale prijzen niet handmatig aan zonder het effect op de netto-omzet per eenheid te controleren. Een prijsverlaging in een land met hoge btw kan je opbrengst sterker verkleinen dan de aanpassing van de adviesprijs doet vermoeden, omdat de btw eruit wordt gehaald vóórdat de revenue share wordt toegepast.
Timing van uitbetalingen: waarom je bankstorting nooit overeenkomt met de verkopen van deze maand
Valve keert ongeveer 30 dagen na afsluiting van de verkoopmaand uit — de verkopen van februari worden bijvoorbeeld eind maart uitbetaald — en Steam houdt de betaling vast totdat je saldo een minimumdrempel van $100 overschrijdt, wat van belang is voor kleine early-access-titels of studio's die meerdere kleine games draaien waarbij de maandelijkse omzet van een individuele titel de drempel op zichzelf misschien niet haalt.
Deze vertraging is verreweg de meest voorkomende bron van verwarring ("mijn boekhouding komt niet overeen met mijn bankrekening") voor nieuwe Steam-developers. De oplossing is standaard stelselmatige boekhouding (accrual accounting): leg de omzet vast in de maand waarin de verkoop daadwerkelijk plaatsvond (volgens je Steamworks-verkooprapport), niet in de maand waarin het geld op je rekening staat. Zet een rekening "Steam te vorderen" op die elke maand de netto-omzet toerekent en wordt afgeboekt zodra de overschrijving of ACH-storting ongeveer 30 dagen later binnenkomt. Zonder dit ziet je maandelijkse winst-en-verliesrekening eruit als een achtbaan die niets te maken heeft met je werkelijke verkooptrend — hij weerspiegelt dan alleen welke maanden toevallig een uitbetaling ontvingen.
Belastinginhouding: de stap die niet-Amerikaanse developers overslaan en waar ze spijt van krijgen
Als je een Amerikaanse belastingplichtige bent, geeft Valve je een 1099 en behandel je dat als elke andere bedrijfsinkomst. Als je geen Amerikaanse belastingplichtige bent, is dit het volgende onderdeel dat mensen te pakken neemt:
Steam-omzet wordt geclassificeerd als royalty-inkomen met Amerikaanse bron (specifiek het auteursrechtelijke royaltytarief voor games en dlc). Tijdens de onboarding bij Steamworks doorloopt elke partner een belastinginterview en genereert daarbij ofwel een Form W-9 (Amerikaanse developers) ofwel een Form W-8BEN (niet-Amerikaanse developers). Afhankelijk van je woonland en of dat land een belastingverdrag heeft met de VS, houdt Valve tussen 0% en 30% van je revenue share in voordat die ooit je bankrekening bereikt, en rapporteert dit jaarlijks op Form 1042-S, uitgegeven vóór 15 maart.
Als er 30% wordt ingehouden terwijl je land een belastingverdrag met de VS heeft dat recht geeft op een verlaagd tarief, heb je het belastinginterview waarschijnlijk niet correct doorlopen — vaak omdat je geen buitenlands of Amerikaans belastingidentificatienummer hebt opgegeven waar het verdragsvoordeel dat vereist. Dat is een formulier dat je opnieuw kunt indienen; het is geen permanent tarief. Voor een solo-developer kan het verschil tussen een niet-geclaimd verdrag (30% ingehouden) en een geclaimd verdrag (vaak 0-15%, afhankelijk van het land) duizenden dollars per jaar schelen — de moeite van een half uur om het interview opnieuw te controleren.
Hoe dan ook, die inhouding is een aparte regel ten opzichte van Steams platformcommissie. Meng "Steams aandeel" en "belastinginhouding" niet tot één cijfer in je boekhouding — ze hebben een compleet andere fiscale behandeling. Het ingehouden bedrag is een vooruitbetaling van je eigen belastingverplichting (je kunt het mogelijk claimen als buitenlandse belastingkrediet of terugvorderen, afhankelijk van de fiscale behandeling in je thuisland), terwijl de platformcommissie gewoon Valves vergoeding is, punt uit, en nergens tegen te verrekenen is.
Een eenvoudig rekeningschema voor een door Steam gefinancierde studio
Voor een kleine studio vangen vijf rekeningen bijna alles hierboven af:
- Steam bruto-omzet — verkopen tegen prijs na btw, vóór terugbetalingen en commissie
- Steam terugbetalingen (contra-omzet) — het bedrag van terugbetaalde/charged-back verkopen
- Steam platformkosten — de commissie van 30/25/20%, apart bijgehouden van...
- Steam belastinginhouding — alleen voor niet-Amerikaanse developers; behandel als een vooruitbetaald belastingactief, niet als kosten
- Steam te vorderen — toegerekende maar nog niet uitbetaalde omzet van de huidige en voorgaande maand, die wordt afgeboekt zodra de uitbetaling binnenkomt
Als je meer dan één titel uitbrengt, voeg dan een klasse of tag per game toe in plaats van een heel nieuwe set rekeningen — je wilt de prestaties per titel kunnen vergelijken zonder je rekeningschema vijf keer te dupliceren.
Houd de boekhouding van je gamestudio net zo netjes als je codebase
Als je je comfortabel voelt bij het lezen van een Steamworks-verkooprapport, voel je je ook comfortabel bij platte tekst — en daar draait Beancount.io precies om. In plaats van te worstelen met een op een GUI gebaseerde boekhoudtool om iets zo grillig als gestaffelde platformkosten, terugbetalingsreserves en buitenlandse bronbelasting te modelleren, schrijf je het één keer op als een versiebeheerd grootboek en krijg je elke daaropvolgende berekening er gratis bij. Bekijk de documentatie voor hoe developers een grootboek voor marktplaatsomzet structureren, of verken Fava voor een dashboardweergave van omzet, terugbetalingen en kosten per titel zonder platte tekst te verlaten.