Integración de facturación electrónica: Peppol, Verifactu, XRechnung, ZUGFeRD y Factur-X en sistemas que no se diseñaron para esto

Comprar un producto de facturación electrónica es fácil. El problema casi nunca es el producto: es el sistema de gestión de pedidos de hace doce años que emite sus facturas, la lógica de precios que nadie documentó y el hecho de que sus números de factura salen de un procedimiento almacenado que escribió alguien que se marchó en 2019.

Nosotros construimos el conector entre lo que usted tiene realmente en producción y lo que exige la norma. Generación de facturas estructuradas, validación, transmisión por red, procesamiento de entrada y archivado, todo conectado a su sistema actual en lugar de sustituirlo.

Las obligaciones y cuándo aprietan

Europa está pasando de la factura en PDF a la factura estructurada y legible por máquina con un calendario país por país, por delante del paquete VAT in the Digital Age (ViDA) de la UE, que acabará armonizándolo todo. Las fechas que hoy mueven los proyectos:

• España: Verifactu y las obligaciones de facturación de la Ley Crea y Crece avanzan en paralelo a los sistemas forales TicketBAI de las haciendas vascas. Verifactu es, en la práctica, un requisito sobre el software: los registros de facturación tienen que ser inalterables, encadenados y trazables, con su huella y su código QR, lo que afecta directamente a quien emite facturas desde un desarrollo propio. Crea y Crece añade encima la factura electrónica obligatoria entre empresas y autónomos, con el calendario definitivo pendiente del reglamento de desarrollo. Y quien factura desde Álava, Bizkaia o Gipuzkoa lleva ya tiempo conviviendo con TicketBAI, que impone su propio formato y su propio envío. Tres obligaciones distintas sobre el mismo flujo de facturación.
• Alemania: recibir facturas electrónicas estructuradas es obligatorio desde el 1 de enero de 2025. Emitirlas pasa a ser obligatorio el 1 de enero de 2027 para las empresas con una facturación superior a 800.000 EUR, y el 1 de enero de 2028 para el resto. Los formatos que se usan en la práctica son XRechnung (XML puro) y ZUGFeRD 2.x (un PDF híbrido con XML incrustado), ambos conformes con la EN 16931.
• Francia: recepción, y emisión para grandes empresas y medianas, desde el 1 de septiembre de 2026; emisión para pymes desde el 1 de septiembre de 2027. La transmisión pasa por plataformas registradas, con Factur-X como formato híbrido común.
• Bélgica: factura electrónica B2B obligatoria a través de Peppol desde el 1 de enero de 2026, con e-reporting sobre un modelo de cinco esquinas previsto para 2028.
• Polonia: KSeF, la plataforma nacional de clearance, con su propio esquema XML y su propio calendario.
• Italia: SdI y FatturaPA, en marcha desde 2019 y todavía el modelo de clearance más estricto de la UE.

Si vende en varios de estos países, no tiene un proyecto. Tiene una arquitectura y varios adaptadores nacionales, y la diferencia entre plantearlo así o no plantearlo es la diferencia entre una integración y cinco.

Dónde se tuercen los proyectos de verdad

Los datos de la factura no existen con la forma que pide la norma. La EN 16931 exige campos que muchos sistemas nunca capturaron: una referencia del comprador en condiciones, desgloses de IVA por tipo y no por línea, condiciones de pago estructuradas, códigos de unidad de un vocabulario controlado. El trabajo de ingeniería consiste en reconstruir esos campos a partir de lo que hay, de forma determinista, para todas las facturas que vaya a emitir.

Los rechazos de validación llegan tarde. Una factura rechazada es una factura impagada. La validación tiene que ejecutarse antes de la transmisión, contra el esquema vigente y las reglas de negocio vigentes de cada país, y los fallos tienen que llegar a una persona que pueda actuar, no a un fichero de log.

La entrada es más difícil que la salida. Todo el mundo planifica la emisión y se olvida de que, desde la fecha de recepción, hay que aceptar facturas estructuradas de cualquier proveedor, en cualquier formato conforme, y meterlas en cuentas a pagar sin que nadie las abra una a una.

Numeración e idempotencia. Los reintentos, los tiempos de espera agotados y las caídas de plataforma son normales. Una factura enviada dos veces con dos números es un problema fiscal, no informático. Esto hay que hacerlo bien desde el principio.

Qué construimos

Evaluación y decisión de formatos

Un trabajo corto, normalmente de una a dos semanas, en el que miramos cómo se producen realmente sus facturas, qué obligaciones le alcanzan y cuándo, y cuáles son sus opciones realistas. El entregable es una recomendación por escrito: qué formatos necesita, si conviene acceder a Peppol a través de un proveedor o con un punto de acceso propio, qué tiene que cambiar en el sistema de origen y cuánto cuesta.

A veces la recomendación es que basta con un producto estándar y un pequeño adaptador. Preferimos decírselo la primera semana antes que facturarle seis meses.

Generación y mapeo de facturas

Construimos la capa de mapeo desde sus datos de origen hasta las sintaxis exigidas (UBL y CII bajo la EN 16931, XRechnung, ZUGFeRD 2.x, Factur-X, FatturaPA, XML de KSeF), con las derivaciones de campo documentadas para que las puedan seguir tanto un auditor como su equipo financiero. Cuando el sistema de origen sencillamente no puede aportar un campo obligatorio, lo decimos pronto y diseñamos su captura en lugar de inventar un valor por defecto.

Validación antes de transmitir

Validación de esquema, reglas de negocio Schematron y comprobaciones específicas de cada país, todo antes de que nada salga de su casa. Los fallos se encaminan a una cola con dueño humano, con un mensaje que dice qué campo ha fallado y por qué, no una traza de excepción.

Conexión a la red

Conexión a un Peppol Access Point, bien a través de un proveedor establecido, bien operando el suyo propio, según el volumen y el control que necesite. En los países de modelo clearance integramos directamente con la plataforma nacional (KSeF, SdI, el ecosistema francés de PDP) incluida la gestión de certificados y autenticación, que cada plataforma resuelve a su manera.

Procesamiento de entrada

Recepción, validación y normalización de las facturas de proveedor a una única representación interna, casadas contra pedidos y albaranes de recepción cuando existen, y entregadas a su circuito de cuentas a pagar. De aquí suele salir el retorno del proyecto, porque elimina un tecleo manual que nadie llegó a medir nunca.

Archivado y pista de auditoría

Conservación conforme del documento estructurado original, en la forma y durante el plazo que exijan las reglas donde opere (el GoBD alemán, la conservazione sostitutiva italiana o su equivalente), con la vía de recuperación probada y no supuesta.

Sistemas con los que integramos

SAP ECC y S/4HANA, Microsoft Dynamics 365 y Business Central, Odoo, NetSuite, Sage, Infor, Xero, interfaces DATEV y (lo más frecuente) un sistema propio o muy modificado que es central para el funcionamiento del negocio y que no se va a sustituir por una obligación normativa. Trabajamos en .NET, Java, PHP, Python, Node.js y, cuando es lo que hay delante, en stacks más antiguos.

Si opera un marketplace, una plataforma de suscripciones o un motor de facturación que emite facturas por programa y en volumen, ese es exactamente nuestro caso: la factura la genera su código, así que el cumplimiento tiene que vivir en su código.

Lo que no hacemos

No vendemos software de facturación y no somos un programa de contabilidad. Si es una empresa pequeña que busca una herramienta que emita facturas conformes, cómprela: hay una docena que lo hacen bien y cuestan una fracción de un proyecto de integración.

Venga a nosotros cuando la factura la produce un sistema que ya es suyo, cuando tienen que convivir las reglas de varios países, o cuando el volumen obliga a que esto funcione sin que nadie lo esté mirando.

Cómo trabajamos

Evaluación, de una a dos semanas, a precio cerrado, con una recomendación escrita y un plan presupuestado.

Construcción, normalmente de seis a doce semanas para el primer país, según lo limpios que estén los datos de origen. Trabajamos en su repositorio, con su estrategia de ramas, con su equipo, y dejamos tests detrás.

Piloto, enviando facturas reales a un grupo reducido de contrapartes en paralelo con el proceso actual, hasta que la tasa de fallo esté donde tiene que estar.

Puesta en marcha y soporte, con la cola de errores monitorizada y alguien que responda de ella, pasando el primer cierre de mes y la primera declaración de IVA, que es cuando afloran las preguntas que importan.

Normas con las que trabajamos

EN 16931 y sus vinculaciones sintácticas (UBL 2.1, UN/CEFACT CII), Peppol BIS Billing 3.0 y la infraestructura de transporte Peppol, XRechnung y el validador KoSIT, los perfiles ZUGFeRD 2.x y Factur-X, FatturaPA, KSeF, y las propuestas ViDA que están dando forma a lo que viene después de 2030.

Preguntas frecuentes

¿Cuándo nos aplica exactamente la obligación alemana de facturación electrónica?

La recepción se aplica a todas las empresas alemanas desde el 1 de enero de 2025. La emisión se aplica desde el 1 de enero de 2027 si su facturación del ejercicio anterior superó los 800.000 EUR, y desde el 1 de enero de 2028 en los demás casos. La obligación cubre las operaciones B2B nacionales; el tratamiento de la facturación transfronteriza y B2C es distinto y conviene confirmarlo con su asesor fiscal.

¿Cuál es la diferencia entre XRechnung y ZUGFeRD?

XRechnung es XML puro, definido por el sector público alemán y obligatorio para las facturas dirigidas a administraciones. ZUGFeRD 2.x es híbrido: un documento PDF/A-3 con los mismos datos estructurados incrustados dentro, de modo que una persona lee el PDF y una máquina lee el XML. Ambos son conformes con la EN 16931. La práctica comercial B2B en Alemania se inclina por ZUGFeRD; muchos compradores aceptan cualquiera de los dos.

¿Necesitamos un Peppol Access Point propio?

Normalmente no. La mayoría de las empresas se conecta a través de un proveedor de punto de acceso ya existente, que es más barato y más rápido. Operar el propio tiene sentido con volúmenes altos, cuando necesita control sobre la capa de transporte, o cuando presta servicios de facturación a terceros.

¿Pueden trabajar con nuestro proveedor actual de facturación electrónica?

Sí, y a menudo es la forma correcta de plantearlo: el proveedor se encarga de la transmisión y de la pertenencia a la red, y nosotros construimos todo lo que hay entre su sistema y su API, el mapeo, la validación, los reintentos, la gestión de fallos y la conciliación.

¿Qué pasa con las facturas que no superan la validación?

Van a una cola con una explicación legible de qué campo incumplió qué regla. Diseñamos esa cola con intención, porque en los primeros meses tras el arranque es la parte más usada del sistema, y una mala cola convierte un proyecto de cumplimiento en un proceso manual permanente.

¿Cómo evitan enviar dos veces la misma factura?

Con una clave de idempotencia estable derivada de la identidad de la factura, arrastrada en cada reintento, más un registro de transmisión que es la autoridad sobre lo que se envió. Cualquier reintento reutiliza el identificador original en lugar de generar uno nuevo.

Primeros pasos

Díganos a qué países factura, cuántas facturas al mes emite aproximadamente y qué las produce hoy. Le diremos qué obligaciones le alcanzan, en qué orden, y si esto es un conector o un proyecto.

Contáctenos para reservar una evaluación de preparación para la facturación electrónica.

Servicios relacionados

• Desarrollo Entrada Mercado UE: el resto del stack normativo para vender en Europa
• Modernización de ERP y salida de SAP ECC: cuando la obligación de facturación cae en mitad de una migración
• Mantenimiento de sistemas legacy: para el sistema que produce las facturas