Toegang tot je MCP-server verkopen: Boekhouding voor verbruiks- en abonnementsinkomsten

Je hebt een MCP-server gepubliceerd die iets oprecht nuttigs doet — bijvoorbeeld gestructureerde toegang tot een onderdelencatalogus of een tool voor het samenvatten van documenten — en op een ochtend word je wakker met 40.000 tool-aanroepen die 's nachts zijn binnengekomen van AI-agents die je nooit hebt ontmoet. Dat is de droom, tot je je realiseert dat je facturatiemeter, je boekhouding en je belastingopzet allemaal ontworpen waren voor mensen die op knoppen klikken in menselijk tempo. Agents gedragen zich niet als menselijke gebruikers: één prompt kan tientallen tool-aanroepen in seconden aan elkaar rijgen, door duizenden verzoeken loopen om één instructie op te lossen, en bij elke hop downstreamkosten veroorzaken. Als je voor toegang in rekening brengt, heb je metering nodig die aansluit bij hoe agents consumeren, omzetregistraties die aansluiten bij wanneer waarde wordt geleverd, en kostenregistratie die je marge zichtbaar houdt. Deze gids behandelt alle drie.

Hoe MCP-omzet daadwerkelijk binnenkomt​

Het Model Context Protocol stelt je server beschikbaar als een set tools en resources die AI-clients aanroepen via JSON-RPC. Omdat elke aanroep programmatisch is, heb je meer prijsopties dan een traditionele SaaS-seat — en elke optie wordt anders geboekt.

Per tool-aanroep. Het eenvoudigste model: elke methodeaanroep kost een vast bedrag. Het is gemakkelijk te meteren en gemakkelijk uit te leggen, en het werkt goed wanneer je tools ongeveer uniforme kosten hebben. Het loopt spaak wanneer de ene lichtgewicht metadata-lookup je bijna niets kost, terwijl een workflow-tool uitwaaiert naar een dozijn downstream-API-aanroepen.

Op datavolume. Wanneer methoden grote payloads retourneren — documentinhoud, embeddings, queryresultaten — sluit het in rekening brengen per geretourneerde megabyte of per duizend tokens de prijs aan op de kosten, zoals modelproviders hun eigen API's prijzen.

Op uitkomst. In plaats van per poging in rekening te brengen, reken je per voltooide actie: per document dat met succes is samengevat, per uitgevoerd apparaatcommando, per query die geldige resultaten oplevert. Klanten zijn er dol op omdat mislukte of lege aanroepen gratis zijn; jij hebt metering nodig die succes van falen kan onderscheiden voordat er een eenheid wordt geteld.

Per sessie of geheugen. Servers die gespreksstatus bijhouden tussen aanroepen kunnen per aangemaakte sessie rekenen, per minuut actieve sessietijd, of per blok bewaarde context. Dit past bij assistenten en langlopende agents die op je geheugenlaag leunen.

Hybride abonnement plus overages. Een basismaandbedrag dat een quotum omvat, met metered kosten boven de drempel. Dit is de meest voorkomende vorm in productie-API-bedrijven omdat de basis je vaste kosten dekt terwijl overages meeschalen met zware gebruikers.

Prepaid credits. Klanten kopen vooraf gebruiksblokken en putten die uit. Prima voor cashflow, lastiger voor de boekhouding (meer daarover hieronder), omdat ontvangen cash geen verdiende omzet is totdat de credits zijn verbruikt.

Marketplace-uitbetalingen. Listings en marketplaces rond MCP-servers nemen een omzetaandeel en betalen de rest aan jou uit — dezelfde vorm als verkopen via welke app-marketplace dan ook, met dezelfde bruto-versus-net boekhoudvraag.

Agent-native micropayments. Protocollen zoals x402 laten een agent per verzoek betalen in stablecoin via HTTP, zonder accountaanmelding en zonder factuur. Als je deze route kiest, kan elke tool-aanroep zijn eigen kleine verkoop worden, wat echte gevolgen heeft voor hoe je omzet en kostprijs vastlegt. (Voor achtergrond over hoe deze machinebetalingen werken, zie onze gids over AI-agents die elkaar betalen via x402.)

Kies de meter die je klant als waarde ervaart — dat is een productbeslissing — maar weet dat elke keuze hierboven een ander boekhoudpatroon creëert. De rest van deze gids volgt het geld door elk ervan.

Je meter is je brondocument voor de boekhouding​

In een verbruiksbedrijf is de gebruiksevenementenstroom wat urenstaten zijn voor een advocatenkantoor: het bronrecord dat elke dollar op de factuur rechtvaardigt. Behandel het zo.

De standaard infrastructuur ziet er zo uit. Je server zendt een gebruiksgebeurtenis uit per factureerbare eenheid — methodenaam, klantidentiteit, hoeveelheid, tijdstempel, succes of falen. Die gebeurtenissen stromen naar een meteringslaag (Stripe Billing Meters, een usage-based billing-platform, of je eigen aggregator), die ze per klant toewijst en samenvoegt tot de factuur aan het einde van de periode. De metered billing van Stripe volgt precies deze vorm: je rapporteert gebruik tijdens de cyclus, en aan het einde van de periode telt het de records op en factureert het totaal.

Drie boekhouddisciplines vloeien uit die pijplijn voort:

1. Reconcileer meter tegen factuur elke cyclus. Metereenheden maal tarief moet gelijk zijn aan gefactureerde verbruiksomzet, net zoals verzonden eenheden maal prijs gelijk moet zijn aan verkopen. Elk gat is ofwel bedoeld free-tier-gebruik, mislukte aanroepen die je uitkomstprijsstelling vergaf, of lekstroom — gebruik dat je meter nooit zag. Lekstroom is de stille killer: een niet-geauthenticeerd endpoint of een niet-gemeterde tool is omzet die je hebt verdiend en nooit zult innen.
2. Bewaar ruwe gebruikslogs als je audittrail. Aggregaten zijn wat je factureert; gebeurtenisniveau-logs zijn wat je toont wanneer een klant een piek betwist of een accountant vraagt waar een omzetcijfer uit bestaat. Bewaar ze minstens zo lang als je factuurgeschillenvenster, idealiter zo lang als je belastinggegevens.
3. Wijs identiteit toe aan de rand. Besluit of de factureerbare partij de eindgebruiker achter de prompt is of de houder van de API-sleutel die je server integreert, en leg die beslissing vast in het event. Wanneer één enterprise-sleutel uitwaaiert naar de agents van vijftig medewerkers, is "wie is de klant" een boekhoudkundige vraag met belastinggevolgen, niet slechts een facturatiedetail.

Verbruiksomzet op de juiste manier vastleggen​

Hier gaan MCP-operators het vaakst de fout in: cash komt binnen bij Stripe, ze boeken het als omzet, en de boeken wijken stilletjes af van de werkelijkheid. Onder ASC 606 — de standaard voor omzetverantwoording — is de regel voor consumptieprijsstelling eenvoudig: erken omzet naarmate de klant consumeert, want elke verbruikte eenheid is de prestatieverplichting die wordt nagekomen. Verbruikskosten zijn variabele vergoeding, wat betekent dat je erkent wat daadwerkelijk in de periode is gebruikt, niet wat je hoopt dat het contract waard is.

Pure pay-as-you-go is het gemakkelijke geval. Agents verbruikten in september 100.000 aanroepen tegen je gepubliceerde tarief; de omzet van september is 100.000 maal het tarief, zelfs als de factuur pas in oktober wordt betaald. Boek een vordering wanneer je factureert, omzet wanneer het gebruik plaatsvond. Als je de volledige behandeling van token- en verbruiksmetering onder ASC 606 wilt, gaan onze gidsen over factureren voor tokens en usage-based SaaS-omzetverantwoording dieper.

Hybride basis plus overage splitst in tweeën. Het basisabonnement wordt pro rata erkend over de serviceperiode — een dertigste per dag bij een maandplan — terwijl overages worden erkend wanneer het extra gebruik plaatsvindt. Houd ze in afzonderlijke omzetrekeningen. Ze vermengen verbergt de twee cijfers die je bedrijf daadwerkelijk runnen: voorspelbare abonnements-MRR en piekerige consumptieomzet.

Prepaid credits creëren een verplichting, geen omzet. Wanneer een klant een blok credits koopt, debiteer je cash en crediteer je uitgestelde omzet. Elke keer dat gebruik het saldo aanspreekt, verplaats je de verbruikte waarde van uitgestelde omzet naar verdiende omzet. Het restant dat klanten nooit verzilveren — breakage — heeft zijn eigen regel: als je geschiedenis je in staat stelt het ongebruikte deel betrouwbaar te schatten, erken je die verwachte breakage geleidelijk in verhouding tot het werkelijke gebruik; als je te nieuw bent om het te schatten, wacht je tot de credits verlopen of verzilvering onwaarschijnlijk wordt, en dan erken je het restant. Nieuwe MCP-servers vallen bijna altijd in de tweede categorie, dus boek verwachte breakage niet vroegtijdig om een maand mooier te maken.

Uitkomstgebaseerde prijsstelling voegt een timing-kronkel toe: omzet wordt erkend wanneer de uitkomst is bereikt en meetbaar is, niet wanneer de aanroep begint. Als je meter alleen succesvolle afrondingen telt, moeten je omzetregistraties dezelfde teller volgen — de meter en het grootboek moeten het eens zijn over wat "een verkoop" is.

Twee praktische gewoonten maken dit alles overleefbaar. Ten eerste: voer een afzonderlijke omzetrekening of tag per facturatiemeter (per-aanroep-tools, datavolume, sessies, overages), zodat een margeprobleem in één tool zich niet verstopt in een gemengd totaal. Ten tweede: handhaaf een maandeinde-afsluiting: gebruik met tijdstempel in september hoort bij september, zelfs als de factuur op 2 oktober definitief wordt. Meteringspijplijnen met batchvertragingen maken afsluitingsfouten de meest voorkomende fout in verbruiksbedrijven.

De kostenzijde: wat een MCP-server echt kost​

Omzet per tool-aanroep betekent niets zonder kosten per tool-aanroep. Bouw je kostprijs van omzet van onderaf op:

• Compute en hosting. De servers, containers of serverless-invocaties die je tools draaien, plus egress-bandbreedte voor payload-zware methoden.
• Downstream-API- en modelkosten. Elke LLM-aanroep, embedding-lookup, zoekquery of third-party-API-hit die je tools namens de klant doen. Als je samenvattingstool per document een modelprovider aanroept, is die passthrough je grootste variabele kostenpost en die moet per tool worden gevolgd, niet als een maandelijkse klomp.
• Data- en licentiekosten. Royalty's of per-query-kosten voor propriëtaire data die je server beschikbaar stelt.
• Marketplace-omzetaandeel. Het aandeel van het platform in marketplace-verkopen is een verkoopkost (of een vermindering van de netto-uitbetaling — kies één behandeling en blijf consistent), nooit een compensatie die in de omzet wordt begraven.
• Betalingsverwerking. Kaartkosten bij abonnementsfacturatie, gatewaykosten bij facturen, netwerkkosten bij stablecoin-afwikkeling. Op micropayment-schaal bijten deze: een vaste transactiekost per transactie kan de marge op een tool-aanroep van minder dan een cent overschrijden, wat precies de reden is dat agent-betalingsprotocollen op goedkope rails zijn beland.

Draai de eenheidsberekening per tool voordat je een prijs bepaalt. Stel dat je catalogus-lookup-tool je $0,004 per aanroep kost aan compute plus downstream-queries, en je rekent $0,01. Dat lijkt 60 procent brutomarge — tot support, meteringsinfrastructuur en vergiffenis voor mislukte aanroepen het naar beneden trekken. Prijs vanuit gemeten kosten, niet vanuit onderbuikgevoel, en draai de berekening opnieuw wanneer een downstream-provider zijn tarieven wijzigt.

Stablecoin-ontvangsten verdienen hun eigen alinea. Voor belastingdoeleinden zijn stablecoins eigendom, geen valuta: de marktwaarde op het moment van ontvangst is je omzet, en die waarde wordt je kostprijs. Als je de munten aanhoudt en de peg wiebelt of je converteert later tegen een andere waarde, is het verschil een winst of verlies. Op micropayment-volume is per-transactie-tracking niet onderhandelbaar — geaggregeerd gokken overleeft geen onderzoek — dus leid afwikkelingsrecords automatisch naar je boeken in plaats van ze aan het einde van het jaar te reconstrueren.

Omzetbelasting: je API is belastbaar in meer staten dan je denkt​

Hier is de compliance-verrassing die op de meeste MCP-operators wacht: het verkopen van API-toegang is het verkopen van software of digitale producten, en staten breiden die definities snel uit.

• Californië ondertekende in juni 2026 SB 122, waarmee de omzetbelasting wordt uitgebreid naar digitale producten, waaronder op afstand benaderde software en SaaS, met ingang van 1 januari 2027 — waarmee een decennialange vrijstelling in de grootste staatsmarkt van het land wordt beëindigd.
• Chicago belast SaaS en cloudsoftware onder zijn Personal Property Lease Transaction Tax tegen 9 procent, ook al belast Illinois SaaS niet op staatsniveau.
• Oklahoma ging de andere kant op en oordeelde dat elektronisch geleverde SaaS-abonnementen zijn vrijgesteld — bewijs dat je niet kunt aannemen dat er één landelijk antwoord is.

Drempels voor economische nexus bepalen waar je moet innen: de meeste staten met omzetbelasting hanteren een drempel van $100.000 aan verkopen voor remote sellers, met Californië, Texas en New York op $500.000. Een metered API met landelijk bereik kan een drempel overschrijden in een staat waar je nooit een voet hebt gezet, puur op transactievolume.

Wat je eraan moet doen:

1. Bepaal de belastbaarheid per staat waar je klanten hebt, niet alleen waar je woont. Je meter registreert al de klantlocatie voor toewijzing — hergebruik die data voor nexus-tracking.
2. Marketplace-verkopen kunnen gedekt zijn. Waar een marketplace kwalificeert als marketplace facilitator, int en draagt zij af op jouw verkopen via haar. Directe verkopen vanaf je eigen site of je eigen x402-endpoint zijn volledig jouw verantwoordelijkheid.
3. Automatiseer inning vroeg. Een tax engine (Stripe Tax en zijn concurrenten) die in de checkout wordt geplugd, kost veel minder dan handmatig registreren, aangeven en afdragen in een dozijn staten — en het houdt het bewijs van klantlocatie bij dat auditors vragen.
4. Let op de kalender. Met de ingangsdatum van Californië in 2027 en vergelijkbare uitbreidingen die door andere wetgevers gaan, verloopt een houding van "we zijn te klein om ons zorgen te maken" snel.

Marketplace-uitbetalingen en belastingformulieren​

Als een deel van je omzet binnenkomt als marketplace-uitbetaling, boek het dan zoals app-store-ontwikkelaars doen: registreer de bruto verkoop als omzet en het aandeel van het platform als kosten. Je 1099-K (of 1099-NEC, afhankelijk van de classificatie door het platform) rapporteert het brutobedrag, en de IRS vergelijkt dat cijfer met je aangifte — alleen de netto storting rapporteren is hoe berichten over onderrapportage beginnen. Reconcileer bruto-uitbetalingsoverzichten elke maand met netto bankstortingen, en bewaar het kostenschema dat het verschil verklaart.

Let ook op het timing-gat: de uitbetalingsdatum van het platform is niet je omzetdatum. Omzet hoort bij de periode waarin de agents van de eindklant je tools verbruikten, zelfs als de marketplace twee weken later afdraagt. Voor directe verkopen geldt hetzelfde principe — de gebruiksperiode is bepalend, de afwikkelingsdatum niet.

Een checklist voor het maandeinde voor MCP-operators​

Sluit je boeken elke maand op dezelfde manier af en de randgevallen stapelen zich niet langer op:

1. Haal gemeterd gebruik per klant per meter op en sluit het aan op gefactureerde verbruiksomzet. Onderzoek elk gat boven je free-tier- en vergiffenisbaseline voor mislukkingen.
2. Splits hybride facturen in basis- (pro rata) en overage- (as-consumed) omzetrekeningen.
3. Haal prepaid-credit-afschrijvingen uit uitgestelde omzet; beoordeel oudere creditsaldi voor breakage-behandeling.
4. Boek downstream-API-, hosting- en datakosten per tool; herbereken de brutomarge per meter.
5. Reconcileer bruto marketplace-overzichten met netto stortingen; voeg de overzichten toe aan de records van de maand.
6. Leg stablecoin-ontvangsten vast tegen marktwaarde en volg de kostprijs door conversie heen.
7. Beoordeel klantlocatie-totalen tegen de nexus-drempels van staten; bevestig belastinginning waar vereist.
8. Bewaar de ruwe gebruiksexport bij het afsluitpakket van de maand — het is het brondocument dat je toekomstige zelf (of auditor) zal vragen.

Vereenvoudig je financiële beheer​

Metered omzet, uitgestelde creditsaldi, passthrough-API-kosten en belastbaarheid in vijftig staten zijn veel bewegende delen voor een zijproject dat begon als een weekend-MCP-server. Beancount.io geeft je plain-text accounting met volledige transparantie en controle over je financiële data — elke verbruiksfactuur, creditafschrijving en marketplace-kost vastgelegd als version-controlled, AI-ready transacties die je daadwerkelijk kunt auditen. Begin gratis en houd je agent-economieboeken even programmeerbaar als je server.