Instalei uma loja autônoma em um condomínio de ~120 unidades em Curitiba. No primeiro mês, o relatório do painel HRM dizia que tinha entrado R$ 4.200. Mas quando fui conferir a soma das transações Pix e cartão, apareceu R$ 3.850. Faltavam R$ 350. Procurei a gente de TI. Ele riu. "Isso é normal".
\n\nNão era normal para mim. Era meu dinheiro.
\n\nDepois que comecei a olhar com atenção, entendi por que a conciliação fica bagunçada. E percebi que muitos operadores convivem com essa confusão como se fosse inevitável. Não é. É só desorganização operacional. O problema está em três lugares: transações que pinguem fora do horário, furtos que viram diferença contábil, e controles de entrada e saída de mercadoria feitos de forma errada.
\n\nQuando uma transação desaparece do extrato Pix
\n\nPix é instantâneo, mas nem sempre o dinheiro aparece no seu extrato na hora certa. Um cliente paga R$ 15 às 18h47. A transação é validada no app da loja. O sistema marca como concluída. Mas o banco do cliente recusa o débito três minutos depois por falta de saldo. Ou porque a conta está bloqueada. Ou porque a chave aleatória expirou.
\n\nO que acontece? O app registra venda. O estoque sai do inventário. Mas o dinheiro não entra. Você descobrirá isso consultando o relatório de transações recusadas do seu adquirente, um documento que a maioria dos operadores nunca abre.
\n\nNa rede Be Honest, operamos um padrão para isso. A conciliação diária começa verificando o arquivo de transações recusadas da maquineta. Se tem R$ 200 em Pix recusados, o saldo esperado cai R$ 200. Parece óbvio. Mas na prática, 70% dos operadores que entrevistei nos primeiros meses não fazia essa etapa.
\n\nEstoque que sai mas não foi roubado
\n\nUm operador olha para a gôndola e vê que faltam sete unidades de refrigerante. Ele sabe que colocou 20 ontem de manhã. Depois de descartar venda, a hipótese é furto. Ele marca como quebra ou perda no sistema.
\n\nMas às vezes o que saiu foi vendido. Um cliente entrou sem avisar ao sensore porque ele entrou carregando uma sacola grande. Ou dois clientes entraram juntos. Ou o sensor de peso já estava descalibrado.
\n\nQuando você marca como perda o que na verdade foi vendido, o saldo de caixa fica maior que o saldo de estoque. A conciliação quebra porque os números estão em mundos diferentes: o painel de vendas diz uma coisa, o controle de entrada e saída de mercadoria diz outra.
\n\nComecei a auditar isso semanalmente. Pesava o estoque. Comparava com o que o painel HRM mostrava. Essa prática reduz discrepâncias em ~40%. Leva meia hora e salva horas de dor de cabeça depois.
\n\nMercadoria que entra contada errado
\n\nVocê recebe uma caixa com 24 iogurtes. Abre. Conta 23. Anota 23 no sistema. Depois, esse iogurte vira venda. Vira dinheiro. Mas o controle de entrada ficou registrado como 23, não como 24. No fim do mês, quando você tira a diferença entre o que entrou e o que saiu, sobra uma discrepância.
\n\nIsso parece microscópico. Mas quando você multiplica por 50, 100 itens diferentes recebidos ao longo de 30 dias, vira R$ 200 a R$ 500 de diferença inexplicável.
\n\nA solução é tirar uma foto da nota fiscal ao lado do produto no momento do recebimento. Se vier escrito 24 na nota e você contou 24, isso fica registrado. Se vier 24 e você contou 23, você registra 23 e tira foto. Daqui a três meses, se sobrar um iogurte na gôndola sem venda associada, você olha a foto e sabe exatamente que aquele iogurte foi um erro de entrada, não de saída.
\n\nQuando cartão recusado some da conta
\n\nCartão é diferente de Pix. Quando um cliente tenta pagar com cartão e a bandeira recusa a transação, o app registra tentativa falha. O cliente sai da loja vazio. Nenhum dinheiro entra. Nenhum produto sai. Deveria ser simples: zero impacto financeiro.
\n\nMas existe um cenário que a maioria não considera. O cliente tenta pagar com cartão. Falha. Ele tenta de novo. E de novo. Três tentativas. O app, mal programado, às vezes registra como três falhas diferentes, ou registra a primeira como venda pendente. O painel HRM mostra uma transação de R$ 20 em