Cuando envía una factura a eConnect, el documento pasa por una serie de pasos de procesamiento. El desarrollo exacto de este procesamiento depende del tipo de archivo (XML o PDF) y de la calidad del archivo suministrado. Este artículo explica lo que sucede entre bastidores.

eConnect dispone de dos rutas de procesamiento fundamentalmente diferentes:

Procesamiento XML (ruta directa): si envía una factura UBL válida (SI-UBL 2.0, Peppol BIS Billing 3.0 u otro formato XML compatible), se procesa directamente. La plataforma lee los datos estructurados del XML, los valida y enruta el documento al destinatario. Esta es la ruta más rápida y fiable.

Procesamiento PDF (conversión vía IDR): si envía una factura PDF, se procesa mediante el Intelligent Document Recogniser (IDR). El IDR extrae los datos de facturación mediante OCR y reconocimiento de patrones, y produce una factura UBL basada en los datos reconocidos. Este proceso es intrínsecamente menos fiable que el procesamiento XML directo, ya que depende de la calidad del PDF.

Consejo : el suministro UBL siempre es preferible al PDF. Es más rápido, más económico y más fiable. Pregunte a su proveedor o software si la exportación UBL está disponible.

Al enviar un archivo XML, eConnect realiza los siguientes pasos:

La plataforma reconoce automáticamente qué formato sigue el archivo basándose en el CustomizationID y el esquema XML. Los formatos compatibles incluyen entre otros NLCIUS, BIS Billing V3, XRechnung, CII y Factur-X.

La factura se valida según las reglas del perfil reconocido. Esto incluye:

• Validación del esquema: ¿el XML cumple con la estructura del esquema UBL 2.1 o CII?
• Reglas de negocio: ¿son correctos los cálculos? ¿Están rellenos los campos obligatorios? ¿Coinciden los valores de las listas de códigos?
• Reglas nacionales: ¿se respetan las reglas NL-R-, DK-R- u otras reglas nacionales?

Consejo: ¿Recibe el mensaje de que no se encontraron "reglas de validación"? Esto generalmente significa que el CustomizationID en su XML falta o no se reconoce. Sin un perfil reconocible, el validador no puede aplicar reglas de negocio. Verifique que su factura contiene un CustomizationID válido, como el de NLCIUS o BIS Billing V3.

Una característica notable del procesamiento de eConnect es la reparación automática de archivos XML. Mediante transformaciones XSL, se corrigen errores conocidos. La plataforma acepta en principio cualquier UBL; los campos no esenciales faltantes se rellenan con valores por defecto. Esta función de reparación se mejora continuamente sobre la base del feedback de los clientes y está lista para producción.

Ejemplos de reparaciones automáticas:

• Los campos opcionales faltantes se completan con valores por defecto correctos
• Los errores de formato conocidos en los campos de identificación se corrigen
• Los datos de contacto incompletos se completan (si el campo ElectronicMail del proveedor está vacío, eConnect rellena automáticamente support@econnect.eu, para que las facturas rechazadas lleguen al remitente)

Si el destinatario admite un formato diferente al formato fuente, el PSB transforma automáticamente el documento. Una factura NLCIUS puede, por ejemplo, transformarse a XRechnung si el destinatario es una administración pública alemana. Esto es posible porque todos los formatos compatibles se basan en el mismo modelo semántico (EN 16931).

Técnico : al descargar una factura a través de la API, puede especificar el formato de recepción deseado mediante el parámetro targetDocumentTypeId. El PSB transforma entonces el documento a ese formato.

eConnect nunca reconoce un pedido de venta (documento de pedido) como una factura y no lo convierte automáticamente en factura. Si envía un pedido de venta en un lugar donde se espera una factura, el documento será rechazado.

El proveedor debe suministrar él mismo un documento de factura correcto: una UBL Invoice con el InvoiceTypeCode correcto. eConnect no modifica el documento fuente y no realiza esta conversión.

Excepción -- orderflip: mediante la función orderflip, los datos del pedido pueden servir de base para preparar una factura borrador (draft). Se trata de una acción de usuario independiente, no de una conversión automática de un pedido de venta en factura definitiva. El proveedor debe completar él mismo esa factura borrador y presentarla como documento de factura definitivo (UBL Invoice + InvoiceTypeCode).

Atención: no confunda el reconocimiento del tipo de documento con el reconocimiento de referencias. Un número de pedido de venta que debe reconocerse en una factura (como OrderReference o order_reference) es un campo de referencia, no el tipo de documento en sí. eConnect lee ese número de pedido de la factura y lo vincula como referencia, sin cambiar por ello el tipo de documento.

ZUGFeRD y Factur-X son formatos de factura híbridos: un archivo PDF/A-3 que contiene una factura CII XML integrada. Para estos documentos, la plataforma intenta primero extraer el XML integrado del PDF. Si el XML es válido, se procesa directamente, como una factura XML regular. Solo si el XML integrado resulta no válido, el sistema recurre al procesamiento OCR mediante el IDR.

Una factura ZUGFeRD que pasa los validadores externos pero se procesa mediante OCR indica un problema con el XML integrado en el proceso de validación de eConnect. En ese caso, puede contactar con soporte.

Técnico : la plataforma legacy solo puede almacenar facturas UBL válidas. Cuando una factura ZUGFeRD se procesa mediante el IDR como PDF, la salida del IDR debe primero transformarse a UBL válido (BIS Billing V3 o NLCIUS). Si esa transformación falla porque los datos fuente no contienen suficientes campos para una factura UBL válida, la plataforma no puede almacenar la factura. En el PSB/Control, este problema es menor, ya que las facturas se almacenan en su formato original y solo se transforman en el momento de la entrega.

Si envía un archivo XML no válido, el sistema recurre automáticamente al PDF adjunto. Funciona de la siguiente manera:

1. La plataforma intenta primero procesar el componente XML.
2. Si el UBL no es válido, se utiliza el PDF adjunto como fallback.
3. El PDF se procesa a través de la ruta IDR (OCR y reconocimiento de patrones).

Este mecanismo garantiza que la factura siempre se procese, incluso si el XML contiene errores. Sin embargo, es una ruta más costosa y más lenta que el procesamiento XML directo.

Si un UBL es rechazado (porque no es válido), eConnect igualmente procesa los demás adjuntos del mismo correo electrónico, como un PDF. El remitente recibe entonces un correo con:

• la notificación de que la factura UBL no será procesada, incluyendo el mensaje de error;
• la notificación de que los demás adjuntos del correo se intentarán procesar.

Atención: este mensaje de error en la factura XML no se puede suprimir mientras se procesen otros adjuntos en el mismo correo.

Ejemplo -- BR-AE-10 (Inversión del sujeto pasivo): un UBL con categoría de IVA AE (Inversión del sujeto pasivo) sin BT-121 (código del motivo de exención de IVA) ni BT-120 (texto del motivo de exención de IVA) activa la regla de validación BR-AE-10. En la categoría AE debe estar presente al menos uno de estos campos. El UBL es rechazado, un PDF adjunto se procesa mediante el fallback IDR, y el mensaje de error sobre el UBL permanece visible en el correo al remitente.

Ejemplo -- BR-CO-18 / BR-Z-01 / BR-Z-05 (Zero rated / tipo cero): un UBL con categoría de IVA Zero rated (Z) en una línea de factura, recargo o descuento de documento, sin el desglose de IVA completo correspondiente (BG-23), activa la regla de validación BR-CO-18 (desglose faltante), BR-Z-01 (ninguna línea de desglose con categoría Z) o BR-Z-05 (tipo de IVA para categoría Z distinto de 0). El dual-path aplica también aquí: el UBL es rechazado por esta(s) regla(s), mientras que un PDF adjunto en el mismo correo se procesa igualmente y llega a la Bandeja de entrada. El fallo está en el UBL enviado por el remitente o su software -- eConnect no ajusta los desgloses de IVA. La corrección requiere un nuevo UBL corregido (desglose Z completo, tipo 0, líneas y totales coherentes); enviar solo el PDF no es un sustituto estructural en la vía Peppol/UBL nativo. Detalle first-line: support/troubleshooting-sending.md § cálculo total de IVA.

SI-UBL 1.2 (Simplerinvoicing 1.2) fue definitivamente retirado el 1 de enero de 2024. Las facturas en este formato son rechazadas en la red Peppol. eConnect puede a veces transformar los archivos SI antiguos recibidos por correo electrónico a NLCIUS válido, siempre que los datos esenciales estén presentes. Si faltan datos, la validación puede fallar.

Atención : ¿Recibe mensajes de error al enviar facturas? Compruebe si su software todavía genera SI-UBL 1.2. Si es así, solicite a su proveedor una actualización a NLCIUS/SI-UBL 2.0 o BIS Billing V3.

El procesamiento difiere ligeramente entre la plataforma legacy y el PSB/Control:

• Plataforma legacy: una factura siempre se transforma primero a UBL válido (BIS Billing V3 o NLCIUS) antes de ser almacenada. Si esa transformación falla, la factura no puede ser almacenada.
• PSB/Control: una factura se valida y almacena en la recepción. La transformación solo tiene lugar más tarde cuando es necesario, por ejemplo durante la entrega a un sistema ERP. Esto significa que una factura puede ser almacenada en el PSB, pero que un error de transformación puede ocurrir posteriormente si el formato objetivo no puede ser generado.

eConnect procesa los campos UBL en la recepción tal como se suministran en el UBL fuente y no modifica su contenido. No existe mapeo de campos configurable por el cliente del lado del destinatario para reescribir los valores suministrados. Los valores faltantes o incorrectos deben ser corregidos por el remitente en el UBL fuente. eConnect solo corrige errores técnicos de formato conocidos y completa campos opcionales no esenciales con valores por defecto (véase reparación XML automática arriba).

Un ejemplo concreto con una nota de crédito intracomunitaria entrante (campos de entrega):

Ambos campos son procesados por eConnect en la recepción tal como se suministran. BT-80 solo es obligatorio cuando la factura incluye un grupo Deliver-to-address (BG-15). eConnect no ofrece un mapeo del lado del destinatario para reescribir BT-72 o BT-80. Las correcciones de valores faltantes o incorrectos las realiza el remitente en el UBL fuente.

Una dirección en la visualización de la factura que muestra una mezcla de datos de domicilio y apartado postal no es una mezcla creada por eConnect en la recepción. eConnect transmite los campos de dirección UBL (cac:PostalAddress) 1:1 y no reescribe ni normaliza direcciones. Si el UBL fuente mezcla los componentes de domicilio y apartado postal en un solo bloque PostalAddress, la visualización sigue esa fuente.

Un patrón de mezcla típico en el UBL fuente:

• cbc:StreetName = calle y número (domicilio)
• cbc:AdditionalStreetName = código postal del domicilio, en el campo incorrecto
• cbc:BuildingName = Apartado postal N (el campo canónico de apartado postal en UBL es cbc:Postbox)
• cbc:PostalZone = código postal del apartado postal

La visualización de la factura muestra entonces a menudo la línea de calle junto con PostalZone/CityName, produciendo visualmente una "dirección mezclada" sin que eConnect combine o corrija ningún campo. Ambos componentes de dirección pueden ser correctos por separado, pero combinarlos en un bloque de dirección compartido con códigos postales cruzados es un error de mapeo en el UBL fuente.

Acción: abra el UBL fuente y revise los elementos hijos de PostalAddress de la parte correspondiente. El proveedor corrige el mapeo: o bien un domicilio consistente (StreetName con el PostalZone correspondiente), o un apartado postal en el campo correcto (Postbox) con el código postal correspondiente -- no ambos mezclados con códigos postales cruzados. Una vez corregido el UBL fuente, la visualización se resuelve por sí sola.

Ejemplo -- factura de crédito "Payee/receptor = propia organización": con crédito versus débito, AccountingSupplierParty y AccountingCustomerParty no se invierten. La dirección (a pagar o a recibir) está en el tipo de documento y el signo de PayableAmount, no en partes invertidas. eConnect no ajusta los roles de las partes y no vuelve a aplicar automáticamente una corrección Payee anterior si el UBL de origen ya es correcto -- el mismo principio de passthrough que el anterior. Desarrollado con ejemplo: Variantes de nota de crédito.

Variantes de búsqueda: "factura de crédito Payee", "factura de crédito Payee propia organización", "Supplier Customer intercambiar crédito".

Ejemplo -- IBAN o cuenta bancaria (PaymentMeans) en la recepción por Peppol: el IBAN y los demás datos de pago en una factura recibida por Peppol provienen del UBL fuente del proveedor, generalmente en cac:PaymentMeans / cac:PayeeFinancialAccount (método de pago y número de cuenta; eventualmente otro beneficiario mediante PayeeParty, por ejemplo en caso de factoring). eConnect no rellena este número de cuenta por sí mismo ni modifica el contenido del valor suministrado -- aquí también aplica el traspaso 1:1. Si el IBAN en una visualización PDF difiere de los datos XML estructurados, la diferencia está en lo que el proveedor puso en el UBL respecto al PDF, no en una modificación de eConnect.

Acción ante un IBAN erróneo o diferente: contacte con el proveedor para obtener una e-factura corregida con el IBAN correcto en el UBL. Verifique mediante una descarga XML si el campo PaymentMeans/IBAN realmente difiere. Compruebe también el canal de envío: el icono de Peppol y el icono de escaneo (Scan & Reconocimiento) en la plataforma muestran la diferencia entre suministro XML y reconocimiento PDF (véase Iconos en la plataforma). En una e-factura vía Peppol no hay reconocimiento IDR/escaneo del IBAN -- esa ruta solo aplica al suministro PDF vía Scan & Reconocimiento.

Ejemplo -- varias cuentas bancarias concatenadas en un solo campo PaymentMeans: en ocasiones falla la coincidencia del proveedor por IBAN porque en el UBL transmitido hay varios números de cuenta concatenados en cac:PayeeFinancialAccount/cbc:ID (por ejemplo IBAN1 seguido directamente de IBAN2, como una sola cadena en lugar de bloques de cuenta separados), y eventualmente también varios códigos BIC concatenados en cac:FinancialInstitutionBranch/cbc:ID. Esto se debe al UBL fuente o al mapeo del proveedor: eConnect transmite el XML 1:1 y no separa ni normaliza IBAN/BIC en la ruta Peppol/XML. En la misma factura vía PDF (Scan & Reconocimiento), el OCR suele reconocer los números de cuenta como cuentas separadas y correctas en el UBL generado -- la diferencia está en la ruta fuente (UBL mal concatenado versus reconocimiento OCR), no en un error arbitrario de la plataforma.

Acción: verifique el canal de envío (icono Peppol versus icono de escaneo). En caso de envío vía Peppol/XML aplica el traspaso anterior: muestre el campo PaymentMeans mediante una descarga XML y haga que el proveedor corrija el UBL fuente con bloques PaymentMeans/PayeeFinancialAccount separados, o un único IBAN primario correcto por bloque. Si del mismo remitente también llega un PDF, el OCR puede ofrecer temporalmente IBAN utilizables y separados -- la solución estructural sigue siendo la corrección del UBL fuente. No confunda esto con la validación IDR-IBAN mediante el verification store: es una ruta de reconocimiento PDF distinta.

Corrección a medida mediante consultoría (no self-service): eConnect puede, mediante consultoría, configurar el RBE (rule/business engine) para correcciones automáticas en el flujo. Esto es trabajo a medida a través de la consultoría de eConnect, no algo que el cliente configure por sí mismo. No existe una reescritura self-service configurable por el cliente de los campos UBL suministrados del lado del destinatario.

¿Desea comprobar si su archivo XML se procesa correctamente? Utilice el validador eConnect gratuito para probar su factura de antemano.

• La estructura de una factura UBL
• ¿Cuál es la diferencia entre XML, UBL, BIS Billing V3 y NLCIUS?
• Campos de envío importantes en UBL
• SEEF: la Standaard Energie eFactuur
• Descargar archivos XML de ejemplo
• De la semántica a la sintaxis