Dertien jaar lang stroomde elke dollar die een iOS-app verdiende aan een Amerikaanse klant door precies één pijp: Apple's in-app aankoopsysteem, waarbij Apple zijn aandeel nam voordat een ontwikkelaar het geld ooit zag. Dat veranderde in april 2025, toen een federale rechter Apple in minachting van het oorspronkelijke bevel in de zaak Epic v. Apple bevond en beval te stoppen met het in rekening brengen van commissie op aankopen via externe betalingslinks. Daarna veranderde het opnieuw in december 2025, toen het Ninth Circuit oordeelde dat Apple uiteindelijk iets in rekening mocht brengen — maar niet het bestraffende tarief van 27% dat het eerst had geprobeerd. En het kan nog een keer veranderen, want op 2 juli 2026 stemde het Hooggerechtshof ermee in om het beroep van Apple tegen deze hele puinhoop te behandelen.
Als je digitale goederen of abonnementen verkoopt via een iOS-app, heb je nu te maken met twee actieve inkomstenkanalen met twee verschillende sets belastingverplichtingen, twee verschillende merchants of record, en — per vandaag — twee verschillende commissietarieven. Dit is wat er daadwerkelijk is veranderd, wat nog onopgelost is, en hoe je je boeken op orde houdt terwijl de advocaten verder vechten.
Hoe We Hier Zijn Gekomen, in Gewoon Nederlands
De korte versie van een juridisch drama van vijf jaar:
- 2021: Rechter Yvonne Gonzalez Rogers oordeelde dat Apple's "anti-stuurregels" (die apps verboden om gebruikers er zelfs maar van op de hoogte te stellen dat ze buiten de app konden betalen) in strijd waren met de Californische wetgeving tegen oneerlijke concurrentie. Ze beval Apple om externe aankooplinks toe te staan.
- 2024: Apple voldeed op papier, maar voegde een commissie van 27% toe aan elke verkoop binnen zeven dagen nadat een gebruiker op een externe link tikte — plus contractvoorwaarden waarvan Epic betoogde dat ze bedoeld waren om externe links commercieel zinloos te maken.
- April 2025: Rechter Rogers verklaarde Apple in minachting, oordeelde dat het tarief van 27% "bestraffend" was in plaats van compenserend, en beval Apple om onmiddellijk te stoppen met het in rekening brengen van enige commissie op aankopen via externe links in de VS.
- December 2025: Het Ninth Circuit handhaafde grotendeels de minachtingsuitspraak, maar verwees de commissievraag terug naar de districtsrechtbank, met de overweging dat Apple uiteindelijk een vergoeding in rekening mag brengen "gebaseerd op de kosten die werkelijk en redelijkerwijs noodzakelijk zijn voor haar coördinatie van externe links... maar niet meer" — waarbij expliciet beveiligings- en privacykosten werden uitgesloten die Apple had proberen in te rekenen.
- April 2026: Het Ninth Circuit hief een schorsing op, waardoor het terugverwijzingsproces kon doorgaan.
- 2 juli 2026: Het Hooggerechtshof verleende certiorari voor het beroep van Apple.
Waar dat ons vandaag brengt: Amerikaanse ontwikkelaars kunnen externe aankooplinks toevoegen tegen 0% Apple-commissie, omdat nog geen enkele rechtbank een specifiek vervangend tarief heeft goedgekeurd. Dat kan veranderen op het moment dat de districtsrechtbank er een vaststelt, of als de uiteindelijke uitspraak van het Hooggerechtshof het hele kader hervormt. Bouw geen permanente prijsstrategie op het huidige getal — bouw een boekhoudsysteem dat flexibel genoeg is om welk tarief er ook komen gaat, te absorberen.
Wat Je Nu Daadwerkelijk Kunt Doen
Als je een in de VS gevestigde ontwikkelaar bent met een iOS-app, kun je aanvraag doen voor Apple's recht op externe aankooplinks, waarmee je het volgende kunt:
- Een link of knop in je app toevoegen die gebruikers naar een webpagina leidt om een aankoop te voltooien
- Prijzen en promoties communiceren met betrekking tot die externe aankoop (voorheen verboden onder de oude anti-stuurregels)
- Die transactie volledig buiten Apple's in-app aankoopsysteem verwerken — via Stripe, Paddle, je eigen merchant account, of een andere verwerker naar keuze
Je bent nog steeds verplicht om in aanmerking komende externe linktransacties aan Apple te rapporteren, doorgaans binnen 15 dagen, zodat Apple naleving kan volgen, zelfs terwijl het $0 int. Als je dit mist, riskeer je intrekking van het recht, dus dit hoort op een terugkerende boekhoudchecklist, niet alleen een taak voor de lanceringsdag.
Twee uitzonderingen om te weten: ontwikkelaars in Apple's Volume Purchase Program (VPP) en News Partner Program (NPP) kunnen nog steeds te maken krijgen met beperkingen op externe links, en de EU werkt onder een volledig aparte vergoedingsstructuur (Digital Markets Act-regels met een gelaagde Core Technology Commission, Initial Acquisition Fee, en store-services fee) die niets te maken heeft met de bovenstaande Amerikaanse rechtszaak. Als je in beide markten verkoopt, heb je twee verschillende boekhoudkundige behandelingen nodig, niet één.
Waarom Dit Een Boekhoudprobleem Is, Niet Alleen Een Juridisch Probleem
Vóór externe links was je App Store-boekhouding bijna mechanisch eenvoudig: Apple was de merchant of record, Apple inde omzetbelasting en btw, Apple hield zijn commissie van 15% of 30% in, en je boekte één netto storting per betaalperiode, doorgaans afgestemd op één enkele 1099-K of 1099-MISC in januari.
Externe linkverkopen blazen dat op tot een tweede, structureel andere inkomstenstroom:
| In-App Aankoop | Externe Link Aankoop | |
|---|---|---|
| Merchant of record | Apple | Jij (of je betalingsverwerker) |
| Omzetbelasting / btw heffing | Verantwoordelijkheid van Apple | Jouw verantwoordelijkheid |
| Commissie vandaag (VS) | 30% standaard / 15% MKB-programma | 0% (in afwachting uitspraak districtsrechtbank) |
| Uitbetalingstermijn | Standaard schema van Apple | Wat je verwerker instelt |
| Belastingformulier | 1099-K of 1099-MISC van Apple | 1099-K van je verwerker, indien drempels worden overschreden |
| Terugbetaling | Via App Store | Via je eigen ondersteuningsproces |
Die laatste rij is belangrijker dan het lijkt. Wanneer een terugbetaling plaatsvindt op een in-app aankoop, keert Apple de transactie om en past het aan wat het aan jou rapporteert. Wanneer een terugbetaling plaatsvindt op een externe linkaankoop, moet jij deze verwerken, en het raakt de boeken van Apple helemaal niet — wat betekent dat je inkomsten- en terugbetalingsgegevens voor de twee kanalen niet met elkaar overeenkomen, en dat ook niet zouden moeten worden gedwongen.
Je Boeken Instellen Voor Twee Inkomstenkanalen
Een paar concrete stappen om te voorkomen dat dit een januariverrassing wordt:
1. Splits de inkomstenrekening. Gooi "App Store-inkomsten" niet op één grootboekregel. Maak aparte rekeningen (of op zijn minst aparte tags/categorieën) voor in-app aankoopinkomsten en externe linkinkomsten. Wanneer het commissietarief voor externe links uiteindelijk wordt vastgesteld — 5%, 12%, wat de districtsrechtbank ook kiest — wil je historische gegevens over het volume van dat kanaal om de impact te modelleren voordat het toeslaat.
2. Boek inkomsten netto van commissie, maar houd bruto apart bij. De standaard software-inkomstenpraktijk onder ASC 606 is om het bedrag dat je daadwerkelijk mocht ontvangen — netto van Apple's aandeel — als inkomsten te erkennen, aangezien de commissie nooit van jou was. Maar voor afstemming en toekomstige modellering, houd het bruto transactievolume bij in een memoveld of rapportagetag. Je zult het willen hebben op de dag dat een commissietarief wordt aangekondigd, zodat je direct de klap kunt inschatten.
3. Behandel omzetbelastinginning als een nieuwe schuldrekening. Als je nu de merchant of record bent voor externe linkverkopen, ben jij (of je betalingsverwerker) verantwoordelijk voor het innen en afdragen van omzetbelasting in elke staat waar je nexus hebt — een verantwoordelijkheid die Apple stilzwijgend voor je afhandelde in de app. Als je verwerker dit niet automatisch doet (Stripe Tax en Paddle's merchant-of-record-model bieden dit allebei anders aan — controleer welke jouw verwerker gebruikt), is dit de gemakkelijkste plek om maandenlang stilletjes te weinig te innen voordat een controle het ontdekt.
4. Stem twee 1099-formulieren af, niet één. In januari ontvang je waarschijnlijk een 1099-K of 1099-MISC van Apple voor in-app inkomsten en een aparte 1099-K van de verwerker die je externe linkverkopen heeft afgehandeld (zodra je de federale drempel van $600 overschrijdt — lager in sommige staten). Stem beide af tegen je interne grootboek voordat je aangifte doet; een discrepantie tussen wat een verwerker rapporteert en wat jij hebt geboekt, is een van de meest voorkomende triggers voor een IRS-kennisgeving.
5. Log de 15-daagse rapportagecadans. Apple's rapportagevereiste voor externe linktransacties is een nalevingstaak met echte gevolgen (intrekking van het recht) als deze verslapt, dus het hoort in het systeem dat je gebruikt om terugkerende boekhoudtaken bij te houden — niet alleen mondelinge kennis.
Een Raamwerk Dat Niet Uitmaakt Welke Kant de Uitspraak Gaat
Omdat het commissietarief nog niet is vastgesteld — en opnieuw kan worden aangevochten nadat het Hooggerechtshof uitspraak doet — is de daadwerkelijke engineeringtaak hier niet "bouwen voor 0%." Het is het bouwen van een rekeningschema en rapportagestructuur die het commissietarief als een variabele behandelt, niet als een constante. Grootboeken in platte tekst met versiebeheer maken dit specifieke probleem gemakkelijker dan boekhouding op basis van spreadsheets: je kunt elke externe linktransactie taggen met het kanaal en commissietarief op het moment van verkoop, en vervolgens een rapport opnieuw uitvoeren zodra een nieuw tarief is bevestigd, zonder historische posten aan te raken of een formule drie tabbladen diep in een werkmap te verbreken.
Houd Je App-Inkomsten Vanaf Dag Eén Georganiseerd
Het splitsen van inkomsten over App Store in-app aankopen, externe betalingslinks en een EU-vergoedingsstructuur die volledig andere regels volgt, is precies het soort meerkanaals complexiteit dat belastingseizoen in een chaos verandert. Beancount.io geeft je boekhouding in platte tekst met versiebeheer, waarbij elke transactie kan worden getagd op kanaal, commissietarief en rechtsgebied — volledig transparant en doorzoekbaar, zonder leveranciersafhankelijkheid. Start gratis en houd de financiën van je app net zo schoon als je code.