Assinaturas vs cobrança por uso explicados sob a ótica de modelagem de dados: medidores, limites, faturas, prorrateamento e os registros a armazenar desde o primeiro dia.
Preço não é só uma página no seu site. Ele determina o que você precisa registrar, como reportar e se você consegue explicar uma cobrança meses depois. Ao escolher entre assinaturas e cobrança por uso, você também escolhe a forma dos seus dados de cobrança.
Uma assinatura simples muitas vezes pode ser calculada a partir de poucos fatos: plano, período de cobrança, data de início e descontos. Preço por uso precisa de mais: o que foi usado, quando aconteceu, a qual cliente pertenceu e como esse uso vira dinheiro. Sem esses registros, você pode até enviar faturas, mas não consegue defendê-las.
Adicionar uso depois sem planejamento geralmente falha em três pontos:
O objetivo é chato, mas essencial: calcular a mesma fatura da mesma forma todas as vezes. Isso significa que você pode reproduzir o cálculo a partir de fatos armazenados (termos do plano, regras de medidor, eventos de uso e a versão exata de preços aplicada).
Uma “visão de modelagem” só significa descrever cobrança como blocos de construção que se encaixam, mesmo que você não seja engenheiro. Imagine um produto de chat em equipe:
Para suportar isso depois, seus dados precisam responder: qual workspace, qual mês, quantas mensagens, o que estava incluído e quais regras de preço estavam ativas.
Assinaturas cobram pelo acesso. Cobrança por uso cobra pelo consumo. Elas se comportam de maneira bem diferente quando há upgrades, downgrades, prorrateamento e casos de borda do mundo real.
Com uma assinatura, a pergunta-chave é: “O cliente tinha direito de usar o produto durante esse período?” Você rastreia principalmente plano, número de assentos, período de cobrança e se a fatura foi paga. Uso ainda importa, mas muitas vezes aparece como limites (soft ou hard) em vez de itens de linha.
Com cobrança por uso, a pergunta-chave vira: “O que aconteceu, exatamente, e quando?” Você precisa de metrologia confiável, regras claras de quando o uso é contado e uma maneira de explicar cada cobrança depois. Mesmo que sua UI mostre um número (como “1.243 chamadas de API”), por trás dele há um conjunto de eventos que precisa ser consistente e auditável.
Muitas equipes B2B SaaS acabam num modelo híbrido: taxa base que cobre um pacote, mais excedentes.
A maioria dos modelos híbridos segue formas familiares:
Previsibilidade ajuda quando clientes precisam de aprovação orçamentária e gasto mensal estável. Pay-as-you-go funciona melhor quando valor escala com atividade (por exemplo, “por fatura processada”), ou quando clientes estão testando e querem baixo risco.
Mudanças de plano são garantidas. Preços, pacotes e embalagens vão mudar. Desenhe a cobrança para que você possa adicionar um novo medidor, introduzir um novo tier ou mudar o que “incluso” significa sem reescrever o histórico. Uma regra prática: armazene o plano do cliente e os termos de preço como eram no momento da cobrança, não apenas como são hoje.
Um medidor é a coisa exata pela qual você cobra, escrita tão claramente que duas pessoas contando chegam ao mesmo número. Ele tem três partes: o evento (o que aconteceu), a unidade (o que você conta) e o tempo (quando é contado).
A maioria das disputas começa aqui. Um lado pensa que paga por resultados, o outro cobra por atividade mensurável.
Escolha medidores que mapeiem para ações reais do produto e possam ser gravados automaticamente. Exemplos comuns:
Depois defina o que conta e o que não conta. Se você cobra por chamada de API, decida se retries contam, se respostas 4xx e 5xx contam, e se chamadas internas de integrações próprias contam.
O tempo importa tanto quanto a unidade. Assentos costumam funcionar melhor como um snapshot em um ponto no tempo por período de cobrança. Chamadas de API geralmente são somadas dentro de uma janela. Armazenamento é complicado: clientes esperam pagar pelo “quanto você armazenou”, que normalmente significa uma média ao longo do tempo, não o pico.
Também decida o escopo: por conta, ou por workspace/projeto. Uma regra simples: se times podem ser cobrados separadamente, medidores devem ser por workspace.
Entitlements são as regras sobre o que um cliente tem direito a fazer por causa do que comprou. Elas respondem: quantos usuários podem adicionar? Quais recursos estão habilitados? Qual volume é permitido por mês? Entitlements ficam entre acesso e cobrança: moldam o que o produto permite, enquanto a medição registra o que realmente aconteceu.
Mantenha entitlements separados da lógica de medição. Entitlements devem ser legíveis e estáveis (plano, add-ons, termos contratuais). A medição vai evoluir conforme o produto evolui (novos eventos, novos medidores), e você não quer que cada mudança de medidor arrisque quebrar o acesso.
Limites hard, soft e cobrança por overage podem parecer semelhantes na UI, mas se comportam de maneiras muito diferentes:
Decida com antecedência o que acontece quando um limite é excedido. Exemplo: um time no tier “Starter” inclui 5 assentos e 10.000 chamadas de API por mês. Se convidarem um 6º usuário, você bloqueia, começa a cobrar por assento extra ou permite por 7 dias como carência? Cada escolha precisa de uma regra que você possa mostrar em uma fatura e nos registros de suporte.
Armazene entitlements como registros com limite de tempo: cliente, plano ou add-on, timestamps de início e fim, valores de limite e modo de aplicação (hard, soft, overage). Isso mantém decisões de acesso e cobrança consistentes.
Uma fatura não é só um PDF. É uma trilha de auditoria que responde: quem foi cobrado, por quê, por quais datas e sob quais regras. Se você mudar preços, ainda deve ser capaz de reconstruir faturas antigas exatamente como eram.
Comece com alguns registros centrais: Customer, Subscription (ou Contract), Billing Period e Invoice com Line Items. Cada item de linha deve apontar para sua origem: taxa do plano, resumo de uso ou cobrança pontual. Esse link é o que torna a cobrança explicável quando alguém contesta uma cobrança.
Períodos de cobrança precisam de uma âncora e de um fuso horário. “Mensal” não é suficiente. Armazene a data âncora do ciclo (por exemplo, dia 15 às 00:00) e o fuso horário usado para cortar os períodos. Mantenha isso consistente ou você terá problemas de um dia a mais/perdido em torno do horário de verão.
Faturas auditáveis geralmente requerem:
Reconhecimento de receita está relacionado, mas não é a mesma coisa que cobrança. Uma taxa de assinatura pré-paga normalmente é reconhecida ao longo do período de serviço, enquanto uso é frequentemente reconhecido quando entregue. Mesmo que você mantenha isso em alto nível, armazene datas suficientes para suportar isso depois.
Trate notas de crédito, reembolsos e ajustes como registros de primeira classe, nunca como edições de faturas antigas. Se um cliente faz upgrade no meio do ciclo, crie uma linha de ajuste ou nota de crédito que referencie a fatura original e indique a regra de prorrateamento usada.
Chaves de idempotência importam para geração de faturas e tentativas de pagamento. Se um job rodar duas vezes, você quer uma fatura, uma cobrança e um log claro.
Mudanças no meio do ciclo são onde começam as discussões de cobrança. Se alguém faz upgrade no dia 20, pausa por uma semana e depois cancela, você precisa de regras que transformem essas ações em números que façam sentido na fatura.
Decida que mudanças você permite e quando elas entram em vigor. Muitas equipes aplicam upgrades imediatamente para que o cliente receba valor na hora, mas aplicam downgrades na renovação para evitar reembolsos complicados.
Prorrateamento pode ser diário, por hora ou inexistente. Quanto mais preciso você for, mais timestamps, regras de arredondamento e casos de borda precisa armazenar e testar.
Trave as escolhas de política cedo:
Evite matemática oculta. Represente prorrateamentos como ajustes explícitos na fatura, como um débito pelo tempo restante no novo plano e um crédito pelo tempo não usado no plano antigo. Cada item de linha deve apontar para o evento de mudança exato que o causou (change_id) e incluir a janela de prorrateamento (start_at, end_at), base de quantidade/tempo e categoria de imposto.
Medidores de uso adicionam mais uma decisão: quando um plano muda, os medidores resetam, continuam acumulando ou se dividem em segmentos? Uma abordagem simples e auditável é segmentar uso por versão de plano. Exemplo: um cliente faz upgrade de 10 para 25 assentos no meio do mês. Você mantém eventos de uso como estão, mas a tarifação os agrupa pelo período de entitlement ativo no momento.
Decida o que é reversível. Ajuda tratar eventos de uso como finais uma vez aceitos, enquanto mudanças de assinatura podem ser reversíveis apenas até a fatura ser finalizada. Armazene eventos de mudança e ajustes de fatura para que você possa regenerar faturas quando regras evoluírem.
Se você esperar para desenhar dados de cobrança até os clientes reclamarem, vai acabar chutando. Seja assinatura, uso ou um modelo híbrido B2B SaaS, o ponto de partida mais seguro é um pequeno conjunto de registros que você sempre pode auditar depois.
Comece com uma hierarquia clara de cliente. Em B2B SaaS, o pagador é geralmente uma conta empresa, mas uso frequentemente acontece dentro de workspaces ou projetos, e ações vêm de usuários individuais. Armazene os três níveis (account, workspace, user) e registre quem fez o quê. Disputas de cobrança muitas vezes viram “qual time fez isso?”
Um desenho mínimo de banco de dados de cobrança que suporta faturas reais e investigações limpas:
Não confie apenas em contadores agregados. Mantenha contadores para velocidade, mas trate o log de eventos como fonte da verdade. Uma regra simples ajuda: eventos são imutáveis, correções são novos eventos (por exemplo, quantidade negativa), e cada evento se vincula a uma definição de medidor específica.
Exemplo: um cliente diz que suas “chamadas de API” dobraram no mês passado. Se você consegue puxar eventos brutos por workspace e dia, você pode mostrar de onde veio o pico ou identificar um loop de integração.
A parte difícil não é a matemática. É fazer o resultado explicável meses depois, mesmo depois que planos, preços e clientes mudem.
Configure produtos, planos, medidores e preços com datas efetivas. Nunca sobrescreva um preço antigo. Se um cliente é cobrado em março, você precisa poder reexecutar março usando o catálogo de março.
Exemplo: “Chamadas de API” custam $0,002 cada a partir de 1º de abril. Faturas de março devem continuar usando a tarifa antiga.
No início de cada período de cobrança (ou quando uma mudança acontece), armazene um snapshot de entitlement: plano, unidades incluídas, limites, regras de tiers, descontos e configurações de imposto. Pense nisso como “o que prometemos” para aquele período.
Uso deve chegar como eventos imutáveis: timestamp, cliente, medidor, quantidade e um id único para deduplicação. Valide o básico na entrada (medidor faltando, quantidade negativa, timestamps impossíveis) e registre o evento bruto mesmo que você também armazene uma versão limpa.
Depois faça o cálculo em duas passadas:
Gere itens de linha de fatura que referenciem os inputs exatos usados (versão do catálogo, id do snapshot, id da agregação).
Por fim, bloqueie a fatura. Armazene os inputs do cálculo e o output, marque como final e impeça alterações quando eventos tardios chegarem. Eventos tardios devem ir para a próxima fatura (ou um ajuste separado) com uma nota de auditoria clara.
Clientes não se importam se você escolheu assinatura ou cobrança por uso. Eles querem que seus números batam com os deles e que consigam prever a próxima cobrança antes que ela aconteça.
Relatórios para clientes funcionam melhor como uma página de cobrança simples que responde algumas perguntas sem tickets de suporte:
Internamente, suporte e finanças precisam explicar um número, não apenas exibí-lo. Isso significa detectar picos, rastrear mudanças e separar matemática de preview da cobrança finalizada.
Mantenha previews de fatura separados das faturas. Previews podem ser recalculados quando uso tardio chega ou quando você refina um medidor. Faturas finalizadas não devem.
Seu relatório interno deve facilitar sinalizar anomalias (picos súbitos de uso, uso negativo, eventos duplicados), reproduzir um item de linha da fatura a partir do uso bruto e das regras, e ver mudanças de plano e regras de prorrateamento para o período.
Trilhas de auditoria importam mais do que a maioria das equipes espera. Se um cliente diz “Fizemos upgrade no dia 12”, você precisa de timestamps, ator (usuário, admin, automação) e os valores exatos antes/depois para plano, assentos, limites e taxas do medidor.
Para retenção, guarde eventos brutos de uso e artefatos de fatura finalizados por longo prazo. Uma regra prática: se isso pode mudar o valor cobrado ou ajudar a defendê-lo em uma disputa, armazene de forma imutável.
A maioria das disputas não é sobre preço. Acontece quando você não consegue explicar um número na fatura, ou quando os mesmos inputs geram um total diferente depois.
Um erro comum é manter apenas totais mensais. Sem eventos brutos, você não consegue responder perguntas simples como “Que dia nos fez ultrapassar o limite?” Guarde o evento, depois agregue.
Outro problema frequente é mudar o significado de um medidor sem versioná-lo. “Usuário ativo” pode começar como “fez login ao menos uma vez” e depois virar “criou um registro”. Se você não versionar definições de medidor, clientes vão comparar faturas antigas com novas e você não terá como provar qual regra se aplicou.
Disputas costumam vir dos mesmos padrões:
Exemplo: um cliente em Tóquio faz upgrade no meio do ciclo no dia 31, horário local. Se você armazena só um timestamp em UTC e sem âncora de cobrança, o upgrade pode aparecer como dia 30 no seu sistema, deslocando prorrateamento e uso para o período errado.
A forma mais rápida de perder confiança é não ter como reproduzir um cálculo de fatura antigo. Armazene os inputs (eventos, versões, âncoras e preços aplicados) para que você possa reexecutar a mesma lógica depois e obter o mesmo resultado, mesmo depois das mudanças no produto.
Antes de ir ao ar, faça um ensaio: escolha um cliente aleatório e recrie a última fatura usando apenas dados armazenados. Se você precisa de “o que o código fez na época”, você não tem trilha de auditoria.
Garanta que todo medidor seja inequívoco. Um medidor precisa de uma unidade clara (requisições, assentos, GB, minutos), uma fonte confiável (qual serviço emite) e uma janela de tempo (por dia, por período de cobrança, por mês calendário). Se você não consegue explicar o medidor em uma frase, clientes não vão confiar nele.
Verificações rápidas que pegam a maioria dos problemas de cobrança:
Exemplo: um cliente faz upgrade de 10 para 25 assentos no dia 18 e cruza um limite de uso no dia 23. Seu sistema deve mostrar (1) qual versão do plano estava ativa em cada data, (2) o evento de mudança de assentos com timestamp, (3) a fórmula de prorrateamento usada e (4) os eventos de uso que compuseram o total final.
Comece pequeno, mas não comece vago. O caminho mais seguro é o menor modelo de dados que ainda permita responder uma pergunta meses depois: “Por que cobramos esse valor?”
Protótipo seu esquema de cobrança e telas administrativas cedo, antes da primeira mudança de preço. Se você esperar até o time de vendas pedir um novo tier ou um upgrade no meio do ciclo, vai acabar remendando lógica em muitos lugares.
Uma divisão prática é: deixe o Stripe cuidar de cobranças, recibos e tentativas de pagamento, mas mantenha o rating (como uso vira itens de linha) no seu próprio sistema. Isso significa armazenar eventos brutos de uso, versões de preço e os resultados do cálculo usados para gerar um preview de fatura.
Um plano de lançamento simples que mantém flexibilidade:
Se quiser avançar rápido sem escrever muito código de back office, você pode modelar essas entidades no AppMaster e construir as telas administrativas e do portal com suas ferramentas visuais, mantendo PostgreSQL como sistema de registro para eventos e faturas.
Exemplo concreto: você lança com um medidor de assentos. Três meses depois adiciona GB de armazenamento. Se medidores, entitlements e regras de preço forem versionados, você pode introduzir o novo medidor sem quebrar faturas antigas, e suporte consegue explicar qualquer item de linha em minutos.
Por que meu modelo de preços afeta quais dados preciso armazenar?Comece decidindo o que você precisa provar depois: por que um cliente foi cobrado naquele valor. Assinaturas precisam de histórico de plano, período e entitlements; cobrança por uso precisa de um registro imutável do que aconteceu, quando e sob quais regras de preço.
O que significa tornar a cobrança “auditable”?Se você não consegue reproduzir a fatura a partir dos dados armazenados, não consegue responder contestações ou auditorias de forma confiável. A configuração mais segura é armazenar termos do plano com limites de tempo, preços versionados, eventos brutos de uso e os resultados exatos do cálculo usados quando a fatura foi finalizada.
Como definir um medidor para evitar disputas?Um bom medidor é algo que duas pessoas podem contar da mesma forma. Defina o evento, a unidade e a janela de tempo, e escreva o que conta e o que não conta (como tentativas de retry, requisições falhas ou chamadas internas) para não mudar o significado no meio do caminho.
Qual é a diferença prática entre hard limits, soft limits e cobrança por overage?Limites hard bloqueiam ações, soft apenas avisam e permitem, e cobrança por overage permite a ação e cobra pelo excedente. Escolha um comportamento por entitlement e armazene a regra com timestamps de início e fim para que suporte, produto e cobrança tomem a mesma decisão.
Por que entitlements devem ficar separados da lógica de medição?Eles resolvem problemas diferentes: entitlements controlam o que o cliente pode fazer; medição registra o que realmente aconteceu. Mantê-los separados evita que uma mudança no medidor quebre o acesso e facilita explicar faturas.
Devo armazenar eventos brutos de uso ou apenas totais mensais?Armazene um log de eventos de uso append-only como fonte da verdade e, opcionalmente, mantenha agregados para desempenho. Os eventos devem incluir timestamp, escopo do cliente (por exemplo, workspace), nome do medidor, quantidade e uma chave única de idempotência para que duplicados não causem cobranças duplas.
Como lidar com mudanças de preço sem quebrar faturas antigas?Nunca sobrescreva preços ou regras de plano antigas; adicione novas versões com datas de vigência. Depois, armazene qual versão de preço foi aplicada a cada fatura (e muitas vezes a cada período de entitlement), assim faturas antigas podem ser reconstruídas exatamente mesmo após mudanças de pacote.
Como evitar bugs de cobrança causados por fusos horários e períodos de cobrança?Cobrança mensal precisa de um âncora de ciclo e de um fuso horário, não apenas “mensal”. Armazene period_start e period_end consistentemente e seja explícito sobre quais timestamps são usados para tempo do evento versus tempo de ingestão para evitar erros de um dia por fusos horários e DST.
Qual é uma política de prorrateamento sensata para upgrades e downgrades?Use uma política que você consiga explicar em uma frase e modele a matemática como itens de linha explícitos na fatura (créditos e débitos) vinculados ao evento de mudança e à janela de prorrateamento. Prorrateamento diário é uma opção comum porque é mais simples de testar e defender que o horário por hora.
O que fazer quando eventos de uso chegam tarde após a fatura ser finalizada?Finalize faturas como snapshots imutáveis e trate uso tardio como um ajuste novo ou como parte do próximo período, com uma nota clara. Previews podem ser recalculados livremente, mas faturas finalizadas não devem mudar quando novos eventos chegam.
21 de jan. de 2026
8 min
20 de jan. de 20268 min
20 de jan. de 20268 minExperimente o AppMaster com plano gratuito.
Quando estiver pronto, você poderá escolher a assinatura adequada.
