Facturas y órdenes de compra: cómo curar datos financieros para IA sin morir en el intento

Sectores regulados
Facturas y órdenes de compra: cómo curar datos financieros para IA sin morir en el intento

Respuesta rápida

¿Cómo normalizar un NIF español extraído de un PDF escaneado con posibles errores de OCR?

Primero, aplica un patrón regex (letra + 8 dígitos + letra). Si falla, corrige automáticamente caracteres confundibles (O->0, l->1, etc.) y revalida. Si sigue fallando, marca el campo para revisión manual y registra el error en la trazabilidad.

En cualquier departamento financiero o administrativo, las facturas y las órdenes de compra son el pan de cada día. También son la fuente de datos favorita para proyectos de IA: extracción automática de importes, detección de duplicados, predicción de pagos, clasificación de proveedores. Pero hay un problema: rara vez dos documentos son iguales.

Curar este tipo de documentos para IA exige algo más que un OCR y un parseo de PDF. Exige entender la lógica de negocio que hay detrás de cada campo.

El lío de los formatos: nunca es solo un PDF

Una factura puede llegar como:

  • PDF nativo (con texto seleccionable).
  • PDF escaneado (solo imagen, hay que hacer OCR).
  • XML facturae (en España, el estándar del Ministerio de Hacienda).
  • EDI (formato electrónico estructurado, muy usado en gran distribución).
  • Imagen de móvil (con sombras, inclinada, a veces con dedos).
  • Datos incrustados en un correo electrónico.

Cada formato exige un tratamiento distinto. Y lo que funciona para un XML (extracción limpia) no sirve para un PDF escaneado de mala calidad. Por eso la curación debe empezar por clasificar el tipo de formato antes de cualquier extracción. Sin esa clasificación, las reglas de parseo se rompen constantemente.

Los campos críticos que siempre fallan (y cómo curarlos)

En facturas y órdenes de compra hay campos que parecen sencillos pero son trampa:

  • Número de factura: a veces incluye letras, a veces solo números, a veces guiones. Algunos proveedores usan el mismo número con un dígito de control. Si no normalizas, tratarás facturas distintas como duplicadas.
  • NIF/CIF del proveedor: los OCR confunden la letra O con el cero, o la letra l con el 1. Una curación mínima debe incluir una validación contra un patrón (letra + 8 dígitos + letra en España) y, si falla, marcar el campo para revisión manual.
  • Importe total: algunos documentos usan coma como separador decimal, otros punto. Algunos incluyen el símbolo de moneda pegado al número. La normalización es obligatoria, pero con cuidado: una factura con «1.000,50» en España son mil euros con cincuenta céntimos; en Inglaterra, mil punto cincuenta.
  • Fecha: formatos dd/mm/aaaa vs mm/dd/aaaa. Si no sabes el país de origen, una fecha como 03/04/2025 puede ser 3 de abril o 4 de marzo. La curación debe incluir el contexto regional.
  • Referencia a orden de compra: el documento debe incluir el número de OC, pero a veces está en un campo aparte, a veces en el texto libre. Y cuando lo extraes, hay que comprobar que esa OC existe en tu sistema. Sin validación referencial, el modelo aprenderá relaciones falsas.

La relación entre factura y orden de compra: el punto más delicado

En un proceso sano, cada factura debería hacer referencia a una orden de compra (o a varias). En la realidad, las referencias están mal escritas, incompletas o directamente ausentes. Para curar un dataset que relacione ambos, necesitas:

  • Extraer la referencia de OC desde la factura (usando reglas específicas por proveedor, si es posible).
  • Normalizar esa referencia al formato que usa tu sistema interno.
  • Registrar si la coincidencia es exacta, aproximada o nula.
  • Para los casos sin coincidencia, decidir si excluyes la factura del dataset o la marcas como «no vinculada».

Un modelo de IA que intente prever retrasos de pago basándose en datos de facturas sin una buena curación de estas relaciones será poco fiable.

Cómo estructurar un dataset curado de facturas y órdenes de compra

Un buen dataset para IA financiera debería incluir, al menos, los siguientes campos curados:

  • id_factura (normalizado, sin duplicados aparentes)
  • id_proveedor (validado contra padrón)
  • fecha_emision (en formato ISO, con zona horaria explícita)
  • importe_total (numérico, sin símbolos, punto decimal)
  • moneda (código ISO tres letras)
  • id_orden_compra (si existe, normalizado)
  • estado_coincidencia (exacta, parcial, inexistente)
  • metadatos_trazabilidad (origen del documento, versión OCR, etc.)

Además, conviene guardar una copia del documento original (o su hash) y un registro de las transformaciones aplicadas. Así, cuando el modelo falle, podrás depurar si fue error de extracción o de lógica de negocio.

Conclusión

Curar facturas y órdenes de compra para IA no es un trabajo de un fin de semana. Requiere conocer los formatos, las trampas de cada campo y la lógica de negocio que relaciona los documentos. Pero si lo haces bien, tu modelo financiero podrá automatizar tareas que antes requerían decenas de horas de revisión manual. Y lo que es mejor: podrás confiar en sus resultados.

Preguntas frecuentes

Depende del objetivo del modelo. Si la relación es obligatoria, excluye esa factura del dataset. Si no, inclúyela pero marca el campo referencia OC como «no disponible» y registra el motivo. No inventes una relación falsa.

Para la curación automática, sí. El XML ya tiene los campos etiquetados, lo que elimina errores de OCR y parseo. Pero muchos proveedores no lo usan. Un buen dataset suele combinar ambas fuentes, normalizando los XML directamente y aplicando curación pesada a los PDF.

No te fíes solo del número de factura. Combina: número + NIF proveedor + importe + fecha (con cierta tolerancia). Y si el dataset incluye la orden de compra, úsala también. Los duplicados suelen tener la misma OC asociada.

Para uso financiero, debería ser >99.5% en campos numéricos críticos. Por debajo de eso, los errores de pago o conciliación pueden ser muy caros. Si no alcanzas esa tasa, considera doble extracción con dos motores OCR distintos o revisión manual por muestreo.