¿Por qué mi OCR omite puntos decimales
y símbolos de moneda? 5 modos de fallo y cómo solucionarlos

Un solo punto decimal faltante no es un error menor — es un error de diez veces. Y lo frustrante es que el resto de la extracción se ve limpia. El nombre del proveedor, la fecha, las líneas de detalle aparecen correctamente. Solo los números que más importan — totales, montos de impuestos, precios unitarios — se han desplazado silenciosamente uno o dos órdenes de magnitud. El impacto no es abstracto: un pago registrado de $15,600 en lugar de $156 inmoviliza efectivo, genera trabajo de conciliación y erosiona la confianza en el proceso automatizado.

La conclusión clave de la investigación en procesamiento de documentos es consistente: los símbolos pequeños — puntos decimales, signos de moneda, signos menos — fallan antes que los caracteres más grandes porque operan en el límite del umbral de resolución de un motor OCR. Estos no son errores aleatorios. Siguen modos de falla predecibles, cada uno con una causa raíz conocida. Identificar con qué modo se está tratando es la diferencia entre una solución rápida con expresiones regulares y un desastre de datos que llega a tu ERP sin ser detectado.

Este artículo cubre cinco modos de falla distintos para puntos decimales y símbolos de moneda faltantes. Cada uno tiene una firma de diagnóstico específica y una solución específica. Para una visión más amplia de por qué las herramientas de extracción devuelven números incorrectos incluso cuando el texto es claramente legible, consulta nuestro artículo complementario sobre errores de diseño de campos que causan números extraídos incorrectos — ese artículo se centra en nombres de columnas ambiguos, mientras que este se enfoca en fallas a nivel de símbolos.

Modo de Falla 1: El Punto Decimal es Demasiado Pequeño para que el Motor lo Vea

Síntomas: "3.50" se extrae como "350" o "3 50". "19.99" se convierte en "1999". Los dígitos en sí son perfectamente legibles — el punto decimal simplemente no está allí. El punto faltante desplaza cada número en tu hoja de cálculo dos órdenes de magnitud.

Por qué sucede: Los motores OCR tradicionales preprocesan las imágenes aplicando filtros de ruido, ajustes de contraste y binarización antes de leer los caracteres. Un punto decimal de 8 a 10 píxeles de altura — común en recibos térmicos, escaneos de baja resolución y documentos faxeados — cae por debajo del umbral de ruido de estos pasos de preprocesamiento. El filtro del motor ve una pequeña mota entre dos dígitos y la clasifica como polvo, fibra de papel o artefacto de compresión. A 72 DPI, un punto decimal ocupa aproximadamente 2–3 píxeles de ancho. A ese tamaño, es visualmente indistinguible de una partícula de polvo para cualquier algoritmo de binarización.

Esto no es una falla de reconocimiento — es una falla de preprocesamiento. El punto decimal nunca llega a la etapa de reconocimiento porque fue eliminado antes de que el motor pudiera examinarlo.

Cómo solucionarlo: La solución más confiable es la validación posterior a la extracción, en lugar de intentar cambiar el preprocesamiento del motor OCR. Implementa una verificación a nivel de campo con expresiones regulares que valide cada monto monetario extraído contra el patrón esperado:

# Verificar: ¿este valor tiene exactamente dos decimales?
pattern = r'^\d+\.\d{2}$'
if not re.match(pattern, extracted_value):
    flag_for_review(extracted_value)

Más allá de las expresiones regulares, compara el valor extraído con una magnitud esperada. Si tu total de factura suele estar entre $50 y $5,000 y la extracción devuelve $500,000, una comprobación de cordura detecta el error antes de que llegue a tu sistema contable. Muchas herramientas de extracción, incluyendo ImageToTable.ai, te permiten definir reglas de formato de salida que estandarizan los montos durante la extracción: la posición decimal pasa a ser parte del esquema de salida, no algo que el OCR crudo deba preservar.

En escaneos de muy baja resolución donde los puntos decimales miden físicamente menos de 6 píxeles, ninguna corrección posterior es totalmente fiable. La respuesta honesta es que la imagen original no contiene la información necesaria para una extracción precisa. En esos casos, volver a escanear a 300 DPI o más es la única solución duradera.

Modo de Falla 2: Símbolo de Moneda Pegado al Primer Dígito se Pierde

Síntomas: "$156.00" se extrae como "156.00" (falta el símbolo) o, en peores casos, como "$15600" (símbolo + dígitos fusionados en un solo token perdiéndose el punto decimal). El contexto de moneda se desvanece y los sistemas posteriores tratan un monto en USD como un número sin unidad.

Por qué ocurre: Los símbolos de moneda ($, €, £, ¥, R$) son tipográficamente distintos de los dígitos — a menudo usan una tipografía o peso diferente, y se sitúan en la misma línea base que el número pero con un perfil visual distinto. Cuando un motor de OCR tokeniza una línea, debe decidir si el "$" es parte del número o una entidad separada. Los tokenizadores basados en proximidad frecuentemente fusionan el símbolo con el dígito inicial, produciendo un solo token como "$156" que el motor luego lee mal porque el clasificador interno de caracteres tiene menor confianza en el símbolo "$" que en los dígitos siguientes. El motor resuelve la confusión eliminando el carácter de baja confianza — el símbolo de moneda — y conservando los dígitos de alta confianza.

Algunos motores de extracción basados en visión manejan esto mejor que el OCR tradicional porque procesan todo el contexto visual en lugar de tokenizar carácter por carácter. Pero incluso los modelos modernos pueden tener dificultades cuando el símbolo de moneda y el primer dígito comparten un cuadro delimitador muy ajustado, o cuando el símbolo aparece en una tipografía poco común (como el "$" rizado de algunas impresoras de recibos).

Cómo solucionarlo: Implementa un mapa de normalización de símbolos de moneda como paso posterior a la extracción. Define el formato de salida esperado para los campos monetarios — por ejemplo, "USD 156.00" o "$156.00" — y normaliza los valores extraídos a ese formato:

# Símbolos de moneda conocidos según el contexto del documento
currency_map = {
    'USD': r'[\$]',
    'EUR': r'[€]',
    'GBP': r'[£]',
    'JPY': r'[¥]'
}
# Si el valor extraído tiene dígitos pero no símbolo,
# asigna la moneda esperada desde los metadatos del documento
if re.match(r'^\d+\.\d{2}$', value) and not has_currency_prefix(value):
    normalized = f"{doc_currency} {value}"

La clave es no depender del OCR para decidir si el símbolo pertenece — defínelo a nivel del esquema de extracción y valida contra él.

Modo de fallo 3: Confusión del separador de miles invierte el decimal

Síntomas: Una factura estadounidense con "1,234.56" se extrae como "1.23456" o "1234.56" (se pierde la coma). Un documento europeo con "1.234,56" se extrae como "1.23456" o "1234.56": el punto se trata como decimal, inflando el valor por 1.000. El mismo signo de puntuación significa lo contrario según la configuración regional, y el motor OCR no sabe qué regla aplicar.

Por qué ocurre: Los motores OCR tratan los signos de puntuación como caracteres, no como notación matemática. Un punto y una coma son caracteres distintos con perfiles visuales conocidos, pero el motor no tiene conocimiento nativo de cuál es el separador decimal en la configuración regional del documento. Esto no es una limitación de un solo motor: toda herramienta OCR convencional, desde Tesseract hasta APIs comerciales en la nube, procesa la puntuación de la misma manera: genera lo que ve, dejando la interpretación de esa puntuación a la lógica posterior. El resultado es que el mismo proceso de extracción puede producir $1,234.56 en una factura estadounidense y 1,234.56€ en una factura alemana, y ambas se analizarán incorrectamente si el sistema posterior no sabe qué convención esperar.

Este problema se agrava cuando se procesan facturas de varios países. Un solo lote de 50 facturas de proveedores estadounidenses, alemanes y franceses puede contener tres convenciones decimales diferentes. El motor de extracción no detecta automáticamente qué convención aplica a cada documento.

Cómo solucionarlo: Dos enfoques. El primero es a nivel de esquema: definir el formato decimal esperado por proveedor o tipo de documento antes de ejecutar la extracción. Si sabe que las facturas de su proveedor alemán usan coma decimal, configure una regla de análisis que interprete las comas como separadores decimales y los puntos como separadores de miles para ese grupo de documentos.

El segundo enfoque es la validación de magnitud, una técnica descrita en detalle en nuestro artículo sobre caídas de precisión en extracción multilingüe, que cubre cómo la variación de formato entre fuentes de documentos crea errores en cascada. En la práctica, verifique que el total extraído esté dentro de un rango razonable de la suma de las líneas de detalle. Un total de $1,234,567.89 cuando las líneas suman $12,345.67 es un claro indicador de una inversión del separador decimal y de miles.

# Validar: ¿coincide el total con la suma de las líneas de detalle
# dentro de una tolerancia razonable?
line_sum = sum(line_items)
total = extracted_total
# Si total es ~1000x line_sum, el decimal se leyó como separador de miles
if abs(total - line_sum) / max(line_sum, 1) > 100:
    flag_decimal_ambiguity(extracted_total)

Modo de Falla 4: Signo Negativo y Paréntesis — El Indicador Invisible

Síntomas: Un abono que muestra "(156.00)" se extrae como "156.00" sin signo negativo. Un saldo de estado de cuenta de "1,247.30-" se extrae como "1,247.30" — el signo menos final se pierde. El número es técnicamente correcto, pero el signo está mal, lo que convierte un abono en un cargo y un reembolso en un cobro.

Por qué ocurre: Los motores OCR tratan los paréntesis como signos de puntuación independientes. Cuando un número está entre paréntesis —la notación contable estándar para valores negativos— el paréntesis de apertura se lee como un carácter separado antes del primer dígito, y el de cierre como otro después del último. Durante la extracción, estos paréntesis suelen descartarse porque no coinciden con la clase de caracteres esperada para un campo numérico. Lo mismo aplica para los signos menos finales: al estar después de los dígitos, quedan fuera del token numérico y se clasifican como un fragmento de texto independiente que la lógica de extracción nunca asocia con el número.

Cómo solucionarlo: Defina reglas de detección de signo a nivel de campo. Si el valor extraído aparece en un campo que suele contener abonos, descuentos o ajustes negativos —o si el documento original tiene paréntesis alrededor de un monto en dólares— aplique una inversión de signo después de la extracción. Combine esto con una convención de nombres de campo: una columna llamada "Monto del Abono" o "Descuento" debe esperar un valor absoluto y aplicar automáticamente un signo negativo, sin importar lo que devuelva el OCR.

# Si el contexto del documento indica un campo de magnitud negativa
# y el valor extraído es positivo, invertir el signo
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 Falla 5: Superíndice y Subíndice — Centavos que se Pierden entre Líneas

Síntomas: Un precio que dice "$99⁹⁹" (que significa $99.99, con los centavos en superíndice) se extrae como "$99" o "$9900". Un monto de impuesto impreso en superíndice pequeño junto a un subtotal desaparece por completo. El número base es correcto, pero la parte fraccionaria que define el valor monetario preciso se pierde.

Por qué ocurre: Los caracteres en superíndice comparten la misma región horizontal que el número principal, pero están por encima de la línea base y tienen un tamaño reducido — típicamente del 40–60% del tamaño de punto de los dígitos principales. Los motores de OCR los detectan como una línea de texto o fragmento separado porque la posición vertical se desvía de la línea base principal. En la extracción de texto, este fragmento se asigna a una línea de salida diferente o se descarta durante el análisis de diseño por considerarse atípico. La notación de centavos común en etiquetas de precio minoristas y en algunas partidas de facturas es la víctima más frecuente.

Los valores en subíndice — menos comunes en contextos monetarios pero frecuentes en tasas impositivas y códigos de referencia — enfrentan el mismo problema en dirección opuesta: los caracteres debajo de la línea base se segmentan como regiones de texto independientes y pierden su asociación con el número principal.

Cómo solucionarlo: El enfoque más práctico es combinar todos los fragmentos de texto que comparten la misma posición horizontal dentro de un rango vertical ajustado, y luego validar el valor combinado contra patrones monetarios esperados. Si un número principal "99" va seguido de un superíndice "99" en la misma región de columna, la combinación "99.99" es un valor monetario válido. Implemente esto como una regla de fusión espacial: cualquier fragmento de texto dentro del 150% del rango de coordenada X del número principal y dentro de un desplazamiento vertical definido debe fusionarse en el valor de campo extraído.

# Fusionar fragmentos en la misma región horizontal
# dentro de una banda vertical ajustada
def merge_superscript(main_number, fragments, y_threshold=15):
    """Combinar el grupo de dígitos principal con fragmentos cercanos."""
    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 después de la fusión
    if re.match(r'^\d+\.\d{2}$', combined):
        return combined
    return main_number  # volver al original si la fusión no es válida

Cuándo escalar: Los límites honestos de las correcciones automáticas

Las cinco soluciones anteriores cubren la mayoría de los fallos de puntos decimales y símbolos de moneda. Pero existe una categoría de documentos donde ninguna regla de postprocesamiento puede recuperar el valor correcto de forma fiable: documentos donde el punto decimal es físicamente más pequeño que la resolución mínima que el método de captura puede reproducir. Un punto decimal en un recibo térmico de 72 DPI mide aproximadamente 2 píxeles de ancho. A ese tamaño, la información literalmente no existe en la imagen para que ningún motor — OCR tradicional o IA de visión — la lea de forma fiable.

Si trabajas con recibos térmicos, documentos faxeados o fotocopias de segunda generación, acepta que algunos puntos decimales requerirán verificación manual. El enfoque práctico es marcar cada valor monetario extraído que falle una verificación de magnitud — total fuera del rango esperado, partidas que no sumen el total, número de decimales inconsistente con la moneda — y enviar esas marcas a un revisor humano. Una revisión de 30 segundos de los valores marcados es más rápida y fiable que intentar ajustar el postprocesamiento para recuperar información que se perdió en la captura.

Para equipos que procesan documentos que llegan constantemente a baja resolución, la inversión más efectiva no es una mejor herramienta de extracción — es un estándar de escaneo que exija 300 DPI o más para los documentos entrantes. A 300 DPI, un punto decimal ocupa de 8 a 10 píxeles, que está por encima del umbral de ruido de cualquier motor de extracción moderno.

Preguntas Frecuentes

Próximos pasos: del diagnóstico a la prevención

Un punto decimal faltante no es un evento aleatorio: es el resultado predecible de uno de cinco modos de falla conocidos. La diferencia entre un equipo que detecta estos errores y uno que no, no es la herramienta que usan, sino si cuentan con un marco de diagnóstico. Cuando sabes cuál de los cinco modos de falla estás enfrentando, la solución suele ser una regla de postprocesamiento, no un motor de IA diferente.

Comienza con una auditoría simple: toma los últimos 50 valores monetarios extraídos de tu flujo y clasifica cada error por modo de falla. Si el 80% de tus errores se concentran en una o dos categorías, tienes una solución enfocada que no cuesta nada más que unas pocas líneas de lógica de validación. Si los errores están distribuidos en los cinco modos, el problema probablemente sea la calidad de captura, y la solución es un estándar de escaneo, no un cambio de herramienta.

Para un análisis más profundo sobre cómo varía la precisión de extracción según el formato del documento y cómo diseñar campos que minimicen la ambigüedad, consulta nuestra guía sobre errores de diseño de campo que producen números extraídos incorrectos y el análisis de cómo la variación de formato entre fuentes de documentos genera caídas de precisión. Entre estos tres diagnósticos —diseño de campo, variación de formato y ahora modos de falla a nivel de símbolo— tienes un marco completo para depurar la precisión de extracción en cada nivel del flujo.