Cobro por uso: el consumo se mide hora a hora y la factura llega una vez

Un contrato de software firmado en enero llega a finanzas en octubre con un número que nadie aprobó. No hubo error de cálculo. Hubo consumo.

En el modelo de cobro por uso, el comprador paga por lo que consume, y del lado de quien vende el consumo se reporta al marketplace hora a hora. En esa modalidad, que AWS Marketplace nombra SaaS subscriptions, cada licencia, cada cuenta y cada dimensión de uso se convierten en una línea con fecha y hora. Del lado de quien compra, lo que llega de forma automática es la factura, que sigue el ciclo del proveedor o del canal, no el reloj del medidor; el intervalo entre una factura y otra depende de lo que el proveedor exponga en el producto.

Quien firma un contrato de software internacional es controller, gerente de compras o líder de TI, y responde por la línea del presupuesto. La distancia entre los dos relojes decide si ese número cabe en el mes. La pregunta que ordena el resto no es cuánto cuesta la licencia. Es quién mide, cada cuánto tiempo, y qué llega a mitad del mes.

Qué cambia en el cobro por uso cuando medir deja de ser caro

La premisa es simple: integrar medición siempre exigió ingeniería del proveedor. El 13 de octubre de 2026, AWS Marketplace publicó una skill de metering que genera el código de integración dentro del IDE. El efecto para el comprador no es un precio menor. La lectura posible es más proveedor con el medidor encendido.

La skill llega por el AWS MCP Server y conduce la construcción de la integración de metering: levanta las dimensiones de uso del producto, recomienda un enfoque de API y entrega el código con las plantillas AWS SAM, que el proveedor revisa y despliega. La skill solo despliega directo un listado Limited; en un producto publicado, el código vuelve al pipeline del proveedor.

Lo que cae es el costo de medir. El precio del software no se mueve por eso.

Y medir no es un acto neutro. El medidor es código que el proveedor escribe, opera y corrige, y la factura es la salida de ese código después de que el marketplace consolida el reporte. Granularidad del dato y confianza en el dato son dos cosas distintas.

Los dos modelos de precio capturan el crecimiento en momentos distintos

El post nombra dos modelos. Son distintos. En el SaaS contract, el crecimiento a mitad del plazo se captura con una nueva oferta y una adenda en la renovación. En SaaS subscriptions, el comprador paga por lo que consume, y el crecimiento puede aparecer en el reporte de ingresos del proveedor dentro de la hora.

La diferencia que importa para quien aprueba presupuesto es el instrumento. En el primer modelo, y mientras no exista una tarifa medida por encima del compromiso, el crecimiento se convierte en un evento con fecha, propuesta y firma. En el segundo, el gasto ocurre en el uso y llega al aprobador en el cierre del ciclo de facturación, no en el momento de la decisión, y la comparación completa entre los dos está en modelos de precios en marketplace de nube.

Quién mide, y con qué frecuencia

La skill despliega dos stacks de CloudFormation: la de eventos de acuerdo escucha el marketplace, y la de metering transforma uso en línea horaria por dos caminos, registro y medición. La aplicación del proveedor graba las líneas. La grabación no es horaria; la agregación y el envío sí lo son.

El stack de eventos de acuerdo trae la regla de EventBridge sobre aws.agreement-marketplace, una cola SQS y una tabla DynamoDB con un registro por acuerdo y el licenseArn que exige el metering. En el camino de registro, un endpoint de API Gateway recibe el token cuando el comprador configura la cuenta, y una Lambda cambia ese token por identificadores de cliente vía ResolveCustomer.

Ese endpoint es el único punto del diseño en el que el comprador aparece. El resto es del proveedor: un mensaje por licencia y por hora entra en una cola, la agregación suma las líneas por licencia, cuenta, dimensión y hora, y la última función envía en lote por la BatchMeterUsage.

Aquí es donde la fuente deja de describir al comprador. Lo que documenta del lado de quien compra termina en la página de registro. La granularidad horaria existe del lado de quien vende. En la contratación directa, lo que el comprador alcanza a ver dentro del mes depende de lo que el proveedor exponga en el producto; en la compra facturada por el canal, la cantidad medida entra en el cobro por otra vía. Lo que falta es cláusula, no medición: la medición interna da sustento a la objeción, pero por sí sola no tiene contra qué comparar.

Lo que la skill no hace, y por qué importa para quien compra

La parte que la skill no hace es la que decide la calidad del número. Es la aplicación del proveedor la que graba las líneas de uso, a partir de las cuentas donde corre la carga. Construir esa entrada es trabajo del proveedor, y es ella la que define si la factura describe el consumo o solo se le parece.

El post de origen dice dos cosas que, leídas juntas, dibujan la posición del comprador: poner el uso hacia adentro es la parte que el vendedor construye, y el código generado debe revisarse contra los requisitos de seguridad y conformidad del propio proveedor antes de ir a producción.

Eso no es una acusación, es una asimetría de información.

Subreportar no devuelve dinero. Genera corrección retroactiva sin techo contractual o cobro complementario después de que el ciclo cerró, sobre un número ya provisionado. Sobrerreportar crea una disputa que el comprador solo gana con dato propio, medido en el mismo evento y en la misma dimensión del contrato. La pregunta deja de ser si el proveedor mide bien. Pasa a ser otra: qué se compromete a mostrar cuando mide mal. Esa respuesta vive en el contrato, no en el producto.

Del Paso 1 al Paso 4: las cuatro preguntas antes de firmar un contrato por consumo

Cuatro preguntas separan un contrato por consumo que se controla de un contrato que se descubre. Cada una tiene una respuesta que sirve y una que no sirve, y la diferencia rara vez está en lo que el proveedor promete. Está en lo que acepta poner por escrito.

La lista maestra:

1. Qué dimensión mide el contrato, y cómo se mapea al uso real.
2. Con qué frecuencia reporta el proveedor, y qué devuelve al comprador.
3. Qué pasa a mitad del plazo si el consumo crece.
4. Qué pasa si el reporte falla o se atrasa, y quién absorbe la diferencia.

Paso 1: la dimensión medida. Parece técnica. Es la más práctica: usuarios activos, horas de procesamiento, llamadas de API y volumen traficado producen facturas muy distintas sobre el mismo uso. Respuesta buena: la dimensión es un evento que el comprador puede contar de su propio lado, con el mismo criterio. Respuesta mala: una unidad de procesamiento definida en un anexo interno del proveedor, que nadie del lado comprador reproduce.

Paso 2: la frecuencia y el retorno. Respuesta buena: un reporte con la misma dimensión y la misma frecuencia usadas en el cobro, entregado antes de la factura, con plazo de objeción nombrado, nunca más corto que el ciclo de cierre del comprador. Respuesta mala: la frecuencia existe como obligación interna del proveedor y el contrato no nombra nada que llegue al comprador.

Paso 3: la mitad del plazo. En el SaaS contract el crecimiento se captura con nueva oferta y adenda en la renovación, así que la pregunta es sobre aviso, mientras que en SaaS subscriptions llega por la factura y la pregunta es sobre gatillo, que se resuelve con límite escrito, no con fecha de renovación. Respuesta buena: el contrato nombra un límite a partir del cual el proveedor avisa antes de que el consumo se convierta en cobro. Respuesta mala: silencio hasta la renovación, que es exactamente el terreno del riesgo silencioso en la renovación.

Paso 4: la falla del reporte. Todo medidor falla. El contrato tiene que decir qué pasa después. Respuesta buena: regla de reenvío, ventana de corrección retroactiva de uno a dos ciclos, con ajuste por crédito y no por factura complementaria abierta, y definición de quién absorbe la diferencia cuando la corrección no es posible. Respuesta mala: "evaluado caso por caso", que devuelve al proveedor la discrecionalidad sobre su propio error.

Las cuatro respuestas, lado a lado:

¿Y si el proveedor se niega? La negativa es una rama posible, y la pregunta solo tiene consecuencia si el comprador sabe qué hacer con ella. Sin cláusula de reporte, limita la exposición con techo escrito, prepago o compromiso, y el riesgo que acepta pasa a tener valor en lugar de quedar desconocido. Negarse no es motivo para no contratar. Es motivo para contratar sabiendo qué quedó afuera.

Qué poner del lado del comprador

Del lado del comprador, el control de consumo SaaS empieza antes de la firma. El contrato por consumo pide tres cosas: orden de servicio con la cláusula de medición anexada, historial de consumo de los ciclos anteriores en la dimensión cobrada, y cláusula de reporte que nombre formato, periodicidad y plazo de objeción.

La gobernanza se vuelve concreta: presupuesto por dimensión, alerta antes del desborde y conciliación entre la medición interna y la factura.

Parte de esa verificación es planilla, parte es herramienta. La descripción de Nexforce Marketplace lista gestión centralizada de las suscripciones, alertas de presupuesto y de renovación, pago local con nota fiscal en BRL y pago en hasta 12 cuotas con tipo de cambio fijado. La reducción de costo de hasta 50% en soluciones internacionales viene de esa cadena de contratación, no de una tabla de descuento. Para el proceso completo, la política de compras de SaaS y reducir costo de SaaS sin renegociar contrato completan la lectura.

La verificación es una reunión y un archivo: pida el reporte de un ciclo cerrado, en el formato que la cláusula promete, y compárelo línea por línea con la factura de ese ciclo. Si el archivo no existe, la cláusula está en el papel, no en el proceso.

Dos errores se repiten en esa verificación. El primero es medir la dimensión equivocada: el equipo sigue usuarios activos mientras el contrato cobra horas de procesamiento. El segundo es conciliar después del cierre, cuando la corrección ya es negociación de crédito. Las dos correcciones son de proceso: espejar en el panel interno la dimensión exacta del contrato y conciliar antes del cierre.

Preguntas frecuentes

¿El comprador recibe del proveedor el consumo detallado hora a hora?

Depende de lo que el proveedor exponga. La granularidad horaria existe en el reporte que el proveedor envía al marketplace, y no es un derecho automático de quien compra. El contrato puede exigir un reporte con la misma dimensión y la misma frecuencia usadas en el cobro, y eso es lo que transforma el dato en cláusula verificable.

¿La cláusula de reporte cambia algo en el SaaS contract?

Cambia, y no es para verificar consumo en la factura del mes. En ese modelo el número que cambia es el de la renovación, y la propuesta de nueva oferta llega con el volumen que el proveedor midió solo. La cláusula define qué entrega de dato antes de esa conversación y qué puede objetar el comprador. Sin ella, la renovación se discute sobre una medición de un solo lado.

¿El cobro por uso es siempre más barato que el SaaS contract?

No. El modelo cobra el consumo, que varía. Medir en la misma dimensión del contrato y tener cláusula de reporte le dan al comprador verificación, no descuento. El precio cae cuando el consumo cae o la tarifa se renegocia, y ninguna de las dos cosas viene del modelo de cobro. Sin verificación, solo traslada la variación al presupuesto.

¿Cómo debe aprobarse el presupuesto en este modelo?

Por dimensión, con techo y alerta, en lugar de una línea fija por proveedor. El valor aprobado se convierte en un límite con gatillo de aviso, y el comprador necesita saber quién responde cuando el gatillo se dispara. Aprobar un número cerrado para un gasto variable es el error que la factura cobra meses después.

¿Qué es el cobro por uso?

El cobro por uso es el modelo en el que el comprador paga por lo que consume, medido en una dimensión declarada en el contrato, en lugar de una licencia fija por plazo. El proveedor graba las líneas y las reporta al marketplace, y la factura llega en el ciclo acordado. La definición desplaza el riesgo: el valor deja de ser previsible por el contrato y pasa a depender del consumo dentro del mes.

Referencias y Lectura Complementaria

Fuentes primarias

• Build AWS Marketplace SaaS metering with the metering agent skill, AWS Marketplace, 13 de octubre de 2026, consultado el 21/10/2026.
• SaaS pricing models, AWS Marketplace Buyer Guide, consultado el 21/10/2026.

Lectura complementaria

• Modelos de precios en marketplace de nube
• Riesgo silencioso en la renovación
• Política de compras de SaaS
• Reducir costo de SaaS sin renegociar contrato
• Comprar software en marketplace de nube

Qué hacer con esto en la próxima renovación

Un contrato por uso no es más barato por definición. Medir el propio consumo en la misma dimensión del proveedor compra verificación, no descuento: lo que abarata es consumir menos o negociar tarifa, y esa conversación se decide antes de la firma, no en la factura. Tres acciones, en el orden en que rinden resultado.

Primero, pedir el reporte de un ciclo cerrado, que es el examen de la cláusula. Segundo, fijar formato, periodicidad, responsable del envío y plazo de objeción. Tercero, montar la medición interna en la dimensión del contrato: sin ella, la objeción se vuelve opinión contra planilla. En ese orden, no en otro.

Para quien va a cambiar de canal, la compra de software en marketplace empieza por el mismo examen, y comprar software en marketplace de nube describe el camino. Para quien renueva en el canal actual sin cláusula de reporte, el costo llega en el ciclo siguiente: la variación del mes entra en el presupuesto de software como costo heredado, y la objeción se convierte en crédito negociado después de que la provisión cerró.