Usage-based billing (UBB) — ou cobrança baseada em uso — é o modelo em que o cliente paga pelo que realmente consumiu, e não por um volume fixo acordado de antemão. Em vez de assinar um plano com um teto de uso mensal, o cliente paga proporcionalmente à quantidade de chamadas de API, tokens processados, usuários ativos, gigabytes armazenados ou qualquer outra métrica relevante para o seu produto.

O modelo existe há décadas nas utilities (energia elétrica, água, telefonia). No SaaS B2B, ele ganhou tração de verdade com infraestrutura cloud e APIs — e hoje é a base de negócios como Stripe, Twilio, AWS e Snowflake.

Por que o UBB está crescendo no SaaS B2B

A adoção do usage-based billing não é uma tendência passageira — é uma resposta direta à mudança de como empresas de tecnologia entregam e consomem valor. Três forças explicam esse movimento:

  • Alinhamento com o valor percebido: o cliente paga exatamente pelo que usa. Isso elimina a fricção do processo comercial e reduz o risco percebido na adoção.
  • Expansão orgânica de receita: clientes que crescem automaticamente geram mais receita sem precisar de renegociação de contrato.
  • Menor churn nos primeiros meses: sem comprometimento de volume mínimo, a barreira de entrada cai e o tempo até o primeiro valor diminui.

As variações do modelo: o UBB não é uma coisa só

Um erro comum é tratar "usage-based" como um modelo único. Na prática, há diversas variações que combinam estruturas diferentes:

Pay-as-you-go puro

O cliente paga exatamente pelo que consumiu no período, sem mínimo e sem compromisso. É o modelo da AWS EC2: você liga a instância, ela roda, você paga. É simples, mas oferece a menor previsibilidade de receita para o fornecedor.

Commit + overage

O cliente compromete um volume mínimo por período (geralmente anual) e paga um preço por unidade sobre o excedente. Combina a previsibilidade do contrato com a flexibilidade do uso real. É o modelo favorito para enterprise deals.

Tiered (faixas de volume)

O preço por unidade muda em faixas de volume. Quanto mais o cliente usa, mais barato fica cada unidade incremental. Incentiva crescimento e cria um mecanismo natural de volume discount sem negociação manual.

No UBB bem estruturado, o sucesso do cliente vira sucesso do fornecedor. Quando o cliente cresce, a receita cresce automaticamente — sem renegociação, sem friction.

O problema real: implementar UBB é difícil

A proposta de valor do UBB é clara. O problema está na execução. Cobrar pelo uso exige infraestrutura que a maioria das empresas subestima:

  • Coleta e agregação de eventos de uso — você precisa de um pipeline confiável que capture, armazene e agregue métricas de uso em tempo real.
  • Motor de cálculo por regras de contrato — cada cliente pode ter um preço, uma faixa, um commit e um ciclo diferente. O motor precisa ser parametrizável por contrato.
  • Geração de fatura com memória de cálculo — o cliente precisa entender o que está sendo cobrado. Uma fatura de usage sem breakdown granular é receita para disputa.
  • Reconciliação com pagamentos — o mapeamento entre o evento de uso, a fatura emitida e o pagamento recebido precisa ser rastreável.

Empresas que constroem isso internamente geralmente levam 6 a 18 meses para ter algo funcional — e mais 12 meses para confiar no número. O custo de manutenção é subestimado, e o débito técnico se acumula silenciosamente.

Como escolher a métrica de uso certa

A escolha da unidade de cobrança é uma decisão estratégica, não técnica. A métrica ideal deve:

  • Correlacionar com o valor que o cliente percebe
  • Ser mensurável com precisão e auditável pelo cliente
  • Crescer naturalmente com o sucesso do cliente
  • Ser simples o suficiente para aparecer num email de cobrança sem precisar de explicação

Exemplos que funcionam bem: chamadas de API, tokens de IA, transações processadas, documentos gerados, usuários ativos mensais, registros sincronizados. Exemplos que criam atrito: métricas técnicas que o cliente não consegue acompanhar (CPU-hours, IOPS), ou que variam por razões fora do controle dele.

UBB e previsibilidade de receita: mito vs. realidade

A principal objeção ao UBB de times de finanças é a imprevisibilidade de receita. A objeção é real, mas parcialmente equivocada.

Em clientes com histórico de uso, o padrão de consumo é altamente previsível — especialmente em bases estáveis. A variância vem de clientes novos e de eventos excepcionais (campanhas, lançamentos, picos sazonais). Commit contracts existem exatamente para resolver isso: o cliente garante uma base mínima de receita, e o upside fica com o fornecedor.

A Snowflake, que opera quase integralmente em UBB, reporta métricas de previsibilidade de receita com alta acurácia — graças a um modelo maduro de análise de padrões de consumo por cliente.

O que a Aira resolve no UBB

A Aira foi construída para operar exatamente esse cenário. Nossa plataforma recebe os eventos de uso do seu produto, aplica as regras de cobrança de cada contrato — faixas, overages, commits, descontos, ciclos customizados — e gera a fatura com a memória de cálculo completa.

Sem pipeline de dados interno. Sem motor de cálculo customizado. Sem risco de erros que só aparecem no email do cliente.