Boekhouding voor Chrome-extensieontwikkelaars: uitbetalingen afstemmen nadat Google in-app betalingen schrapte

Open vandaag het ontwikkelaarsdashboard van de Chrome Web Store en je merkt iets op dat ontbreekt: een tabblad "betalingen". Google heeft zijn eigen in-app-betaalsysteem voor extensies in 2021 stopgezet, en het is nooit teruggekomen. Wil je in 2026 geld vragen voor een Chrome-extensie, dan sta je er alleen voor wat betreft facturatie, abonnementen, terugbetalingen, belastinginning en — het onderdeel waar bijna niemand op rekent — het afstemmen van wat er daadwerkelijk op je bankrekening binnenkomt tegenover wat je hebt verkocht.

Dat laatste onderdeel struikelt meer indie-ontwikkelaars dan prijsstelling ooit doet. Een eenmanszaak die drie of vier extensies via Stripe, Paddle of een wrapper zoals ExtensionPay draait, eindigt met uitbetalingsstortingen die niet netjes aan één product te koppelen zijn, pieken in terugbetalingen die uit het niets opduiken na een reviewvertraging van de Chrome Web Store, en een banksaldo dat nooit helemaal overeenkomt met wat het verkoopdashboard zegt dat het zou moeten zijn. Niets daarvan is een fout in je bedrijf. Het is het voorspelbare gevolg van het zelf aan elkaar knopen van een betaalstack die Google vroeger voor je regelde.

Zo bouw je een boekhouding die dit overleeft.

Waarom Google uit de betalingenbusiness stapte​

Chrome Web Store Payments lanceerde begin jaren 2010, toen er nog niet veel goede opties waren voor een solo-ontwikkelaar om geld te vragen voor een browserextensie. Tegen 2021 waren Stripe, Braintree en een golf van "merchant of record"-diensten volwassen genoeg geworden dat Google besloot dat het zijn eigen afreken-, licentiesleutel- en uitbetalingssysteem niet langer nodig had. Het zette Chrome Web Store Payments stop en dwong elke betaalde extensie te kiezen tussen gratis worden of overstappen op een externe verwerker.

Het praktische resultaat voor ontwikkelaars: elke dollar die een extensie verdient, stroomt nu door een betaalstack die je zelf hebt samengesteld, en elk afstemmingsprobleem dat die stack veroorzaakt, moet je zelf oplossen. Er bestaat niet langer één "uitbetalingsrapport van de Chrome Web Store" — er is wat je verwerker je geeft, plus wat de eigen vermeldingsanalyse van de Chrome Web Store laat zien, plus je bankafschrift, en die drie dingen zijn het bij eerste oogopslag zelden met elkaar eens.

Betalingsverwerker of merchant of record — kies er één per extensie​

Voordat de afstemming zelfs maar begint, moet je weten aan welke kant van de transactie je juridisch staat, want dat bepaalt wat er in je boekhouding terechtkomt.

Een betalingsverwerker (Stripe rechtstreeks, of een wrapper die erop is gebouwd zoals ExtensionPay) maakt jou de verkoper. Jij int het geld, jij bent voor belastingdoeleinden de merchant of record, en jij bent verantwoordelijk voor het uitzoeken van omzetbelasting- en btw-verplichtingen in elk rechtsgebied waar een klant woont. De kosten zijn lager — Stripe's basistarief is 2,9% + $0,30 per transactie, en een wrapper zoals ExtensionPay rekent daar doorgaans nog eigen kosten bovenop — maar de nalevingslast ligt bij jou.

Een Merchant of Record (Paddle, Lemon Squeezy, Fungies en vergelijkbare partijen) wordt juridisch de verkoper in plaats van jij. Zij innen de btw of gst, dienen de aangiftes in bij de ruim 140 landen die dit inmiddels vereisen voor digitale goederen, handelen chargebacks af en keren jou de netto-opbrengst uit. Je levert 4–8% van de omzet in in plaats van ~3%, maar een hele categorie boekhoud- en aangiftewerk verdwijnt. Voor een volledig overzicht van de afwegingen en hoe je berekent wanneer de overstap zichzelf terugbetaalt, zie onze gids over Merchant of Record.

Voor de meeste solo-extensieontwikkelaars onder een paar duizend dollar per maand is de extra 3–5% die een MoR rekent goedkope verzekering tegen de noodzaak om je handmatig in een dozijn landen voor de btw te registreren. Zodra je echte terugkerende omzet draait over meerdere extensies, maak je de vergelijking opnieuw — de rekensom verandert naarmate het volume groeit.

Wat je ook kiest, leg het vast. Je boekhouding heeft een duidelijk antwoord nodig op "wie is de juridische verkoper van record voor deze extensie", want dat bepaalt of omzetbelastingverplichtingen überhaupt op je balans verschijnen.

Het afstemmingsprobleem is structureel, geen fout​

Dit is het deel dat ontwikkelaars overvalt: zelfs met een correct geconfigureerde verwerker komt de uitbetaling die je ontvangt vrijwel nooit één-op-één overeen met de omzet die je die periode hebt gegenereerd. Drie dingen doorbreken die 1:1-match:

• Gebundelde uitbetalingen. Stripe en de meeste MoR's keren uit volgens een doorlopend schema (vaak 2–7 dagen na de transactie, soms wekelijks), dus een uitbetaling die op de 5e van de maand binnenkomt, bevat verkopen van de laatste paar dagen van de voorgaande maand. Als je uitbetalingen boekt als omzet op de dag dat ze op je bankrekening staan, ken je elke maand inkomsten toe aan de verkeerde periode.
• Meerdere extensies, één verwerkersaccount. Als je meerdere extensies via hetzelfde Stripe- of Paddle-account draait — gebruikelijk voor ontwikkelaars die een handvol kleine tools uitbrengen in plaats van één vlaggenschipproduct — is de uitbetaling één totaalbedrag dat ze allemaal dekt. Zonder tagging per extensie (Stripe's metadatavelden, of aparte producten/prijzen per extensie) kun je niet zien welke extensie de omzet daadwerkelijk heeft gegenereerd, waardoor je niet kunt bepalen welke jouw onderhoudstijd waard is.
• Kosten, terugbetalingen en valutaomrekening worden al verrekend voordat je het bedrag ziet. Het uitbetalingsbedrag is al netto na verwerkingskosten, eventuele terugbetalingen die in die periode zijn uitgegeven, en valutaomrekening als je internationaal verkoopt. De uitbetaling boeken als bruto-omzet overdrijft je omzet en verbergt je werkelijke marge.

De oplossing is een driewegafstemming, minimaal maandelijks uitgevoerd:

1. Verkooprapport van de verwerker — bruto-transacties, uitgesplitst per product/extensie als je account dat ondersteunt, vóór verrekening van kosten en terugbetalingen.
2. Uitbetalingsrapport van de verwerker — de nettobedragen die daadwerkelijk naar je bank zijn overgemaakt, met kosten en terugbetalingen als aparte regels uitgesplitst.
3. Bankafschrift — de stortingen die daadwerkelijk zijn bijgeschreven.

Stem alle drie op elkaar af. Het verkooprapport vertelt je wat je hebt verdiend (omzet, verantwoord op het moment dat de klant betaalde voor de dienstperiode). Het uitbetalingsrapport vertelt je de kostenafname en terugbetalingsactiviteit om als uitgaven en tegenover-omzet te boeken. Het bankafschrift bevestigt dat het geld daadwerkelijk is aangekomen. Als twee van de drie niet met elkaar kloppen, is dat je signaal dat er iets onderzocht moet worden — een mislukte uitbetaling, een betwiste chargeback, of een onverwachte verwerkerskosten.

Het Chrome-specifieke risico: reviewvertragingen en verwijderingen​

Elke betaalstack kent gewone terugbetalingsactiviteit. Chrome-extensies hebben een extra faalmodus die het waard is om als eigen regel bij te houden: reviewvertragingen en beleidsverwijderingen van de Chrome Web Store.

Wanneer het reviewteam van Google een gepubliceerde extensie markeert wegens een beleidsschending, krijg je ofwel een onmiddellijke verwijdering (bij matige tot ernstige overtredingen) of een waarschuwingsperiode van ongeveer 7 tot 30 dagen om een kleine overtreding te herstellen. In beide gevallen verliezen gebruikers toegang tot een extensie waarvoor ze actief betalen, en dat leidt tot een voorspelbare piek in terugbetalingsverzoeken, chargebacks en supporttickets — ontwikkelaars hebben gemeld dat ze tientallen procenten van een maand abonnementsomzet zijn kwijtgeraakt door precies dit patroon, bovenop de directe terugbetalingen.

Twee boekhoudgewoontes maken dit beheersbaar in plaats van een verrassing:

• Tag terugbetalingen en chargebacks naar oorzaak. Een terugbetaling omdat een klant de extensie niet leuk vond is een normale kostenpost van het zakendoen. Een terugbetaling omdat je extensie een week is verwijderd, is een apart, traceerbaar bedrijfsrisico. Door ze te scheiden (al is het maar met een memoveld of een subrekening) zie je over een jaar hoeveel omzetvolatiliteit voortkomt uit platformrisico versus product-marktfit.
• Behandel een lopende review of een openstaande beleidswaarschuwing als een meldenswaardige gebeurtenis, net zoals je een churnrisico bij een sleutelklant zou markeren. Als je de cijfers doorrekent om te beslissen of je de prijzen verhoogt, hulp inhuurt of een lening aangaat, is een extensie die momenteel onder een 30-daagse nalevingswaarschuwing staat geen "stabiele terugkerende omzet" — modelleer die als risicovol totdat de review is doorstaan.

Verantwoord omzet wanneer je ze verdient, niet wanneer de uitbetaling binnenkomt​

Abonnements- en eenmalige-aankoopextensies vragen om verschillende behandeling, en ze door elkaar halen is de meest voorkomende boekhoudfout in deze niche:

• Maandelijkse of jaarlijkse abonnementen: verantwoord omzet gelijkmatig over de periode waarvoor de klant betaalt, niet allemaal ineens op het moment dat de transactie binnenkomt. Een jaarplan dat vooraf wordt betaald, creëert een verplichting voor uitgestelde omzet — je bent betaald, maar je hebt nog niet elf van de twaalf maanden dienstverlening geleverd, dus slechts 1/12e is omzet in de maand van verkoop en de rest loopt maand voor maand van de balans af.
• Lifetime deals (een populair prijsmodel specifiek voor extensies, omdat gebruikers wantrouwend staan tegenover doorlopende abonnementen voor een browsertool): deze vertegenwoordigen nog steeds een verplichting om onbeperkt updates en ondersteuning te leveren, dus 100% van het geld op dag één als omzet verantwoorden overdrijft je werkelijk verdiende inkomen voor die maand. Een verdedigbaardere aanpak verantwoordt lifetime-deal-omzet over een redelijk ingeschatte dienstperiode (veel bedrijven gebruiken 12–36 maanden als richtlijn) in plaats van alles ineens.
• Eenmalige aankopen zonder doorlopende verplichting: verantwoord volledig bij levering — dit is het eenvoudige geval.

MRR (maandelijkse terugkerende omzet) is een nuttige groeimaatstaf, maar het is niet hetzelfde getal als verantwoorde omzet in je boekhouding. MRR vertelt je het jaartempo van actieve abonnementen; je grootboek moet weergeven wat je deze periode daadwerkelijk hebt verdiend na uitstel.

Een grootboekstructuur die meerdere extensies overleeft​

Als je je boekhouding bijhoudt in een platte-tekst, double-entry-systeem, is de oplossing voor het "één uitbetaling, meerdere extensies"-probleem een rekeningschema dat inkomsten vanaf dag één per product scheidt, plus expliciete rekeningen voor de aftrekposten die een uitbetalingsrapport al heeft verrekend:

2026-07-05 * "Stripe payout - batch #4471"
  Assets:Bank:Checking                      842.17 USD
  Income:Extensions:FocusTimer             -510.00 USD
  Income:Extensions:TabArchiver            -390.00 USD
  Expenses:PaymentProcessing:StripeFees      41.83 USD
  Expenses:Refunds:FocusTimer                16.00 USD

Elke uitbetaling wordt één transactie die de bankstorting afstemt tegen inkomsten, kosten en terugbetalingen per extensie als aparte boekingen — in plaats van één ondoorzichtige "Stripe-storting"-regel die je niets vertelt over welk product eigenlijk winstgevend is. Omdat het bestand platte tekst is, kun je het doorzoeken of bevragen per extensie, per maand of per terugbetalingsoorzaak, precies het inzicht dat een uitbetalingsrapport met één totaalbedrag je niet geeft.

Een maandelijkse checklist​

1. Haal het verkooprapport van de verwerker voor de maand op (bruto, uitgesplitst per product indien mogelijk).
2. Haal het uitbetalingsrapport op en splits kosten, terugbetalingen en chargebacks in aparte regels.
3. Bevestig uitbetalingsstortingen tegen het bankafschrift.
4. Boek abonnements- en lifetime-deal-omzet volgens een verantwoordingsschema, niet bij ontvangst.
5. Tag elke terugbetaling die verband houdt met een reviewvertraging of verwijdering van de Chrome Web Store apart van gewone churn.
6. Als je internationaal verkoopt via een directe betalingsverwerker (geen MoR), controleer dan of je cumulatieve verkoop in enig land een btw/gst-registratiedrempel heeft overschreden.

Houd de boekhouding van je extensiebedrijf net zo schoon als je code​

Je zou nooit een extensie uitbrengen zonder versiebeheer, en je financiën verdienen dezelfde discipline — zeker zodra uitbetalingen verdeeld zijn over meerdere producten en verwerkers. Beancount.io biedt platte-tekst, versiebeheerde boekhouding waarmee je inkomsten per extensie kunt taggen, uitgestelde omzet kunt volgen en uitbetalingen kunt afstemmen tegen je bankafschrift met dezelfde precisie die je in je codebase toepast. Begin gratis en ontdek waarom ontwikkelaars hun boekhouding op dezelfde manier beheren als al het andere dat ze bouwen.