---
id: saas/conciliacao-faturamento
industria: SaaS e tecnologia
uso: muito usado
esforco: alto
grao: Fatura (documento de cobrança); recebível por transação x parcela; conciliação por mês
---

# Conciliação de faturamento

Billing, gateway, ERP e caixa numa tabela só, com o que foi vendido e não recebido e o que foi recebido sem nota aparecendo sozinhos.

## Resumo executivo

**Para quem:** Financeiro e controladoria de empresas de SaaS que cobram por mais de um gateway ou conta de billing.

**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.

**Por que importa:** Quando a receita vive em várias contas de billing, gateways e um ERP, cada área fecha o mês com um número diferente e ninguém sabe qual está certo. A conciliação é o que dá confiança ao board, à contabilidade e ao cálculo de MRR, e é onde aparecem vendas sem nota e pagamentos que nunca chegaram.

**Perguntas de negócio que responde**

- Quanto faturamos, quanto entrou no caixa e quanto ficou em aberto no mês passado?
- Quais clientes compraram e o dinheiro não chegou?
- Quais vendas aprovadas estão sem nota fiscal emitida?
- Quanto vamos receber dos adquirentes nos próximos 30 dias, já líquido de taxa?
- Quanto pagamos de taxa de gateway por mês e por meio de pagamento?
- Quais vendas foram reembolsadas e continuam com nota ativa?

**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

## Detalhado

### O problema

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.

### Regras de negócio

1. **Todas as contas numa tabela, com a origem marcada.** 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. (Evite: Uma consulta por conta e soma na planilha, ou empilhar sem marcar a origem.)
2. **Um status por fatura, escolhido por prioridade.** 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. (Evite: Pegar o registro mais recente ou contar todos.)
3. **Tentativa não é cobrança.** 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. (Evite: Somar charges para chegar no faturamento.)
4. **Faturamento, caixa e em aberto fecham entre si.** 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. (Evite: Três relatórios com três filtros diferentes que nunca batem.)
5. **Caixa é a data em que o adquirente liquida.** 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). (Evite: Tratar a data do pagamento aprovado como entrada no caixa.)
6. **Cruze os sistemas por id gravado, nunca por valor e data.** 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. (Evite: Casar fatura e pagamento pelo mesmo valor no mesmo dia.)
7. **Use a tabela de pagamentos, não a de movimentações.** 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. (Evite: Somar a tabela de transações do gateway como receita.)
8. **Unidade e sinal certos antes de somar.** 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. (Evite: Dividir por 100 em cada relatório, ou nunca.)
9. **Matriz e filial são empresas separadas.** 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. (Evite: Empilhar matriz e filial sem coluna de empresa.)
10. **Exceções viram tabelas, não correções silenciosas.** 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. (Evite: Filtrar as linhas estranhas para o número bater.)

### Status do gateway para categoria

Na ordem de prioridade usada para ficar com um registro por cobrança.

- **paid, succeeded, approved** → Paga (prioridade 1) (`conta no caixa bruto`)
- **chargeback, dispute lost** → Chargeback (2) (`sai do caixa, vai para reembolso`)
- **refunded, amount_refunded > 0** → Reembolsada (3) (`total ou parcial pelo valor`)
- **in_protest, dispute aberta** → Em disputa (4) (`caixa recebido, ainda em risco`)
- **pending, waiting_funds** → Em aberto (5) (`entra no valor em aberto`)
- **expired, canceled** → Expirada ou cancelada (6) (`fora do faturamento`)
- **failed, declined** → Recusa (`tentativa, nunca fatura`)

### Definições

| Métrica | Definição |
|---|---|
| Faturamento do mês | soma do valor das faturas de receita, deduplicadas por documento, com competência ou emissão no mês, status pago ou pendente |
| Caixa bruto | soma do valor pago das faturas, pela data de pagamento, antes de taxas |
| Caixa líquido | soma por parcela de valor menos taxa, taxa de antecipação e taxa de antifraude, pela data de liquidação do adquirente |
| Em aberto | faturamento do mês menos o caixa bruto das faturas daquele mês, na data de corte |
| Vendido e não recebido | fatura emitida no produto ou no billing sem cobrança paga correspondente no gateway, pelo id gravado |
| Recebido sem nota | venda aprovada no gateway sem nota emitida ou fora do emissor de nota |
| Taxa efetiva do gateway | soma das taxas / caixa bruto no mês, por gateway e meio de pagamento |
| Recusa | uma tentativa de pagamento negada, com código padronizado; a mesma venda pode ter várias |

### Armadilhas

- **Gateway em dobro.** 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. Como evitar: Receita só da tabela de cobranças; movimentações só para caixa.
- **Recusas que sumiam.** 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. Como evitar: Ligue charge a assinatura pelas linhas da invoice.
- **Reembolso parcial invisível.** A flag de reembolsado só fica verdadeira quando o valor inteiro volta. Reembolsos parciais ficavam como receita cheia. Como evitar: Use o valor reembolsado, não a flag.
- **Um boleto, vários contratos.** 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. Como evitar: Conte quantos contratos cada título cobre e rateie ou deduplique pelo título.
- **Planilha que vira data.** 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. Como evitar: Converta serial a partir de 30/12/1899, reverta valores lidos como data e trate texto vazio como nulo na primeira camada.
- **Código de recusa que não casa.** O mesmo motivo chegava como 051 num gateway e 51 no outro, e motivos novos caíam em silêncio fora do de-para. Como evitar: Tire o zero à esquerda de códigos de três caracteres e mantenha um monitor de motivos não mapeados.

Validado em dados reais: Na conta Stripe da própria Nekt, cerca de 7% das faturas tiveram mais de uma tentativa de cobrança (até 14 na mesma fatura), quase todas recusas seguidas de pagamento, e nenhuma teve dois pagamentos com sucesso: somar charges inflaria o número de cobranças, deduplicar por invoice resolve. Os valores vêm em centavos, os reembolsos parciais não ligam a flag de reembolsado e o dinheiro de cartão em reais fica disponível em mediana 29 dias depois da cobrança, já líquido de cerca de 4,3% de taxa.

### Teste de aceitação

- [ ] 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.

### Context document

```text
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>.
```

### Variações

- **Recebíveis por adquirente:** Central de recebíveis por transação x parcela, com relatório diário de realizado e a receber por adquirente.
- **Aceite contábil:** Conferência por adquirente usando TID, NSU e código de autorização da transação do gateway contra o extrato.
- **Recusas de cartão:** Tabela de recusas com código padronizado, categoria e flag de retentável, base para dunning e conversão no cartão.