Errores frecuentes al enviar facturas, con su causa y solución.
Al enviar una factura desde la plataforma eConnect puede recibir un mensaje de error. La mayoría de los errores se deben a datos incompletos o incorrectos en la factura. A continuación encontrará los mensajes más frecuentes, su causa y cómo resolverlos.
Este mensaje de error genérico es activado por la validación previa al envío de la interfaz de la plataforma. La plataforma comprueba antes del envío si el valor del identificador (p. ej. OINO, número de registro mercantil) se ajusta al formato esperado. Si esa comprobación falla, aparece este mensaje de error.
Ejemplo común: el schemeID 0190 (OINO) requiere exactamente 20 dígitos. Si el valor contiene un prefijo — por ejemplo NL:OINO:00000001001932779000 en lugar de simplemente 00000001001932779000 — la validación falla.
Nota: este error también puede producirse con facturas creadas mediante la API, no solo con facturas creadas manualmente.
Solución: compruebe los valores del identificador y elimine los prefijos o caracteres no válidos. El valor debe ajustarse exactamente al formato esperado para el schemeID (p. ej. 20 dígitos para OINO, 8 dígitos para número de registro mercantil).
Regla general -- introduzca solo el valor numérico; la plataforma añade automáticamente el prefijo schemeID. Esto se aplica a todos los esquemas de identificación, no solo OINO. Si el usuario también introduce el prefijo manualmente (p. ej. 0088:1234567890123 cuando el esquema ya está configurado como GLN/0088), la validación de formato falla. Ejemplo GLN (schemeID 0088, GS1): seleccione el esquema GLN e introduzca solo los dígitos GLN en el campo de valor -- sin 0088: delante.
Si un proveedor coloca un apóstrofo antes del número OIN en el XML (un artefacto conocido de Excel), el enrutamiento Peppol falla. El sistema heredado reconoce la factura y la entrega internamente — el destinatario no ve ninguna factura en su buznón de cuentas por pagar, pero recibe un correo de notificación con un enlace.
Solución: solicite al proveedor que introduzca el número OIN sin apóstrofo en el XML y que compruebe la configuración de exportación de Excel.
Cuando se producen errores de envío desde 4PS, la causa a menudo no es inmediatamente clara. No asuma de antemano que una conexión PSB faltante (Peppol Service Bus) es la causa.
Pasos:
En resumen: el diagnóstico por parte de TechSupport siempre precede a la ruta de ventas. La ruta de ventas (onboarding PSB) solo se aplica cuando TechSupport ha determinado que una conexión PSB faltante es la causa.
La plataforma valida cada factura según los estándares vigentes de Peppol y NLCIUS antes del envío. Los códigos de error que comienzan con BR (Business Rule) indican qué regla no se ha cumplido.
Su propia organización (el proveedor) no está correctamente seleccionada en la factura. Esto ocurre cuando el campo del proveedor se ha modificado manualmente o cuando la organización aún no ha sido activada.
Solución: Haga clic en el icono de edición junto a "Proveedor" y seleccione de nuevo su organización. Si su organización aún no está activada, hágalo primero mediante Añadir y activar una organización.
Ha añadido un adjunto con un tipo MIME no permitido en la validación actual de Peppol BIS Billing V3. Los tipos de adjunto permitidos son (BT-125):
application/pdf)image/png)image/jpeg)text/csv)application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)application/vnd.oasis.opendocument.spreadsheet)application/xml no está permitido como tipo MIME de adjunto en la validación actual de BIS Billing V3. XML como adjunto pertenece a EN 16931-1:2026 y a una futura versión de Peppol (posiblemente BIS Billing 4.0) — no añada un adjunto XML para resolver BR-CL-24.
Causa frecuente (Business Central, Unit4 ERPx y otros ERP): el ERP incrusta automáticamente los adjuntos vinculados a la factura registrada, o exporta bloques UBL incompletos. Un tipo de adjunto no admitido (p. ej. un documento Word) provoca BR-CL-24; falta de BT-122 lleva a BR-52; transferencia sin IBAN a BR-61; etiquetas vacías a PEPPOL-EN16931-R008. Varios códigos a la vez apuntan a la carga útil/exportación ERP, no a una incidencia de entorno eConnect. Puede validar de antemano con el Document Validator.
Solución:
BR-52 se produce cuando el bloque de documento adicional (BG-24) está presente sin Supporting document reference (BT-122). Es habitual en la exportación UBL del ERP, por ejemplo Unit4 ERPx en prueba o piloto.
Solución: indique un ID (BT-122) por adjunto o referencia de documento, u omita el bloque de adjunto incompleto. La corrección está en la exportación UBL del ERP, no en eConnect.
BR-61 se produce cuando Payment means type code (BT-81) es una transferencia (p. ej. SEPA o local/non-SEPA credit transfer, códigos como 30 o 58) sin Payment account identifier (BT-84, normalmente IBAN). Es EN 16931 BR-61.
Solución: indique el IBAN o número de cuenta en los datos de pago, o no envíe un código de transferencia mientras no se incluya un número de cuenta.
PEPPOL-EN16931-R008 se produce cuando el UBL contiene elementos XML vacíos (etiquetas vacías).
Solución: omita por completo los campos sin valor en la exportación UBL; no envíe etiquetas vacías. La corrección está en la exportación ERP/UBL, no en eConnect.
La unidad de medida que ha introducido en una línea de factura no se reconoce como un código UN/ECE válido. Esto ocurre al utilizar una abreviatura o denominación propia.
Solución: Utilice una unidad estándar de la lista desplegable, como "Unidades" (EA), "Horas" (HUR) o "Días" (DAY).
El tipo de identificador en "OrganisatieID" difiere del tipo en "Enviar vía". Por ejemplo: OrganisatieID está configurado como OIN, pero "Enviar vía" está en KvK.
Solución: Asegúrese de que ambos campos utilicen el mismo tipo de identificador. Si factura a un organismo público, configure ambos como OIN/OINO. Si factura a una empresa, utilice KvK (0106) en ambos campos.
El número de IVA del proveedor no está incluido en la factura.
Solución: Introduzca su número de IVA en la configuración de la organización.
¿Su organización no tiene número de IVA (por ejemplo, una fundación, organismo público o proveedor sanitario que presta exclusivamente servicios exentos de IVA)? No utilice el valor ficticio NL000000000B01. Elija en su lugar la categoría de IVA 'O' — fuera del ámbito del IVA al elaborar la factura. Con la categoría 'O', desaparece la obligación de rellenar un número de IVA y la factura cumple con la norma Peppol. Véase también IVA invertido y categoría de IVA O para una explicación de los códigos de categoría de IVA.
Las fundaciones, determinados organismos públicos y proveedores sanitarios que prestan exclusivamente servicios exentos de IVA no tienen número de IVA. Al crear una factura en la plataforma, aparece el requisito de introducir un número de IVA del proveedor.
Solución: Seleccione la categoría de IVA 'O' — fuera del ámbito del IVA (código UNCL5305 O, "Services outside scope of tax") en el formulario de facturación. Con la categoría 'O', se elimina el requisito de la interfaz para el campo número de IVA y la factura puede enviarse sin número de IVA del proveedor.
No utilice números de IVA ficticios como NL000000000B01 — no es la solución prevista para este escenario. La categoría 'O' es la elección correcta para organizaciones sin obligación de IVA.
Diferencia 'E' y 'O': La categoría de IVA 'E' (Exempt from VAT) está destinada a organizaciones sujetas a IVA que facturan una transacción específica exenta. La categoría 'E' sí requiere un número de IVA. La categoría 'O' es para organizaciones sin ninguna obligación de IVA.
Al facturar al Gobierno central neerlandés (Basisfactuur Rijk, vía Digipoort) es obligatorio incluir un IBAN.
Solución: Introduzca su número IBAN en los datos de pago de la factura. En general, es recomendable incluir siempre un IBAN en sus facturas, ya que este requisito se ampliará en el futuro.
Este error se produce cuando el CompanyID (el campo PartyLegalEntity en el UBL) contiene un número de IVA en lugar de un número de registro mercantil o un OIN. Esto no está permitido: la validación NLCIUS exige que las partes neerlandesas siempre utilicen un número de registro mercantil (schemeID 0106) o un OIN (schemeID 0190) como CompanyID. NL-R-003 se aplica al proveedor y NL-R-005 al cliente.
La confusión surge porque el EndpointID (la dirección Peppol utilizada para el enrutamiento) sí puede contener un número de IVA (schemeID 9944). Por lo tanto, una factura con un número de IVA como EndpointID llega correctamente a través de la red Peppol, pero se rechaza si ese mismo número de IVA también aparece en el CompanyID.
Técnico: EndpointID y CompanyID son dos campos distintos con funciones diferentes. El EndpointID determina el enrutamiento a través de Peppol y acepta cualquier tipo de la lista de códigos EAS (incluido 9944 para números de IVA). El CompanyID identifica la entidad jurídica y, para partes neerlandesas, siempre debe ser un número de registro mercantil (0106) o un OIN (0190).
Solución: Verifique el UBL que genera su sistema y asegúrese de que el CompanyID contenga un número de registro mercantil o un OIN, aunque el EndpointID sea un número de IVA. Ambos campos deben referirse a la misma organización, pero pueden tener tipos de identificador diferentes.
Consejo: La legislación ViDA hará progresivamente más estricta la relación entre EndpointID y CompanyID. Asegúrese de que su integración esté correctamente configurada ahora, para no verse sorprendido por futuros cambios normativos.
Variantes de búsqueda: "BR-AE-10", "SOAP:CLIENTBR-AE-10", "Reverse charge shall have a VAT exemption reason", "BT-120", "BT-121", "falta motivo exención inversión sujeto pasivo", "facturas rechazadas reverse charge".
BR-AE-10 se produce cuando una categoría de IVA AE (Reverse Charge) en el desglose de IVA (BG-23) no contiene motivo de exención: ni BT-121 (código) ni BT-120 (texto, por ejemplo "IVA con inversión del sujeto pasivo" o "Reverse charge"). Se trata de un error en el UBL suministrado desde el ERP o el paquete de facturación -- eConnect valida la factura pero no ajusta automáticamente los campos AE.
Solución:
Véase también IVA con inversión del sujeto pasivo: códigos K, AE y G para la explicación completa de los códigos de inversión del sujeto pasivo.
Estas reglas de validación EN 16931 comprueban si el desglose del IVA y los totales de la factura son mutuamente coherentes. Los valores son calculados por el software emisor — no son campos que pueda corregir en la interfaz de eConnect.
Variantes de búsqueda BR-CO-12 / BR-E-01: "BR-CO-12", "BR-E-01", "ChargeTotalAmount", "BT-108", "total de recargos no cuadra", "gastos de envío no en línea de factura", "Shipping costs AllowanceCharge", "falta desglose Exempt".
BR-CO-12 ocurre cuando el total de recargos a nivel de factura no coincide con la suma de los recargos de documento individuales — por ejemplo, gastos de envío incluidos como AllowanceCharge de documento independiente (ChargeIndicator=true, motivo "Shipping costs" / código FC). Esto es UBL válido; véase Recargos y descuentos para la estructura. BR-E-01 ocurre cuando una línea de factura, recargo o descuento de documento con categoría de IVA 'Exento de IVA' (E) no tiene un desglose Exempt correspondiente en el resumen de IVA.
Causa frecuente: redondear el IVA por línea en lugar de por tipo de IVA, o una discrepancia entre los importes de línea y los descuentos a nivel de factura.
Solución: contacte con el proveedor del software emisor para obtener una corrección. eConnect no puede ajustar estos valores porque el cálculo está fijado en el XML proporcionado.
Variantes de búsqueda: «Invalid payload BR-S-08», «Delivery Failed BR-S-08», «el resumen de IVA no cuadra», «línea de factura sin cantidad», «cantidad línea factura faltante», «BT-116», «VAT category taxable amount».
Además de los errores de redondeo, BR-S-08 también falla cuando una línea de factura no tiene cantidad (o tiene una cantidad vacía) (Invoiced quantity / BT-129). En ese caso, el importe de línea sin IVA es incorrecto (cantidad x precio unitario más recargos de línea menos descuentos de línea), por lo que la suma de las líneas se desvía del VAT category taxable amount (BT-116) en el desglose de IVA para Standard rated. El mensaje de error literal suele parecerse a: Invalid payload. [BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is Standard rated, the VAT category taxable amount (BT-116)....
Diferencia con los errores xs:decimal: en la sección «'no es un xs:decimal válido'» anterior, el propio campo de importe no es un número decimal válido (vacío o notación científica). Con BR-S-08 el campo de importe es un número válido, pero el cálculo entre los importes de línea y el desglose de IVA no cuadra.
Lista de verificación de primera línea (antes de escalar al proveedor de software):
Categoría IVA E vs. O: ¿la organización no tiene número de IVA (fundación, organismo público, sanidad)? Utilice la categoría O (fuera del ámbito del IVA) — véase la sección «Organizaciones exentas de IVA: categoría O» más arriba. La categoría E siempre requiere un número de IVA.
R120 es una regla de cálculo que verifica si LineExtensionAmount = (Quantity × PriceAmount ÷ BaseQuantity) + recargos − descuentos. R120 no prohíbe explícitamente los importes negativos; la validación falla cuando el cálculo no cuadra. Esto ocurre con frecuencia cuando un descuento a nivel de línea (AllowanceCharge a nivel de línea) supera el precio del artículo.
Solución: utilice el importe neto del abono directamente como PriceAmount y omita el elemento AllowanceCharge en la línea. Consulte el artículo sobre recargos y descuentos para más detalles y un ejemplo XML.
Estos tres códigos de error aparecen cuando la factura se ha enviado técnicamente, pero el destinatario o el validador rechaza el contenido por campos básicos en el UBL/XML. La causa está en el propio archivo XML, no en la conexión Peppol, el ID Peppol o el método de entrega al cliente.
cbc:CustomizationID (BT-24)urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1) -- eso no debe figurar literalmente en CustomizationID. Consulte BIS Billing 3.0 para la estructura completa del tipo de documento.cbc:ProfileID (BT-23)urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 (factura/abono estándar)Unknown, vacío o texto arbitrario indica un perfil de facturación Peppol no reconocido en el software de origen. Esto no es un fallo por parte de eConnect.Solución: ajuste los campos correspondientes en el software donde se genera la factura -- CustomizationID y ProfileID son valores fijos por tipo de documento, no una configuración en la plataforma eConnect. Si faltan tanto BuyerReference como OrderReference, añada uno de los dos antes de reenviar la factura.
Atención con R007 y otros perfiles BIS: el valor por defecto de la tabla se aplica a una factura/abono estándar. El self-billing y otros perfiles Peppol BIS (p. ej. self-billing invoicing) tienen su propio ProfileID, distinto. No fuerce el valor por defecto en facturas que usan deliberadamente otro perfil BIS -- compruebe primero qué perfil se aplica antes de usar esta FAQ.
No confundir con: un registro Peppol ausente en el destinatario, un EndpointID incorrecto, una caída del Access Point, o el mensaje «no hay reglas de validación disponibles» (véase esa sección más abajo) -- esos casos presentan síntomas distintos a esta combinación de especificación, perfil y referencia.
Este error aparece cuando cbc:InvoiceTypeCode (BT-3) tiene el valor 326 (factura parcial) o 384 (factura de corrección), mientras que el proveedor y el destinatario no son ambos organizaciones alemanas. La regla Peppol BIS Billing 3.0 PEPPOL-EN16931-P0112 solo permite 326 y 384 cuando ambas partes son alemanas.
Interfaz del portal: el selector de tipo de factura está a la derecha en el borrador de la factura. Las etiquetas visibles para el cliente incluyen factura parcial (junto a los términos estándar "factura de corrección" y "factura comercial") -- fácil de pasar por alto.
Solución (portal, factura NL o no alemana):
Fuente: Peppol BIS Billing 3.0 -- PEPPOL-EN16931-P0112.
Este error aparece en línea(s) de factura con categoría de IVA Entrega intracomunitaria / Intra-community supply (K, BT-151) cuando falta un dato de IVA obligatorio. Para la categoría K son obligatorios: el IVA del proveedor (seller VAT, BT-31) o el IVA del representante fiscal (seller tax representative VAT, BT-63), y el IVA del comprador (buyer VAT, BT-48). Los datos que faltan están en los datos de la parte (organización o cliente), no en la línea de factura en sí. El error no señala un número de línea concreto -- la regla se activa en cuanto una de las líneas de factura usa la categoría K.
Solución:
Los ID Peppol belgas pueden tener dos formas:
0208:9925:BE + 10 dígitos; BE1xxxxxxxxx es válido desde 2025)Formato número de IVA: BE seguido de exactamente 10 dígitos (añadir ceros iniciales si es necesario). Verifique el número de IVA mediante la herramienta de validación VIES de la Comisión Europea (ec.europa.eu/taxation_customs/vies).
¿La opción Peppol no aparece para el deudor belga? Compruebe con qué tipo de identificador está registrado el deudor en Peppol. Algunas organizaciones belgas solo están registradas mediante 0208: (KBO) y no mediante 9925: (IVA). En ese caso, pruebe el número KBO: el número de IVA sin BE delante (p. ej. para BE0123456789 el número de empresa es 0123456789; para BE1xxxxxxxxx es 1xxxxxxxxx -- ambos prefijos son válidos).
AFAS: el número de empresa con puntos falla en Peppol BIS V3. Cuando AFAS envía inicialmente una factura SI2.0, no se realiza ninguna validación del número de empresa belga -- los formatos con puntos (p. ej. 0809.948.614) son aceptados. Al cambiar a Peppol BIS V3, el error de formato aparece porque BIS V3 sí valida el número de empresa. Solución: el cliente actualiza los datos maestros en AFAS y elimina los puntos del número de empresa. El formato correcto es exactamente 10 dígitos que comienzan con 0 o 1, sin separadores.
Otros: las líneas de precio negativas no están permitidas en facturas belgas; utilice una cantidad negativa con un precio positivo.
Los códigos de error BR-DE-* son reglas de validación específicas de Alemania para XRechnung.
Leitweg-ID faltante (EAS 0204): frecuente al facturar a organismos públicos alemanes. Solicite el Leitweg-ID al organismo contratante y añádalo como identificador con schemeID 0204.
PDF no aceptado: desde el 1 de enero de 2025, Alemania exige la recepción de facturas electrónicas. Un simple PDF ya no es suficiente en muchos casos. Envíe la factura como XRechnung o ZUGFeRD.
Rechazo KSeF: frecuentemente causado por un formato XML FA_VAT inválido. El PSB de eConnect normalmente gestiona la transformación correcta al formato polaco KSeF.
Errores de certificado: pueden producirse si los certificados KSeF no están correctamente instalados o han expirado.
Limitación de velocidad: KSeF aplica límites al número de solicitudes. eConnect utiliza el procesamiento por lotes para evitar esto.
UWV aplica sus propias reglas de validación además de la validación estándar de Peppol/NLCIUS.
0000000419177124900000000004172892677000Solución por código UWV: complete el campo faltante en la factura. La serie UWV001 se refiere a campos obligatorios del proveedor; la serie UWV002 a elementos de identificación.
No. eConnect es el Access Point de Peppol: se encarga del transporte de tu factura a través de la red Peppol (véase ¿Qué es Peppol?). eConnect no es un software de contabilidad ni de facturación.
Regla práctica para el límite de alcance: un error que se produce antes de que la factura llegue a eConnect -- por ejemplo, una validación de campo en Ciudad, Código postal u otros datos del registro de cliente en el software con el que se crea la factura -- queda fuera del ámbito de eConnect.
Este mensaje aparece en la Bandeja de salida cuando la factura no ha podido entregarse al destinatario a través de la red Peppol. Posibles causas:
Si la entrega falla, puede reenviar la factura y corregir el EndpointID.
not available al (probar) enviar a un destinatario significa: el destinatario no está activo en Peppol para recibir documentos con el identificador utilizado. No se trata de un problema en el lado del remitente.
not available, la plataforma ofrece automáticamente la alternativa por correo electrónico, para que el documento pueda entregarse igualmente al destinatario por e-mail.El campo del proveedor no contiene datos. Esto sucede cuando su organización no está seleccionada o cuando no ha sido activada.
Solución: Haga clic en el icono de edición junto al campo del proveedor y seleccione su organización. ¿Su organización aún no está activada? Siga primero los pasos de Añadir y activar una organización.
El campo del proveedor solo acepta una organización que seleccione en la lista desplegable. Si escribe usted mismo un texto en este campo -- por ejemplo, el nombre de su propia empresa -- en lugar de seleccionar la organización, la sección Proveedor de la factura no se construye correctamente. El campo parece estar completo, pero la factura se rechaza al enviarla. Este error suele aparecer bajo otro mensaje, como "Falta el número de IVA" o "Identificador del proveedor obligatorio".
Solución: elimine el texto escrito en el campo del proveedor, haga clic en el campo y seleccione su propia organización de la lista desplegable. A continuación, vuelva a enviar la factura.
Esta es la misma solución que para "El campo Proveedor está vacío" y BR-NL-1: seleccione su propia organización mediante la lista desplegable. La diferencia es que aquí el campo parece estar completo a primera vista, porque contiene texto -- solo que no una selección válida.
La regla de validación BR-CO-09 comprueba si el número de IVA tiene un formato válido. El número de IVA siempre debe introducirse con el código de país y sin puntos, espacios ni separadores.
123456789B01 (sin código de país)NL123456789B01NL 123.456.789 B01 (espacios y puntos)NL123456789B01BE 0123456789 (espacio)BE0123456789Los códigos de país siguen la norma ISO 3166-1 alpha-2. Los números de IVA son obligatorios cuando el proveedor o el destinatario es sujeto pasivo del IVA y el tipo impositivo no está exento.
Variantes de búsqueda: "icono de stop rojo enviar", "círculo rojo enviar", "la factura no se puede enviar", "el envío falla", "icono de stop factura", "nota de factura obligatoria", "IBAN cuenta bancaria obligatoria", "más información nota de factura", "datos de pago IBAN vacío", "campos obligatorios enviar factura".
Al enviar una factura de venta manual, puede aparecer un icono de stop rojo: la factura no sale. La causa es la validación de formulario del lado del cliente -- no un error de Peppol ni de red, y no un defecto de la plataforma. El deudor/OIN, la accesibilidad de Peppol y el número de pedido ya pueden ser correctos mientras el envío sigue fallando porque otro campo obligatorio quedó vacío.
Compruebe estos dos campos:
Diferencia con otros bloqueos:
¿El envío sigue fallando tras rellenar ambos campos? Pida una captura de pantalla del mensaje de error exacto, no solo del icono de stop.
Variantes de búsqueda: "número de cuenta bancaria con formato incorrecto", "cuenta bancaria con formato incorrecto", "IBAN con formato incorrecto", "error de formato IBAN", "espacios en el IBAN", "formato IBAN datos de pago", "error IBAN al enviar factura manual".
Al enviar una factura de venta manual puede aparecer un mensaje indicando que el número de cuenta bancaria o el IBAN no tiene el formato correcto, incluso si el número es correcto en el fondo. La causa es una validación de formato previa al envío sobre el IBAN o la cuenta bancaria en la sección Datos de pago -- no un error de Peppol ni de red. Espacios, guiones u otros separadores (o la falta de código de país) hacen que la comprobación falle.
Solución:
NL00BANK0123456789).NL.Diferencia con otros bloqueos:
¿El mensaje sigue apareciendo? Pida el contenido exacto del campo (incluidos espacios o caracteres) y el mensaje de error literal o una captura de pantalla.
Variantes de búsqueda: «el botón de envío no responde», «la pantalla de carga se cuelga al enviar», «texto extraño en la factura», «nombre de proveedor raro», «unidad ilogica en la factura», «la organización muestra texto extraño», «iniciar sesión varias veces para guardar», «volver a iniciar sesión para enviar», «campos de factura traducidos», «traducción del navegador al crear la factura», «no puedo iniciar sesión», «texto extraño en la página de inicio de sesión».
Si el botón de envío no responde o la pantalla de carga no avanza al enviar una factura Peppol, y ve sintaxis de plantilla sin traducir como {{invoice.data.supplierDetails.name}} en lugar de los valores introducidos, la causa probable es la traducción automática del navegador.
El mismo patrón puede producirse al crear una (nueva) factura: etiquetas/valores de campo ilógicos o «traducidos» en, entre otros, proveedor, organización y unidad, donde guardar o enviar solo funciona tras iniciar sesión varias veces. Esto tiene la misma causa que los marcadores de posición del botón de envío -- no es un defecto del producto ni motivo para reinstalar software cliente (la plataforma es solo de navegador).
Lo mismo ocurre en la página de inicio de sesión de platform.econnect.eu y en otras partes de la interfaz: texto de marcador de posición o claves i18n en bruto (por ejemplo {{lang.text}} o I18N_COLLABRR_WS.*) en lugar de las etiquetas normales. Los usuarios suelen reportar esto como «no puedo iniciar sesión». Vea también Inicio de sesión y 2FA.
La traducción automática del navegador (Chrome o Edge) interfiere con el DOM de la plataforma. Esto impide que los botones funcionen correctamente y deja visibles marcadores de posición de plantilla o i18n, o etiquetas de campo ilógicas.
Solución (orden de primera línea):
platform.econnect.eu).Si el importe introducido desaparece al pasar al siguiente paso, el campo probablemente contiene caracteres no permitidos. El campo de importe solo acepta números con una coma como separador decimal. Introduzca los importes como 100,00 y no como € 100,00 ni 100.00.
Variantes de búsqueda: «Error al enviar», «error de portal intermitente», «funciona tras reiniciar», «error de envío sin detalles», «mensaje de error sin contenido».
A veces un usuario informa de un error al enviar a través de la plataforma, sin el texto literal del error ni una captura de pantalla. Sin ese contenido no hay suficiente información para un diagnóstico firme; no se trata de una interrupción generalizada conocida.
Posible primer paso (causa no confirmada):
No confundir con:
SentRetry o SentError tras la aceptación -- véase la sección sobre la reentrega automática de Peppol más abajo en esta página; se trata de un mecanismo de reintento del lado del servidor, no de un problema de caché del navegador.Al enviar una factura puede aparecer el mensaje de error «EndpointID no encontrado». Se trata de un bug conocido de la plataforma — no es un problema de registro en Peppol por parte del cliente. Un diagnóstico automático a veces lo clasifica erróneamente como un problema de registro; esa clasificación es incorrecta.
Solución (alternativa temporal): abra el bloque de la factura → haga clic en el icono de lápiz en la parte superior derecha → vuelva a seleccionar el proveedor y/o deudor → envíe la factura de nuevo. La plataforma reconstruye los identificadores en el XML y puede enviar la factura correctamente.
Esta es la misma solución mediante el icono de lápiz que para «El campo Proveedor está vacío» / BR-NL-1 e «Identificador del proveedor obligatorio». La diferencia está en el mensaje de error específico «EndpointID no encontrado».
Este mensaje aparece cuando carga manualmente una factura XML y falta el campo EndpointID del proveedor en el archivo. En la interfaz de la plataforma, este es el campo "Partij-ID" bajo "Proveedor".
Solución: seleccione un valor de su propia organización en el desplegable. Si el desplegable no muestra el resultado correcto, vuelva a seleccionar el proveedor para actualizar la vinculación.
Variantes de búsqueda: «No se han encontrado identificadores activados para el envío de la empresa proveedora», identificadores activados para el envío, «verificación del proveedor aún no realizada», enviar factura nueva administración, dos organizaciones con y sin S.L., identificadores no verificados.
Este mensaje, y la frase del cliente «verificación del proveedor aún no realizada» en una primera factura o nueva administración, normalmente no indica un paso KYC de proveedor independiente. La causa casi siempre se encuentra en uno de estos cuatro puntos.
Lista de verificación (en orden):
Si el mensaje persiste tras estos cuatro pasos, vuelva a enviar la factura después de corregir los datos de la organización o de la factura.
Si una factura no puede enviarse y permanece en la carpeta "Borradores", compruebe dos cosas:
La plataforma eConnect utiliza a veces un prefijo de espacio de nombres en las facturas UBL generadas (p. ej. <urn:Invoice xmlns:urn="...">). Ambas formas — con y sin prefijo — son XML técnicamente válido.
Un destinatario que rechaza facturas por el prefijo del espacio de nombres no cumple con Peppol. El prefijo del espacio de nombres no es configurable por destinatario.
Comunicación al cliente: la factura es técnicamente correcta. El destinatario debe utilizar un analizador XML correcto que gestione tanto los espacios de nombres con prefijo como los predeterminados. El rechazo basado en el prefijo del espacio de nombres no está permitido en Peppol.
Los códigos de error EBMS como EBMS:0003 y EBMS:0004 son errores de transporte AS4 en la comunicación entre puntos de acceso. Los clientes ven SentError o SentRetry en la plataforma — el código EBMS en sí no es visible en la interfaz del cliente.
Acción: remita al cliente a TechSupport. TechSupport puede ver los detalles del error a través del registro de auditoría y Application Insights.
El código de error estado 40 significa que el documento no se ha procesado correctamente. Dos posibles causas:
Diagnóstico: un empleado de eConnect debe investigar en CloudWatch qué pasos de procesamiento ha realizado el documento.
A través de la opción Reenviar en el buzón de salida, puede volver a enviar una factura ya enviada. Antes del envío efectivo, puede modificar campos como la referencia (número de pedido, OrderReference). La factura se reenvía con el mismo número de factura pero con la referencia corregida.
Este es el enfoque recomendado cuando un destinatario rechaza una factura por un número de pedido incorrecto u otro error de referencia. Evita la necesidad de crear una nota de crédito y una nueva factura.
EndpointID obsoleto o modificado (por ejemplo, tras un cambio de número de IVA en el destinatario): si una factura se envió a un ID de Peppol incorrecto o posteriormente modificado, Reenviar con la corrección del EndpointID es la ruta preferida, no abonar y volver a facturar. Vaya al buzón de salida, busque la factura que fue al ID de Peppol incorrecto, haga clic en Reenviar, corrija el EndpointID al ID correcto antes de enviar, y envíe. La factura se reenvía con el mismo número de factura al ID de Peppol correcto. Verifique el ID correcto a través del Peppol Directory.
No es necesaria una nota de crédito con refacturación completa para este escenario. Esa ruta más pesada solo se aplica cuando la factura original ya se haya entregado (parcialmente) o deba corregirse por motivos contables.
Un cliente solo puede realizar un reenvío por sí mismo con una cuenta de plataforma activada con acceso al buzón de salida. Un socio de TI sin cuenta propia debe registrarse primero.
En el actual Peppol BIS Billing 3.0 y NLCIUS, solo se admite 1 referencia de pedido (OrderReference) por factura. Esta es una limitación derivada de la norma europea EN 16931. Si una factura cubre varios pedidos, el proveedor debe enviar facturas separadas.
AdditionalDocumentReference puede contener referencias adicionales de otros tipos (proyecto, contrato o referencia del comprador), pero no múltiples OrderReferences.
Futuro: la EN 16931-1:2026 revisada (aprobada formalmente por CEN el 13 de marzo de 2026) añade soporte para múltiples órdenes de compra por factura. Se espera que se incorpore en una futura versión del estándar Peppol (posiblemente BIS Billing 4.0). Hasta entonces, se aplica la limitación actual de 1 OrderReference por factura en BIS Billing 3.0 y NLCIUS.
Si una factura es rechazada por un número de pedido faltante o desconocido, deben distinguirse dos niveles.
1. Una referencia es obligatoria según EN 16931. Una referencia -- número de pedido u otra referencia (BuyerReference, referencia de contrato o proyecto) -- es obligatoria. Una factura sin ninguna referencia no cumple con las reglas básicas de la norma.
2. eConnect no rechaza por defecto según el contenido de la referencia. La única situación en la que la plataforma rechaza en este punto es cuando no hay ninguna referencia presente.
3. La configuración específica del cliente puede ser más estricta. El rechazo efectivo depende de la configuración del destinatario. En una configuración específica, una factura puede ser rechazada si la referencia es desconocida para ese destinatario. Esto depende de la configuración y no es el comportamiento estándar de la plataforma eConnect.
4. Número de pedido (BT-13, OrderReference/ID) no reconocido por el destinatario. Un número de pedido en el XML normalmente debería ser reconocido por el ERP del destinatario. En la práctica, la coincidencia a veces falla por una de estas razones:
eConnect puede corregir esto a nivel de producto por destinatario, para que el proceso de coincidencia funcione correctamente. Esto también puede configurarse para un remitente específico.
Acción:
Una factura con estado final InvoiceSentError (tras un error de validación 4xx) no intenta más entregas. Solo los errores 5xx se reintentan (máximo 8 intentos, aproximadamente 35 horas). Para un error 4xx, solo se realiza un intento; no se envía nada más al destinatario.
No existe un punto de acceso DELETE para las facturas de venta (salesInvoice). Una factura de venta enviada o rechazada es un evento relevante para la auditoría y permanece disponible en el registro de auditoría durante 90 días. Si la factura era incorrecta, emita una nota de crédito o factura correctiva según el flujo contable estándar.
La red Peppol dispone de un mecanismo automático de reentrega/retry ante fallos temporales de entrega entre Access Points. Cuando la entrega al Access Point receptor (C3) falla temporalmente -- por ejemplo, debido a una interrupción en el lado del destinatario -- el Access Point emisor (C2) intenta volver a entregar el documento más tarde.
SentRetry (nivel de transporte AS4). En caso de fallo definitivo, este pasa a SentError.Este mecanismo de reentrega explica en parte por qué la fecha de recepción puede ser varios días posterior a la fecha de factura (IssueDate). Véase también Fecha de factura (IssueDate) frente a fecha de recepción en eConnect para la explicación en el lado receptor.
Fuente: confirmación de experto Johan Schaeffer (Peppol & Facturación electrónica), 2026-07-04, relativa al ticket #15268901 (W776).
Los errores de validación como TaxInclusiveAmount '-1.336061E6' no es un xs:decimal válido se producen porque el sistema fuente serializa un importe numérico en notación científica (p. ej. -1.336061E6 para -1.336.061,00). Los campos de importe UBL son de tipo xs:decimal, que no permite notación E.
Causa común: el sistema fuente almacena importes internamente como double/float y usa la conversión de cadena predeterminada, que cambia automáticamente a notación exponencial para valores muy grandes o muy pequeños.
Segunda causa distinta -- campo de importe vacío: el error The string '' is not a valid Decimal value en un campo PriceAmountType ocurre cuando un campo de importe (por ejemplo cbc:PriceAmount) contiene una cadena vacía ("") en una o más líneas de factura en lugar de un número decimal. xs:decimal no permite una cadena vacía como valor léxico. Esta es una causa distinta y separada de la notación científica, pero de la misma clase de patrón de error ("no es un xs:decimal válido"/"not a valid Decimal value"): el sistema fuente simplemente deja el campo vacío en lugar de enviar un número mal formateado.
Solución en el lado del cliente (ambas variantes): actualizar el sistema fuente para que los importes se escriban siempre como cadena decimal normal (p. ej. mediante tipos decimal/BigDecimal o un patrón decimal independiente de la configuración regional, sin separadores de miles y sin notación E), y para que ningún campo de importe quede vacío.
En el lado de eConnect: no se puede corregir automáticamente -- el valor ya es incorrecto (o vacío) en el XML suministrado. Remitir al proveedor del paquete de software; la factura debe reenviarse con un importe válido en todas las líneas.
Este escenario se aplica cuando el proveedor afirma haber enviado la factura pero el destinatario no ha recibido nada, y la factura aún no ha alcanzado el estado final 'Entregada' o el estado es incierto.
Diagnóstico en tres pasos:
Para el escenario en el que el estado ya muestra Entregada pero el destinatario dice no haber recibido nada, consulte la sección "Estado 'entregado' pero el destinatario no ha recibido la factura" a continuación.
El estado Entregado significa que el punto de acceso receptor (el proveedor de servicios Peppol del deudor) ha aceptado técnicamente el documento y confirmado esa aceptación. eConnect recibe un returnedMessageId (formato GUID@econnect.eu): prueba de que la factura ha llegado al punto de acceso del destinatario. Dónde es visible el returnedMessageId difiere entre la plataforma y el PSB — compruebe el entorno correcto para el cliente.
Si el deudor indica no haber recibido la factura cuando el estado muestra 'Entregado', el documento ha sido entregado en el punto de acceso del deudor, pero aún no es visible en su propio software o contabilidad. Se trata de un problema posterior en el lado del destinatario.
Pasos para resolver:
returnedMessageId puede facilitarse: con ese identificador, el punto de acceso receptor puede localizar el documento.Variantes de búsqueda: «agregar organización» en una factura, portal de proveedores, nombre de organización + número de registro mercantil arriba a la derecha, no se puede editar la fila de organización existente, no se puede renombrar la organización existente, captura de pantalla organización cliente arriba a la derecha, mensaje de identificador al agregar una organización (proveedor), agregar la propia organización por separado, deudor como propia organización, agregar destinatario de factura al entorno, activar organización deudora de administración pública, el destinatario debe estar en el entorno, registrarse bajo el OIN propio de un municipio, OIN del cliente como propia organización, facturar a un municipio con OIN propio, OIN destinatario no es el propio identificador, esquema 0190 deudor.
Los nuevos usuarios -- especialmente los que cambian de otros servicios de facturación electrónica -- a veces intentan añadir la organización receptora como su propia organización en la plataforma al enviar una factura. Esto no es necesario y genera un mensaje de error.
Para enviar una factura a un destinatario, esa organización no necesita estar en su propia cuenta: al crear la factura, seleccione el destinatario a través del campo de búsqueda de deudor. Puede buscar por número de registro mercantil, nombre de empresa o número OIN.
Mensaje de error "El identificador ya ha sido verificado en otra organización"
Este mensaje aparece durante la presentación de la factura (vía Peppol) o al intentar "agregar una organización receptora". El mensaje cubre dos escenarios con causas y soluciones diferentes:
Escenario 1: el mensaje se refiere al identificador del CLIENTE (destinatario/deudor). Esto es una expresión de uso incorrecto de la plataforma: el usuario intenta agregar una organización cliente/destinataria a su propio entorno. Esto no es un problema de autorización — el soporte no necesita liberar el identificador internamente. El procedimiento correcto: agregue únicamente su(s) propia(s) organización(es) y actívelas en su propio entorno. Luego envíe la factura al destinatario a través del campo de búsqueda de deudor — el destinatario no necesita estar en su cuenta.
Escenario 2: el mensaje se refiere al PROPIO identificador del usuario. El identificador ya está registrado bajo una organización diferente en otra cuenta. Esto no es un uso incorrecto de la plataforma: el usuario desea crear legítimamente su propia organización. Posibles causas: un colega ya ha creado la organización, o la organización todavía existe en una cuenta antigua.
Variantes de búsqueda: "enabled for Peppol sending", "additional Peppol activation", "is sending already enabled", "activación de envÃo adicional", "University of Luxembourg", "9938", "scheme destinatario extranjero".
En una organización activada, el envÃo está activo de forma predeterminada: forma parte de la conexión estándar. No hay un paso aparte de «Peppol send enable» además de un estado de organización activo. Consulte Registrarse en Peppol para el procedimiento de activación completo.
Introduzca el destinatario (por ejemplo, una parte Peppol extranjera como una universidad luxemburguesa) solo en la factura, mediante el campo de búsqueda de deudor (ID de organización + Enviar vÃa). No agregue al destinatario como organización propia en la cuenta; véase también la sección «Confusión: intentar agregar la organización destinataria como la propia organización» más arriba.
¿Sigue recibiendo un error que no se describe aquí? Contacte a través de support.econnect.eu.
Contactar con soporte