El IDR (Intelligent Document Recogniser) reconoce automáticamente los datos principales de una factura PDF y los convierte en campos estructurados en la e-factura. Los campos reconocidos dependen de su suscripción y de la configuración.

En cada conversión de PDF se reconocen automáticamente los siguientes campos:

Con algunos formatos de proveedor, el IDR puede capturar un campo diferente al número de factura, por ejemplo un ID de transacción en lugar del número de factura real. Un ejemplo conocido son las facturas de Meta (Facebook), donde el número de factura aparece en la parte inferior de una página posterior del PDF y el ID de transacción se reconoce de forma más prominente. Otros casos: el número de registro mercantil del proveedor, un número de pedido/PO o una referencia bancaria/de pago (por ejemplo una referencia bancaria, el IBAN o una parte del IBAN/número de cuenta) en lugar del número de factura real, lo que provoca un número de factura incorrecto en Coda o en el sistema ERP. Esta última variante también puede bloquear una nota de crédito como duplicado (véase Factura duplicada). Se trata de un error de selección de campo en el reconocimiento, distinto del reconocimiento correcto de una referencia de pago como campo PaymentID independiente (véase Domiciliación y cuenta G): ahí la referencia de pago no sobrescribe el número de factura, aquí se reconoce por error en su lugar.

Esto puede mejorarse para el formato de proveedor en cuestión. El reconocimiento del número de factura no es configurable por el cliente, pero se optimiza internamente por un miembro del equipo de soporte mediante detección de valores atípicos, regex y sugerencias por proveedor o formato. No se requiere ningún cambio en la hoja de ruta; se trata de una optimización dirigida de la funcionalidad existente. Informe de este caso al soporte — con base en el informe, el equipo añade una sugerencia específica del proveedor para que las futuras facturas de ese formato reciban el número de factura correcto.

¿Cómo funciona el reconocimiento en segundo plano (SampleStore)? El IDR utiliza para ello el SampleStore: una base de datos de patrones de reconocimiento por proveedor. El proceso se realiza en tres pasos: (1) búsqueda de números que coincidan con un patrón RegEx en el SampleStore, (2) comparación con ejemplos anteriores del mismo proveedor (longitud, estructura, guiones, puntos, guiones bajos, coherencia), (3) ajuste de autoaprendizaje basado en nuevas facturas. El soporte añade ejemplos y opcionalmente un RegEx al SampleStore tras un informe.

Número corto o diferente en lugar de un patrón de prefijo más largo. Cuando las facturas de un proveedor normalmente tienen un prefijo fijo y una longitud fija, el IDR a veces reconoce un número más corto o diferente sin ese prefijo. Si el patrón (prefijo, longitud, estructura) ya está claro a partir del informe, el primer paso es ajustar directamente el SampleStore o el RegEx para ese proveedor; un ejemplo de PDF o XML sirve entonces como evidencia, no como primer paso obligatorio. Si el reconocimiento funcionaba correctamente antes y ha vuelto a ser incorrecto con el tiempo, se aplica el mismo enfoque: revisar y ajustar el SampleStore para ese proveedor, lo que no indica un defecto del producto.

Para la investigación, el XML de la plataforma del buzón de entrada es el archivo útil: contiene el rastro de reconocimiento IDR. Un XML que usted mismo exporta desde su sistema ERP (por ejemplo AFAS) una vez corregido manualmente el número de factura generalmente carece de ese bloque IDR y solo muestra el número ya corregido — ese archivo no es adecuado para analizar el error de reconocimiento.

Texto oculto o transparente en el PDF (reutilización de plantilla). Algunos proveedores reutilizan un PDF de factura antiguo como plantilla para nuevas facturas. Fechas o números de factura anteriores pueden quedar como texto residual invisible o transparente en la capa de texto del PDF. El IDR utiliza OCR híbrido: además de la imagen visible, también se lee la capa de texto del PDF. En una captura de pantalla o en pantalla solo se ven las líneas visibles, pero el reconocimiento ve la capa de texto completa incluido el texto residual oculto. Esto puede ser la causa cuando un número de factura o fecha antiguo y uno nuevo se mezclan en el reconocimiento. Si sospecha este patrón, solicite siempre el PDF original: una captura de pantalla no es suficiente porque carece de la capa de texto. Luego copie el texto del archivo en un editor de texto plano para verificar la discrepancia con la visualización visible.

Síntoma secundario: factura marcada incorrectamente como duplicado. Una factura posterior puede marcarse incorrectamente como duplicado porque el IDR reutiliza o hace coincidir un número de factura incorrecto (oculto). Esto es una consecuencia del error de reconocimiento subyacente, no un problema separado: primero corrija el reconocimiento de la capa de texto como se describe arriba, en lugar de tratar la detección de duplicados de forma aislada (véase Factura duplicada).

Variantes de búsqueda: «número de registro mercantil diferente en el XML», «número de registro mercantil factura vs XML», «registro mercantil remitente difiere», «registro mercantil proveedor incorrecto en XML», «registro mercantil proveedor XML diferente de la factura», «ID de parte remitente XML PDF», «AccountingSupplierParty registro mercantil».

A veces el número de registro mercantil del proveedor (u otro ID de parte, como un número de IVA) en el bloque de remitente del XML difiere de lo que figura en el PDF original, o el reconocimiento asocia la factura con el proveedor equivocado. Se trata de un error de reconocimiento de campo en el identificador del proveedor, igual que con los importes, la divisa o el número de factura.

Atención — no es lo mismo que «registro mercantil leído como número de factura». En ese otro caso (véase arriba), el número de registro mercantil se reconoce por error en el campo del número de factura. Aquí se trata del ID de parte en el propio bloque de remitente, que no coincide con el PDF. Ambos son cuestiones de reconocimiento distintas.

¿Qué puede hacer? No existe una opción de autoservicio para ajustar el XML. Reúna el PDF original y el XML asociado (descargable desde el documento en el buzón de entrada) y/o el ID del documento de la tarea de conversión, e infórmelo al soporte. Con base en ello, el equipo ajusta el reconocimiento o la coincidencia de proveedor. Al igual que con otros errores de reconocimiento, no se aplica ningún plazo estricto aquí.

Variantes de búsqueda: «divisa no reconocida correctamente», «divisa reconocida incorrectamente», «divisa incorrecta IDR», «SEK en lugar de NOK», «currency wrong PDF», «reconocimiento divisa factura», «PDF divisa incorrecta», «divisa leída incorrectamente».

La divisa es un campo reconocido en estándar (ver tabla anterior) y cae bajo los mismos errores genéricos de reconocimiento PDF→XML que el número de factura o el importe: el IDR puede reconocer incorrectamente el código de divisa ISO en comparación con el PDF (por ejemplo SEK en lugar de NOK). Esto no es una funcionalidad separada ni un problema independiente, sino la misma cuestión de reconocimiento que con otros campos.

¿Qué puede hacer? Informe de la discrepancia al soporte y proporcione el PDF original junto con el XML asociado (del buzón de entrada), o el ID del documento de la tarea de conversión. Con ello, el equipo optimiza el reconocimiento para el formato de proveedor en cuestión. Al igual que con otros errores de reconocimiento, no se aplica ningún plazo estricto aquí.

Con la suscripción Professional se reconocen campos adicionales:

Variantes de búsqueda: "fecha americana", "fecha de factura americana", "fecha proveedor EE. UU.", "fecha de factura USA", "fecha de factura MDY", "MDY en lugar de DMY", "formato de fecha Estados Unidos", "fecha de factura no reconocida correctamente proveedor americano", "American date format invoice date", "US supplier date format MDY".

El IDR reconoce fechas en facturas PDF y las convierte al formato de fecha UBL estándar (YYYY-MM-DD). Como las notaciones de fecha varían según el país, el IDR determina, según el país del proveedor, cómo interpretar las fechas ambiguas:

• Estados Unidos: MDY (mes-día-año). La fecha 03/11 se interpreta como el 11 de marzo.
• Todos los demás países: DMY (día-mes-año). La fecha 03/11 se interpreta como el 3 de noviembre.

¿Ve en un proveedor de Estados Unidos una fecha de factura que cree que se ha reconocido incorrectamente? Compruebe primero esta regla de país antes de reportarlo como un error de reconocimiento de campo: en un proveedor americano, 03/11 es, por ejemplo, el 11 de marzo, no el 3 de noviembre. Si la notación de fecha no es la explicación, se trata de otra cuestión de reconocimiento (véase arriba).

Si la detección automática del país no basta, se puede añadir por proveedor una indicación específica sobre el formato de fecha mediante el mecanismo de hints.

Tip: las fechas interpretadas de forma incorrecta (por ejemplo 03/11 como 11 de marzo en lugar del 3 de noviembre) casi siempre son un tema de reconocimiento, no de la plataforma. La plataforma muestra siempre la fecha tal como figura en el UBL.

Con la suscripción Professional, el IBAN reconocido se compara con el verification store: una base de datos de IBAN validados manualmente con anterioridad por proveedor. Si el IBAN de la factura difiere de lo verificado antes, se señala. Esto ayuda a detectar facturas falsas o datos bancarios modificados.

Nota: según la norma europea EN16931, el IBAN en una factura sirve principalmente para identificar al proveedor, no como instrucción de pago. Un IBAN modificado debe validarse siempre primero en los datos maestros de su sistema financiero antes de pagar.

Además de las referencias estándar (número de pedido, número de contrato, número de proyecto), se pueden configurar otras referencias de forma específica por proveedor, por ejemplo códigos presupuestarios, códigos de responsable de presupuesto o referencias internas. Es un trabajo a medida que se configura por tarjeta de franjas.

El reconocimiento de referencias configurables utiliza un mecanismo de tres capas:

1. Regex: validación de formato para garantizar que la referencia extraída coincide exactamente con el formato esperado
2. Outlier detection: detección estadística de valores poco probables
3. Hints: datos de entrenamiento generados automáticamente a partir de correcciones del equipo QC

Tip: el número de pedido es la referencia más utilizada y la indican la mayoría de proveedores en la factura. Si un proveedor no puede rellenar un campo de referencia concreto en su software, poco sirve exigirlo. En ese caso use el número de pedido como referencia principal.

Nota: número de pedido, número de contrato y número de proyecto son campos estándar de Professional, pero el reconocimiento solo se activa tras una configuración única del soporte por cliente/proveedor (basada en al menos 5 facturas de ejemplo, opcionalmente complementada con una regex). Contacte con soporte y facilite preferiblemente una factura de ejemplo.

¿Recibe a través de la API la respuesta informativa Order Reference detection skipped as Sample store is empty o Contract Reference detection skipped as Sample store is empty? No es un error de procesamiento. El IDR solo rellena estas referencias cuando el Customer Sample Store de su endpoint contiene referencias de ejemplo con las que comparar. Si el store está vacío, solo se omite esa detección de referencia; el resto de campos y funciones se reconocen normalmente.

Solución: facilite algunos números de pedido o referencias de contrato de ejemplo (al menos 3 caracteres por ejemplo) exactamente como aparecen en las facturas, para que soporte pueda configurarlos en el Customer Sample Store. Después se aplica primero una coincidencia de etiqueta (por ejemplo «Your order number»), con regex como respaldo. También hay disponible un Remote Starter a través de ventas para configurar el reconocimiento del número PO.

No, no directamente en la plataforma. No gestiona usted mismo el Customer Sample Store, las reglas de formato ni la RegEx para el reconocimiento del número de pedido; esto lo configura el soporte de eConnect.

Sin embargo, indirectamente, puede:

• hacer que los proveedores facturen con un formato de referencia de pedido claro y uniforme (vea la buena práctica a continuación);
• compartir el conocimiento del formato (prefijo, longitud fija, estructura) con soporte;
• proporcionar, tras un reconocimiento fallido, el PDF original o el ID de documento junto con el número de pedido correcto, para que soporte pueda actualizar el Sample Store.

Buena práctica para el formato de la referencia de pedido en el PDF:

• indique la referencia de pedido preferiblemente una sola vez en la factura, sin repetirla en varios lugares;
• use una etiqueta habitual, por ejemplo Número de pedido, Número PO, Número de pedido de compra o Your order number;
• separe la etiqueta y el número con un espacio o signo de puntuación, por ejemplo Número de pedido: 420000007 en lugar de PO420000007;
• mantenga una estructura fija y preferiblemente una ubicación fija en la factura.

Vea también Errores de envío ante una factura bloqueada o rechazada por un número de pedido mal reconocido.

Variantes de búsqueda: "varios números de pedido", "varios números de orden de compra una factura", "varias referencias de pedido PDF", "OrderReference cabecera", "PO en línea de factura", "reconocimiento de líneas PO", "reconocimiento varios números PO".

• Nivel de cabecera: máximo un número de pedido (OrderReference) en la cabecera de la factura. Varios números de pedido en un mismo PDF no rellenan automáticamente varias referencias de pedido de cabecera.
• Nivel de línea como texto: números de pedido adicionales en el PDF pueden acabar en la descripción de línea (fragmento de texto) mediante el reconocimiento de líneas; esto no es en sí una referencia de línea de pedido estructurada.
• Referencia de pedido real a nivel de línea: solo si el destinatario tiene configuración a nivel de línea; no es estándar "varios PO → varias referencias de pedido".

No espere un enlace automático entre varios números de pedido y varias referencias de pedido de cabecera. Para un diseño multi-PO, compruebe primero la configuración de Professional y Sample Store para el único PO de cabecera; los números de pedido adicionales acaban como texto de línea, no como referencia de línea de pedido separada, a menos que el destinatario lo haya configurado él mismo. Vea también Reconocimiento de líneas para los campos de referencia por línea.

Según la norma europea EN16931, una referencia (buyer reference) es obligatoria en una factura electrónica; suele ser un número de pedido u otra referencia del destinatario. Un remitente puede colocar un valor incorrecto en este campo.

eConnect no rechaza una factura por la referencia de forma predeterminada. Una factura solo incumple las reglas básicas de la norma europea si no hay ninguna referencia en absoluto. Si una factura es rechazada por una referencia desconocida o incorrecta depende de la configuración del destinatario: en una configuración específica del destinatario, una factura puede rechazarse si la referencia es desconocida. Por lo tanto, esto es una propiedad de la configuración receptora, no del procesamiento estándar de eConnect.

Consejo: si deseas rechazar facturas por referencias faltantes o desconocidas, configura esto a través de RBE (Rule Based Enrichment) en el endpoint receptor.

El número de factura (campo UBL cbc:ID, BT-1) es obligatorio en EN 16931, UBL BIS Billing 3.0 y NLCIUS para facturas regulares. Sin embargo, el IDR procesa un flujo de documentos mixto: facturas regulares, notas de crédito, gastos y recibos. Los recibos caen bajo el régimen de factura simplificada (transacciones hasta aproximadamente 100 € IVA incluido), para el que la administración fiscal no establece el número de factura como requisito legal. Rechazar por un número de factura faltante excluiría todos los recibos y gastos del procesamiento.

Por ello, la pipeline IDR genera automáticamente un número sustituto cuando no se puede extraer ningún número de factura del documento durante el reconocimiento. El campo cbc:ID (BT-1) se rellena con la estructura:

YYYYMMDDHHmmss-NOTFOUND

La marca de tiempo es el momento del procesamiento por la pipeline IDR, no la fecha en el documento. Ejemplo: 20240315143022-NOTFOUND.

El filtrado es posible en dos niveles:

1. RBE (Rule Based Enrichment): configura una regla que comprueba si BT-1 (cbc:ID) termina en -NOTFOUND. En base a esto, el documento puede retenerse para revisión manual, redirigirse a una bandeja de entrada separada, o rechazarse automáticamente.
2. Sistemas propios (ERP/software contable): una búsqueda directa de cadena o expresión regular en -NOTFOUND en el campo cbc:ID es suficiente.

Con el reconocimiento de líneas también se reconocen las líneas individuales de la factura: descripción, precio unitario, cantidad, importe de línea y campos de referencia por línea. Es una función independiente que puede activar usted mismo en Mi Entorno.

¿Quiere saber cómo funciona el reconocimiento a nivel técnico? Lea ¿Cómo funciona Scan & Reconocimiento (IDR/OCR)?.