Facturatie naar gebruik is niet nieuw, maar kunstmatige intelligentie (AI)-producten hebben dit naar een punt gedreven waarop standaardprocessen niet langer volstaan. Tokenvariabiliteit, agentloops die zich uitbreiden naar honderden downstream-aanroepen, en workloads die binnen enkele minuten kunnen pieken, zorgen voor technische problemen op het gebied van gebeurtenisattributie, meetnauwkeurigheid en kostenbeheersing die traditionele Application Programming Interface (API) facturatie nooit hoefde op te lossen. Sterker nog, 46% van de IT-leiders zegt dat onvoorspelbare tarieven een belangrijke barrière vormen voor de implementatie van generatieve AI binnen hun organisatie.

Hieronder bespreken we hoe je facturatie naar gebruik voor AI-diensten implementeert, hoe je onbewerkte gebeurtenissen omzet in duidelijke factureerbare totalen, en hoe je vangrails toevoegt die uit de hand lopende kosten opvangen voordat ze tot factuurgeschillen leiden.

Hoogtepunten

• Het contract voor gebruiksgebeurtenissen vormt de basis voor alles wat daarna komt. Schemabeslissingen die je vroeg neemt, kunnen bepalen hoeveel moeite je zult hebben als tarieven veranderen of geschillen moeten worden opgelost.

• Ontdubbeling, beleid voor late gebeurtenissen, correcties en regelversiebeheer onderscheiden een systeem dat betrouwbare facturen produceert van een systeem dat uiteindelijk iets dubbel telt. Determinisme en idempotentie zijn geen optie.

• Kostenbeheersing moet in de uitvoeringslaag worden ingebouwd. Kredietreserveringen, circuitbreakers voor agentloops en anomaliedetectie moeten worden geactiveerd voordat er gebruik wordt gegenereerd.

Wat is facturatie naar gebruik voor AI-bedrijven?

Bij facturatie naar gebruik betalen klanten naar rato van wat ze verbruiken (bijv. verwerkte tokens, rekenseconden, API-aanroepen, acties van agents) in plaats van een vast bedrag.

Het model is flexibel omdat de kosten van inferentie per klant enorm kunnen verschillen. Een vast tarief subsidieert intensieve gebruikers of jaagt minder intensieve gebruikers weg. Gebruiksgebaseerde tarieven vereisen een pijplijn die gebruiksgebeurtenissen kan genereren, deze betrouwbaar kan verwerken, correct kan meten en omzetten in facturen, vaak bijna in realtime.

Hoe werkt facturatie naar gebruik voor AI-bedrijven?

Op hoog niveau gaat het systeem van een factureerbare actie in je product naar een factuurregel van een klant. Elke fase kent zijn eigen risico’s, die elkaar versterken als ze niet goed zijn ontworpen.

Dit zijn de fasen en hoe ze werken:

• Verzenden: je applicatie genereert een gebruiksgebeurtenis telkens wanneer er een factureerbare actie plaatsvindt: een voltooiing, een integratieverzoek, een tool-agent of een agent-stap.

• Invoer: de gebeurtenis stroomt door een pijplijn die deze valideert, buffert en duurzaam opslaat. De pijplijn moet in staat zijn om verkeer op te vangen zonder records te verliezen of in kwaliteit achteruit te gaan.

• Meten: onbewerkte gebeurtenissen worden over facturatieperiodes samengevoegd tot factureerbare hoeveelheden. Deze laag past consequent eenheidsdefinities, tarieven en aggregatieregels toe.

• Factuur: de gemeten totalen worden doorgegeven aan je systeem voor facturatie, dat factuurregels genereert, tegoeden of kortingen toepast en de klant factureert.

Elke laag moet op zichzelf kloppen. Je wilt geen opnameprobleem ontdekken als je weken later een omzetverschil ziet.

Welke AI-specifieke gedragingen maken facturatie naar gebruik moeilijker te implementeren?

Traditionele API’s gaan uit van een eenvoudige koppeling: één verzoek levert één reactie en één factureerbare gebeurtenis op. AI-workloads gedragen zich niet zo.

Dit is wat AI-specifiek gedrag moeilijker te implementeren maakt voor facturatie naar gebruik:

Agent-loops en fan-out bij het aanroepen van tools

Eén gebruikersactie (bijv. “onderzoek dit onderwerp en stel een rapport op”) kan tientallen of honderden aanroepen van grote taalmodellen (LLM), tool-aanroepen en opvraagstappen activeren. Toewijzing wordt al snel ingewikkeld. Welke acties zijn factureerbaar? Wie betaalt er als één agentsessie meerdere gebruikers, projecten of tenants omvat? Als dit niet op het niveau van het gebeurtenisschema is gedefinieerd, kan het later moeilijker worden om dit te corrigeren.

Variabiliteit van tokens

Input- en output-tokens verschillen in kosten en zijn niet vooraf voorspelbaar. Een verzoek met een prompt van 200 tokens kan 50 tokens of enkele duizenden opleveren, afhankelijk van de taak, modelinstellingen en het generatiegedrag. Je kunt niet vooraf factureren op basis van de grootte van het verzoek. Je moet na uitvoering gebeurtenissen verzenden met de werkelijke aantallen.

Ongelijkmatige werkbelastingen

Een batchtaak van een onderneming om 2 uur 's nachts kan in een paar uur meer gebruik genereren dan in de afgelopen twee weken samen. Ingestiesystemen moeten deze pieken aankunnen zonder gebeurtenissen te laten vallen, achterop te raken of de facturatie te vertragen.

Niet-deterministische kosten

Dezelfde prompt kan bij verschillende runs verschillende aantallen tokens opleveren, vooral bij streaming, het aanroepen van functies of agentketens. Dit maakt deterministisch testen moeilijk en vereist meetlogica die vanaf het begin is ontworpen om variatie te tolereren.

Niet-deterministische kosten

Dezelfde prompt kan bij verschillende runs verschillende aantallen tokens opleveren, vooral bij streaming, functieaanroepen of agentketens.

Hoe ziet een betrouwbaar contract voor gebruiksgebeurtenissen eruit voor AI-bedrijven?

De gebruiksgebeurtenis is de basisbouwsteen van je facturatie-systeem. Elk downstream-systeem – van meting tot facturering tot controle – is afhankelijk van een stabiel en expliciet gebeurteniscontract.

Zo ziet een betrouwbaar contract voor gebruiksgebeurtenissen eruit:

• Klant- en project-ID's: stabiele, onveranderlijke ID's die niet veranderen wanneer een klant zijn organisatie hernoemt of zijn accounthiërarchie herstructureert.

• Tijdstempel van de actie: wanneer de actie plaatsvond, niet wanneer de gebeurtenis werd verzonden. Asynchrone pijplijnen kunnen vertragingen veroorzaken die van belang zijn voor de toewijzing aan een periode.

• Eenheid en hoeveelheid: wat je meet (bijv. input tokens, output tokens en rekenseconden) en hoeveel. Houd eenheden atomair, tenzij je tarieven ze identiek behandelen.

• Correlatie-ID: een unieke identificatie die een gebruiksgebeurtenis koppelt aan het oorspronkelijke verzoek, de sessie of de agentrun. Hiermee kun je een factuurregel terugvolgen naar de applicatielogboeken.

• Factureerbare vlag en redencode: niet elke actie is factureerbaar. Maak de beslissing over de facturatie expliciet in de gebeurtenis in plaats van deze te verbergen in downstream-logica, waar deze moeilijker te controleren is.

• Schema-versie: wanneer je tarieven veranderen, moeten oude en nieuwe gebeurtenissen naast elkaar bestaan. Versiebeheer maakt dat mogelijk.

Hoe moeten AI-bedrijven opname en opslag ontwerpen voor facturatie naar gebruik?

Twee vereisten domineren deze laag: betrouwbaarheid en onveranderlijkheid. Al het andere (doorvoer, latentie, schemavalidatie) dient deze doelen.

Zo moeten AI-bedrijven de opname en opslag ontwerpen:

Betrouwbaarheid

Schrijf naar een duurzaam wachtrijsysteem met “at-least-once delivery”-semantiek. De wachtrij beschermt je tegen tijdelijke storingen; downstreamklanten zorgen voor de ontdubbeling. Schrijf gebruiksgebeurtenissen niet rechtstreeks vanuit je applicatie naar een database.

Zorg ervoor dat verplichte velden aanwezig zijn, identificatiegegevens correct worden omgezet en tijdstempels aannemelijk zijn. Weiger slecht gevormde gebeurtenissen in een vroeg stadium met duidelijke foutmeldingen, in plaats van slechte gegevens in de meting te laten lekken.

Ontwerp expliciet voor pieken. Onvoldoende ingangscapaciteit leidt meestal tot mislukkingen door verloren gegane gebeurtenissen.

Onveranderlijkheid

Je opslag voor onbewerkte gebeurtenissen moet alleen-toevoegen zijn. Dit betekent dat hoewel nieuwe gegevens kunnen worden toegevoegd (aangehecht) aan het einde van een bestand of database, bestaande gegevens onveranderlijk blijven (ze kunnen niet worden gewijzigd of verwijderd). Als er fouten gebeuren, zoals een verkeerd berekend aantal tokens of een verkeerd toegewezen klant, stuur dan een correctiegebeurtenis die naar het origineel verwijst in plaats van het bronrecord te bewerken. Dit is onontbeerlijk voor geschillenbeslechting. Als een klant een rekening betwist, moet je de exacte reeks gebeurtenissen die dat bedrag hebben opgeleverd, kunnen terugspelen.

Hoe zetten AI-bedrijven onbewerkte gebruiksgebeurtenissen om in nauwkeurige factureerbare roll-ups?

Bij meting is nauwkeurigheid essentieel. Bij dezelfde invoergebeurtenissen en regels moet de uitvoer altijd hetzelfde zijn.

Vier eigenschappen maken dat mogelijk:

• Ontdubbeling en idempotentie: “at-least-once delivery” garandeert duplicaten. Deze idempotentie (waarbij de output van een bewerking altijd hetzelfde resultaat oplevert) betekent dat elke gebeurtenis een unieke ID nodig heeft, en dat bij het samenvoegen eerst ontdubbeling moet plaatsvinden voordat er geteld wordt. Zonder dit is de kans op dubbele facturatie veel groter.

• Afhandeling van late gebeurtenissen: gebeurtenissen komen niet op volgorde binnen. Stel een duidelijk beleid op: sluit een facturatieperiode X minuten na de deadline af, accepteer late gebeurtenissen tot aan die deadline en markeer of weiger alles wat daarna komt. Consistentie is belangrijk.

• Correctiegebeurtenissen: wanneer er fouten aan het licht komen, stuur dan correctiegebeurtenissen die de totalen aanpassen, verwijs naar de oorspronkelijke gebeurtenis en leg uit waarom de wijziging plaatsvond. Herschrijf geen historische aggregaten.

• Versiebeheer van regels: tariefregels kunnen veranderen, maar gebeurtenissen moeten worden gemeten volgens de regels die golden op het moment dat ze plaatsvonden. Als je de huidige regels toepast op het verbruik van het afgelopen kwartaal, leidt dat tot onjuiste facturen.

Tools zoals Stripe Billing regelen de aggregatie aan de factuurkant, maar je interne meetlaag moet zelfstandig zijn eigen roll-ups genereren. Deze vormen je bron van waarheid voor reconciliatie.

Hoe gebruiken AI-bedrijven vangrails voor kostenbeheersing?

AI-workloads kunnen sneller uitgaven genereren (van jou en je klanten) dan een mens kan ingrijpen. Vangrails moeten in realtime werken.

Zo gebruiken AI-bedrijven ze om uit de hand lopende kosten te voorkomen:

Kredietrekeningen en reserveringen

Reserveer de verwachte kosten op het saldo van de klant voordat je een actie uitvoert die gebruik genereert. Als de reservering mislukt, voer de actie dan niet uit. Na uitvoering verreken je met het daadwerkelijke gebruik. Dit lijkt op de preautorisatie van een creditcard en is het juiste mentale model voor AI-facturatie.

Zachte en harde limieten

Harde limieten stoppen het gebruik direct. Zachte limieten geven waarschuwingen af als drempels worden benaderd. Beide moeten per klant en per project configureerbaar zijn. Productieworkloads en proefaccounts hebben verschillende toleranties.

Circuitbreakers voor agent-workloads

Agenten hebben speciale behandeling nodig. Stel maximale stapaantallen, maximale uitgaven per sessie en geautomatiseerde kill-switches in. Handhaaf deze op het moment van uitvoering, niet na de facturatie. Zodra de facturatie de gebeurtenis ziet, zijn de kosten al gemaakt.

Detectie van afwijkingen

Houd de gebruiksintensiteit per klant bij en markeer afwijkingen boven een bepaalde drempel (bijvoorbeeld $ 0,1 per eenheid). Automatisch pauzeren met een menselijke controlewachtrij is vaak de juiste reactie. Het doel is om op hol geslagen processen op te vangen voordat ze uitmonden in geschillen of verrassingen in de kostprijs van verkochte goederen (COGS).

Hoe Stripe Billing je kan helpen

Met Stripe Billing kun je klanten factureren en beheren zoals jij dat wilt, van eenvoudige terugkerende facturatie tot facturatie naar gebruik en contracten die tijdens de verkoop zijn onderhandeld. Begin binnen enkele minuten met het ontvangen van terugkerende betalingen wereldwijd, zonder dat je daarvoor code nodig hebt, of bouw een aangepaste integratie met behulp van de API.

Stripe Billing kan je helpen:

• Flexibele prijzen aan te bieden: sneller reageren op de vraag van gebruikers met flexibele tariefmodellen, waaronder op gebruik gebaseerde, gestaffelde, flat-fee plus overage, en meer. Ondersteuning voor coupons, gratis proefperiodes, evenredige verdeling en add-ons is ingebouwd.

• Wereldwijd uit te breiden: verhoog de conversie door de betaalmethoden aan te bieden die klanten het liefst gebruiken. Stripe ondersteunt meer dan 100 lokale betaalmethoden en meer dan 130 valuta's.

• Je omzet te verhogen en klantverloop te verminderen: verbeter je omzet en verminder onvrijwillig klantverloop met Smart Retries en geautomatiseerde herstelworkflows. Met de hersteltools van Stripe hebben gebruikers in 2024 meer dan $ 6,5 miljard aan omzet teruggewonnen.

• Je efficiëntie te verhogen: gebruik de modulaire tools van Stripe voor belastingen, omzetrapportage en gegevens om meerdere omzetsystemen te consolideren tot één systeem. Eenvoudige integratie met software van derden.

Lees meer over Stripe Billing of ga vandaag nog aan de slag.