Por que o OCR troca números no extrato bancário (e como conferir)

Um erro que não se parece com um erro

Quase todo defeito de software se anuncia: o arquivo não abre, o campo fica vazio, aparece uma mensagem vermelha. O reconhecimento óptico de um extrato escaneado não faz nada disso. Ele substitui: onde o papel dizia 760,53, o arquivo passa a dizer 160,53, e a conversão segue sem uma queixa.

Repare no que não aconteceu: nada quebrou, nada ficou em branco. O que foi gravado é um número perfeitamente possível numa conta bancária, e nenhuma validação técnica reprova isso. O defeito existe só no mundo real, onde aquela linha ficou seiscentos reais mais pobre.

Compare com o outro estrago do mesmo extrato: ao fundir duas linhas da tabela, o OCR produziu o histórico DEN SS009065 Iracema Sant. Esse é inofensivo porque é escandaloso — quem bate o olho vê que não é histórico de nada. O dígito trocado é o perigoso justamente por ser discreto: não pede a sua atenção, dispensa. E ninguém confere extrato linha a linha contra o PDF — se fosse para isso, não haveria motivo para converter. O valor errado é conciliado como os outros e ressurge semanas depois como uma diferença que ninguém explica.

Por que um leitor treinado em português estraga número

O motor reconhece o extrato em português (o modelo por do tesseract), e não é escolha estética: extrato brasileiro é feito de "TRANSFERENCIA", "TARIFA" e nomes de pessoas — sem o modelo do idioma, a leitura do texto despenca.

Só que um modelo de idioma não é um leitor neutro; é um palpiteiro treinado. Diante de uma forma ambígua, ele não pergunta "que desenho é este?", e sim "que palavra provavelmente está aqui?". Um borrão entre rn e m vira m, porque m é mais provável em português — em texto corrido, é o que salva um scan torto.

Aplique o mesmo palpite a -2.752,73: ali não existe sequência provável, qualquer combinação de dígitos é tão plausível quanto outra. O modelo palpita mesmo assim, e nada o impede de errar. A força que ajuda na palavra é a que destrói o número.

Os casos que medimos

Nada disso é hipótese. Os casos abaixo saíram de extratos reais, e cada um está anotado no código ao lado do tratamento que existe por causa dele:

Os cinco primeiros compartilham a assinatura da falha: o que saiu ainda passa por dado legítimo. Ninguém, olhando só o resultado, sabe que 160,53 não é o valor verdadeiro — nem você, nem o seu ERP, nem o conversor.

A última linha é de outra natureza: o dígito virou pontuação, a linha deixou de parecer um lançamento e o leitor a descartou. Num extrato do PagBank isso custou um rendimento de R$ 0,20 — e foi esse vintém faltando a única razão pela qual o problema apareceu. O erro que apaga se deixa encontrar; o erro que substitui, não.

Defesa 1: tirar as palavras do caminho

Se o problema é o palpite do idioma, a saída é removê-lo de onde atrapalha, sem perdê-lo onde ajuda.

Em vez de reconhecer a página inteira de uma vez, o conversor recorta faixas verticais e lê cada uma com regras próprias. A do histórico vai com todo o português a favor. A dos valores vai com o alfabeto restrito a 0123456789.,-; a das datas, a 0123456789/. É restrição durante a leitura, não faxina depois: sem candidatos a palavra, não sobra o que "corrigir". Nas tabelas difíceis ainda dobramos o raster de 300 para 600 dpi.

De brinde, resolve a segmentação. Em tabela larga o OCR funde linhas próximas: no Bradesco, o tipo do lançamento e o detalhe viravam a papa ilegível que gerou o DEN SS009065. Lendo só a tira estreita da coluna, ele separa as duas — e um extrato de teste que não produzia nenhuma transação passou a produzir as 26 que ele tem.

Defesa 2: o extrato prova a si mesmo

Restringir o alfabeto reduz o erro, não o elimina: lendo só dígitos, um débito impresso em vermelho ainda saiu -2.152,73. Contra o que sobra há uma segunda defesa, que não depende do OCR — e sim de uma aritmética que o documento já carrega.

Extrato com coluna Saldo é redundante: o saldo de uma linha é o saldo da linha de cima somado ao lançamento daquela linha — uma continha que já vem com o resultado ao lado. Acompanhe a distância entre o saldo impresso e o saldo que os lançamentos lidos implicam: num extrato íntegro ela é zero do começo ao fim. Quando não é, há dois desenhos, e eles não se confundem:

• A distância aparece e some. Uma linha destoa, a seguinte volta a zero: os lançamentos estão certos e quem errou foi o saldo — a cadeia se realinha no primeiro saldo íntegro. Foi 23.713,09 lido como 23.013,09.
• A distância aparece e fica, deslocando todos os saldos seguintes do mesmo tanto até o fim. É a assinatura de um lançamento errado: o valor torto entrou na soma e contamina o resto. Foi o débito vermelho — e o deslocamento revela o tamanho do estrago, o que torna o valor recuperável.

É assim que se sabe qual dos dois campos mentiu, e por isso nossos extratos de teste fecham exatamente no total do rodapé — não "perto".

Como conferir o seu próprio arquivo

Tudo acima é o que a ferramenta faz. Esta seção é o que você faz — e vale para qualquer conversor, o nosso incluído. Comece pelo mais barato: abra o OFX no Excel, que traz as fórmulas prontas de somar e contar.

1. Conte as linhas. Quantidade diferente da do extrato denuncia a corrupção que destrói a linha — a data virada 2//04/2026. Fácil de ver, impossível de adivinhar.

2. Feche a soma contra o rodapé. Pegue os dois saldos impressos pelo banco, abertura e fechamento: a diferença entre eles tem que ser exatamente o que o seu arquivo soma. É o teste mais forte do lado de fora — qualquer dígito trocado empurra esse total, e nenhum erro de OCR sobrevive a ele.

3. Não fechou? Procure o "quase certo". Aqui está a diferença entre cinco minutos e uma tarde: não procure valor absurdo, procure o plausível demais. Duas pistas encurtam o caminho:

• O tamanho da diferença aponta a casa. Diferença redonda — R$ 600,00, R$ 700,00 — é assinatura de um dígito trocado numa casa alta, como em 760,53 → 160,53. Diferença pequena e quebrada cheira a casa decimal ou a linha perdida.
• Os confundíveis são poucos. O motor troca sempre entre os mesmos pares: 7 e 1, 0 e 8, 5 e 6, 3 e 8.

Sabendo a casa e os candidatos, você compara uma linha com o PDF, não trezentas.

4. Ordene por data e olhe as pontas. Um lançamento em 2028 num extrato de 2026 salta na primeira ou na última linha — o erro de ano é o único que se entrega sozinho.

Se a diferença persistir sem candidato, o problema pode nem ser de leitura: o guia de erros comuns na importação separa o que é do arquivo do que é do seu sistema.

Quando desconfiar

Este risco só existe se o extrato passou por OCR, e você descobre isso em dois segundos: tente marcar um valor do PDF com o cursor. Ficou selecionado? Há texto de verdade no arquivo, os valores são copiados e você pode esquecer este guia. Não marcou nada? O documento é imagem — escaneado, fotografado, passado por "Microsoft: Print To PDF" ou deitado em paisagem.

O diagnóstico completo está no guia sobre extrato em PDF sem texto selecionável. Aqui basta a regra: é esse arquivo, e só ele, que exige a conferência da seção anterior.

A regra de ouro

Toda a engenharia deste guia — recorte por coluna, alfabeto restrito, reconciliação por saldo — existe para consertar um problema que não precisava existir. Ela funciona, mas é uma reconstrução, e reconstrução boa ainda perde para o original.

Então: baixe sempre o PDF que o próprio banco gerou — internet banking, app, anexo do e-mail. Nele os valores não são interpretados: saem tal como o banco os escreveu, e esta classe inteira de erro deixa de ser possível. Se o extrato chegou de outra pessoa já escaneado, peça o original: custa uma mensagem e economiza uma caçada.

Quando o escaneado for tudo o que existe, converta — é para isso que o OCR está lá —, mas gaste os cinco minutos da conferência antes de importar. Se algo não fechar e o culpado não aparecer, mande o caso com o banco e o canal de origem.