O financeiro chega na segunda-feira com dois números na cabeça. O ERP diz que o saldo disponível é R$ 48.200. A planilha de controle diz R$ 51.700. A reunião com o sócio é em 40 minutos. Qual número ele usa?
Esse momento não é acidente. É o resultado estrutural de meses operando dois sistemas que registram a mesma realidade de formas diferentes, sem nenhuma regra definindo qual dos dois está certo quando os dois divergem. A equipe escolhe um número, torce para que seja o bom, e segue.
Por que a planilha paralela sempre nasce (e não é falha da equipe)
Toda empresa que adota um ERP começa com a melhor intenção: centralizar tudo no sistema. Três meses depois, a planilha está de volta. Não porque a equipe é indisciplinada. Porque o ERP tem lacunas.
O sócio pede um relatório que o ERP não entrega pronto. Alguém precisa acompanhar uma negociação que ainda não virou nota. A planilha entra como solução pontual, e fica. O problema é que ninguém avisa o sistema quando ela passa a registrar o mesmo dado.
O problema não é a planilha existir. O problema é que ela começa a receber dados que também existem no ERP, e ninguém define o que acontece quando os dois discordam.
61% das PMEs brasileiras ainda usam Excel ou Google Sheets para controle financeiro. 44% das pequenas empresas têm algum ERP. Isso significa que planilha e sistema coexistem na maioria das PMEs. O que varia é se a empresa tem alguma regra sobre qual dos dois manda.
O custo real da divergência
Na prática, conciliar ERP com planilha ocupa uma parte significativa do dia do analista financeiro, às vezes duas horas, às vezes mais. Até que o número feche, nenhuma decisão avança. Esse tempo não aparece no DRE, mas está lá, todo fechamento.
O custo que aparece no relatório, horas de conciliação, é menor do que o que não aparece. Uma decisão de pricing ou de antecipação de recebíveis tomada com o saldo errado pode custar mais do que meses de retrabalho. O problema é que ninguém consegue rastrear isso depois: quando o número estava errado, a decisão já foi tomada.
Por que dois sistemas corretos geram números diferentes
A divergência mais comum não vem de erro de digitação. Ela vem de dois sistemas individualmente corretos que capturam o mesmo evento em momentos diferentes, com critérios diferentes.
O caso do e-commerce é o mais visível: a empresa tem ERP, gateway de pagamento e adquirente. O gateway captura a venda no momento da aprovação. A nota sai dias depois, no ERP. O dinheiro só aparece no extrato quando a adquirente liquida: D+2 ou D+30, dependendo do contrato. Os três estão certos. Mas se você somar os totais de cada um no mesmo dia, os números são diferentes.
O problema não é que alguém errou. É que dois sistemas corretos produziram saldos diferentes porque cada um captura a realidade a partir de um regime diferente: um trabalha com competência, o outro com caixa, o terceiro com liquidação financeira. Sem uma regra sobre qual regime vence em cada tipo de decisão, a divergência é garantida.
Outros pontos de ruptura frequentes: impostos (ERP registra bruto, planilha controla líquido após retenções), provisões trabalhistas (ERP só registra no pagamento, planilha anota a provisão), antecipações de recebíveis (ERP mostra valor cheio, planilha refletiu o líquido após taxas), transferências entre contas (o ERP faz em um lançamento, a planilha às vezes em dois lados em dias diferentes por pessoas diferentes).
O protocolo de fonte única: como definir qual sistema ganha para cada tipo de dado
A solução não é escolher entre planilha e ERP. É definir, por categoria de dado, qual dos dois é a fonte de verdade. Quando os dois divergem naquela categoria, a fonte de verdade vence sem discussão.
Para cada tipo de dado financeiro, existe um sistema melhor posicionado para ser a fonte de verdade:
- Saldo bancário realizado: ERP / banco (conciliação precisa da data de liquidação efetiva)
- Receita por competência: ERP (nota fiscal e lançamento contábil ficam no sistema)
- Provisões trabalhistas: Planilha / DP (ERP raramente calcula com a granularidade necessária)
- Fluxo de caixa projetado: Planilha (projeção envolve premissas e cenários que ERP não suporta)
- Contas a pagar/receber pendentes: ERP (o lançamento e aprovação devem gerar rastreabilidade)
- Negociações em andamento: Planilha / CRM (não virou NF ainda; não pertence ao ERP)
- DRE gerencial: Camada de integração (consolida ERP + planilha; precisa de fonte única de consolidação)
O JPMorgan perdeu US$ 6,2 bilhões em 2012 porque dois modelos divergiram e ninguém tinha escrito, em lugar nenhum, qual dos dois mandava quando isso acontecia. Numa PME o valor em jogo é diferente, mas a mecânica é a mesma: na ausência de protocolo escrito, cada pessoa na sala vai usar o número que conhece.
Quando vale reformar o ERP e quando vale criar uma camada de integração
A maioria dos artigos sobre esse problema termina recomendando trocar o ERP. É o caminho mais fácil de vender e o mais difícil de executar para uma PME.
Primeiro eixo: o ERP atual consegue ser configurado para cobrir as lacunas que geraram a planilha paralela? Se sim, a configuração resolve. Em média, uma reconfiguração de ERP para cobrir lacunas leva entre 2 e 6 semanas e não exige migração de histórico.
Segundo eixo: a planilha faz algo que nenhum ERP razoável vai substituir? Projeção de cenários com premissas variáveis, modelos de precificação com lógica proprietária, consolidação de grupos empresariais: esses casos justificam manter a planilha, mas com uma camada de integração que sincroniza os dados relevantes de forma automatizada. Uma distribuidora com planilha de precificação por cliente é caso de integração, não de troca de ERP: a lógica proprietária não entra no sistema, mas os saldos aprovados precisam sair de lá.
O que raramente se justifica é manter os dois sistemas alimentados manualmente por pessoas diferentes, sem integração e sem protocolo de fonte única. Esse é o cenário que garante divergência todo fechamento.
Por onde começar: o diagnóstico de ruptura de dados da sua operação
Antes de decidir qualquer coisa sobre ERP ou integração, é preciso mapear onde os dados estão quebrando. O diagnóstico tem quatro perguntas concretas:
-
Quais categorias de dado existem nos dois sistemas ao mesmo tempo? Liste cada tipo de dado financeiro e marque em quais sistemas ele é inserido. Onde aparecer em dois ou mais, existe risco de divergência.
-
Para cada categoria duplicada, qual sistema é atualizado primeiro? O sistema atualizado depois é candidato a ser eliminado ou automatizado. Se ninguém sabe qual é atualizado primeiro, o problema já está instalado.
-
Qual é o regime de cada sistema: caixa ou competência? Se o ERP usa competência e a planilha usa caixa para o mesmo dado, eles vão divergir sempre. Não é erro. É design.
-
Quando os dois divergem, o que a equipe faz? Se a resposta for "depende de quem está na reunião", não existe protocolo. A governança começa em documentar a resposta correta para essa pergunta.
Com essas quatro respostas em mão, é possível priorizar as intervenções por impacto. O ponto de ruptura que gera mais horas de retrabalho ou mais risco de decisão errada vem primeiro.
Comece agora: pegue as três categorias de dado que mais causaram divergência no último fechamento. Para cada uma, escreva em uma linha qual sistema é a fonte de verdade e o que acontece quando os dois discordam. Se você não conseguir preencher sem perguntar para alguém, o protocolo ainda não existe, e esse é o ponto de partida.
Se o seu financeiro ainda chega em reunião de fechamento com dois números diferentes e ninguém sabe qual usar, o problema está na arquitetura, não na equipe. A Coffe&Code Labs mapeia os pontos de ruptura entre o seu ERP e as planilhas paralelas e define o protocolo de fonte única por categoria, sem exigir troca de sistema. Acesse o contato e descreva onde os seus números costumam divergir.