Suscripciones vs facturación por uso explicado desde la perspectiva del modelado de datos: medidores, límites, facturas, prorrateo y los registros que debes conservar desde el primer día.
El precio no es solo una página en tu web. Decide qué debes registrar, cómo informarlo y si podrás explicar un cargo meses después. Al elegir suscripciones o facturación por uso también eliges la forma de tus datos de facturación.
Una suscripción simple a menudo se puede calcular a partir de unos pocos hechos: plan, periodo de facturación, fecha de inicio y descuentos. El precio por uso necesita más: qué se usó, cuándo ocurrió, a qué cliente pertenece y cómo ese uso se convierte en dinero. Sin esos registros puedes enviar facturas, pero no puedes defenderlas.
Agregar uso más tarde sin planificar suele fallar en tres puntos:
El objetivo es aburrido pero esencial: calcular la misma factura de la misma manera cada vez. Eso significa que puedes reproducir el cálculo a partir de hechos almacenados (términos del plan, reglas de medidor, eventos de uso y la versión exacta de precios que se aplicó).
Una “vista de modelado” solo significa describir la facturación como bloques que encajan, incluso si no eres ingeniero. Imagina un producto de chat para equipos:
Para soportarlo más adelante, tus datos deben responder: qué workspace, qué mes, cuántos mensajes, qué estaba incluido y qué reglas de precio estaban activas.
Las suscripciones cobran por acceso. La facturación por uso cobra por consumo. Se comportan de forma muy distinta cuando hay upgrades, downgrades, prorrateos y casos límite del mundo real.
Con una suscripción, la pregunta clave es: “¿Tenía el cliente derecho a usar el producto durante este tiempo?” Principalmente registras plan, número de asientos, periodo de facturación y si la factura fue pagada. El uso sigue importando, pero suele aparecer como límites (suaves o duros) en lugar de partidas de línea.
Con facturación por uso, la pregunta clave se vuelve: “¿Qué ocurrió exactamente, y cuándo?” Necesitas medición confiable, reglas claras sobre cuándo se cuenta el uso y una forma de explicar cada cargo más tarde. Incluso si tu interfaz muestra un número (por ejemplo, “1.243 llamadas a la API”), detrás hay un conjunto de eventos que deben ser consistentes y auditables.
Muchos equipos B2B SaaS optan por precios híbridos: una tarifa base que cubre un paquete, más excesos.
La mayoría de los modelos híbridos encajan en unas cuantas formas familiares:
La previsibilidad ayuda cuando los clientes necesitan aprobación presupuestaria y gasto mensual estable. Paga-por-lo-que-usa funciona mejor cuando el valor escala con la actividad (por ejemplo, “por factura procesada”), o cuando los clientes te prueban y quieren bajo riesgo.
Los cambios de plan son inevitables. Precios, paquetes y empaquetado cambiarán. Diseña la facturación para que puedas añadir un nuevo medidor, introducir un nuevo nivel o cambiar lo que significa “incluido” sin reescribir el historial. Una regla práctica: almacena el plan del cliente y los términos de precio tal como eran en el momento del cargo, no solo como son hoy.
Un medidor es la cosa exacta por la que cobras, escrita tan claramente que dos personas que lo cuenten lleguen al mismo número. Tiene tres partes: el evento (qué pasó), la unidad (qué cuentas) y el tiempo (cuándo se cuenta).
La mayoría de las disputas empiezan aquí. Una parte piensa que paga por resultados, la otra está cobrando por actividad medible.
Elige medidores que se mapeen a acciones reales del producto y que puedan registrarse automáticamente. Ejemplos comunes:
Luego define qué cuenta y qué no. Si facturas por llamada a la API, decide si los reintentos cuentan, si las respuestas 4xx y 5xx cuentan, y si las llamadas internas hechas por tus propias integraciones cuentan.
El tiempo importa tanto como la unidad. Los asientos suelen funcionar mejor como una instantánea en un punto del periodo de facturación. Las llamadas API normalmente se suman dentro de una ventana. El almacenamiento es delicado: los clientes esperan pagar por “cuánto almacenaste”, lo que suele significar un promedio en el tiempo, no el pico.
También decide alcance: ¿por cuenta o por workspace/proyecto? Una regla simple: si los equipos pueden facturarse por separado, los medidores deberían ser por workspace.
Las habilitaciones son las reglas de lo que un cliente puede hacer por lo que compró. Responden preguntas como: ¿Cuántos usuarios pueden añadir? ¿Qué funciones están habilitadas? ¿Qué volumen está permitido por mes? Las habilitaciones se sitúan entre el acceso y la facturación: moldean lo que el producto permite, mientras que el metering registra lo que realmente sucedió.
Mantén las habilitaciones separadas de la lógica de medición. Las habilitaciones deben ser legibles y estables (plan, complementos, términos contractuales). El metering evolucionará conforme el producto evolucione (nuevos eventos, nuevos medidores), y no quieres que cada cambio de medidor arriesgue romper el acceso.
Límites duros, límites suaves y facturación por exceso pueden parecer similares en la UI, pero se comportan muy distinto:
Decide de antemano qué ocurre cuando se excede un límite. Ejemplo: un equipo en el nivel “Starter” incluye 5 asientos y 10.000 llamadas API por mes. Si invitan al sexto usuario, ¿lo bloqueas, empiezas a cobrar por asiento extra o lo permites 7 días como periodo de gracia? Cada elección necesita una regla que puedas mostrar en una factura y en los registros de soporte.
Almacena las habilitaciones como registros acotados en el tiempo: cliente, plan o complemento, timestamps de inicio y fin, valores de límite y modo de aplicación (duro, suave, exceso). Esto mantiene las decisiones de acceso y facturación consistentes.
Una factura no es solo un PDF. Es una pista de auditoría que responde: quién fue facturado, por qué, para qué fechas y bajo qué reglas. Si cambias precios, deberías poder reconstruir facturas antiguas exactamente como eran.
Empieza con unos pocos registros centrales: Cliente, Suscripción (o Contrato), Periodo de Facturación y Factura con Partidas de Línea. Cada partida debe apuntar a su origen: una tarifa de plan, un resumen de uso o un cargo único. Ese enlace es lo que hace que la facturación sea explicable cuando alguien disputa un cargo.
Los periodos de facturación necesitan un ancla y una zona horaria. “Mensual” no es suficiente. Guarda la fecha ancla del ciclo (por ejemplo, el día 15 a las 00:00) y la zona horaria usada para cortar periodos. Mantén esto consistente o tendrás errores de un día alrededor del cambio de horario.
Las facturas auditables suelen requerir:
El reconocimiento de ingresos está relacionado pero no es lo mismo que cobrar. Una tarifa de suscripción prepaga suele reconocerse a lo largo del periodo de servicio, mientras que el uso se reconoce a medida que se entrega. Aunque mantengas esto a alto nivel, guarda suficientes fechas para soportarlo más tarde.
Trata las notas de crédito, reembolsos y ajustes como registros de primera clase, nunca como ediciones a facturas antiguas. Si un cliente hace un upgrade a mitad de periodo, crea una partida de ajuste o nota de crédito que haga referencia a la factura original y explique la regla de prorrateo usada.
Las claves de idempotencia importan para la generación de facturas y los intentos de pago. Si un job corre dos veces, quieres una factura, un cargo y un registro claro.
Los cambios a mitad de ciclo son donde empiezan las discusiones de facturación. Si alguien hace un upgrade el día 20, pausa por una semana y luego cancela, necesitas reglas que conviertan esas acciones en números que tengan sentido en una factura.
Decide qué cambios permites y cuándo entran en efecto. Muchos equipos aplican upgrades inmediatamente para que el cliente reciba valor, pero aplican downgrades en la renovación para evitar reembolsos complejos.
El prorrateo puede ser diario, por hora o no aplicarse. Cuanto más preciso seas, más timestamps, reglas de redondeo y casos límite debes almacenar y testear.
Fija elecciones de política temprano:
Evita matemáticas ocultas. Representa el prorrateo como ajustes explícitos en la factura, como un débito por el tiempo restante en el nuevo plan y un crédito por el tiempo no usado en el plan anterior. Cada partida debe apuntar al evento de cambio exacto que la causó (change_id) e incluir la ventana de prorrateo (start_at, end_at), la cantidad/base temporal y la categoría de impuestos.
Los medidores de uso añaden una decisión más: cuando un plan cambia, ¿los medidores se reinician, siguen acumulando o se dividen en segmentos? Un enfoque simple y auditable es segmentar el uso por versión de plan. Ejemplo: un cliente hace un upgrade de 10 asientos a 25 asientos a mitad de mes. Mantienes los eventos de uso tal cual, pero el rating los agrupa por el periodo de habilitación activo en cada momento.
Decide qué es reversible. Ayuda tratar los eventos de uso como finales una vez aceptados, mientras que los cambios de suscripción pueden ser reversibles solo hasta que la factura se finalice. Guarda eventos de cambio y ajustes de factura para poder regenerar facturas limpiamente cuando las reglas evolucionen.
Si esperas a diseñar los datos de facturación hasta que los clientes se quejen, terminarás adivinando. Sea que elijas suscripción, uso o un modelo híbrido B2B SaaS, el punto más seguro de partida es un conjunto pequeño de registros que siempre te permitan auditar después.
Comienza con una jerarquía clara de cliente. En B2B SaaS, el pagador suele ser una cuenta de empresa, pero el uso a menudo ocurre dentro de workspaces o proyectos, y las acciones provienen de usuarios individuales. Almacena los tres niveles (cuenta, workspace, usuario) y registra quién hizo qué. Las disputas de facturación a menudo se convierten en “¿qué equipo hizo esto?”
Un diseño mínimo de base de datos de facturación que soporte facturas reales e investigaciones claras:
No dependas solo de contadores agregados. Mantén contadores para velocidad, pero trata el log de eventos como la fuente de la verdad. Una regla simple ayuda: los eventos son inmutables, las correcciones son eventos nuevos (por ejemplo, una cantidad negativa), y cada evento se vincula a una definición de medidor específica.
Ejemplo: un cliente dice que sus “llamadas API” se duplicaron el mes pasado. Si puedes extraer eventos crudos por workspace y día, puedes mostrar de dónde vino el pico o detectar un bucle de integración.
La parte difícil no es la matemática. Es hacer que el resultado sea explicable meses después, incluso después de que los planes, precios y clientes cambien.
Configura productos, planes, medidores y precios con fechas de vigencia. Nunca sobrescribas un precio viejo. Si un cliente se factura en marzo, debes poder volver a ejecutar marzo usando el catálogo de marzo.
Ejemplo: “Llamadas API” cuesta $0.002 cada una a partir del 1 de abril. Las facturas de marzo deben seguir usando la tarifa anterior.
Al inicio de cada periodo de facturación (o cuando ocurre un cambio), guarda una snapshot de habilitaciones: plan, unidades incluidas, límites, reglas de niveles, descuentos y ajustes fiscales. Piénsalo como “lo que prometimos” para ese periodo.
El uso debe llegar como eventos inmutables: timestamp, cliente, medidor, cantidad y un id único para deduplicación. Valida lo básico en la puerta (medidor faltante, cantidad negativa, timestamps imposibles) y registra el evento crudo incluso si también guardas una versión limpiada.
Luego haz el cálculo en dos pasadas:
Genera partidas de factura que referencien los insumos exactos usados (versión del catálogo, id de snapshot, id de agregación).
Finalmente, bloquea la factura. Guarda los insumos del cálculo y el resultado, márcala como final y evita que cambie cuando lleguen eventos tardíos. Los eventos tardíos deben ir a la siguiente factura (o a un ajuste separado) con una nota de auditoría clara.
A los clientes no les importa si escogiste suscripciones o facturación por uso. Les importa que tus números coincidan con los suyos y que puedan predecir el próximo cargo antes de que ocurra.
El reporte para clientes funciona mejor como un panel de facturación simple que responda unas pocas preguntas sin tickets de soporte:
Internamente, soporte y finanzas necesitan explicar un número, no solo mostrarlo. Eso significa detectar picos, rastrear cambios y separar cálculos de vista previa de la facturación finalizada.
Mantén las vistas previas de factura separadas de las facturas. Las vistas previas pueden recalcularse cuando llega uso tardío o cuando refinás la definición de un medidor. Las facturas no deben hacerlo.
Tu reporting interno debería facilitar marcar anomalías (saltos repentinos de uso, uso negativo, eventos duplicados), reproducir una partida de factura desde uso crudo y reglas, y ver cambios de plan y reglas de prorrateo aplicadas en el periodo.
Las pistas de auditoría importan más de lo que la mayoría de equipos espera. Si un cliente dice, “Actualizamos el día 12,” necesitas timestamps, actor (usuario, admin, automatización) y los valores exactos antes/después para plan, asientos, límites y tarifas de medidor.
Para retención, conserva eventos crudos de uso y artefactos de factura finalizados a largo plazo. Una regla práctica: si puede cambiar el monto cobrado o ayudar a defenderlo en una disputa, guárdalo inmutable.
La mayoría de las disputas de facturación no son por el precio. Ocurren cuando no puedes explicar un número en una factura, o cuando los mismos insumos producen un total distinto más tarde.
Un error común es guardar solo totales mensuales. Sin eventos crudos, no puedes responder preguntas simples como “¿Qué día nos pasó del límite?” Conserva el evento y luego agréga.
Otro problema frecuente es cambiar lo que significa un medidor sin versionarlo. “Usuario activo” puede empezar como “inició sesión al menos una vez” y luego convertirse en “creó un registro”. Si no versionas las definiciones de medidor, los clientes compararán facturas antiguas con nuevas y no podrás demostrar qué regla aplicó.
Las disputas suelen venir de patrones recurrentes:
Ejemplo: un cliente en Tokio hace un upgrade a mitad de ciclo el día 31 hora local. Si solo almacenas un timestamp en UTC y no guardas el ancla de facturación, el upgrade puede aparecer como el día 30 en tu sistema, moviendo prorrateo y uso al periodo equivocado.
La forma más rápida de perder confianza es no poder reproducir un cálculo de factura antiguo. Guarda los insumos (eventos, versiones, anclas y precios aplicados) para poder volver a ejecutar la misma lógica más tarde y obtener el mismo resultado, incluso después de que el producto cambie.
Antes del lanzamiento, haz un simulacro: elige un cliente al azar y recrea su última factura usando solo los datos almacenados. Si necesitas “lo que el código hizo en ese momento”, no tienes una pista de auditoría.
Asegúrate de que cada medidor sea inequívoco. Un medidor necesita una unidad clara (peticiones, asientos, GB, minutos), una fuente confiable (qué servicio lo emite) y una ventana temporal (por día, por periodo de facturación, por mes calendario). Si no puedes explicar el medidor en una frase, los clientes no confiarán en él.
Comprobaciones rápidas que detectan la mayoría de problemas de facturación:
Ejemplo: un cliente pasa de 10 a 25 asientos el día 18 y cruza un umbral de uso el día 23. Tu sistema debería mostrar (1) qué versión del plan estuvo activa en cada fecha, (2) el evento de cambio de asientos con timestamp, (3) la fórmula de prorrateo usada y (4) los eventos de uso que se agregaron en el total final.
Empieza pequeño, pero no vago. El camino más seguro es el modelo de datos más pequeño que aún te permita responder una pregunta meses después: “¿Por qué cobramos esta cantidad?”
Prototipa tu esquema de facturación y las pantallas administrativas pronto, antes del primer cambio de precios. Si esperas hasta que ventas pida un nuevo nivel o un upgrade a mitad de ciclo, terminarás parcheando lógica en demasiados sitios.
Una división práctica es: deja que Stripe maneje cobros, recibos e intentos de pago, pero mantén el rating (cómo el uso se convierte en partidas de factura) en tu propio sistema. Eso significa que guardas eventos crudos de uso, versiones de precios y los resultados del cálculo usados para generar una vista previa de factura.
Un plan de lanzamiento simple que mantiene flexibilidad:
Si quieres moverte rápido sin escribir mucho código de back office, puedes modelar estas entidades en AppMaster y construir las pantallas administrativas y de portal con sus herramientas visuales, manteniendo PostgreSQL como sistema de registro para eventos y facturas.
Ejemplo concreto: lanzas con un medidor de asientos. Tres meses después añades GB de almacenamiento. Si medidores, habilitaciones y reglas de precios están versionados, puedes introducir el nuevo medidor sin romper facturas antiguas y soporte puede explicar cualquier partida en minutos.
¿Por qué mi modelo de precios afecta qué datos debo almacenar?Comienza decidiendo qué necesitas probar más tarde: por qué se le cobró esa cantidad a un cliente. Las suscripciones necesitan historial de plan, periodo y habilitaciones; el cobro por uso requiere un registro inmutable de qué ocurrió, cuándo y bajo qué reglas de precios.
¿Qué significa hacer la facturación “auditable”?Si no puedes reproducir la factura a partir de los datos almacenados, no podrás responder disputas o auditorías. La configuración más segura es guardar términos de plan acotados en el tiempo, precios versionados, eventos crudos de uso y los resultados exactos del cálculo usados cuando la factura se finalizó.
¿Cómo defino un medidor para que no genere disputas?Un buen medidor es algo que dos personas contarían del mismo modo. Define el evento, la unidad y la ventana temporal, y documenta qué cuenta y qué no (por ejemplo reintentos, fallos o llamadas internas) para no cambiar el significado a mitad del camino.
¿Cuál es la diferencia práctica entre límites duros, suaves y la facturación por exceso?Los límites duros bloquean la acción, los límites blandos avisan pero permiten, y la facturación por exceso permite y cobra. Elige un comportamiento por habilitación y guárdalo como regla con timestamps de inicio y fin para que soporte, producto y facturación actúen igual.
¿Por qué las habilitaciones deben estar separadas de la lógica de medición?Resuelven problemas distintos: las habilitaciones controlan lo que el cliente puede hacer, mientras que el metering registra lo que realmente ocurrió. Mantenerlos separados evita que cambiar un medidor rompa el acceso y hace las facturas más fáciles de explicar.
¿Debo almacenar eventos crudos de uso o solo totales mensuales?Almacena un registro de eventos de uso append-only como fuente de la verdad, y opcionalmente mantén agregados para velocidad. Los eventos deben incluir timestamp, alcance del cliente (por ejemplo workspace), nombre del medidor, cantidad y una clave única de idempotencia para evitar duplicados.
¿Cómo manejo los cambios de precio sin romper facturas antiguas?Nunca sobrescribas precios o reglas de plan antiguas; añade nuevas versiones con fechas de vigencia. Guarda qué versión de precio se aplicó a cada factura (y a menudo a cada periodo de habilitación) para reconstruir facturas antiguas exactamente, aun tras cambios en el empaquetado.
¿Cómo evito errores de facturación causados por zonas horarias y periodos de facturación?La facturación mensual necesita un ancla de ciclo y una zona horaria, no solo “mensual”. Guarda period_start y period_end consistentemente y sé explícito sobre qué timestamps usas para el tiempo del evento frente al tiempo de ingestión para evitar errores por zonas horarias o DST.
¿Cuál es una política de prorrateo sensata para upgrades y downgrades?Usa una política que puedas explicar en una frase y modela la matemática como partidas explícitas en la factura (créditos y débitos) vinculadas al evento de cambio y a la ventana de prorrateo. El prorrateo diario es un punto de partida común porque es más simple de probar y defender que el horario.
¿Qué hago cuando eventos de uso llegan tarde tras finalizar una factura?Finaliza las facturas como snapshots inmutables y trata el uso tardío como un ajuste nuevo o como parte del siguiente periodo, con una nota clara. Las vistas previas de factura pueden recalcularse libremente, pero las facturas finalizadas no deben cambiar cuando llegan eventos nuevos.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
