Leonardo Peron5 min de leitura
A integração com a contabilidade é a que menos reclama e a que mais erra. Não derruba pedido, não trava a expedição, não gera chamado. Entrega um número errado numa conta certa, ou um número certo num mês errado, e segue rodando — até o fechamento, quando alguém pergunta por que a receita do mês não bate com a que a operação sabe ter feito.
Três coisas diferentes com o mesmo nome
"Mandar a venda para a contabilidade" trata como uma coisa só o que são três, com regras e datas próprias.
O movimento operacional é o fato do negócio: o pedido foi feito, a mercadoria saiu, o serviço foi prestado. É o que a operação chama de venda.
O documento fiscal é a obrigação com o fisco: a nota emitida, com número, série e situação. Tem vida própria — pode ser cancelado, rejeitado ou emitido em data diferente da do pedido.
O lançamento contábil é o registro em contas, por partida dobrada: todo débito tem um crédito de mesmo valor. Não é espelho do pedido, é uma classificação dele.
Integração que trata os três como "o pedido" acerta enquanto tudo é simples e erra em toda exceção — e exceção é a regra do fiscal. É a decisão de escopo que qualquer integração de ERP toma antes do código.
A competência não é a data do pedido
O campo mais perigoso é o que se chama apenas data. Num único negócio existem
várias: a do pedido, a da emissão da nota, a da saída da mercadoria, a do
vencimento, a do recebimento. Não coincidem, e cada regime usa uma.
Pela competência, o resultado pertence ao período em que o fato aconteceu; pelo caixa, ao período em que o dinheiro entrou. Uma venda de dezembro recebida em janeiro é receita de dezembro para um e de janeiro para outro, e as duas estão certas dentro da própria pergunta. A integração não decide isso, mas precisa carregar todas as datas — quem decide não reclassifica o que não recebeu.
É a raiz de dois times, dois números: não é erro de conta, são perguntas diferentes com o mesmo nome.
O cancelamento e a devolução não são a mesma coisa
Cancelar uma nota dentro do prazo que a legislação permite desfaz o documento: é como se ele não tivesse existido. Devolver, não — a devolução é operação nova, com documento próprio, e o fato original continua tendo acontecido.
Essa diferença dói no período fechado. Depois que a contabilidade encerra um mês não existe voltar atrás: o ajuste acontece no período aberto, referenciando o anterior. Se a origem reenvia o registro "corrigido" com a data original, a contabilidade recebe uma alteração que não pode aplicar — e o mais comum é que não recuse. Aceita, e o efeito vai para o lugar errado.
Correção contábil é contra-lançamento, não edição
É a regra que mais surpreende quem vem do lado operacional. No ERP, um registro errado se corrige editando o registro. No razão, não: o lançamento errado permanece, um segundo em sentido oposto o anula, e depois vem o certo. O saldo final é o mesmo, e o histórico conta tudo, inclusive o erro. O motivo é auditoria — um razão que permite apagar não prova nada, e provar é a função dele.
Para a integração, três consequências. "Atualizar" quase não existe do lado contábil; existem "lançar" e "estornar". O identificador do lançamento gerado precisa voltar ao ERP e ficar guardado, porque sem ele não há o que estornar — e sem essa volta o contador corrige à mão e os dois sistemas param de concordar em silêncio. E reprocessar lote é perigoso por natureza: sem chave estável, o reenvio não corrige, duplica, pelo mecanismo de o mesmo evento duas vezes.
Por que falha em silêncio
Um sistema contábil bem configurado quase não recusa. Tem conta transitória e classificação padrão para o que não reconhece, porque a alternativa seria travar a escrituração. O lançamento entra, o retorno é sucesso, o painel fica verde — e o valor foi para uma conta que ninguém consulta.
Por isso a conferência aqui não pode ser "rodou sem erro". Precisa ser conciliação de saldo: o total lançado no período, por natureza de operação, contra o que o ERP diz ter movimentado. É o método de provar que nada se perdeu, aplicado todo mês. E é por isso que fila de erro é monitoramento insuficiente: o que precisa existir é o oposto, um relatório do que entrou e onde entrou.
O de-para não é decisão do time técnico
O mapa entre o que o ERP produz e as contas em que aquilo cai pertence à contabilidade. Plano de contas, natureza de operação, centro de custo, imposto — nada disso se deduz do payload, e quem escolher sozinho vai escolher razoavelmente e errado. É um de-para como o de qualquer migração, e o mapeador serve para começá-lo.
O que levantar antes da primeira linha de código
- O plano de contas vigente e quem assina alterações nele.
- Quais datas a origem tem, e qual delas cada relatório usa hoje.
- Em que dia o período fecha, e o procedimento para o que chega depois.
- O que o contábil aceita como estorno, e se devolve o identificador do lançamento criado.
- Se existe conta transitória para o não classificado — e quem olha para ela.
- Como devolução, cancelamento e desconto chegam hoje, e quem os classifica.
O teste que fecha o assunto é o do mês inteiro: pegue um período já fechado, processe-o pela integração num ambiente separado e compare com o que a contabilidade apurou à mão. Se bater, existe fluxo. Se não bater, a diferença é a especificação que faltava — o cuidado que sistemas que movem dinheiro exigem antes de qualquer volume.