ASC 606 voor Indie App-ontwikkelaars: Moet je App Store-omzet bruto of netto boeken?

Open App Store Connect of de Google Play Console en je ziet een getal dat aanvoelt als jouw omzet. Vorige maand stond er €10.000. Je bankrekening ontving €7.000. Geen van beide getallen is fout — maar slechts één hoort op je winst-en-verliesrekening als "omzet", en die beslissing verkeerd nemen kan stilletjes je brutomarge vertekenen, je groeipercentage verkeerd weergeven, en een kredietverstrekker of investeerder een beeld van je bedrijf geven dat niet klopt.

Dit is de principaal-versus-agent-vraag, en onder de ASC 606-omzetverantwoordingsstandaard van de Amerikaanse GAAP is het geen optioneel papierwerk — het is de regel die bepaalt of je €10.000 aan omzet en €3.000 aan kostprijs rapporteert, of slechts €7.000 aan omzet met verder niets te melden. Voor een indie-ontwikkelaar die verkoopt via de Apple App Store of Google Play Store, verbaast het antwoord mensen meestal.

De Vraag Die Elke App-ontwikkelaar Uiteindelijk Stelt​

De aanleiding is bijna altijd hetzelfde: een oprichter stelt een pitchdeck samen, vraagt een lening voor een klein bedrijf aan, of probeert gewoon te achterhalen "hoeveel heb ik dit kwartaal eigenlijk verdiend", en realiseert zich dat ze altijd hebben geboekt wat er op hun bankrekening binnenkwam als "verkopen". Dat getal is netto van de commissie van Apple of Google — het heeft de platformvergoeding er dus al afgetrokken.

Het probleem is dat het salderen van je omzet met een platformvergoeding geen stijlkeuze is. ASC 606 heeft een specifieke test voor precies deze situatie, en die draait om één vraag: wie controleert het ding dat wordt verkocht voordat het van eigenaar wisselt met de klant?

De ASC 606-controletest, in Gewoon Nederlands​

Het vijfstappen-omzetmodel van ASC 606 vereist dat je de prestatieverplichtingen in een contract identificeert en bepaalt wie deze nakomt. Wanneer een marktplaats of platform tussen jou en de eindklant zit — Apple, Google, Etsy, DoorDash, Uber — noemen accountingstandaarden dit de principaal versus agent-beoordeling, en PwC's omzetgids merkt op dat app store-verkopen een schoolvoorbeeld zijn van regelingen die deze zorgvuldige blik vereisen.

• Principaal: jij controleert het goed of de dienst voordat het aan de klant wordt overgedragen. Je herkent het volledige, bruto bedrag dat de klant betaalde als omzet, en de commissie van het platform wordt een kostprijs van de omzet (een kostenpost), geen vermindering van de omzet.
• Agent: het platform controleert het aanbod en jij regelt alleen de verkoop namens iemand anders. Je herkent alleen het netto bedrag dat je houdt als jouw vergoeding.

Drie indicatoren bepalen welke je bent, volgens de kaders van Deloitte en PwC:

1. Uitvoeringsverantwoordelijkheid — wie is verantwoordelijk als de app niet werkt, de abonnementsdienst niet levert, of een klant klaagt? Dat ben jij meestal, de ontwikkelaar, niet Apple.
2. Risico vóór overdracht — wie draagt het risico dat de "voorraad" (jouw app, jouw content, jouw abonnementsniveau) niet verkoopt of de klant niet tevreden stelt? Wederom, doorgaans jij.
3. Prijsbepalingsvrijheid — wie bepaalt wat de klant daadwerkelijk betaalt? Jij kiest de prijsklasse van je app; het platform onderhandelt er niet per deal over met je.

Omdat de meeste indie-ontwikkelaars de productervaring controleren, de klantrelatie voor ondersteuning en updates beheren, en hun eigen prijzen bepalen, vallen ze aan de principaal-kant van de test — wat betekent dat de juiste boekhouding is om het bruto bedrag dat de klant betaalde als omzet te boeken, en de vergoeding van Apple of Google te behandelen als een kostprijs van de omzet, niet als een onzichtbare korting.

De Getallen Achter de Vergoeding​

Weten dat je de principaal bent, heeft alleen zin als je weet wat er daadwerkelijk wordt afgetrokken. De structuur van de platformvergoedingen is de afgelopen jaren aanzienlijk veranderd, en de meeste ontwikkelaars budgetteren nog steeds op basis van verouderde aannames:

Plus vaste jaarlijkse kosten die de meeste mensen vergeten toe te wijzen: de ontwikkelaarsprogrammakosten van Apple van $99/jaar en de eenmalige registratiekosten van Google van$25. Klein, maar ze horen ergens in je rekeningschema thuis — meestal als algemene bedrijfskosten, niet als kostprijs van de omzet.

Correct Boeken: Een Uitgewerkt Voorbeeld​

Stel dat een klant een in-app-abonnement van €9,99 koopt via Apple, en je valt onder het standaardtarief van 30%. Apple int de €9,99 bij de klant, houdt €3,00, en stort uiteindelijk €6,99 op je bankrekening. Het boeken van €6,99 als "omzet" geeft je bovenste regel 30% te laag weer — wat enorm uitmaakt als je je groeipercentage vergelijkt met een concurrent die direct verkoopt, of je marges uitlegt aan een kredietverstrekker.

De juiste boekingen herkennen de volledige verkoop, en boeken de commissie vervolgens apart als een kostenpost:

2026-07-18 * "Apple" "iOS-abonnement — bruto verkoop"
  Activa:Vorderingen:AppStore           9.99 EUR
  Inkomsten:AppVerkoop                 -9.99 EUR
 
2026-07-18 * "Apple" "30% App Store commissie"
  Kosten:Kostprijs:Platformvergoedingen 3.00 EUR
  Activa:Vorderingen:AppStore          -3.00 EUR
 
2026-07-20 * "Apple" "Uitbetaling ontvangen"
  Activa:LopendeRekening               6.99 EUR
  Activa:Vorderingen:AppStore          -6.99 EUR

Merk op dat de vorderingrekening op nul uitkomt zodra de uitbetaling is verwerkt, maar je winst-en-verliesrekening toont nog steeds €9,99 aan omzet en €3,00 aan kostprijs — een brutomarge van 70% op die verkoop, geen mysterieus ontbrekende 30%. Dit is precies het soort transactie dat grootboeken in platte tekst en versiebeheer goed aankunnen: de bruto verkoop, de platformvergoeding en de uitbetaling zijn drie afzonderlijke, controleerbare gebeurtenissen in plaats van één vage bankstorting.

Waarom het Dashboardgetal Niet Volstaat​

Zelfs als je de regel kent, is het handmatig toepassen ervan moeilijker dan het klinkt. Standaardrapporten van App Store Connect en Play Console tonen geaggregeerde totalen, niet de transactiedetails op abonnee- of transactieniveau die ASC 606 technisch gezien wil — opbrengsten, terugbetalingen en valutaconversie komen vaak dagen of weken na de daadwerkelijke verkoop in één enkel bedrag binnen. Die kloof is precies de reden waarom een groeiend aantal abonnements-app-bedrijven platform-API's of tools zoals RevenueCat gebruikt om per-transactie-detail te reconstrueren, in plaats van te proberen het terug te rekenen uit een maandelijkse overzichts-PDF.

Deze stap overslaan heeft echte kosten. Een veel geciteerd voorbeeld: een ontwikkelaar zag €3.400 in hun dashboard voor de maand, en na commissies, belastingen en andere platforminhoudingen was slechts €1.294 besteedbaar — een kloof van meer dan 60% tussen de "omzet" die ze dachten te hebben en wat het bedrijf daadwerkelijk hield. Ontwikkelaars die aanwervings- of uitgavenbeslissingen baseren op het dashboardgetal, in plaats van het gereconcilieerde cijfer, budgetteren tegen een getal dat nooit echt was.

Veelgemaakte Fouten Die Je Boeken Verstoren​

• Alleen de nettostorting als omzet boeken. Dit is de meest voorkomende fout en waar dit artikel over gaat — het verlaagt zowel de omzet als de kostprijs, waardoor je brutomargebeeld plat wordt tot iets betekenisloos.
• Terugbetalingen en chargebacks negeren. Apple en Google verwerken beide terugbetalingen van klanten namens jou, soms weken na de oorspronkelijke verkoop — als je niet per transactie reconcileert, kan terugbetaalde omzet voor onbepaalde tijd op je boeken blijven staan.
• De Apple-ontwikkelaarskosten van $99 of Google-registratiekosten van$25 mengen in de kostprijs. Dit zijn vaste operationele kosten, geen transactiecommissies — ze horen in een heel andere kostenemmer thuis.
• Het aparte EU-tariefschema vergeten. Als een deel van je gebruikersbestand in de EU zit en je hebt gekozen voor de alternatieve Apple-voorwaarden, heeft die omzet een andere commissiestructuur dan de rest van je bedrijf en heeft het zijn eigen rekening nodig.

Houd Je Financiën Georganiseerd Terwijl Je Schaalt​

Of je nu een solodeveloper bent met één app in de store of een kleine studio runt met een handvol abonnementsproducten, de bruto-versus-netto-beslissing stapelt zich elke maand op dat je het fout doet — tegen de tijd dat je een financieringsronde ophaalt of een lening aanvraagt, is een te laag weergegeven omzetregel moeilijk uit te leggen. Beancount.io geeft ontwikkelaars een grootboek in platte tekst met versiebeheer, gebouwd voor precies dit soort meerstapstransacties — bruto verkoop, platformcommissie en uitbetaling als drie afzonderlijke, controleerbare boekingen in plaats van één vage bankstorting. Begin gratis en zie waarom ontwikkelaars die al in code denken, de voorkeur geven aan boekhouding die op dezelfde manier werkt.