LLM API-kosten zijn COGS, geen overhead: een brutomarge-gids voor AI-wrappers

Een oprichter die een AI-schrijfassistent bouwt, vertelde me dat zijn "softwarekosten" $40,000 per maand bedroegen. Toen we het bedrag uitsplitsten, bleek $34,000 daarvan uit facturen van OpenAI en Anthropic te bestaan — en niets daarvan stond in zijn kostprijs van de omzet. Het stond gewoon op een algemene rij "Software & abonnementen", vlak naast zijn projectmanagementtool van $19 per maand. Zijn gerapporteerde brutomarge was 91%. Zijn werkelijke brutomarge, zodra de inferentiekosten op de juiste plek stonden, was 58%.

Dat is geen boekhoudkundige technicaliteit. Het is het verschil tussen een bedrijf dat eruitziet als software en een bedrijf dat zich gedraagt als een fabriek — een fabriek waar elke verkochte eenheid een echte, variabele input verbruikt. Als je bouwt op GPT-5, Claude, Gemini of een ander gehost model, dan is je LLM-factuur geen overhead. Het is kostprijs van de omzet (COGS), en als je het anders behandelt, weet je in werkelijkheid niet hoeveel geld je verdient.

Waarom deze fout zo makkelijk wordt gemaakt​

Traditionele SaaS heeft een hele generatie oprichters geleerd om softwarekosten als vast te beschouwen. Je betaalt voor hosting, je betaalt voor je CRM, je betaalt voor Slack — en geen van die facturen beweegt in lockstep mee met hoeveel een specifieke klant je product daadwerkelijk gebruikt. Dus wanneer de eerste API-factuur van OpenAI binnenkomt, is het logisch om die in hetzelfde mentale vakje te stoppen: "tools waarvoor we betalen om het bedrijf draaiende te houden."

Het probleem is dat een LLM API-factuur zich niet gedraagt als een SaaS-abonnement. Het gedraagt zich als een grondstof. Elke keer dat een klant een prompt verstuurt, verbruik je tokens, en elke token heeft een prijs. Een klant die 50 verzoeken per dag doet, kost je aanzienlijk meer om te bedienen dan een klant die er 2 doet. Dat is de leerboekdefinitie van kostprijs van de omzet: een kost die rechtstreeks meeschaalt met de levering van je product aan een specifieke klant, in tegenstelling tot een kost die je toch zou betalen om de zaak draaiende te houden, ongeacht het gebruik.

Sectorgegevens onderstrepen hoe materieel dit inmiddels is geworden. Uit het State of AI-rapport van ICONIQ van januari 2026 blijkt dat inferentie nu gemiddeld 23% van de totale omzet uitmaakt bij AI B2B-bedrijven in de scale-up-fase, en 84% van die bedrijven meldde een brutomargedaling van zes procentpunt of meer die rechtstreeks toe te schrijven is aan AI-infrastructuurkosten. Dit is geen afrondingsverschil dat je kunt wegmoffelen onder "overige opex." Het is vaak de grootste kostenpost van het bedrijf, en verdient het ook als zodanig te worden behandeld.

De grens tussen COGS en OpEx, correct getrokken​

De regel die COGS scheidt van operationele kosten is niet veranderd alleen omdat de input nu een model-API is in plaats van een magazijn vol onderdelen: kosten om je product te leveren aan een betalende klant horen thuis in COGS; kosten om je product te bouwen horen thuis in R&D onder OpEx. Toegepast op een AI-wrapper ziet die verdeling er zo uit:

Hoort thuis in COGS:

• Productie-inferentiekosten — elke API-aanroep die je live product doet namens een betalende klant, of dat nu een chatcompletie, een embedding-aanroep, een classificatiestap of een agent tool-call-lus is
• Modelhosting / GPU-rekenkracht — als je een open-weight model draait op je eigen of gehuurde infrastructuur in plaats van een gehoste API aan te roepen, de rekentijd die toe te schrijven is aan het bedienen van klantverzoeken
• Ondersteunende inferentie-infrastructuur — vectordatabasequery's, embedding-pipelineruns en orchestratie-overhead die specifiek bestaan om productieverzoeken te bedienen
• AI-specifieke supportkosten — een supportengineer wiens taak het is om problemen met modeloutput voor klanten te triëren, is een kost van het leveren van het product, geen algemene SG&A-uitgave

Hoort thuis in OpEx (meestal R&D):

• Ontwikkelings- en testinferentie — elke prompt die een engineer verstuurt tijdens het itereren op een feature, het debuggen van een regressie of het evalueren van een nieuwe modelversie
• Fine-tuning en evaluatieruns — het bouwen of verbeteren van het model is R&D, geen levering
• Interne AI-tools — de ChatGPT Enterprise-licenties of GitHub Copilot-licenties van je team zijn een productiviteitsuitgave, geen kost van het bedienen van klanten

De praktische stap die deze scheiding mogelijk maakt, is saai maar essentieel: gebruik vanaf dag één aparte API-keys of factureringsprojecten voor productie- en ontwikkelverkeer. Als je engineers prompts testen tegen dezelfde key die je product in productie gebruikt, heb je geen manier om de factuur achteraf correct toe te wijzen, en zul je elke maand opnieuw je werkelijke marge over- of onderschatten.

Hoe een "echte" brutomarge eruitziet voor AI-producten​

Zodra je de scheiding hebt doorgevoerd, kun je verwachten dat het resultaat er anders uitziet dan je gewend bent. Traditionele SaaS-bedrijven mikken bijna als vanzelfsprekend op brutomarges van 70–80%. AI-native producten komen daar niet op dezelfde manier. Het pricing-playbook van Bessemer Venture Partners van februari 2026 legt de typische brutomarge van AI-producten op 50–60%, ruim onder de bandbreedte van 80–90% voor traditionele SaaS, en de cijfers van ICONIQ tonen dat de gemiddelde brutomarge van AI-producten in de sector stijgt — maar slechts tot 52%, tegenover 41% in 2024 en 45% in 2025.

Een nuttige vuistregel die is ontstaan bij operators die dit nauwlettend beheren: houd de LLM-kosten onder ongeveer 20% van de totale COGS als je een duurzaam, schaalbaar businessmodel wilt. Overschrijd je die drempel, dan versnelt de margecompressie doorgaans naarmate je groeit, in plaats van af te nemen, omdat grotere klanten het product juist meer gebruiken, niet minder. Sommige AI-zware categorieën — codeassistenten, documentverwerkingsagents — draaien met LLM-kostenratio's van 30–40% van de COGS en blijven toch levensvatbaar, maar alleen omdat ze bewust rond die realiteit hebben geprijsd in plaats van er achteraf tegenaan te lopen.

Het cijfer dat er werkelijk toe doet, is niet je gemengde, bedrijfsbrede brutomarge — het is de kost per klant. Zware gebruikers van een AI-functie kunnen 50 tot 100 keer meer kosten om te bedienen in ruwe inferentie dan lichte gebruikers op exact dezelfde abonnementstier. Als je dat niet bijhoudt, weet je niet welke klanten winstgevend zijn en welke je stilletjes elke maand subsidieert. Een vast tarief dat prima leek bij je eerste tien klanten, kan geld beginnen te verliezen zodra een van hen een workflow naar productie duwt en zijn verzoekvolume met 20x vermenigvuldigt.

Het kostenmodel per verzoek opbouwen​

Je hebt geen uitgebreide tooling nodig om te beginnen — je hebt discipline nodig om bij elk verzoek de juiste cijfers te loggen. De basisformule is eenvoudig:

request_cost = (input_tokens / 1,000,000) × input_price_per_million
             + (output_tokens / 1,000,000) × output_price_per_million

Outputtokens kosten doorgaans 2–5x meer dan inputtokens per eenheid, omdat generatie rekenintensiever is dan het lezen van een prompt — dus een kostenmodel per verzoek dat alleen het totale aantal tokens bijhoudt zonder input en output te scheiden, zal systematisch een verkeerde prijs berekenen voor alles met lange completions. Als werkend voorbeeld bij prijzen van medio 2026: een verzoek met 2,000 inputtokens en een antwoord van 500 tokens tegen een gangbaar middensegmentmodel (ruwweg $3 input / $15 output per miljoen tokens) kost ongeveer $0.0135. Voer datzelfde type verzoek 50,000 keer per maand uit en je kijkt tegen ongeveer $675 aan inferentiekosten aan voor die ene feature — een bedrag dat onzichtbaar is als het begraven ligt in een vijfcijferige rij "cloudkosten," maar heel zichtbaar wordt zodra het wordt gekoppeld aan de feature en het klantsegment dat het heeft veroorzaakt.

Om dit bruikbaar te maken:

1. Log tokenaantallen bij elk verzoek, niet alleen de kosten — de meeste modelproviders geven het aantal input-/outputtokens al terug in de API-respons zelf, dus dit is een logging-aanpassing, geen nieuwe databron.
2. Label elk verzoek met een klant-ID en een feature-identifier zodat je kosten kunt optellen per account en per productonderdeel, niet alleen per maand.
3. Bereken de kost per klant per factureringsperiode en vergelijk die met wat die klant je betaalt. Dit is het cijfer dat je vertelt of je prijstiers daadwerkelijk overeenkomen met je leveringskosten, niet je gemengde gemiddelde marge.
4. Route naar goedkopere modellen waar de kwaliteit het toelaat. Niet elk verzoek heeft je meest capabele (en duurste) model nodig — classificatie, extractie en eenvoudige opmaaktaken presteren vaak acceptabel op een kleiner, goedkoper model, en modelroutering is een van de weinige margehefbomen die je volledig zelf in de hand hebt, in tegenstelling tot de prijsstelling van providers.

Prijsstelling om de marge die je zojuist vond te beschermen​

Zodra inferentie correct als COGS is geclassificeerd, verandert je prijsgesprek. Een veelgebruikt anker onder operators is prijzen op ruwweg 3–5x de kost per eenheid token, zodat een taak van $0.30 wordt geprijsd op $1.00 of meer — niet omdat die factor magisch is, maar omdat het ruimte laat om gebruiksvariatie, volatiliteit in modelprijzen en de support- en infrastructuurkosten die naast de ruwe inferentie meelopen, op te vangen.

Gebruiksgebaseerde facturering is de standaardmanier geworden waarop AI-bedrijven prijsstelling en COGS gelijk laten oplopen: reken per token, per verzoek of per voltooide taak, en je omzet schaalt mee met dezelfde variabele die je kosten aandrijft, in plaats van ervan af te drijven zoals een vast abonnement doet zodra het gebruik piekt. Als je nog niet klaar bent om volledig over te stappen op gebruiksgebaseerde prijsstelling, bouw dan op zijn minst tiers met een verplicht minimum plus overage, zodat een klant die het typische gebruik ver overschrijdt niet stilletjes een verlieslijdend product wordt voor de rest van de maand.

Houd je kostenstructuur even controleerbaar als je code​

Niets hiervan is optionele boekhoudkundige hygiëne — het is het verschil tussen weten dat je businessmodel werkt en er tijdens een due-diligencegesprek voor een fondsenwerving achter komen dat het niet werkt, wanneer een medewerker van een investeerder het kostenmodel per klant bouwt dat jij zes maanden eerder had moeten bouwen. De oprichters die dat gesprek vermijden, zijn degenen die vanaf de allereerste API-aanroep inferentiekosten koppelen aan klanten en features, niet degenen die wachten tot de OpenAI-factuur te groot is om te negeren.

Beancount.io biedt je plain-text, versiebeheerde boekhouding waarmee je moeiteloos inferentie-uitgaven aan de juiste rekening koppelt, productie- van ontwikkel-API-gebruik scheidt en je werkelijke COGS elke maand tegen de omzet afstemt — geen black-box-categorisatie, geen vendor lock-in. Begin gratis en ontdek waarom developers en AI-native oprichters overstappen op plain-text boekhouding.