Por que meu OCR está perdendo pontos decimais
e símbolos de moeda? 5 modos de falha e como corrigir cada um

Uma única vírgula decimal faltando não é um erro pequeno — é um erro de dez vezes. E o frustrante é que o resto da extração parece correto. O nome do fornecedor, a data, os itens da linha vêm todos certos. Apenas os números que mais importam — totais, valores de impostos, preços unitários — se deslocaram silenciosamente em uma ou duas ordens de grandeza. O impacto não é abstrato: um pagamento registrado de R$ 15.600 em vez de R$ 156 trava o caixa, gera trabalho de conciliação e corrói a confiança no processo automatizado.

A percepção central da pesquisa em processamento de documentos é consistente: símbolos pequenos — vírgulas decimais, marcas de moeda, sinais de menos — falham antes que caracteres maiores falhem, porque operam no limite do limiar de resolução de um mecanismo de OCR. Estes não são erros aleatórios. Eles seguem modos de falha previsíveis, cada um com uma causa raiz conhecida. Identificar qual modo você está enfrentando é a diferença entre uma correção rápida com regex e um desastre de dados que chega ao seu ERP sem ser detectado.

Este artigo aborda cinco modos distintos de falha para vírgulas decimais e símbolos de moeda ausentes. Cada um tem uma assinatura diagnóstica específica e uma correção específica. Para uma visão mais ampla de por que as ferramentas de extração retornam números errados mesmo quando o texto está claramente legível, veja nosso artigo complementar sobre erros de design de campo que causam números extraídos errados — esse artigo foca em nomes de colunas ambíguos, enquanto este foca em falhas no nível dos símbolos.

Modo de Falha 1: A Vírgula Decimal é Pequena Demais para o Mecanismo Enxergar

Sintomas: "3,50" é extraído como "350" ou "3 50." "19,99" vira "1999." Os dígitos em si estão perfeitamente legíveis — a vírgula decimal simplesmente não está lá. O ponto ausente desloca cada número na sua planilha em duas ordens de grandeza.

Por que acontece: Mecanismos tradicionais de OCR pré-processam imagens aplicando filtros de ruído, ajustes de contraste e binarização antes de ler os caracteres. Uma vírgula decimal com 8–10 pixels de altura — comum em recibos térmicos, digitalizações de baixa DPI e documentos faxados — fica abaixo do piso de ruído dessas etapas de pré-processamento. O filtro do mecanismo vê um pequeno ponto entre dois dígitos e o classifica como poeira, fibra de papel ou artefato de compressão. A 72 DPI, uma vírgula decimal ocupa aproximadamente 2–3 pixels de largura. Nesse tamanho, é visualmente indistinguível de uma partícula de poeira para qualquer algoritmo de binarização.

Isso não é uma falha de reconhecimento — é uma falha de pré-processamento. A vírgula decimal nunca chega ao estágio de reconhecimento porque foi removida antes que o mecanismo pudesse examiná-la.

Como corrigir: A correção mais confiável é a validação pós-extração, em vez de tentar alterar o pré-processamento do mecanismo de OCR. Implemente uma verificação de regex no nível do campo que valide cada valor monetário extraído contra o padrão esperado:

# Verifica: este valor tem exatamente duas casas decimais?
pattern = r'^\d+\.\d{2}$'
if not re.match(pattern, extracted_value):
    flag_for_review(extracted_value)

Além do regex, compare o valor extraído com uma magnitude esperada. Se o total da sua fatura normalmente fica entre R$ 50 e R$ 5.000 e a extração retorna R$ 500.000, uma verificação de sanidade detecta o erro antes que ele chegue ao seu sistema contábil. Muitas ferramentas de extração, incluindo o ImageToTable.ai, permitem definir regras de formatação de saída que padronizam valores durante a extração — a posição decimal se torna parte do esquema de saída, em vez de algo que a saída bruta do OCR precisa preservar.

Para digitalizações de resolução extremamente baixa, onde os pontos decimais são fisicamente menores que 6 pixels, nenhuma correção de pós-processamento é totalmente confiável. A resposta honesta é que a imagem de origem não contém as informações necessárias para uma extração precisa. Nesses casos, redigitalizar a 300 DPI ou mais é a única correção duradoura.

Modo de Falha 2: Símbolo da Moeda Grudado no Primeiro Dígito é Descartado

Sintomas: "$156,00" é extraído como "156,00" (símbolo ausente) ou, em casos piores, como "$15600" (símbolo + dígitos mesclados em um único token com o ponto decimal perdido na mesclagem). O contexto da moeda desaparece e os sistemas downstream tratam um valor em USD como um número sem unidade.

Por que acontece: Símbolos de moeda ($, €, £, ¥, R$) são tipograficamente distintos dos dígitos — geralmente são definidos em uma tipografia ou peso diferente e ficam na mesma linha de base do número, mas com um perfil visual diferente. Quando um mecanismo de OCR tokeniza uma linha, ele precisa decidir se o "$" faz parte do número ou é uma entidade separada. Tokenizadores baseados em proximidade frequentemente mesclam o símbolo com o dígito inicial, produzindo um único token como "$156" que o mecanismo então lê incorretamente porque o classificador interno de caracteres tem menor confiança no símbolo "$" do que nos dígitos que o seguem. O mecanismo resolve a confusão descartando o caractere de baixa confiança — o símbolo da moeda — e mantendo os dígitos de alta confiança.

Alguns mecanismos de extração baseados em visão lidam melhor com isso do que o OCR tradicional, pois processam todo o contexto visual em vez de tokenizar caractere por caractere. Mas mesmo modelos modernos podem ter dificuldades quando o símbolo da moeda e o primeiro dígito compartilham uma caixa delimitadora apertada, ou quando o símbolo aparece em uma tipografia incomum (como o "$" curvado em algumas impressoras de recibos).

Como corrigir: Implemente um mapa de normalização de símbolos de moeda como uma etapa de pós-extração. Defina o formato de saída esperado para campos monetários — por exemplo, "USD 156,00" ou "$156,00" — e normalize os valores extraídos para esse formato:

# Símbolos de moeda conhecidos por contexto do documento
currency_map = {
    'USD': r'[\$]',
    'EUR': r'[€]',
    'GBP': r'[£]',
    'JPY': r'[¥]'
}
# Se o valor extraído tem dígitos mas nenhum símbolo,
# atribua a moeda esperada dos metadados do documento
if re.match(r'^\d+\.\d{2}$', value) and not has_currency_prefix(value):
    normalized = f"{doc_currency} {value}"

O segredo é não depender do OCR para decidir se o símbolo pertence — defina isso no nível do esquema de extração e valide contra ele.

Modo de Falha 3: Confusão do Separador de Milhar Inverte o Decimal

Sintomas: Uma fatura dos EUA com "1.234,56" é extraída como "1.23456" ou "1234.56" (a vírgula é perdida). Um documento europeu com "1.234,56" é extraído como "1.23456" ou "1234.56" — o ponto é tratado como decimal, inflando o valor em 1.000. O mesmo sinal de pontuação significa coisas opostas dependendo da localidade, e o mecanismo de OCR não sabe qual regra aplicar.

Por que acontece: Mecanismos de OCR tratam sinais de pontuação como caracteres, não como notação matemática. Um ponto e uma vírgula são caracteres distintos com perfis visuais conhecidos, mas o mecanismo não tem conhecimento nativo de qual deles é o separador decimal na localidade do documento. Isso não é uma limitação de um único mecanismo — toda ferramenta de OCR mainstream, do Tesseract às APIs comerciais em nuvem, processa pontuação da mesma forma: ela gera o que vê, deixando a interpretação dessa pontuação para a lógica downstream. O resultado é que o mesmo pipeline de extração pode produzir $1.234,56 em uma fatura dos EUA e 1.234,56€ em uma fatura alemã — e ambos serão analisados incorretamente se o sistema downstream não souber qual convenção esperar.

Esse problema se agrava quando você processa faturas de vários países. Um único lote de 50 faturas de fornecedores dos EUA, Alemanha e França pode conter três convenções decimais diferentes. O mecanismo de extração não detecta automaticamente qual convenção se aplica a cada documento.

Como corrigir: Duas abordagens. A primeira é no nível do esquema: defina o formato decimal esperado por fornecedor ou por tipo de documento antes da extração. Se você sabe que faturas do seu fornecedor alemão usam vírgula como decimal, configure uma regra de análise que interprete vírgulas como separadores decimais e pontos como separadores de milhar para esse grupo de documentos.

A segunda abordagem é a validação de magnitude — uma técnica descrita em detalhes em nosso artigo sobre quedas na precisão da extração multilíngue, que aborda como a variação de formato entre fontes de documentos cria erros em cascata. Na prática, verifique se o total extraído está dentro de uma faixa razoável da soma dos itens de linha. Um total de $1.234.567,89 quando os itens de linha somam $12.345,67 é um indicador claro de inversão do separador decimal-milhar.

# Validar: o total corresponde à soma dos itens de linha
# dentro de uma tolerância razoável?
soma_itens = sum(itens_linha)
total = total_extraido
# Se total for ~1000x soma_itens, o decimal foi lido como separador de milhar
if abs(total - soma_itens) / max(soma_itens, 1) > 100:
    sinalizar_ambiguidade_decimal(total_extraido)

Modo de Falha 4: Sinal Negativo e Parênteses — O Indicador Invisível

Sintomas: Um aviso de crédito mostrando "(156,00)" é extraído como "156,00" sem sinal negativo. Um saldo de extrato bancário de "1.247,30-" é extraído como "1.247,30" — o menos final é descartado. O número está tecnicamente correto, mas o sinal está errado, transformando um crédito em débito e um reembolso em cobrança.

Por que acontece: Motores de OCR tratam parênteses como caracteres de pontuação independentes. Quando um número está entre parênteses — a notação contábil padrão para valores negativos — o parêntese de abertura é lido como um caractere separado antes do primeiro dígito, e o de fechamento como um caractere separado após o último dígito. Durante a extração de dados, esses parênteses são frequentemente descartados por não corresponderem à classe de caracteres esperada para um campo numérico. O mesmo se aplica a sinais de menos finais: posicionados após os dígitos, ficam fora do token numérico e são classificados como um fragmento de texto separado que a lógica de extração nunca associa ao número.

Como corrigir: Defina regras de detecção de sinal no nível do campo. Se o valor extraído aparecer em um campo que normalmente contém créditos, descontos ou ajustes negativos — ou se o documento original contiver parênteses em torno de um valor monetário — aplique uma inversão de sinal após a extração. Combine isso com uma convenção de nomenclatura de campos: uma coluna chamada "Valor do Crédito" ou "Desconto" deve esperar um valor absoluto e aplicar um sinal negativo automaticamente, independentemente do que o OCR retornou.

# Se o contexto do documento indicar um campo de magnitude negativa
# e o valor extraído for positivo, inverta o sinal
negative_context_fields = ['credit_memo', 'discount', 'refund', 'adjustment']
if field_name in negative_context_fields and extracted_value > 0:
    extracted_value = -extracted_value

Modo de Falha 5: Sobrescrito e Subscrito — Centavos Que Desaparecem Entre Linhas

Sintomas: Uma etiqueta de preço com "$99⁹⁹" (significando $99,99, com centavos em sobrescrito) é extraída como "$99" ou "$9900." Um valor de imposto impresso em sobrescrito minúsculo ao lado de um subtotal desaparece completamente. O número base está correto, mas a parte fracionária que define o valor monetário preciso desaparece.

Por que acontece: Caracteres sobrescritos compartilham a mesma região horizontal do número principal, mas ficam acima da linha de base em uma fração do tamanho — tipicamente 40–60% do tamanho do ponto dos dígitos principais. Motores de OCR os detectam como uma linha ou fragmento de texto separado porque a posição vertical se desvia da linha de base principal. Na extração de texto, esse fragmento é atribuído a uma linha de saída diferente ou descartado durante a análise de layout como um valor atípico. A notação de centavos comum em etiquetas de preço de varejo e alguns itens de linha de faturas é a vítima mais frequente.

Valores subscritos — menos comuns em contextos monetários, mas frequentes em alíquotas de impostos e códigos de referência — enfrentam o mesmo problema na direção oposta: caracteres abaixo da linha de base são segmentados como regiões de texto independentes e perdem sua associação com o número principal.

Como corrigir: A abordagem mais prática é combinar todos os fragmentos de texto que compartilham a mesma posição horizontal dentro de um intervalo vertical restrito e, em seguida, validar o valor combinado com padrões monetários esperados. Se um número principal "99" for seguido por um sobrescrito "99" na mesma região de coluna, a combinação "99,99" é um valor monetário válido. Implemente isso como uma regra de mesclagem espacial: qualquer fragmento de texto dentro de 150% do intervalo de coordenada X do número principal e dentro de um deslocamento vertical definido deve ser mesclado ao valor do campo extraído.

# Mesclar fragmentos na mesma região horizontal
# dentro de uma faixa vertical restrita
def merge_superscript(main_number, fragments, y_threshold=15):
    """Combinar aglomerado de dígitos principal com fragmentos próximos."""
    combined = main_number
    for frag in fragments:
        if abs(frag.y - main_y) < y_threshold and \
           abs(frag.x - main_x) < main_width * 0.5:
            combined += frag.text
    # Validar após mesclagem
    if re.match(r'^\d+\.\d{2}$', combined):
        return combined
    return main_number  # retornar ao original se a mesclagem for inválida

Quando escalar: os limites honestos das correções automatizadas

As cinco correções acima cobrem a maioria das falhas de ponto decimal e símbolo de moeda. Mas existe uma categoria de documento onde nenhuma regra de pós-processamento consegue recuperar o valor correto de forma confiável: documentos onde o ponto decimal é fisicamente menor que a resolução mínima que o método de captura consegue reproduzir. Um ponto decimal em um recibo térmico de 72 DPI tem aproximadamente 2 pixels de largura. Nesse tamanho, a informação literalmente não existe na imagem para nenhum motor — OCR tradicional ou IA de visão — ler de forma confiável.

Se você trabalha com recibos térmicos, documentos faxados ou fotocópias de segunda geração, aceite que alguns pontos decimais exigirão verificação manual. A abordagem prática é sinalizar todo valor monetário extraído que falhe em uma verificação de magnitude — total fora da faixa esperada, itens que não somam ao total, número de casas decimais inconsistente com a moeda — e encaminhar essas sinalizações para um revisor humano. Uma revisão de 30 segundos dos valores sinalizados é mais rápida e confiável do que tentar ajustar o pós-processamento para recuperar informações perdidas na captura.

Para equipes que processam documentos que chegam consistentemente em baixa resolução, o investimento mais eficaz não é uma ferramenta de extração melhor — é um padrão de digitalização que exija 300 DPI ou mais para documentos recebidos. A 300 DPI, um ponto decimal ocupa de 8 a 10 pixels, o que está acima do piso de ruído de todos os motores de extração modernos.

Perguntas Frequentes

Próximos Passos: Do Diagnóstico à Prevenção

Um ponto decimal ausente não é um evento aleatório — é o resultado previsível de um dos cinco modos de falha conhecidos. A diferença entre uma equipe que detecta esses erros e uma que não detecta não é a ferramenta que usam; é se possuem um framework de diagnóstico. Quando você sabe qual dos cinco modos de falha está enfrentando, a correção geralmente é uma regra de pós-processamento — não um motor de IA diferente.

Comece com uma auditoria simples: pegue os últimos 50 valores monetários extraídos do seu pipeline e classifique cada erro por modo de falha. Se 80% dos seus erros se enquadram em uma ou duas categorias, você tem uma correção focada que não custa nada além de algumas linhas de lógica de validação. Se os erros estão espalhados por todos os cinco modos, o problema provavelmente é a qualidade da captura — e a correção é um padrão de digitalização, não uma troca de ferramenta.

Para uma análise mais aprofundada de como a precisão da extração varia conforme o formato do documento e como projetar campos que minimizem ambiguidades, consulte nosso guia sobre erros de design de campo que produzem números extraídos incorretos e a análise de como a variação de formato entre fontes de documentos causa quedas de precisão. Entre esses três diagnósticos — design de campo, variação de formato e agora modos de falha em nível de símbolo — você tem um framework completo para depurar a precisão da extração em todos os níveis do pipeline.