Un fundador que dirigeix un assistent d'escriptura amb IA em va dir que els seus "costos de programari" eren de $40,000 al mes. Quan vam desglossar la xifra, $34,000 corresponien a factures d'API d'OpenAI i Anthropic — i cap d'ells formava part del seu cost de les mercaderies venudes. Estava dins d'una línia general de "Programari i subscripcions", just al costat de la seva eina de gestió de projectes de $19 al mes. El seu marge brut declarat era del 91%. El seu marge brut real, un cop la inferència es va traslladar on li pertocava, era del 58%.
Això no és un tecnicisme comptable. És la diferència entre un negoci que sembla programari i un negoci que es comporta com una fàbrica — un on cada unitat venuda consumeix una entrada real i variable. Si estàs construint sobre GPT-5, Claude, Gemini o qualsevol model allotjat, la teva factura de LLM no és una despesa general. És cost de les mercaderies venudes, i tractar-la d'una altra manera significa que no saps realment quants diners guanyes.
Per què és tan fàcil cometre aquest error
El SaaS tradicional va ensenyar a tota una generació de fundadors a pensar en els costos de programari com a fixos. Pagues per l'allotjament, pagues pel teu CRM, pagues per Slack — i cap d'aquestes factures es mou en sintonia amb l'ús que en fa un client concret del teu producte. Per això, quan arriba la primera factura d'API d'OpenAI, és natural classificar-la mentalment en el mateix calaix: "eines que paguem per fer funcionar el negoci."
El problema és que una factura d'API de LLM no es comporta com una subscripció SaaS. Es comporta com una matèria primera. Cada cop que un client envia un prompt, consumeixes tokens, i cada token té un preu. Un client que fa 50 sol·licituds al dia et costa significativament més de servir que un que en fa 2. Aquesta és la definició de manual del cost de les mercaderies venudes: un cost que escala directament amb el lliurament del teu producte a un client concret, en contraposició a un cost que pagaries només per mantenir el negoci en marxa, independentment de l'ús.
Les dades del sector confirmen fins a quin punt això s'ha tornat material. L'informe State of AI de gener de 2026 d'ICONIQ va trobar que la inferència representa ara de mitjana el 23% dels ingressos totals a les empreses B2B d'IA en fase d'escalat, i el 84% d'aquestes empreses van declarar una erosió del marge brut de sis punts percentuals o més atribuïble directament als costos d'infraestructura d'IA. Això no és un error d'arrodoniment que puguis absorbir dins de "despeses operatives diverses." Sovint és el principal factor de cost del negoci, i mereix ser tractat com a tal.
La línia entre COGS i OpEx, traçada correctament
La regla que separa el COGS de les despeses operatives no ha canviat pel simple fet que l'entrada sigui una API de model en lloc d'un magatzem ple de peces: els costos de lliurar el teu producte a un client de pagament pertanyen al COGS; els costos de construir el teu producte pertanyen a R+D dins de l'OpEx. Aplicat a un wrapper d'IA, aquesta divisió té aquest aspecte:
Pertany al COGS:
- Costos d'inferència de producció — cada crida a l'API que el teu producte en viu fa en nom d'un client de pagament, ja sigui una compleció de xat, una crida d'embedding, un pas de classificació o un bucle de crides d'eines d'un agent
- Allotjament del model / còmput de GPU — si executes un model de pesos oberts en infraestructura pròpia o llogada en lloc de cridar una API allotjada, el temps de còmput atribuïble a servir les sol·licituds dels clients
- Infraestructura de suport a la inferència — consultes a bases de dades vectorials, execucions de pipelines d'embedding i sobrecàrrega d'orquestració que existeixen específicament per servir sol·licituds de producció
- Costos de suport específics d'IA — un enginyer de suport la feina del qual és triar problemes en les sortides del model per als clients és un cost de lliurar el producte, no una despesa general de SG&A
Pertany a l'OpEx (normalment R+D):
- Inferència de desenvolupament i proves — cada prompt que un enginyer envia mentre itera sobre una funcionalitat, depura una regressió o avalua una nova versió del model
- Execucions de fine-tuning i avaluació — construir o millorar el model és R+D, no lliurament
- Eines internes d'IA — les llicències de ChatGPT Enterprise o GitHub Copilot del teu equip són una despesa de productivitat, no un cost de servir clients
El pas pràctic que fa possible aquesta divisió és avorrit però essencial: utilitza claus d'API o projectes de facturació separats per al trànsit de producció i de desenvolupament des del primer dia. Si els teus enginyers proven prompts amb la mateixa clau que el teu producte utilitza en producció, no tens manera d'assignar la factura correctament a posteriori, i acabaràs sobrevalorant o infravalorant el teu marge real cada mes.
Com és el marge brut "real" per als productes d'IA
Un cop hagis fet la divisió, espera que la xifra resultant sigui diferent del que estàs acostumat. Els negocis SaaS tradicionals apunten a marges bruts del 70–80% gairebé per defecte. Els productes nadius d'IA no hi arriben de la mateixa manera. El manual de preus de febrer de 2026 de Bessemer Venture Partners situa els marges bruts típics dels productes d'IA en un 50–60%, molt per sota del rang del 80–90% del SaaS tradicional, i les dades d'ICONIQ mostren que el marge brut mitjà del sector per als productes d'IA va pujant — però només fins al 52%, des del 41% el 2024 i el 45% el 2025.
Una regla pràctica útil que ha sorgit d'operadors que gestionen això de prop: mantén els costos de LLM per sota d'aproximadament el 20% del COGS total si vols un model de negoci durador i escalable. Un cop superat aquest llindar, la compressió del marge tendeix a accelerar-se a mesura que creixes, en lloc de suavitzar-se, perquè els clients més grans utilitzen el producte més, no menys. Algunes categories intensives en IA — assistents de codificació, agents de processament de documents — operen amb ràtios de cost de LLM del 30–40% del COGS i encara són viables, però només perquè han fixat els preus deliberadament al voltant d'aquesta realitat en lloc d'arribar-hi per casualitat.
La xifra que realment importa no és el teu marge brut combinat a nivell d'empresa — és el cost per client. Els usuaris intensius d'una funcionalitat d'IA poden costar entre 50 i 100 vegades més de servir en inferència bruta que els usuaris lleugers en el mateix nivell de subscripció. Si no ho estàs fent un seguiment, no saps quins clients són rendibles i a quins estàs subvencionant discretament cada mes. Un pla de tarifa plana que semblava bé amb els teus primers deu clients pot començar a perdre diners en el moment que un d'ells posa un flux de treball en producció i multiplica el seu volum de sol·licituds per 20x.
Construint el model de cost per sol·licitud
No necessites eines elaborades per començar — necessites disciplina per registrar les xifres correctes a cada sol·licitud. La fórmula bàsica és senzilla:
request_cost = (input_tokens / 1,000,000) × input_price_per_million
+ (output_tokens / 1,000,000) × output_price_per_millionEls tokens de sortida normalment costen entre 2 i 5 vegades més que els tokens d'entrada per unitat, perquè la generació és més intensiva en còmput que la lectura d'un prompt — així que un model de cost per sol·licitud que només fa un seguiment del total de tokens sense separar entrada de sortida valorarà sistemàticament malament qualsevol cosa amb compleccions llargues. Com a exemple pràctic amb preus de mitjans de 2026: una sol·licitud amb 2,000 tokens d'entrada i una resposta de 500 tokens contra un model de gamma mitjana convencional (aproximadament $3 d'entrada / $15 de sortida per milió de tokens) costa uns $0.0135. Executa aquest mateix tipus de sol·licitud 50,000 vegades al mes i estaràs parlant d'uns $675 en cost d'inferència per a aquesta única funcionalitat — una xifra que és invisible si queda enterrada en una línia de "costos de núvol" de cinc xifres, però molt visible un cop s'etiqueta amb la funcionalitat i el segment de client que la va generar.
Per fer-ho pràctic:
- Registra el nombre de tokens a cada sol·licitud, no només el cost — la majoria de proveïdors de models retornen els recomptes de tokens d'entrada/sortida a la mateixa resposta de l'API, així que això és un canvi de registre, no una nova font de dades.
- Etiqueta cada sol·licitud amb un ID de client i un identificador de funcionalitat perquè puguis agregar els costos per compte i per superfície de producte, no només per mes.
- Calcula el cost per client per període de facturació i compara'l amb el que aquest client et paga. Aquesta és la xifra que et diu si els teus nivells de preus realment coincideixen amb el teu cost de lliurament, no el teu marge mitjà combinat.
- Redirigeix cap a models més barats on la qualitat ho permeti. No totes les sol·licituds necessiten el teu model més capaç (i més car) — les tasques de classificació, extracció i formatació senzilla sovint funcionen de manera acceptable amb un model més petit i barat, i l'enrutament de models és una de les poques palanques de marge que controles totalment, a diferència dels preus dels proveïdors.
Fixar preus per protegir el marge que acabes de trobar
Un cop la inferència es classifica correctament com a COGS, la teva conversa sobre preus canvia. Un ancoratge habitual que utilitzen els operadors és cobrar aproximadament de 3 a 5 vegades el teu cost per unitat de token, de manera que una tasca de $0.30 es fixi a $1.00 o més — no perquè aquest multiplicador sigui màgic, sinó perquè deixa marge per absorbir la variància d'ús, la volatilitat dels preus dels models, i els costos de suport i infraestructura que acompanyen la inferència bruta.
La facturació basada en l'ús s'ha convertit en la manera estàndard amb què les empreses d'IA mantenen alineats els preus i el COGS: cobra per token, per sol·licitud o per tasca completada, i els teus ingressos escalen amb la mateixa variable que impulsa el teu cost, en lloc de separar-se'n com fa una subscripció plana quan l'ús es dispara. Si no estàs preparat per passar completament a preus basats en l'ús, com a mínim construeix nivells de mínim compromès més excedent perquè un client que supera l'ús típic no es converteixi discretament en un producte de pèrdua per a la resta del mes.
Mantén la teva estructura de costos tan auditable com el teu codi
Res d'això és higiene comptable opcional — és la diferència entre saber que el teu model de negoci funciona i descobrir que no ho fa durant una trucada de due diligence de captació de fons, quan un associat d'un inversor construeix el model de cost per client que tu hauries d'haver construït sis mesos abans. Els fundadors que eviten aquesta conversa són els que etiqueten els costos d'inferència als clients i les funcionalitats des de la primera crida a l'API, no els que esperen fins que la factura d'OpenAI és massa gran per ignorar-la.
Beancount.io et proporciona una comptabilitat en text pla i controlada per versions que fa senzill etiquetar la despesa d'inferència al compte correcte, separar l'ús de l'API de producció del de desenvolupament, i reconciliar el teu COGS real amb els ingressos cada mes — sense categorització de caixa negra, sense dependència d'un proveïdor. Comença gratis i descobreix per què els desenvolupadors i els fundadors nadius d'IA estan canviant a la comptabilitat en text pla.