Sua fatura da Tecton mostra um número, sua conta da AWS carrega silenciosamente o resto, e nenhum dos dois documentos se apresenta como o custo total de servir features. Essa divisão é a armadilha. A Tecton precifica por consumo — créditos de computação pelas pipelines que ela executa mais os recursos de nuvem que essas pipelines consomem dentro da sua própria conta — então a fatura que você recebe da Tecton é sempre apenas parte do gasto. Se seus livros registram a fatura e param por aí, seu custo dos produtos vendidos está subestimado, sua margem bruta está superestimada, e toda decisão de precificação que você toma com base nessa margem repousa sobre um número que nunca foi completo.
Este post explica como a Tecton de fato mede e fatura, por que o serving de features em produção pertence ao custo dos produtos vendidos, como lidar com créditos pré-pagos e compromissos de consumo, e como conciliar tudo isso no fechamento do mês para que cada dólar caia na conta certa.
Como a Tecton Mede: Feature Views, Não Licenças por Usuário
A Tecton é uma plataforma gerenciada de features para machine learning. Você define transformações sobre seus dados como feature views, a Tecton as computa em pipelines de batch ou streaming, e serve os resultados aos seus modelos — um offline store para recuperação em larga escala no treinamento e um online store para recuperação de baixa latência durante a inferência ao vivo. Não há licenças por usuário a contar. Você paga pelo que a plataforma consome enquanto computa, armazena e serve suas features.
Esse consumo se divide em dois baldes que são faturados em dois lugares diferentes, e essa é a primeira coisa a internalizar.
O primeiro balde são os créditos da Tecton. Eles cobrem a computação que a Tecton gerencia em seu nome: créditos de computação Spark streaming para feature views de stream, créditos de computação Spark batch para feature views de batch. Seu uso da plataforma se traduz em créditos, e os créditos aparecem na fatura da Tecton.
O segundo balde é a própria infraestrutura, e ela é faturada através da sua própria conta de nuvem. A Tecton gerencia recursos de computação e armazenamento dentro do seu ambiente AWS ou GCP, então as leituras e gravações no online store, a computação do cluster Spark, o armazenamento do online store e o armazenamento S3 caem todos na sua fatura de nuvem — não na da Tecton. Uma equipe que provisiona por um canal e concilia pelo outro sempre encontrará uma lacuna. Decida de uma vez que o custo real de uma feature view é a soma dos dois baldes, e garanta que sua extração de fim de mês cubra tanto a fatura da Tecton quanto as linhas marcadas na fatura de nuvem.
Feature views de stream e de batch consomem de forma diferente
Os componentes de custo diferem por tipo de feature view, e saber quais você executa indica quais linhas observar.
Feature views de stream carregam leituras e gravações no online store, computação do cluster Spark stream, créditos de computação Spark streaming da Tecton, armazenamento S3 e armazenamento do online store. Feature views de batch carregam uma lista semelhante — leituras e gravações no online store, computação do cluster de jobs Spark, créditos de computação Spark batch da Tecton e armazenamento S3 — menos as peças específicas de streaming.
Os parâmetros que movem a fatura são as decisões de design que seus engenheiros de ML tomam todos os dias. O processamento contínuo de stream faz checkpoints e gravações com muito mais frequência do que o processamento por intervalos, então custa mais. Janelas de agregação maiores exigem mais computação. Watermarks mais longos para dados que chegam atrasados elevam os requisitos de memória. A configuração do cluster precifica cada job diretamente. A compactação de dados reduz o custo de armazenamento e melhora o desempenho de leitura. Nenhuma dessas são configurações de finanças; são configurações de engenharia com consequências financeiras, e é por isso que a contabilização dessa plataforma começa com uma conversa entre as duas equipes sobre quais feature views existem e para o que estão ajustadas.
A hierarquia de custos mostra para onde o dinheiro vai
A própria orientação da Tecton classifica o impacto de custo do maior para o menor, e vale memorizar a ordem porque ela prevê de onde virão suas surpresas.
As operações no online store estão no topo. As gravações no online store costumam ser o maior custo de infraestrutura, especialmente durante backfills — recálculo de features históricas para uma feature view nova ou alterada — ou sob processamento contínuo de stream. Um backfill é um pico planejado: dias ou semanas de computação histórica e uma enxurrada de gravações comprimidas em uma única janela. Se ninguém avisar as finanças de que ele vem aí, o mês em que ele cai parece um estouro de custo em vez de um investimento.
Os recursos de computação vêm em segundo lugar: custos de cluster Spark para processamento de stream e batch, variando com configuração e carga de trabalho. O armazenamento vem em terceiro: armazenamento e leituras do online store mais S3, geralmente com impacto menor do que computação e gravações.
A consequência prática é que sua fatura é movida por gravações e eventos de computação, não por quantas pessoas fazem login no console. Planejamento de capacidade aqui significa governar backfills, modos de processamento e janelas de agregação — não headcount.
Por Que o Serving de Features em Produção É COGS
Segundo os US GAAP, o custo dos produtos vendidos de uma empresa SaaS — custo de receita — inclui os custos diretos de entregar o serviço que os clientes pagam: infraestrutura de hospedagem, computação e armazenamento em nuvem, software de terceiros embutido no produto, e qualquer outra coisa que escale com o uso. O serving de features para um produto de ML em produção passa facilmente nesse critério. Quando seu modelo de fraude pontua uma transação, seu motor de recomendação ranqueia um feed, ou seu modelo de precificação cota uma tarifa, as leituras no online store e as pipelines que mantêm essas features atualizadas são um custo de entrega tão direto quanto os servidores de aplicação por trás deles.
Essa classificação importa porque flui direto para a margem bruta, o número que investidores, credores e adquirentes usam para julgar se a economia do seu produto funciona. Colocar custos de serving abaixo da linha em despesas operacionais gerais infla a margem bruta e esconde a história de escala. Uma equipe de due diligence vai remapear seu plano de contas para uma definição padrão de COGS de SaaS de qualquer forma; classificar corretamente desde o início significa que seus próprios dashboards contam a mesma história que um outsider vai calcular.
Nem todo dólar da Tecton pertence ao COGS, porém. A divisão segue o uso, não o fornecedor:
- Serving em produção é COGS. Leituras e gravações no online store para inferência ao vivo, as pipelines de streaming e batch que mantêm as features de produção atualizadas, e o armazenamento por trás delas entregam o serviço voltado ao cliente.
- Experimentação e staging são despesas operacionais. Feature views de desenvolvimento, experimentação offline e ambientes de staging dão suporte à pesquisa e desenvolvimento, não à entrega. Registre-os em P&D.
- Trabalho exclusivo de treinamento exige julgamento. A computação de features offline que existe apenas para treinar a próxima versão do modelo parece mais P&D do que entrega; a mesma pipeline alimentando o online store para serving ao vivo é COGS. Quando uma feature view faz as duas coisas, aloque por um direcionador defensável — o gasto de nuvem marcado por ambiente é o mais limpo que a maioria das equipes tem.
A Tecton marca instâncias de computação e recursos do online store por feature view, então os dados de alocação existem no seu explorador de custos de nuvem. A tarefa contábil é decidir o mapeamento uma vez — quais feature views servem à produção, quais servem à experimentação — e então aplicá-lo todos os meses em vez de rediscuti-lo a cada fechamento.
Comprar a Tecton é despesa; construir o equivalente pode ser capital
Mais uma classificação que vale acertar: a equipe que compra a Tecton lança o consumo como despesa conforme descrito acima, mas a equipe que constrói sua própria feature store sobre software open-source enfrenta uma questão de capitalização. Software de uso interno desenvolvido para suas próprias operações pode se qualificar para capitalização uma vez que um projeto passa da fase preliminar, o que transforma salários de engenharia e infraestrutura em um ativo amortizável em vez de uma despesa do período.
Nenhum dos dois tratamentos é detalhe opcional. Se você usa a Tecton, não capitalize suas faturas como se você tivesse construído a plataforma. Se você migra de uma store construída internamente para a Tecton, o antigo ativo capitalizado continua amortizando enquanto o novo consumo entra no COGS — duas linhas diferentes, duas histórias diferentes, ambas corretas ao mesmo tempo.
Créditos Pré-Pagos e Compromissos São Ativos Primeiro, Despesa Depois
Plataformas de consumo comumente vendem créditos pré-pagos ou compromissos anuais de gasto, e a contabilização de ambos segue o princípio da competência: registre o pagamento como um ativo e depois lance-o como despesa conforme o benefício é consumido. Um dólar transferido a um fornecedor antecipadamente ainda não é custo de nada. Ele se torna COGS quando os créditos são consumidos contra o serving de produção, P&D quando são consumidos contra a experimentação, e prejuízo se expirarem sem uso.
Na prática, isso significa três lançamentos, não um. Quando você compra créditos, debite um ativo pré-pago e credite caixa. A cada mês, reduza o saldo pelo que foi efetivamente consumido — consumo de produção em COGS, consumo de staging em P&D. Se os créditos tiverem data de expiração, agende-a; um saldo expirado é um prejuízo real que merece uma baixa planejada, não uma descoberta durante a limpeza do ano seguinte.
Mínimos take-or-pay adicionam uma apropriação por competência em cima disso. Se seu contrato o compromete a um gasto mínimo trimestral, você deve o maior valor entre o consumo real e o mínimo. Quando o consumo fica abaixo do compromisso perto do fim do período, aproprie a diferença que você deverá de qualquer forma. A fatura chegará depois, mas o passivo existe na data do balanço, e o fechamento deve refleti-lo.
Conciliando no Fechamento do Mês: Duas Faturas, Uma Verdade
A Tecton publica logs de uso faturável — registros CSV detalhados do uso da plataforma e de como ele se traduz em créditos, que chegam ao seu próprio armazenamento de objetos cerca de um ou dois dias após o uso. Combinados com o gasto de nuvem marcado, esses logs são as leituras de medidor das quais sua conciliação depende. Trate o processo mensal como a correspondência de três fontes entre si: os logs de uso, a fatura da Tecton e a fatura de nuvem.
Uma checklist de fechamento viável é assim:
- Extraia os logs de uso do mês completo. Confirme que os créditos de cada feature view de produção e os créditos de cada experimento estão presentes, incluindo os dois últimos dias — o atraso do log significa que um fechamento executado no primeiro dia do mês está sem dados. Ou espere pelos logs ou apropie os dias finais pela taxa de execução e faça o acerto no mês seguinte.
- Apropie o lado não faturado da Tecton. Como a maioria das cobranças por consumo, a fatura chega após o período que cobre. Registre uma apropriação pelos créditos estimados do mês em COGS e P&D pela divisão por ambiente, depois estorne e faça o acerto quando a fatura chegar.
- Extraia o gasto de nuvem marcado. Filtre seu explorador de custos de nuvem pelas tags de feature view do mesmo período. Este é o segundo balde — clusters Spark, operações do online store, armazenamento — e ele deve ser dividido entre produção e staging da mesma forma.
- Concilie logs, fatura e fatura de nuvem. Os logs de uso devem fechar com a fatura da Tecton; as linhas marcadas da nuvem devem se mover na mesma direção. Um mês com backfill dará picos em ambos. Uma fatura que diverge dos logs é uma questão de cobrança a ser levantada agora, não na renovação.
- Reduza pré-pagamentos e compromissos. Lance como despesa os créditos consumidos retirando-os do ativo pré-pago, apropie qualquer diferença de compromisso, e confirme que os saldos restantes ainda parecem utilizáveis antes da expiração.
A falha mais comum é o passo três — conciliar meticulosamente a fatura da Tecton enquanto o gasto do lado da nuvem se esconde dentro de uma fatura de infraestrutura maior sob uma rubrica genérica de hospedagem. Se seu extrato de nuvem mostra uma linha única de computação combinada, corrija a marcação antes de corrigir qualquer outra coisa. Gasto sem marcação não pode ser alocado, e gasto não alocado sempre acaba em algum lugar errado.
Um mês concreto nos livros
Suponha que sua plataforma de ML consuma créditos da Tecton faturados em $40.000 contra serving de produção e $8.000 contra experimentação em janeiro, mais $12.000 de gasto de nuvem marcado, dividido em $9.500 de produção e $2.500 de staging. Você também pré-pagou $100.000 em créditos no início do trimestre. Janeiro é registrado assim:
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Prepaid:Tecton-Credits USD
2026-01-01 open Expenses:CostOfSales:Feature-Serving USD
2026-01-01 open Expenses:Research:ML-Experimentation USD
2026-01-01 open Liabilities:Accrued:Tecton USD
2026-01-01 open Liabilities:Accrued:Cloud USD
2026-01-05 * "Tecton" "Prepay Q1 consumption credits"
Assets:Prepaid:Tecton-Credits 100000.00 USD
Assets:Cash:Operating -100000.00 USD
2026-01-31 * "Tecton" "January credit consumption, prod serving plus experimentation"
Expenses:CostOfSales:Feature-Serving 40000.00 USD
Expenses:Research:ML-Experimentation 8000.00 USD
Assets:Prepaid:Tecton-Credits -48000.00 USD
2026-01-31 * "Cloud" "January tagged feature-platform infra, prod plus staging"
Expenses:CostOfSales:Feature-Serving 9500.00 USD
Expenses:Research:ML-Experimentation 2500.00 USD
Liabilities:Accrued:Cloud -12000.00 USDO padrão se generaliza: o pré-pagamento é um ativo, o consumo o move para despesa por ambiente, e o lado da nuvem é apropriado separadamente porque é faturado separadamente. Se sua equipe mantém seus livros em texto puro, os padrões de rastreamento de custos na documentação se estendem naturalmente a uma divisão por feature view, e as visualizações de dashboard tornam a tendência de produção versus staging visível mês a mês.
Erros Que Distorcem a Margem
Quatro erros aparecem repetidamente em equipes que operam infraestrutura de ML cobrada por consumo. Cada um é barato de prevenir e caro de desfazer ao longo de períodos reapresentados.
Registrar a fatura da Tecton como o custo total. A fatura é um balde. Todo mês a computação do lado da nuvem, as operações do online store e o armazenamento adicionam um segundo balde de tamanho comparável, e omiti-lo subestima o COGS em cerca de metade. Concilie ambos ou não reporte nenhum.
Lançar pré-pagamentos como despesa no momento do pagamento. Uma compra de $100.000 em créditos não é uma despesa de $100.000 no mês em que a transferência sai. É um ativo que se converte em despesa conforme os créditos são consumidos. Lançar como despesa no pagamento antecipa o trimestre, deixa os meses seguintes sem seu custo real, e torna as tendências de consumo ilegíveis.
Direcionar staging para o COGS. Feature views de experimentação, backfills offline para pesquisa de modelos e ambientes de staging são P&D. Misturá-los aos custos de serving superestima o COGS e penaliza a margem bruta por trabalho que nunca tocou um cliente. As tags de feature view existem justamente para manter essa divisão honesta — use-as.
Pular a apropriação. As cobranças por consumo são faturadas em atraso, os logs de uso atrasam um ou dois dias, e a fatura de nuvem chega ainda depois. Um fechamento sem apropriação registra um mês parcial como se fosse completo, e os dias faltantes aparecem como uma variação misteriosa no mês seguinte. Apropie pela taxa de execução e depois faça o acerto quando os documentos chegarem.
Seu último passo útil deste mês é pequeno: abra seu explorador de custos de nuvem, filtre pelas tags de feature view, e confirme que o número que você vê é o número nos seus livros. Se os dois nunca se encontraram, você acabou de encontrar a lacuna que este post foi escrito para fechar.
