AI-API-gebruik factureren: Stripe Billing of Metronome

De API geeft 200 terug, maar één time-out kan dezelfde AI-run nog een keer naar je meter sturen. Als die tweede levering je klantfactuur verhoogt, zit je probleem niet in je tarief maar in de grens tussen gebruikslog en factuur.

De facturering voor ingeschakelde OpenAI Dots begint op 18 november 2026. De openbare documentatie noemt nog geen tarieven, en Dots-kosten zijn de rekening voor OpenAI’s eigen product, niet de factuur die een AI-aanbieder aan zijn klanten stuurt. OpenAI zet de Dots-facturering op 18 november en publiceert nog geen tarieven; de huidige helptekst bevestigt de datum maar noemt geen bedragen.

Verbruiksfacturatie zet meetbare productactiviteit om in een contractueel bedrag per klant. Een event telt pas mee nadat het aan de juiste klant, periode, eenheid en tariefversie is gekoppeld. De factuur is de eindweergave van die berekening. Je bronledger bewaart wat werkelijk is gebeurd en waarom het bedrag klopt.

De prijsmaat verschuift ook wie risico draagt: bij resultaatprijzen bepaalt de definitie van de meeteenheid wie de marge houdt. Bij gebruik geldt hetzelfde; het contract moet zeggen welke actie telt.

Voor een nieuwe Stripe-gebaseerde integratie raadt Stripe Metronome als startpunt aan. Stripe blijft bestaande Basic Meter-integraties ondersteunen; een bestaande route hoeft niet te migreren zolang hij de prijsregels aankan. De keuze draait dus om meer dan eventvolume: ook credits, contracten, datalocatie en de export naar de financiële administratie bepalen waar de grens ligt.

Wat je nodig hebt: AI-gebruik uitlegbaar maken

Leg dit klaar voordat je een meter of tariefkaart aanmaakt:

• Een ondertekend prijsbesluit. Noteer per klant wat een factureerbare eenheid is, wanneer die ontstaat, hoe afronding werkt, welke valuta geldt, hoe gratis gebruik of credits worden verrekend en wat met mislukte of opnieuw uitgevoerde verzoeken gebeurt. Dezelfde term moet op je prijspagina, in je contract en op de factuur staan.
• Een gebruiksbron die je zelf kunt teruglezen. Bewaar per afgeronde actie de interne klant-ID, event-ID, tijdstip, eenheid, hoeveelheid, prijsversie en verwerkingsstatus. Een leveranciersdashboard is een controlebron, geen vervanging voor je eigen logboek.
• Een stabiele klantkoppeling. Kies één interne account-ID en leg de relatie met Stripe Customer ID of Metronome customer vast. E-mailadressen veranderen en zijn geen veilige financiële sleutel. Als je meerdere Stripe-accounts gebruikt, leg ook vast naar welk account een factuur hoort.
• Een afleverbuffer met herhaalbare opdrachten. Een database-outbox of berichtwachtrij bewaart events die nog niet zijn afgeleverd. Je hebt een foutwachtrij nodig voor ongeldige payloads en een herstelpad waarmee een medewerker ziet of een event al is verwerkt.
• Een testomgeving met echte uitzonderingen. Neem een normale aanvraag, een herhaalpoging, een mislukte aanvraag, een late event, een klantwijziging en een gedeeltelijke correctie op. Een test met alleen keurige maandtotalen bewijst niets over dubbele leveringen.
• Twee benoemde eigenaren. Product of engineering bepaalt wat het productgebruik betekent. Finance bepaalt welke periode, btw-behandeling, grootboekrekening en correctieroute bij de factuur horen. Laat één persoon niet tegelijk de regel wijzigen en de financiële uitzondering vrijgeven.
• Een besluit over dataopslag. Bepaal of eventvelden naar een SaaS-meter mogen, welke regio voor verwerking en back-ups vereist is en of prompts of klantinhoud buiten je eigen omgeving moeten blijven. Voor facturatie is doorgaans de hoeveelheid nodig, niet de prompt.
• Een maandbudget met drie regels. Zet de softwareprijs, eventkosten en betalingskosten apart. Vraag bij een offerte ook naar jaarlijkse platformkosten, exportkosten, volumeafspraken en kosten voor historische import. Metronome en Stripe publiceren verschillende prijscomponenten, niet één totaalbedrag.

Een event is de regel die jouw product echt heeft geleverd. Een factuurregel is wat het contract voor die regel vraagt. Houd die twee apart: een correctie op een factuur mag je bronlog niet achteraf herschrijven.

Concrete stappen: van API-event naar controleerbare factuur

Volg één productactie door de keten voordat je een hele catalogus aan tarieven toevoegt.

1. Kies de eenheid die de klant begrijpt

Kies eerst wat de klant betaalt. Voor een AI-API kan dat een request, verwerkt document, minuut audio, succesvolle workflow of tokenvolume zijn. Een request is eenvoudig uit te leggen, maar kan heel verschillende kosten verbergen. Input- en outputtokens zijn controleerbaar, maar de meeste klanten willen weten welke taak ze kochten en hoeveel daarvan is uitgevoerd.

Schrijf de regel als een formule, bijvoorbeeld: bedrag = basisfee + inputtokens × tarief + outputtokens × tarief. Definieer ook of een afgebroken request telt, of een herstart de oorspronkelijke run vervangt en of je afrondt per event, per dag of per factuurperiode. Sla het tarief op als een versie met een ingangsdatum. Een prijswijziging op 1 november mag een oktober-event niet stilzwijgend opnieuw prijzen.

Controle: Support kan aan een klant uitleggen welke eenheid op de factuur staat en welk productresultaat die eenheid vertegenwoordigt.

2. Maak één canoniek event voordat je een leverancier kiest

Bouw een event uit de gegevens die je product zelf vastlegt. Metronome verwacht voor /ingest onder meer transaction_id, customer_id, timestamp, event_type en optioneel properties. De waarden in properties stuur je als strings, ook wanneer het aantallen zijn. Dat voorkomt verlies van precisie bij decimale waarden. Gebruik alleen velden die nodig zijn voor tariefberekening, controle en uitleg aan de klant. Metronome adviseert extra dimensies die later nodig kunnen zijn al in het event mee te geven, omdat nieuwe factureerbare metrieken niet retroactief op oude data werken.

Een voorbeeld voor een succesvol verzoek:

{
  "transaction_id": "run_20261024_14321",
  "customer_id": "cus_demo_2041",
  "timestamp": "2026-10-24T14:03:21Z",
  "event_type": "llm_request.completed",
  "properties": {
    "input_tokens": "150000",
    "output_tokens": "20000",
    "model_family": "reasoning",
    "price_version": "ratecard_nl_2026-10-01"
  }
}

Stuur geen prompttekst mee om een tokenmeter te laten werken. Houd de interne account-ID in je eigen bron en gebruik voor de leverancier een stabiele, niet-betekenisvolle klant-ID of ingest alias. De klantnaam en het factuuradres horen thuis in je klant- en facturatiesysteem.

Controle: je kunt vanuit één event de oorspronkelijke productactie, klant, periode en tariefversie terugvinden, zonder klantinhoud naar de meter te sturen.

3. Schrijf eerst naar je ledger en lever daarna af

Schrijf de succesvolle productactie en het meter-event in dezelfde duurzame transactie of via een outbox-patroon. De API-aanvraag mag niet afhangen van een live antwoord van je facturatieprovider. Zet de event-ID vast voordat je naar buiten belt. Bij een timeout herhaal je dezelfde opdracht met dezelfde transaction_id, niet een nieuwe.

Metronome negeert een tweede event met dezelfde transaction_id gedurende 34 dagen nadat de eerste levering is geaccepteerd. Dat helpt bij een herhaalpoging, maar jouw eigen sleutel blijft leidend. Na die 34 dagen kan een oude replay anders worden behandeld. Stripe Basic Billing verwerkt meter-events asynchroon en een recente meter-samenvatting hoeft daardoor niet meteen alle net ontvangen events te tonen. Behandel een HTTP 429 als een rate limit die begrensde backoff en herstelbare retries vraagt; overige 4xx-fouten gaan naar een foutwachtrij. Stripe waarschuwt dat basic meter-samenvattingen vertraagd kunnen bijwerken.

Controle: lever dezelfde testbatch vijf keer opnieuw af. Het aantal unieke events en de factuur veranderen geen enkele keer.

4. Maak de meter en de klantrelatie expliciet

Maak in Metronome factureerbare metrieken voor de velden waar je echt op factureert, bijvoorbeeld de som van inputtokens en de som van outputtokens. Bewaar model, regio, accounttype of project als aanvullende dimensies wanneer je later per klant een bruikbare uitsplitsing nodig hebt. Metronome ondersteunt onder meer SUM, COUNT, MAX en UNIQUE. Kies niet voor UNIQUE als een klant per uitgevoerde taak betaalt en één taak meerdere regels kan opleveren.

Voor bestaande Stripe Billing Meters hoef je deze route niet opnieuw te bouwen. Stripe ondersteunt de basic-meterroute voor bestaande integraties. Het huidige vergelijkingsdocument markeert die route wel als beperkt voor hoge eventvolumes en noemt geen harde numerieke grens. Stripe plaatst Metronome als het startpunt voor nieuwe integraties en noemt credits, commits, ramps, multidimensionale prijzen en realtime inzicht als redenen om het te gebruiken.

Controle: laat één klantperiode in de meter zien en vergelijk per metric de som met je eigen ledger. Eén ontbrekende eigenschap of onverwachte metric is reden om te stoppen.

5. Koppel klant, contract en tariefversie

Maak de klant eerst in je eigen productdatabase. Koppel die daarna aan een Metronome customer en Stripe Customer. Metronome kan ingest aliases gebruiken, zodat events al aankomen wanneer de billing-klant nog asynchroon wordt aangemaakt. Maak vervolgens een contract voor de klant met het juiste product, de tariefkaart, valuta, startdatum, factuurfrequentie en eventuele credits, commit of meerverbruik. Leg de interne account-ID en Customer-ID ook vast in je Stripe-koppeling, zodat een verbruiksfactuur nooit aan een tweede klantrecord wordt gehangen.

Heb je al een vaste basisprijs of licentieprijs per gebruiker in Stripe Subscriptions, dan kan Metronome de verbruik naast die bestaande facturatie afhandelen. Beide systemen maken dan facturen op dezelfde Stripe Customer. De klant ontvangt dus een abonnementsfactuur en een aparte verbruiksfactuur. Gebruik je Metronome zelfstandig, dan stuurt het de verbruiksfactuur naar Stripe Invoicing voor betaling. Stripe verzorgt de betaling, btw en omzetverantwoording; Metronome stuurt definitieve facturen naar Stripe en volgt de betaalstatus terug.

Controle: zoek met een interne account-ID de juiste Stripe Customer, Metronome customer, contract, tariefversie en factuurfrequentie op.

6. Laat de eerste facturen als concept staan

Maak een sandboxproef met ten minste twee klanten en een volledige factuurperiode. Laat de meter op nul beginnen, stuur de eventset, maak de conceptfactuur en controleer per regel: eenheid, hoeveelheid, tarief, korting, credit, valuta en periode. Controleer ook afronding. Een maandtarief met tokens kan na afronding per regel een ander totaal geven dan afronding per event.

Als Metronome facturen naar Stripe stuurt, kan de koppeling facturen standaard automatisch laten doorgaan. Zet in Metronome bij de Stripe-integratie Leave invoices as drafts aan zolang de financiële administratie iedere nieuwe prijsregel moet controleren. Bewaar op de Stripe Invoice ook het Metronome-invoice-ID. De integratie zet standaard metronome_id-metadata; dat maakt de factuur terugvindbaar. Stripe zegt dat Metronome nieuwe verbruiksfacturen kan laten controleren voordat Stripe ze finaliseert.

Controle: op een conceptfactuur kan Finance elke regel narekenen zonder de eventbron of tariefversie op te vragen bij Engineering.

7. Sluit bronledger, meter en export op dezelfde sleutel

Maak vóór vrijgave drie totalen per klant, metric en serviceperiode: wat het product logde, wat de meter aggregeerde en wat op de conceptfactuur staat. De eerste vergelijking is in hoeveelheid, de tweede in geld. Bewaar per bedrag de contractversie en eventuele credit, zodat je een verschil kunt lokaliseren in event, metric of tarief.

Metronome Data Export schrijft naar een warehouse, database of objectopslag. Volgens de actuele docs wordt data minstens dagelijks bijgewerkt, afhankelijk van de tabel. Objectopslag werkt append-only met at-least-once levering. Updates kunnen dus als herhaalde rijen verschijnen. Pak de meest recente rij per primaire sleutel, anders tel je een wijziging als een nieuw record. Metronome Data Export wordt minstens dagelijks vernieuwd en kan in objectopslag herhaalde primaire sleutels bevatten.

Stripe Data Pipeline en Sigma zien Stripe-facturen, betalingen en charges, maar niet automatisch Metronome-events, contractstatus of credit-ledgers. Die gegevens vragen een aparte export. Stripe scheidt de export van Metronome-events, contracten en credits van zijn eigen data-export.

Controle: de ledger-totalen en meter-totalen zijn gelijk per klant, metric en periode. Een exportbestand is een rapportagekopie, geen tweede gebruiksbron.

8. Houd correcties zichtbaar voor en na finalisatie

Komt een fout vóór finalisatie boven water, corrigeer dan de conceptfactuur. Bij een verkeerd gebruiks-event kan Metronome binnen het open factuurmoment een compenserend event verwerken dat de oorspronkelijke metrichoeveelheid opheft. Geef dat event een eigen ID en leg de oorspronkelijke event-ID, reden en vrijgever vast. Daarna stuur je de juiste hoeveelheid opnieuw en controleer je de conceptfactuur vanaf nul.

Na finalisatie is de factuur onveranderlijk. Voor een beperkte historische fout in gebruiksdata kun je een credit op een volgende factuur zetten of een creditnota in je debiteuren- of ERP-systeem maken. Metronome maakt zelf geen gebruikelijke ERP-creditnota. Een hele verkeerde factuur voiden en opnieuw genereren kan, maar de Stripe-factuur moet je downstream ook corrigeren. Een gefinaliseerde factuur is onveranderlijk, al kun je een foutieve factuur voiden en opnieuw genereren. Bij een eerdere periode hangt de correctie af van de gekozen creditmemo-route.

Controle: iedere correctie heeft een reden, verwijst naar de oorspronkelijke gebruiksregel of factuur en blijft zichtbaar in de klantfactuur en het ledger.

9. Zet pas automatisch vrij na een koperstest

Test de route met een representatieve maand, een piekbatch en herhaalde events. Een testdoel is geen leverancierlimiet. Gebruik bijvoorbeeld tien keer je hoogste gemeten kwartierpiek als interne belastingproef, en vraag de leverancier om de limiet en foutrespons schriftelijk te bevestigen. De bronpagina’s geven geen getal waarmee je veilig een harde eventgrens kunt aannemen.

Maak de vrijgaveregel hard: geen ontbrekende transaction_id, geen onverklaarde hoeveelheid, geen onbekend tarief en nul verschil tussen meterberekening en conceptfactuur. Wijs een Finance-eigenaar aan die kan publiceren, en een Engineer die het eventpad kan herstellen. Een eventvolume dat je niet op piekbelasting hebt getest, blijft eerst in concept.

Controle: een collega die de integratie niet bouwde, kan één regel van productevent naar conceptfactuur en terug reconstrueren. De eerste factuurperiode blijft handmatig controleerbaar.

Valkuilen: waar verbruiksfacturen ontsporen

Een provider-token wordt stilzwijgend jouw factuureenheid

Een modelprovider kan input- en outputtokens met verschillende tarieven tellen. Dat maakt tokens geschikt om je eigen kostprijs te controleren, maar niet automatisch om klantwaarde uit te drukken. Een klant kan betalen voor een geslaagde extractie, terwijl jij intern tokens nodig hebt om de marges te begrijpen. Houd die twee administratiepaden gescheiden. Interne AI-agentkosten begrens je per virtuele sleutel met een budget en noodrem; jouw klantcontract bepaalt de verkoopmeter.

Een dubbele levering wordt een dubbele verkoop

Symptoom: een hogere eventhoeveelheid na een timeout, terwijl het product maar één taak afrondde. Oorzaak: je herhaalpoging kreeg een nieuw ID of je replay kwam na Metronomes 34-dagen deduplicatieperiode. Mitigatie: maak de sleutel in je eigen ledger, hergebruik hem bij iedere herhaalpoging en controleer vóór een oude replay welke events de leverancier al accepteerde. Een provider-API is geen volledige garantie tegen je eigen dubbele schrijfopdracht.

Een late event komt achter een definitieve factuur aan

Symptoom: je productlog toont gebruik dat niet op de verstuurde rekening staat. Oorzaak: verwerking van events na de ingestelde grace period of na factuurfinalisatie. Mitigatie: meet je vertraging tussen eventtijd en aflevering, kies een afsluitmoment op basis van die meting en laat de eerste maanden de factuur als concept staan. Metronome houdt Bulk Data Ingest op 7 november 2026 nog in private preview, verwerkt imports asynchroon en werkt definitieve facturen niet automatisch bij.

Een metric gebruikt informatie die je niet hebt vastgelegd

Symptoom: Finance vraagt later om een uitsplitsing per model, regio of project, maar oude events hebben dat veld niet. Oorzaak: de metric was alleen ontworpen voor de eerste prijskaart. Metronome kan een nieuwe factureerbare metric niet met terugwerkende kracht toepassen op historische eventstreams. Mitigatie: voeg vanaf dag één dimensies toe die je verantwoord kunt bewaren. Zet er nog geen prijs op tot je die nodig hebt.

Een klant krijgt twee facturen zonder dat je dat hebt afgesproken

Symptoom: een abonnementsregel staat op de Stripe-factuur en opnieuw op de verbruiksfactuur. Oorzaak: Stripe Subscriptions en Metronome maken ieder hun eigen factuur. Mitigatie: laat Stripe de vaste basisfee of licentieprijs per gebruiker houden en Metronome alleen de afgesproken variabele metric leveren. Als de klant één factuur verwacht, maak dat een acceptatiepunt in de demo. Een contract, factuur, betaalstatus en payout vragen ieder een eigen bron en status; deze gids stopt bij de verbruiksberekening tot en met de factuur.

Een dagelijkse export wordt aangezien voor een live teller

Symptoom: je dashboard loopt achter of telt bijgewerkte regels dubbel. Oorzaak: exporttabellen verversen minstens dagelijks en objectopslag levert append-only met at-least-once semantiek. Mitigatie: gebruik de event-API of productledger voor actuele klantlimieten, en maak van de export een reconciliatiefeed. Dedupliceer exportregels op primaire sleutel en neem de laatste wijziging.

Een correctie verandert de leverancierfactuur maar niet de debiteurenadministratie

Symptoom: Metronome toont een gecorrigeerde factuur, maar Stripe of het ERP nog de oorspronkelijke verkoop. Oorzaak: Metronome en Stripe synchroniseren in die richting niet alle invoice-data terug. Mitigatie: behandel correctie als twee gekoppelde handelingen. Bewaar beide IDs, maak de creditnota of void ook in het debiteurensysteem en controleer de uiteindelijke klantbalans. Stripe-fees en payoutregels sluiten pas aan op de boekhouding als je ze per transactie matcht.

Beslis-kader: welke route past bij je schaal en eisen?

Kies de kleinste route die je prijsmodel én de afwijkingen kan dragen. Een laag eventaantal maakt een ingewikkeld tarief niet eenvoudiger. Een eenvoudig tarief wordt niet automatisch een enterprisevraagstuk omdat je veel events hebt. Stripe tekende in december 2025 een overeenkomst om Metronome over te nemen en voltooide de overname op 14 januari 2026. Dat maakt de eigenaarsrelatie relevant voor je exitplan: bewaar eventledger, contractsleutels en exports buiten de factuurinterface.

Een bestaande Stripe Billing Meters-route behouden past als je die al in productie hebt, één of enkele eenvoudige metrics gebruikt, geen realtime bestedingsmeter nodig hebt en elke factuur volledig uit je brondata kunt verklaren. Stripe ondersteunt bestaande basic-meterintegraties. Migratie is niet verplicht. Houd bij groei het verschil tussen ontvangen, geaggregeerde en gefactureerde events in de gaten.

Metronome zelfstandig met Stripe Invoicing past als dit een nieuwe Stripe-gebaseerde integratie voor facturatie naar gebruik is of als je credits, commits, ramps, meerdere dimensies of actuele bestedingsinzage nodig hebt. Stripe documenteert Metronome als startpunt voor nieuwe integraties. Metronome gebruikt gebruiksdata, tariefberekening en contracten voor de meterlaag; Stripe neemt betalingsinning, btw en omzetverantwoording over. Metronome Data Export blijft wel apart nodig voor events, contracten en credit-ledgers.

Metronome naast bestaande Stripe Subscriptions past als je bestaande basisprijs of licentieprijs per gebruiker al betrouwbaar loopt en je alleen verbruik toevoegt. Dit is een uitbreiding, geen migratie van de subscription. Spreek vooraf af of twee facturen acceptabel zijn. Gebruik een aparte productregel en eigen serviceperiode, zodat vaste en variabele prijs niet dubbel lopen.

Lago Cloud of self-hosted past als een harde eis voorschrijft waar het facturatieplatform draait en je de inzet zelf wilt beheren. Lago biedt Cloud en self-hosted deployment, waaronder in je eigen datacenter of VPC. De huidige prijspagina publiceert geen bedrag en noemt exportvolumes en meerdere facturatie-entiteiten als mogelijk begrensde onderdelen. Laat vóór keuze de regio van verwerking en back-ups, ondersteuningstoegang, exportvorm, contract en capaciteit bevestigen. Zelf hosten geeft je locatiecontrole, maar maakt beschikbaarheid en upgrades jouw werk.

Hanteer drie meetbare stopregels:

1. Geld: als je een eventvolume rond 1.000.000 per maand verwacht, is Metronomes gepubliceerde eventcomponent bij 0,04 dollar per 1.000 events ongeveer 40 dollar per maand. Die eventcomponent is even groot als 0,8% van 5.000 dollar verbruiksomzet. Boven die factuuromzet domineert in deze berekening het percentage; eronder weegt eventvolume zwaarder. Dit is vóór jaarlijkse platformkosten, betaling, btw en export.
2. Foutmarge: accepteer vóór automatische finalisatie nul onverklaarde events en nul bedragverschil tussen je meter en conceptfactuur. Als er één verschil blijft staan, blijft de factuur in concept tot iemand het verklaart.
3. Eigenaarschap: wijs minimaal één technische eigenaar en één financiële goedkeurder aan. Als één van die rollen ontbreekt, automatiseer dan eventaanvoer en preview, maar laat de factuur niet zonder menselijke vrijgave versturen.

Metronome publiceert Starter als 0,8% van billing volume plus 0,04 dollar per 1.000 ingest-events. De Nederlandse Stripe Billing-pagina noemt pay-as-you-go voor Billing op 0,7% van Billing-volume, exclusief eenmalige facturen. Dat is niet de volledige prijs van betaling verwerken. De Metronome-prijspagina zet datawarehouse-export op de Custom-route; de prijsdocumentatie noemt ook een mogelijke jaarlijkse platformfee. Controleer de orderbevestiging in plaats van het Starter-percentage als totaalprijs te behandelen. Stripe rekent voor Billing pay-as-you-go 0,7% van het Billing-volume, exclusief losse facturen; Metronome’s actuele Starter-tarieven zijn 0,8% en $0,04 per 1.000 events, terwijl de prijsdocumentatie platform- en verbruikskosten apart definieert.

Bij 1.000.000 events kost de eventcomponent $40. Bij $5.000 facturatie is ook 0,8% precies $40. Bij $50.000 facturatie is het percentage $400; met dezelfde miljoen events komt de gepubliceerde gebruiksprijs uit op $440. Deze berekening laat de verhouding zien, niet een offerte.

Uitgewerkt voorbeeld: een dubbel geleverd AI-event

Dit fictieve voorbeeld gebruikt een Nederlandse AI-API met de naam Raster AI. De klant krijgt een hybride prijs: €39 basis per maand, €0,90 per miljoen inputtokens en €3,60 per miljoen outputtokens. De prijsversie ratecard_nl_2026-10-01 geldt van 1 oktober 2026. De som hieronder is vóór btw, behalve waar de btw apart wordt toegevoegd.

In oktober staan 8.000 unieke afgeronde events in Raster AI’s eigen bronledger. Eén grote run bevat 150.000 inputtokens en 20.000 outputtokens. Een timeout zorgt dat het event voor die run twee keer naar de billing-provider gaat. De afleverlaag ziet dus 8.001 leveringen, maar de ledger bevat nog steeds 8.000 productacties.

De provider krijgt voor die run hetzelfde transaction_id bij beide leveringen. Hij telt de tweede levering niet mee. Na deduplicatie zijn de maandtotalen 12.400.000 inputtokens en 1.850.000 outputtokens. Dat zijn de totalen uit de ledger, niet de som van iedere binnengekomen POST.

De maandelijkse regelberekening is:

Voor dit fictieve binnenlandse rekenvoorbeeld berekent de facturatieomgeving 21% btw over €56,82. Dat is €11,93 na afronding. De conceptfactuur bedraagt daarmee €68,75 inclusief btw. In productie bepaalt de btw-configuratie het tarief en de behandeling per klant, product en land; neem een 21%-som niet blind over voor iedere exportmarkt.

Test ook wat er misgaat als de tweede levering ten onrechte meetelt. Dan zouden de metrics 12,55 miljoen inputtokens en 1,87 miljoen outputtokens zien. Bij dezelfde tariefregels worden de afgeronde verbruiksregels €11,30 en €6,73. Met de basisfee is het foutieve nettobedrag €57,03. De btw wordt €11,98 en de klant zou €69,01 betalen. Dat is €0,26 boven de juiste factuur.

De herstelhandeling is niet om de ledgerregel te wissen. Markeer de tweede aflevering als duplicate, bewaar de oorspronkelijke event-ID en laat de factuur opnieuw berekenen vanuit 8.000 unieke events. Vergelijk vóór finalisatie drie cijfers: 8.000 events in de ledger, 12.400.000 inputtokens en 1.850.000 outputtokens op de metrics, en €56,82 exclusief btw op het concept. Zodra de waarden gelijk zijn, kan Finance de conceptfactuur goedkeuren.

Als de fout pas na finalisatie ontdekt wordt, is dezelfde correctie geen edit op de oude factuur. Maak een creditnota of expliciete toekomstige credit in het gekozen debiteurensysteem. Koppel die aan de oorspronkelijke invoice-ID en bewaar waarom €0,26 aan te hoge bruto-facturatie is teruggedraaid. De bronlog voor verbruik blijft ongewijzigd; de correctie is een apart financieel record.

Vergelijkingstabel: welke route draagt jouw factuur echt?

Productdetails en openbare prijzen in deze tabel zijn gecontroleerd op 7 november 2026. Betalingsverwerking, btw, eventuele platformkosten, dataverwerking en bouwtijd komen waar van toepassing boven op de genoemde billingprijs.

Lago biedt Cloud en self-hosted deployment, maar publiceert geen maandbedrag.

Een variabel prijsmodel vraagt meer dan een teller. FTI Consulting publiceerde op 9 april 2026 een analyse op basis van een onderzoek uit 2025 onder 420 enterprise-softwarebedrijven. Die analyse noemt telemetry, voorspelbare metrics en financiële processen als voorwaarden voor een overstap naar facturatie naar verbruik. De bruikbare les is praktisch: kies een eenheid die de klant kan voorspellen en Finance kan terugrekenen.

Een AI-API factureren is uiteindelijk een belofte over wat een klant kocht, niet een kopie van wat jouw modelprovider rekende. Als één factuurregel niet terug te voeren is op een unieke productactie, een tariefversie en een expliciete correctie, is de meter nog niet klaar voor live facturatie.