Cobrar por tokens de IA: del evento de uso a la factura en Chile

Para cobrar por tokens o llamadas a la API a tus clientes de IA, mide el consumo de cada llamada con el dato que entrega el modelo, conviértelo en créditos con tu margen y descuéntalo de un saldo prepagado o cóbralo como excedente. En Chile, un paquete de créditos se factura con IVA al cobrarlo, no al consumirlo.

El token es fácil de medir y difícil de vender: tu cliente no sabe cuántos necesita ni qué obtiene con ellos, y en Chile además hay que facturarlo bien. Por eso conviene separar tres capas: la comercial (qué modelo de cobro usar y qué unidad vender), la técnica (cómo pasa el consumo del modelo a un registro confiable por cliente) y la tributaria (qué documento emites y cuándo). Este artículo las recorre en ese orden.

Cuatro formas de cobrar por tokens

El pospago parece el más simple, pero con IA tiene un problema: tu costo es inmediato y variable. Si un cliente deja un agente corriendo un fin de semana, tú le pagas al proveedor del modelo ese mismo mes y a él le cobras 30 o 60 días después, si es que paga. El prepago invierte ese orden.

Salvo con clave propia, en todos los modelos queda la pregunta de qué unidad le vendes al cliente.

¿Por qué vender créditos y no tokens?

Porque el token es una unidad técnica que tu cliente no controla. Una misma consulta gasta más o menos tokens según el largo de la pregunta, el modelo y la respuesta, y el token de salida casi siempre cuesta más que el de entrada. Si vendes tokens, le traspasas toda esa variación. Si vendes créditos, la absorbes tú en una tabla de conversión.

Un ejemplo con números hipotéticos. Tu producto responde consultas que gastan en promedio 2.000 tokens de entrada y 500 de salida. Si el modelo te cobra USD 3 por millón de tokens de entrada y USD 15 por millón de salida, cada consulta te cuesta:

• Entrada: 2.000 × USD 3 / 1.000.000 = USD 0,006
• Salida: 500 × USD 15 / 1.000.000 = USD 0,0075
• Total: USD 0,0135 por consulta

Si defines que 1 crédito vale USD 0,01 y cada consulta descuenta 5 créditos, cobras USD 0,05 por consulta. Un paquete de 10.000 créditos a USD 100 alcanza para 2.000 consultas que te cuestan USD 27: un margen bruto de 73%. Si el proveedor baja precios o cambias de modelo, ajustas cuántos créditos descuenta cada acción sin tocar el precio del paquete.

Hay un riesgo más en Latinoamérica: el proveedor te cobra en dólares y tu cliente probablemente te paga en pesos. Si fijas el paquete en pesos, el tipo de cambio mueve tu margen y conviene dejar un colchón; si lo fijas en dólares, el contrato tiene que decir qué tipo de cambio se usa al facturar.

Los créditos resuelven la variación del costo. Pero no son el último paso.

De tokens a créditos, y de créditos a resultados

Scott Woody, CEO de Metronome, separa tres cosas por las que se puede cobrar: lo que te cuesta producir (los tokens), lo que tu producto entrega (una conversación de soporte resuelta, un documento procesado, una imagen generada) y el resultado que obtiene el cliente (una venta cerrada, un ahorro). Su tesis es que la factura debería mostrar lo segundo: cobrar por tokens con un recargo deja que tu costo fije tu precio, y cobrar por resultados casi nunca funciona porque es difícil atribuirlos.

Los créditos son el puente entre los tokens y la unidad de trabajo. En el ejemplo anterior, "1 consulta = 5 créditos" ya es casi un precio por unidad de trabajo: el cliente piensa en consultas y los tokens quedan como un costo interno. En la factura chilena se nota la diferencia, porque la glosa puede decir "2.000 consultas" en vez de "4 millones de tokens de entrada y 1 millón de salida".

Para cobrar por cualquiera de esas unidades, el sistema por debajo es el mismo: cada llamada tiene que dejar un registro de qué se entregó y cuántos tokens costó.

¿Cómo se mide el consumo de cada cliente?

Con el dato que el proveedor del modelo devuelve en cada respuesta. El dato está ahí; lo que hay que cuidar es leerlo en el momento correcto.

Con el consumo leído, tu backend emite un evento de uso por cada llamada: quién consumió, qué, cuánto y cuándo. Un evento típico se ve así:

{
  "idempotency_key": "req_01HZX8Q4N2",
  "external_customer_id": "acme",
  "event_name": "llm_call",
  "timestamp": "2026-10-27T14:03:07Z",
  "properties": {
    "model": "modelo-grande",
    "input_tokens": 2000,
    "output_tokens": 500
  }
}

A partir de esos eventos se definen las métricas que se cobran: la suma de tokens de entrada del mes por cliente, el conteo de llamadas, o la suma filtrada por modelo si cobras distinto cada uno. Guardar el evento crudo, y no solo el total, es lo que permite cambiar de pricing después sin perder historia, y calcular el margen por cliente comparando lo que le cobraste con lo que te costaron sus tokens.

El flujo se ve simple en un diagrama. En producción aparecen siempre los mismos cuatro problemas.

Cuatro problemas que aparecen en producción

1. Eventos duplicados. Un timeout hace que tu backend reintente el envío, y la misma llamada se cobra dos veces. La solución es una llave de idempotencia por evento, idealmente el id de la request: si llega dos veces con el mismo contenido, se cuenta una. Si llega la misma llave con contenido distinto, es un error que conviene rechazar, porque significa que algo en tu sistema generó dos versiones de la misma llamada.

2. Eventos tardíos y correcciones. Una cola que se atrasa, un worker que se cae o un consumo atribuido al cliente equivocado. El timestamp tiene que ser el momento en que ocurrió el consumo, en UTC, no el momento del envío, para que caiga en el período correcto. Y cuando hay que corregir un evento, se anula o se reemplaza, nunca se edita. Si el período ya se facturó, la factura emitida no se toca: la diferencia se ajusta con nota de crédito o de débito.

3. Decimales. Tokens multiplicados por un precio por millón dan fracciones de centavo. Con números de punto flotante, esas fracciones se redondean distinto en cada paso y la factura no cuadra con el detalle. Cantidades y montos se guardan como decimales exactos, y se redondea una sola vez, al final.

4. Saldo en tiempo real. Con créditos prepagados necesitas saber si al cliente le alcanza antes de llamar al modelo, pero el consumo real se conoce después. El patrón es el de una tarjeta de crédito: antes de la llamada se reserva un estimado, al terminar se descuenta el consumo real y se libera la diferencia. Sin reserva, diez llamadas en paralelo pueden gastar el mismo saldo diez veces.

Ese último problema ya es un límite de gasto, y los límites son la forma de evitar la queja más común del cobro por uso.

¿Cómo evitar las facturas sorpresa?

Con dos tipos de límite que conviene no confundir.

El primero corta el consumo en tiempo real. Lo hace el gateway o el backend que llama al modelo: herramientas como LiteLLM permiten fijar un presupuesto máximo por cliente y rechazan las llamadas cuando se supera. Ahí también van las alertas de saldo bajo y la recarga automática.

El segundo es comercial y actúa en la factura: mínimos que el cliente se compromete a consumir, topes por sobre los cuales no se le cobra más y unidades incluidas sin costo. Ese control vive en el contrato y en el sistema de facturación, y define qué número termina en el documento tributario.

Entre los dos queda el diseño del paquete que vendes, con decisiones que después cuestan caro de cambiar.

Seis decisiones al diseñar un paquete de créditos prepagados

Los créditos de regalo, los que entregas al registrarse o como compensación, conviene llevarlos separados de los comprados: se consumen igual, pero no tienen precio y no deberían mezclarse con lo que el cliente pagó.

Esa diferencia entre lo pagado y lo consumido es justo la que importa cuando llega el momento de facturar.

¿Cuándo se factura un paquete de créditos en Chile?

Cuando lo cobras, no cuando se consume. Desde 2023 todas las prestaciones de servicios están afectas a IVA, salvo excepciones puntuales, y en servicios la ley fija el momento de la factura según el pago: las facturas deben emitirse en el mismo período tributario en que se percibe la remuneración. El mismo oficio aclara que, si emites la factura antes de recibir el pago, que es lo normal en B2B, el IVA se devenga con esa emisión.

En un caso concreto se ve mejor.

Un cliente durante dos meses, en pesos

Un cliente ficticio compra en marzo un paquete de 10.000 créditos a $95.000 neto, sin vencimiento. Los excedentes se cobran a $10,50 neto por crédito.

En marzo pagaste IVA por $18.050 aunque el cliente solo usó el 40% del paquete. Ese desfase entre lo facturado y lo consumido es normal, y se vuelve una pregunta cuando parte del saldo nunca se usa.

¿Y si el cliente no usa todos sus créditos?

Depende de si le devuelves plata.

Si los créditos vencen y no hay devolución, no corresponde nota de crédito: la factura ya se emitió por un servicio pagado y el IVA declarado se mantiene. Si en cambio le devuelves el saldo, emites una nota de crédito, pero esa nota solo tiene valor tributario si la plata se restituye de verdad.

En la contabilidad pasa algo distinto. Bajo NIIF 15, lo que el cliente paga antes de recibir el servicio se registra como un pasivo del contrato y pasa a ingreso a medida que el cliente consume. El saldo que probablemente nunca se use tiene su propio tratamiento en la norma, como derechos no ejercidos de los clientes, y la forma de estimarlo conviene definirla con tu contador desde el primer paquete.

Así, un mismo paquete vive en tres calendarios: el tributario, que se cierra al facturar; el contable, que avanza con el consumo; y el del cliente, que mira su saldo. Mantenerlos alineados es trabajo de todos los cierres de mes.

Dónde se va el tiempo

El trabajo pesado está en conectar el evento de uso con el saldo, el saldo con la factura y la factura con el pago, y en que los tres calendarios cuadren cada mes.

Para eso existe Relvo, una plataforma que automatiza el ciclo que va del contrato al cobro para empresas B2B. Envías el consumo de tu producto por API y el modelo de cobro se configura en el contrato de cada cliente: créditos prepagados, cuota con cupo incluido, pospago, mínimos, topes o tramos por volumen. Relvo descuenta los créditos, emite la factura que corresponde en cada caso y concilia el pago con el banco. Si mañana pasas de cobrar tokens a cobrar créditos, o de créditos a un precio por consulta, cambias el contrato, no tu código. El corte en tiempo real queda en tu gateway; todo lo que pasa después del consumo, en Relvo.