100%
Voltar ao catálogo de notas

Nota técnica

Nota produto

Financial Leak Detector: vazamentos financeiros invisíveis

Camada analítica que cruza pedidos, pagamentos e reembolsos para detectar descontos errados, estornos suspeitos e divergências entre sistemas — narrativa orientada a CFO.

7 min de leitura alta planejamento
financeiro auditoria reconciliacao anti-fraude delivery sql
Stack: SQL avançado Python Regras declarativas DW ou lakehouse

Visão geral

Extensão financeira da linha de auditoria operacional: em vez de só “atraso” e “cancelamento”, focar em dinheiro que sai sem explicação aceitável — desconto fora da política, reembolso duplicado, divergência entre gateway e ERP.

Problema

  • CFO vê DRE agregado; não vê padrão de micro-perdas por canal ou loja.
  • Equipes descobrem erro meses depois, via reclamação ou auditoria externa.
  • Sistemas (PDV, delivery, financeiro) não batem centavo a centavo e ninguém prioriza o gap.

Casos de uso

  • Desconto acima do limite por perfil de usuário ou campanha.
  • Reembolso após entrega confirmada ou double refund.
  • Taxa de serviço aplicada duas vezes ou zerada indevidamente.
  • Pedido pago no app e não reconhecido no fechamento da loja.
  • Série temporal de “ajustes manuais” concentrados em um operador ou loja.

Abordagem

  1. Mapa de fontes: sistema de pedidos, adquirente, conciliação bancária, ERP.
  2. Chaves de junção documentadas (order_id, transaction_id, NSU).
  3. Conjunto de regras de reconciliação + fila de exceções.
  4. Severidade por valor acumulado e recorrência.

Output

  • Lista diária de anomalias classificadas (valor estimado, evidência SQL, IDs).
  • Dashboard: vazamento por categoria mês a mês.
  • Opcional: workflow de aprovação para ajuste contábil.

Stack sugerida

  • SQL em warehouse (BigQuery, Snowflake, Postgres analítico) ou DuckDB em fase exploratória.
  • Camada Python para regras complexas e envio de alertas.
  • Idempotência nos jobs para não duplicar alertas.

Relação com Delivery-Projeto

O case atual já materializa valores e flags no domínio pedido; o próximo passo é trazer ledger financeiro (mesmo que mock na fase de estudo) e provar reconciliação.

MVP

  • 5 regras de negócio com impacto em R$.
  • Relatório semanal “top 20 exceções”.
  • Documento de definição de “bateu” entre sistemas.

Riscos

  • Falso positivo gera ruído — toda regra precisa de exemplo validado com negócio.
  • Dados financeiros sensíveis — controle de acesso e mascaramento.

Próximo passo

Desenhar diagrama de entidades pedido ↔ pagamento ↔ estorno e listar 3 inconsistências que já aconteceriam no mock.