Billing, gateways, adquirentes, ERP e emissor de nota
Um status por fatura, cruzamento por id e cada número na sua data
Faturamento, caixa e em aberto que fecham, mais exceções
Fechamento, fila de cobrança e agente de IA do financeiro
O que resolve
- Uma tabela única de faturas, sem fatura contada duas vezes entre contas, gateways e retentativas.
- Faturamento, caixa e inadimplência fecham entre si todo mês, ao centavo.
- Vendido e não recebido, recebido sem nota e valor divergente viram listas de trabalho, não descobertas de fim de trimestre.
Perguntas de negócio que responde
Faça estas perguntas ao seu agente quando o caso estiver pronto.
O que você precisa
- Billing e gateways conectados na Nekt, todas as contas e empresas
- O ERP ou emissor de nota, com o id da fatura do billing gravado em algum campo
- A regra da empresa: o que é receita recorrente e em que data cada número é contado
O que você recebe
- Uma tabela de faturas com origem, status único e as três datas
- Uma conciliação mensal faturamento x caixa x em aberto que fecha
- Uma base de recebíveis por adquirente com realizado e a receber
- Tabelas de exceção para o financeiro revisar toda semana
Onde ativar
Conciliação faturamento x caixa x em aberto como primeiro relatório do fechamento, com as exceções anexas.
Tabelas de exceção enviadas para planilha ou Slack toda semana, com dono por tipo.
Responde sobre faturamento, caixa e recebíveis com a data e a regra de status já aplicadas.
Cada gateway tem estrutura própria e o cruzamento com o ERP depende de um id gravado. Comece por uma conta de billing e um mês fechado. O detalhado traz as regras de negócio, as armadilhas e o teste de aceitação. Ou mande tudo direto para o seu agente com o MCP da Nekt.
A receita fica espalhada em várias contas de billing, dois ou três gateways e um ERP. A mesma cobrança aparece em várias linhas: uma por tentativa, uma por conta, uma na tabela de pagamentos e outra na de movimentações. Quem soma tudo infla o faturamento; quem cruza por valor e data concilia o cliente errado. E o que mais importa, venda sem dinheiro e dinheiro sem nota, só aparece quando a contabilidade reclama.
Como costuma ser feito, e a regra
Cada linha é um erro que já aconteceu na prática.
Empresas com mais de uma conta de billing (por empresa do grupo, linha de produto ou subsidiária) empilham as contas numa tabela só, com uma coluna de origem. O id da fatura só é único dentro da conta: a chave é origem + id. Toda conta nova entra na mesma tabela no dia em que é conectada.
Gateways geram mais de um registro para a mesma cobrança (segunda via, reemissão, retentativa). Fique com um por cobrança pela ordem: paga, chargeback, reembolsada, em protesto, pendente, expirada; no empate, a mais recente. Assim uma segunda via paga não convive com a primeira expirada.
Cada tentativa de cartão vira uma linha de charge, e uma fatura pode ter várias recusas antes de ser paga. Faturamento e caixa contam o documento (fatura do billing, pedido no e-commerce), nunca a tentativa. As recusas vão para uma tabela própria, uma linha por tentativa, com o código de recusa padronizado.
Faturamento do mês = caixa bruto das faturas do mês + o que delas segue em aberto. Cada número tem a sua data: faturamento pela competência ou emissão, caixa pela data de pagamento, em aberto pelo vencimento. Se a identidade não fecha num mês, há duplicidade ou fatura perdida, e o relatório não sai.
O dinheiro do cartão cai no saldo semanas depois do pagamento e parcelado cai por parcela. Monte os recebíveis por transação x parcela com situação realizado ou a receber. Líquido = valor menos taxa, taxa de antecipação e taxa de antifraude. Na projeção, tire vendas com chargeback ou reembolso. Pix e boleto sem repasse registrado entram no dia útil bancário seguinte, com calendário de feriados bancários (os móveis calculados pela Páscoa).
O ERP guarda o id da fatura do billing num campo personalizado da transação e o id do cliente do billing no cadastro do cliente. A fatura do produto guarda o id da cobrança do gateway (external_id). Cruze por esses ids. Para achar vendido e não recebido, traga só o lado pago do gateway na junção e liste o que ficou sem par.
Gateways têm uma tabela de cobranças e outra de movimentações do saldo, que repete cada pagamento e acrescenta taxas e transferências. Receita vem da tabela de cobranças. No Stripe, ligue charge a assinatura pelas linhas da invoice: a tabela pronta de charges por assinatura só traz as que deram certo.
Stripe, Pagar.me e campos *_cents vêm em centavos: divida por 100 uma vez, na primeira camada. Linhas de pedido de venda em alguns ERPs vêm com sinal invertido e precisam ser negadas. Estornos e reembolsos entram negativos no caixa e positivos na tabela de reembolso, nunca os dois no mesmo total.
Quando a venda é emitida por mais de uma empresa do grupo, cada relatório vem de um token por empresa e leva a coluna empresa. Um código de venda global que aparece nas duas empresas é duplicidade. Se a empresa emissora mudou numa data, a regra de qual empresa vale é por data de corte, declarada.
A conciliação não apaga nem corrige linhas. Ela publica uma tabela por tipo de problema: aprovada fora do emissor de nota, aprovada sem nota emitida, produto fora do de-para, reembolsada com nota ativa, valor divergente entre billing e nota, duplicidade entre empresas. Tabela vazia é o objetivo.
Status do gateway para categoria
Na ordem de prioridade usada para ficar com um registro por cobrança.
Definições
Armadilhas que já aconteceram
A primeira versão consolidada somava a tabela de transações de um gateway, que repete cada pagamento junto com taxas e transferências, e a receita daquele gateway saía quase o dobro.
Receita só da tabela de cobranças; movimentações só para caixa.
O relatório de renovações falhas partia da tabela pronta de charges por assinatura, que só guarda cobranças com sucesso. Nenhuma recusa aparecia.
Ligue charge a assinatura pelas linhas da invoice.
A flag de reembolsado só fica verdadeira quando o valor inteiro volta. Reembolsos parciais ficavam como receita cheia.
Use o valor reembolsado, não a flag.
Um mesmo título no financeiro cobria mais de um contrato do cliente. O cruzamento por cliente repetia o valor do título em cada contrato.
Conte quantos contratos cada título cobre e rateie ou deduplique pelo título.
Datas vinham como número serial do Excel (base 30/12/1899), quantidades e valores unitários chegavam convertidos em data e alguns sistemas mandavam texto vazio em vez de nulo.
Converta serial a partir de 30/12/1899, reverta valores lidos como data e trate texto vazio como nulo na primeira camada.
O mesmo motivo chegava como 051 num gateway e 51 no outro, e motivos novos caíam em silêncio fora do de-para.
Tire o zero à esquerda de códigos de três caracteres e mantenha um monitor de motivos não mapeados.
Teste de aceitação
O caso está pronto quando todos os itens passam.
- Em cada mês fechado, faturamento = caixa bruto + em aberto, com diferença zero.
- O faturamento de cada conta de billing bate com o painel do próprio billing no mesmo período (diferença abaixo de 0,5%).
- A tabela de faturas não tem chave origem + id repetida, e nenhuma fatura tem mais de um status.
- A soma do caixa líquido realizado de um adquirente no mês bate com os repasses recebidos no extrato bancário.
- Cada tabela de exceção tem dono e toda linha nela tem motivo registrado ou foi resolvida na origem.
Pacote para o agente
Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.
Conciliação de faturamento - A tabela de faturas tem uma linha por fatura, com a coluna origem (conta de billing ou gateway). A chave é origem + id. - Cada cobrança tem um status, escolhido pela prioridade: paid > chargeback > refunded > in_protest > pending > expired; no empate, a mais recente. - Tentativa de pagamento não é fatura. Faturamento e caixa contam o documento; recusas estão na tabela de recusas, uma linha por tentativa. - Faturamento do mês = caixa bruto + em aberto das faturas do mês. Faturamento usa competência ou emissão; caixa usa a data de pagamento; em aberto usa o vencimento. - Caixa líquido é por parcela, na data de liquidação do adquirente, menos taxa, antecipação e antifraude. - Valores do Stripe e de campos *_cents já estão convertidos para reais na tabela tratada. Não divida de novo. - Reembolso parcial: use o valor reembolsado, não a flag. - O cruzamento com o ERP é pelo id da fatura do billing gravado no ERP. Nunca cruze por valor e data. - Para perguntas de exceção (vendido e não recebido, sem nota, valor divergente, duplicidade), use as tabelas de exceção e não recalcule. - Se a pergunta não disser a data, responda por competência e diga isso. Exceções por cliente: - <cliente>: receita recorrente só quando a linha da fatura tem assinatura; avulsos e implantação ficam fora do faturamento recorrente. - <cliente>: vendas por <gateway> de boleto externo ficam fora da conciliação do billing. - <cliente>: até <data>, a empresa emissora era <matriz>; depois, <filial>.
Construa no meu workspace Nekt o caso "Conciliação de faturamento" seguindo as regras em https://academy.nekt.com/industrias/saas/conciliacao-faturamento.md. 1) Encontre as tabelas de origem e confirme as colunas usadas pelas regras. 2) Crie uma transformação no grão indicado aplicando todas as regras. 3) Rode o teste de aceitação e me mostre o resultado de cada item. 4) Crie o context document do caso no workspace, com as exceções dos meus clientes em aberto para eu preencher.
Variações
Central de recebíveis por transação x parcela, com relatório diário de realizado e a receber por adquirente.
Conferência por adquirente usando TID, NSU e código de autorização da transação do gateway contra o extrato.
Tabela de recusas com código padronizado, categoria e flag de retentável, base para dunning e conversão no cartão.