Användningsbaserad fakturering är inte nytt, men produkter inom artificiell intelligens (AI) har drivit det till en punkt där standardprocesser inte längre räcker. Tokenvariationer, agentloopar som sprider sig i hundratals nedströmsanrop, och arbetsbelastningar som kan skjuta i höjden på några minuter skapar teknikproblem för händelseattribuering, mätningsnoggrannhet och kostnadsbegränsning som traditionell API-fakturering aldrig behövde lösa. Faktum är att 46 % av IT-chefer säger att oförutsägbar prissättning är ett primärt hinder för att implementera generativ AI i sina organisationer.

Nedan går vi igenom hur man implementerar användningsbaserad fakturering för AI-tjänster, hur man omvandlar rådatahändelser till tydliga fakturerbara summor, och hur man lägger till skyddsfunktioner som fångar upp skenande kostnader innan de blir fakturatvister.

Viktiga punkter

• Kontraktet för användningshändelser är grunden för allt nedströms. Schemabeslut som fattas tidigt kan avgöra hur svårt det blir när prismodeller ändras eller tvister behöver lösas.

• Deduplicering, policyer för sena händelser, korrigeringar och regelversionshantering skiljer ett system som producerar tillförlitliga fakturor från ett som så småningom dubbelräknar något. Determinism och idempotens är inte valfria.

• Kostnadsbegränsning måste byggas in i exekveringslagret. Kreditreservationer, kretsbrytare för agentloopar och avvikelsedetektering måste aktiveras innan användning genereras.

Vad är användningsbaserad fakturering för AI-företag?

Användningsbaserad fakturering debiterar kunder i proportion till vad de förbrukar (t.ex. bearbetade token, beräkningssekunder, API-anrop, agentåtgärder) i stället för en fast avgift.

Modellen är flexibel eftersom kostnaden för inferens kan variera med flera storleksordningar mellan kunder. Fast prissättning gynnar storförbrukare eller avskräcker mindre förbrukare. Användningsbaserad prissättning kräver en pipeline som kan utfärda användningshändelser, mata in dem tillförlitligt, mäta dem korrekt och omvandla dem till fakturor, ofta i nästan realtid.

Hur fungerar användningsbaserad fakturering för AI-företag?

På en hög nivå går systemet från en fakturerbar åtgärd i din produkt till en radpost på en kunds faktura. Varje steg har sina egna fellägen, vilka förvärras om de inte är väl utformade.

Här är stegen och hur de fungerar:

• Utfärda: Din applikation utfärdar en användningshändelse varje gång en fakturerbar åtgärd inträffar: ett slutförande, en inbäddningsbegäran, en verktygsagent eller ett agentsteg.

• Mata in: Händelsen flödar genom en pipeline som validerar den, buffrar den och lagrar den varaktigt. Pipelinen måste kunna absorbera trafik utan att tappa poster eller försämras.

• Mät: Råa händelser aggregeras till fakturerbara kvantiteter över faktureringsperioder. Detta lager tillämpar konsekvent enhetsdefinitioner, prissättningslogik och aggregeringsregler.

• Fakturera: Uppmätta summor skickas in i ditt faktureringssystem, som genererar fakturaradposter, tillämpar krediter eller rabatter och debiterar kunden.

Varje lager bör vara korrekt i sig. Du vill inte upptäcka ett problem med inmatningen när du ser en intäktsavvikelse flera veckor senare.

Vilka AI-specifika beteenden gör användningsbaserad fakturering svårare att driftsätta?

Traditionella API:er utgår från en enkel mappning: en begäran genererar ett svar och en fakturerbar händelse. AI-arbetsbelastningar beter sig inte på det sättet.

Här är vad som gör AI-specifika beteenden svårare att driftsätta för användningsbaserad fakturering:

Agentloopar och utspridning av verktygsanrop

En enskild användaråtgärd (t.ex. "forska om detta ämne och utarbeta en rapport") kan aktivera dussintals eller hundratals anrop till stora språkmodeller (LLM), verktygsanrop och hämtningssteg. Tillskrivningen blir snabbt komplicerad. Vilka åtgärder är fakturerbara? Vem debiteras när en enskild agentsession omfattar flera användare, projekt eller hyresgäster? Om det inte definieras på händelseschemanivå kan det bli svårare att åtgärda senare.

Tokenvariationer

In- och utdatatoken skiljer sig åt i kostnad och är inte förutsägbara i förväg. En begäran med en prompt på 200 token kan returnera 50 token eller flera tusen, beroende på uppgiften, modellinställningarna och genereringsbeteendet. Du kan inte fakturera i förskott baserat på storleken på en begäran. Du måste utfärda händelser efter körningen med faktiska antal.

Ojämna arbetsbelastningar

Ett företagsbatchjobb kl. 02:00 kan generera mer användning på några timmar än under de föregående två veckorna sammantaget. Inmatningssystem måste hantera dessa toppar utan att tappa händelser, hamna på efterkälken eller fördröja fakturering.

Icke-deterministiska kostnader

Samma prompt kan ge olika antal token mellan körningar, särskilt vid streaming, funktionsanrop eller agentkedjor. Detta gör deterministisk testning svår och kräver mätningslogik som är utformad för att tolerera varians från början.

Icke-deterministiska kostnader

Samma prompt kan ge olika antal token mellan körningar, särskilt vid streaming, funktionsanrop eller agentkedjor.

Hur ser ett tillförlitligt kontrakt för användningshändelser ut för AI-företag?

Användningshändelsen är den grundläggande enheten i ditt faktureringssystem. Alla efterföljande led – från mätning till fakturering till revision – är beroende av att kontraktet för händelser är stabilt och explicit.

Så här ser ett tillförlitligt kontrakt för användningshändelser ut:

• Kund- och projektidentifierare: Stabila, oföränderliga ID:n som inte ändras när en kund byter namn på sin organisation eller omstrukturerar sin kontohierarki.

• Tidsstämpel för åtgärd: När åtgärden inträffade, inte när händelsen utfärdades. Asynkrona pipelines kan orsaka fördröjningar som spelar roll för periodattribuering.

• Enhet och kvantitet: Vad du mäter (t.ex. indatatoken, utdatatoken och beräkningssekunder) och hur mycket. Se till att enheterna förblir atomära såvida inte din prissättning behandlar dem identiskt.

• Korrelations-ID: En unik identifierare som kopplar en användningshändelse tillbaka till den ursprungliga begäran, sessionen eller agent-körningen. Det är det här som gör att du kan spåra en fakturaradpost tillbaka till applikationens loggar.

• Flagga för fakturerbarhet och orsakskod: Inte varje åtgärd är fakturerbar. Gör faktureringsbeslut explicit i händelsen snarare än att gömma det i nedströmslogik, där det är svårare att granska.

• Schemaversion: När dina prismodeller förändras måste gamla och nya händelser samexistera. Versionshantering gör det möjligt.

Hur bör AI-företag utforma inmatning och lagring för användningsbaserad fakturering?

Två krav är avgörande för detta lager: tillförlitlighet och oföränderlighet. Allt annat (genomströmning, latens, schemavalidering) tjänar dessa mål.

Så här bör AI-företag utforma inmatning och lagring:

Tillförlitlighet

Skriv till ett beständigt kösystem med "leverans minst en gång"-semantik. Kön skyddar dig från tillfälliga fel; nedströmskunder hanterar deduplicering. Skriv inte användningshändelser direkt från din applikation till en databas.

Säkerställ att obligatoriska fält är närvarande, att identifierare matchas korrekt och att tidsstämplar är rimliga. Avvisa dåligt utformade händelser tidigt med tydliga fel i stället för att låta felaktiga data läcka in i mätningen.

Utforma systemet specifikt för toppar. Om kapaciteten för inmatning är för liten leder det oftast till tappade händelser.

Oföränderlighet

Ditt lagringsutrymme för rådata bör endast vara för tillägg. Detta innebär att även om ny data kan läggas till (bifogas) i slutet av en fil eller databas, förblir befintlig data oföränderlig (den kan inte ändras eller tas bort). När misstag inträffar, som ett felberäknat token-antal eller en felaktigt tillskriven kund, ska du utfärda en korrigeringshändelse som refererar till originalet i stället för att redigera källposten. Detta är ett krav för tvistlösning. När en kund bestrider en faktura måste du spela upp den exakta sekvens av händelser som ledde fram till det beloppet.

Hur förvandlar AI-företag rådatahändelser för användning till korrekta fakturerbara sammanställningar?

Vid mätning är noggrannhet avgörande. Om indatahändelserna och reglerna är desamma måste resultatet alltid bli detsamma.

Följande fyra egenskaper gör det möjligt:

• Deduplicering och idempotens: "Minst en gång-leverans" garanterar dubbletter. Denna idempotens (varvid åtgärdsresultat ger samma resultat) innebär att varje händelse behöver ett unikt ID, och aggregering måste dedupliceras före räkning. Utan detta är risken för dubbelfakturering mycket större.

• Hantering av sena händelser: Händelser anländer inte i ordning. Definiera en tydlig policy: stäng en faktureringsperiod X minuter efter gränsen, acceptera sena händelser fram till den gränsen och flagga eller avvisa allt bortom det. Det är viktigt att vara konsekvent.

• Korrigeringshändelser: När fel dyker upp, utfärda korrigeringshändelser som justerar summor, refererar till den ursprungliga händelsen och förklarar varför ändringen inträffade. Skriv inte om historiska sammanställningar.

• Hantering av regelversioner: Prissättningsregler kan ändras, men händelser måste mätas enligt de regler som gällde när de inträffade. Att tillämpa nuvarande regler på förra kvartalets användning kommer att resultera i felaktiga fakturor.

Verktyg som Stripe Billing hanterar sammanställning på fakturasidan, men ditt interna mätningslager bör producera sina egna sammanslagningar oberoende av detta. Dessa blir din officiella källa för avstämning.

Hur använder AI-företag skyddsfunktioner för kostnadskontroll?

AI-arbetsbelastningar kan generera utgifter (dina och dina kunders) snabbare än någon människa kan ingripa. Skyddsfunktioner måste fungera i realtid.

Så här använder AI-företag dem för att förhindra skenande kostnader:

Kreditreskontra och reservationer

Innan du utför en användningsgenerande åtgärd, reservera den förväntade kostnaden mot kundens saldo. Om reservationen misslyckas, kör inte åtgärden. Efter utförandet avräknar du mot faktisk användning. Det här speglar förauktorisering av kreditkort och är rätt mental modell för AI-fakturering.

Mjuka och hårda gränser

Hårda gränser stoppar användning direkt. Mjuka gränser utlöser varningar när trösklar närmar sig. Båda bör vara konfigurerbara per kund och per projekt. Produktionsarbetsbelastningar och provperiodskonton har olika toleranser.

Kretsbrytare för agentarbetsbelastningar

Agenter kräver särskild hantering. Ange maximalt antal steg, maximala utgifter per session och automatiserade kill switch-funktioner. Tillämpa dessa vid exekveringstillfället, inte efter fakturering. När faktureringen ser händelsen är kostnaden redan realiserad.

Identifiering av avvikelser

Spåra användningshastigheten per kund och flagga avvikelser utöver ett definierat tröskelvärde till exempel 0,1 USD per enhet). Automatisk pausning med en mänsklig granskningskö är ofta rätt svar. Målet är att fånga upp okontrollerade processer innan de förvandlas till tvister eller överraskningar vad gäller kostnad för sålda varor (COGS).

Hur Stripe Billing kan hjälpa

Med Stripe Billing kan ni fakturera och hantera kunder hur ni vill – från enkel återkommande fakturering till användningsbaserad fakturering och förhandlade kontrakt. Börja ta emot återkommande betalningar globalt på bara några minuter – ingen kod krävs – eller skapa en anpassad integration med API.

Stripe Billing kan hjälpa dig att:

• Erbjuda flexibla priser: Svara snabbare på användarefterfrågan med flexibla prismodeller, inklusive användningsbaserad, nivåindelad, fast avgift plus extra avgifter med mera. Stöd för kuponger, kostnadsfria provperioder, proportionella fördelningar och tillägg är inbyggt.

• Expandera globalt: Öka konverteringen genom att erbjuda kunder deras föredragna betalningsmetoder. Stripe har stöd för över 100 lokala betalningsmetoder och fler än 130 valutor.

• Öka intäkterna och minska kundbortfallet: Öka intäkterna och minska ofrivilligt kundbortfall med Smart Retries och automatiserade återvinningsarbetsflöden. Stripes återställningsverktyg hjälpte användare att återställa över 6,5 miljarder USD i intäkter under år 2024.

• Öka effektiviteten: Använd Stripes modulära skatt, intäktsrapportering och dataverktyg för att kombinera flera intäktssystem i ett. Integrera enkelt med programvara från tredje part.

Läs mer om Stripe Billing, eller börja idag.