Cobrança por uso: o consumo é medido de hora em hora, a fatura chega uma vez

Um contrato de software assinado em janeiro chega ao financeiro em outubro com um número que ninguém aprovou. Não houve erro de cálculo. Houve consumo.
No modelo de cobrança por uso, o comprador paga pelo que consome, e do lado de quem vende o consumo é reportado ao marketplace de hora em hora. Nessa modalidade, que o AWS Marketplace nomeia como SaaS subscriptions, cada licença, cada conta e cada dimensão de uso viram uma linha com data e hora. Do lado de quem compra, o que chega de forma automática é a fatura, que segue o ciclo do fornecedor ou do canal, não o relógio do medidor; o intervalo entre uma fatura e outra depende do que o fornecedor expõe no produto.
Quem assina um contrato de software internacional é controller, gerente de compras ou líder de TI, e responde pela linha do orçamento. A distância entre os dois relógios decide se esse número cabe no mês. A pergunta que organiza o resto não é quanto custa a licença. É quem mede, de quanto em quanto tempo, e o que chega no meio do mês.
O que muda na cobrança por uso quando medir deixa de ser caro
A premissa é simples: integrar medição sempre exigiu engenharia do fornecedor. Em 13 de outubro de 2026, o AWS Marketplace publicou uma skill de metering que gera o código de integração dentro da IDE. O efeito para o comprador não é preço menor. A leitura possível é mais fornecedor com medidor ligado.
A skill chega pelo AWS MCP Server e conduz a construção da integração de metering: levanta as dimensões de uso do produto, recomenda uma abordagem de API e entrega o código com os templates AWS SAM, que o fornecedor revisa e implanta. A skill só implanta direto uma listagem Limited; num produto publicado, o código volta para o pipeline do fornecedor.
O que cai é o custo de medir. O preço do software não se move por causa disso.
E medir não é ato neutro. O medidor é código que o fornecedor escreve, opera e corrige, e a fatura é a saída desse código depois de o marketplace consolidar o reporte. Granularidade do dado e confiança no dado são duas coisas diferentes.
Os dois modelos de preço capturam o crescimento em momentos diferentes
O post nomeia dois modelos. Eles são distintos. No SaaS contract, o crescimento no meio do prazo é capturado por nova oferta e aditivo na renovação. No SaaS subscriptions, o comprador paga pelo que consome, e o crescimento pode aparecer no reporte de receita do fornecedor dentro da hora.
A diferença que importa para quem aprova orçamento é o instrumento. No primeiro modelo, e enquanto não houver tarifa metrada acima do compromisso, o crescimento vira um evento com data, proposta e assinatura. No segundo, o gasto acontece no uso e chega ao aprovador no fechamento do ciclo de faturamento, não no momento da decisão, e a comparação completa entre os dois está em modelos de precificação em marketplace de nuvem.
Quem mede, e com que frequência
A skill implanta duas stacks CloudFormation: a de eventos de acordo escuta o marketplace, e a de metering transforma uso em linha horária por dois caminhos, registro e medição. A aplicação do fornecedor grava as linhas. A gravação não é horária; a agregação e o envio são.
A stack de eventos de acordo traz a regra do EventBridge sobre aws.agreement-marketplace, uma fila SQS e uma tabela DynamoDB com um registro por acordo e o licenseArn que o metering exige. No caminho de registro, um endpoint do API Gateway recebe o token quando o comprador configura a conta, e uma Lambda troca esse token por identificadores de cliente via ResolveCustomer.
Esse endpoint é o único ponto do desenho em que o comprador aparece. O resto é do fornecedor: uma mensagem por licença e por hora entra numa fila, a agregação soma as linhas por licença, conta, dimensão e hora, e a última função envia em lote pela BatchMeterUsage.
É aqui que a fonte para de descrever o comprador. O que ela documenta do lado de quem compra termina na página de registro. A granularidade horária existe do lado de quem vende. Na contratação direta, o que o comprador enxerga dentro do mês depende do que o fornecedor expõe no produto; na compra faturada pelo canal, a quantidade metrada entra na cobrança por outra via. O que falta é cláusula, não medição: a medição interna dá lastro à contestação, mas sozinha não tem contra o que comparar.
O que a skill não faz, e por que isso importa para quem compra
A parte que a skill não faz é a que decide a qualidade do número. É a aplicação do fornecedor que grava as linhas de uso, a partir das contas onde a carga roda. Construir essa entrada é trabalho do fornecedor, e é ela que define se a fatura descreve o consumo ou apenas se parece com ele.
O post de origem diz duas coisas que, lidas juntas, desenham a posição do comprador: colocar o uso para dentro é a parte que o vendedor constrói, e o código gerado deve ser revisado contra os requisitos de segurança e conformidade do próprio fornecedor antes de ir para produção.
Isso não é uma acusação, é uma assimetria de informação.
Subnotificar não devolve dinheiro. Gera correção retroativa sem teto contratual ou cobrança complementar depois que o ciclo fechou, sobre um número já provisionado. Supernotificar cria uma disputa que o comprador só ganha com dado próprio, medido no mesmo evento e na mesma dimensão do contrato. A pergunta deixa de ser se o fornecedor mede bem. Passa a ser outra: o que ele se compromete a mostrar quando mede errado. Essa resposta mora no contrato, não no produto.
Do Passo 1 ao Passo 4: as quatro perguntas antes de assinar um contrato por consumo
Quatro perguntas separam um contrato por consumo que se controla de um contrato que se descobre. Cada uma tem uma resposta que serve e uma que não serve, e a diferença raramente está no que o fornecedor promete. Está no que ele aceita colocar por escrito.
A lista mestra:
- Qual dimensão o contrato mede, e como ela mapeia o uso real.
- Com que frequência o fornecedor reporta, e o que ele devolve ao comprador.
- O que acontece no meio do prazo se o consumo crescer.
- O que acontece se o reporte falhar ou atrasar, e quem absorve a diferença.
Passo 1: a dimensão medida. Parece técnica. É a mais prática: usuários ativos, horas de processamento, chamadas de API e volume trafegado produzem faturas muito diferentes sobre o mesmo uso. Resposta boa: a dimensão é um evento que o comprador consegue contar do próprio lado, com o mesmo critério. Resposta ruim: uma unidade de processamento definida em anexo interno do fornecedor, que ninguém do lado comprador reproduz.
Passo 2: a frequência e o retorno. Resposta boa: um relatório com a mesma dimensão e a mesma frequência usadas na cobrança, entregue antes da fatura, com prazo de contestação nomeado, nunca mais curto que o ciclo de fechamento do comprador. Resposta ruim: a frequência existe como obrigação interna do fornecedor e o contrato não nomeia nada que chegue ao comprador.
Passo 3: o meio do prazo. No SaaS contract o crescimento é capturado por nova oferta e aditivo na renovação, então a pergunta é sobre aviso, enquanto no SaaS subscriptions ele chega pela fatura e a pergunta é sobre gatilho, que se resolve com limite escrito, não com data de renovação. Resposta boa: o contrato nomeia um limite a partir do qual o fornecedor avisa antes de o consumo virar cobrança. Resposta ruim: silêncio até a renovação, que é exatamente o terreno do risco silencioso na renovação.
Passo 4: a falha do reporte. Todo medidor falha. O contrato precisa dizer o que acontece depois. Resposta boa: regra de reenvio, janela de correção retroativa de um a dois ciclos, com acerto por crédito e não por fatura complementar aberta, e definição de quem absorve a diferença quando a correção não é possível. Resposta ruim: "analisado caso a caso", que devolve ao fornecedor a discricionariedade sobre o próprio erro.
As quatro respostas, lado a lado:
| Pergunta | Resposta boa | Resposta ruim |
|---|---|---|
| Qual dimensão o contrato mede | Evento que o comprador conta do próprio lado, no mesmo critério. | Unidade definida em anexo interno do fornecedor. |
| Com que frequência o fornecedor reporta | Relatório na dimensão e na frequência da cobrança, antes da fatura. | Obrigação interna, sem nada que chegue ao comprador. |
| O que muda no meio do prazo | Limite nomeado, com aviso antes de o consumo virar cobrança. | Silêncio até a renovação. |
| O que acontece se o reporte falhar | Regra de reenvio, janela de correção, quem absorve a diferença. | "Analisado caso a caso". |
E se o fornecedor recusar? A recusa é um ramo possível, e a pergunta só tem consequência se o comprador souber o que fazer com ela. Sem cláusula de reporte, ele limita a exposição por teto escrito, pré-pago ou compromisso, e o risco que aceita passa a ter valor em vez de ficar desconhecido. Recusar não é motivo para não contratar. É motivo para contratar sabendo o que ficou de fora.
O que colocar do lado do comprador
Do lado do comprador, o controle de consumo SaaS começa antes da assinatura. O contrato por consumo pede três coisas: ordem de serviço com a cláusula de medição anexada, histórico de consumo dos ciclos anteriores na dimensão cobrada, e cláusula de reporte que nomeie formato, periodicidade e prazo de contestação.
A governança fica concreta: orçamento por dimensão, alerta antes do estouro e reconciliação entre a medição interna e a fatura.
Parte dessa conferência é planilha, parte é ferramenta. A descrição do Nexforce Marketplace lista gestão centralizada das assinaturas, alertas de orçamento e de renovação, pagamento local com nota fiscal em BRL e parcelamento em até 12x com câmbio travado. A redução de custo de até 50% em soluções internacionais vem dessa cadeia de contratação, não de uma tabela de desconto. Para o processo inteiro, a política de compras de SaaS e reduzir custo de SaaS sem renegociar contrato completam a leitura.
A verificação é uma reunião e um arquivo: peça o relatório de um ciclo fechado, no formato que a cláusula promete, e compare linha por linha com a fatura daquele ciclo. Se o arquivo não existe, a cláusula está no papel, não no processo.
Dois erros se repetem nessa conferência. O primeiro é medir a dimensão errada: o time acompanha usuários ativos enquanto o contrato cobra horas de processamento. O segundo é reconciliar depois do fechamento, quando a correção já é negociação de crédito. As duas correções são de processo: espelhar no painel interno a dimensão exata do contrato e reconciliar antes do fechamento.
Perguntas frequentes
O comprador recebe do fornecedor o consumo detalhado hora a hora?
Depende do que o fornecedor expõe. A granularidade horária existe no reporte que o fornecedor envia ao marketplace, e não é um direito automático de quem compra. O contrato pode exigir um relatório com a mesma dimensão e a mesma frequência usadas na cobrança, e é isso que transforma o dado em cláusula verificável.
A cláusula de reporte muda algo no SaaS contract?
Muda, e não é para conferir consumo na fatura do mês. Nesse modelo o número que muda é o da renovação, e a proposta de nova oferta chega com o volume que o fornecedor mediu sozinho. A cláusula define o que ele entrega de dado antes dessa conversa e o que o comprador pode contestar. Sem ela, a renovação se discute sobre uma medição de um lado só.
Cobrança por uso é sempre mais barata que SaaS contract?
Não. O modelo cobra o consumo, que varia. Medir na mesma dimensão do contrato e ter cláusula de reporte dão ao comprador verificação, não desconto. O preço cai quando o consumo cai ou a tarifa é renegociada, e nenhuma das duas coisas vem do modelo de cobrança. Sem verificação, ele só transfere a variação para o orçamento.
Como o orçamento deve ser aprovado nesse modelo?
Por dimensão, com teto e alerta, em vez de uma linha fixa por fornecedor. O valor aprovado vira um limite com gatilho de aviso, e o comprador precisa saber quem responde quando o gatilho dispara. Aprovar um número fechado para um gasto variável é o erro que a fatura cobra meses depois.
O que é cobrança por uso?
Cobrança por uso é o modelo em que o comprador paga pelo que consome, medido em uma dimensão declarada no contrato, em vez de uma licença fixa por prazo. O fornecedor grava as linhas e as reporta ao marketplace, e a fatura chega no ciclo acordado. A definição desloca o risco: o valor deixa de ser previsível pelo contrato e passa a depender do consumo dentro do mês.
Referências e Leitura Complementar
Fontes primárias
- Build AWS Marketplace SaaS metering with the metering agent skill, AWS Marketplace, 13 de outubro de 2026, acesso em 21/10/2026.
- SaaS pricing models, AWS Marketplace Buyer Guide, acesso em 21/10/2026.
Leitura complementar
- Modelos de precificação em marketplace de nuvem
- Risco silencioso na renovação
- Política de compras de SaaS
- Reduzir custo de SaaS sem renegociar contrato
- Comprar software em marketplace de nuvem
O que fazer com isso na próxima renovação
Contrato por uso não é mais barato por definição. Medir o próprio consumo na mesma dimensão do fornecedor compra verificação, não desconto: o que barateia é consumir menos ou negociar tarifa, e essa conversa se decide antes da assinatura, não na fatura. Três ações, na ordem em que rendem resultado.
Primeiro, pedir o relatório de um ciclo fechado, que é o teste da cláusula. Segundo, fixar formato, periodicidade, responsável pelo envio e prazo de contestação. Terceiro, montar a medição interna na dimensão do contrato: sem ela, a contestação vira opinião contra planilha. Nessa ordem, não em outra.
Para quem vai trocar de canal, a compra de software em marketplace começa pelo mesmo teste, e comprar software em marketplace de nuvem descreve o caminho. Para quem renova no canal atual sem cláusula de reporte, o custo chega no ciclo seguinte: a variação do mês entra no orçamento de software como custo herdado, e a contestação vira crédito negociado depois que a provisão fechou.

Contrate softwares internacionais e IAcom faturamento local economizando até 50%
Nacionalize a contratação de ferramentas de tecnologia garantindo total compliance e máxima eficiência financeira
Fazer SimulaçãoArtigos relacionados

Meta Muse Spark Open: pesos abertos de 816B que rodam em dois Mac Studios
A Meta publicou os pesos do Muse Spark Open, modelo multimodal de 816B parâmetros totais e 42B ativos com contexto de 1M tokens. A peça decompõe a arquitetura esparsa que permite essa combinação, as condições reais de execução em dois Mac Studios com MLX e o que a oferta muda na decisão entre modelo hospedado e execução própria.
Read more
Impostos na remessa de SaaS: quanto sua empresa paga
IRRF, CIDE, PIS/COFINS e IOF: veja quanto um SaaS do exterior custa além da licença, com exemplo numérico da remessa do comprador brasileiro.
Read more
Como Calcular o Custo Total de uma Assinatura de Software para a Equipe de TI
Aprenda a calcular o TCO real de assinaturas de software corporativo, desmembrando impostos de importação, spread cambial e custos operacionais ocultos.
Read more