BORRADOR DEL PROYECTO DE REAL DECRETO POR EL QUE SE ESTABLECE EL RÉGIMEN JURÍDICO APLICABLE A LA FACTURA ELECTRÓNICA ENTRE EMPRESARIOS Y PROFESIONALES

El borrador del reglamento de facturación electrónica B2B publicado en marzo de 2025 introduce cambios relevantes para empresas y profesionales en España. Esta nueva regulación afecta tanto a los plazos de entrada en vigor como a los formatos obligatorios, sistemas de autenticidad y procedimientos de comunicación de pagos. En este artículo desglosamos las claves técnicas y jurídicas más importantes del texto.

En marzo de 2025 fue publicada la segunda y definitiva información pública del proyecto de RD que aprobará el Reglamento de desarrollo de la facturación electrónica B2B.

A modo de resumen:

• Se abandona el formato Facturae en la solución pública de facturación y se escoge en su lugar el formato UBL, alineándose así con las previsiones de VIDA
• Se realiza una regulación más detallada de la figura de la copia fiel de la eFactura
• Se detalla la forma de realizar el cálculo del plazo de pago de las facturas electrónicas
• El plazo de para la entrada en vigor se alarga y será:
  • Para los empresarios y profesionales cuyo volumen de operaciones (calculado según la Ley del IVA) haya excedido durante el año natural inmediato anterior de 8 millones de euros: El Real Decreto producirá efectos transcurrido un año desde la aprobación de la orden ministerial
  •  Para el resto de los empresarios y profesionales (aquellos cuyo volumen de operaciones sea igual o inferior a 8 millones de euros): El Real Decreto producirá efectos transcurridos dos años desde la aprobación de la referida orden ministerial

REQUISITOS TÉCNICOS

Los requisitos técnicos para adaptar el sistema de facturación más relevantes que recoge este Reglamento son:

1. Formato y Estructura de la Factura Electrónica:
   • La factura electrónica obligatoria debe ser un mensaje informático de carácter estructurado. Esto significa que no basta con un simple PDF, sino que debe contener los datos de forma organizada y legible.
   • Debe ajustarse al modelo semántico de datos EN16931 del Comité Europeo de Normalización.
   • Las sintaxis (formatos) admitidas son CII, UBL, EDIFACT y Facturae. Peppol BIS se considera incluido en UBL si cumple EN16931.
   • Si su empresa utiliza una plataforma privada, esta plataforma debe tener la capacidad de transformar el mensaje de factura entre todos los formatos admitidos.
   • La Solución Pública de Facturación Electrónica de la AEAT utilizará la sintaxis UBL como referencia. Si utiliza la solución pública, deberá emplear UBL. Si una plataforma privada se interconecta a través de la solución pública, la sintaxis será UBL.
2. Contenido Mínimo y Adicional:
   • La factura electrónica debe cumplir con los requisitos mínimos sobre el contenido definidos en el Reglamento por el que se regulan las obligaciones de facturación (RD 1619/2012).
   • Debe identificarse con un código único que incluya necesariamente el NIF del emisor, el número y serie de la factura, y la fecha de expedición. Este código puede estar en un solo campo o en una concatenación de campos.
   • Se podrá incluir contenido voluntario adicional si encaja en la sintaxis admitida y si ha sido acordado contractualmente con el proveedor. La información provista por el destinatario solo podrá requerirse si se remitió de forma fehaciente al emisor antes de la operación.
   • Las copias electrónicas fieles que se remitan a la solución pública (si no se usa la solución pública para emitir) deben contener la información de los conceptos de la factura original que tengan correspondencia semántica equivalente en la sintaxis UBL de la solución pública, cumpliendo el contenido mínimo del RD 1619/2012.
3. Autenticidad, Integridad y Sistemas:
   • La factura electrónica debe ser producida por sistemas y programas informáticos o electrónicos adaptados al artículo 29.2.j) de la Ley General Tributaria.
   • La autenticidad (identidad del emisor) y la integridad (no modificación) deben estar garantizadas.
   • Si se emite a través de una plataforma privada, la factura debe estar firmada por el emisor con firma electrónica avanzada (basada en certificado o sello electrónico cualificado). Otros medios como EDI con procedimientos que lo garanticen, o medios previamente validados por la AEAT, también pueden usarse.
   • Si se utiliza la Solución Pública, la autenticidad e integridad se garantizarán mediante los procedimientos que la AEAT tenga establecidos.
   • La autenticidad e integridad se presumirá acreditada si se usa un sistema o programa informático conforme al reglamento específico (aún en desarrollo) sobre los requisitos técnicos para sistemas de facturación (desarrollo del art. 29.2.j LGT).
4. Obligaciones de Interacción del Sistema (Plataformas y Solución Pública):
   • Su sistema de facturación (si es propio o a través de una plataforma privada) debe ser capaz de emitir y recibir facturas electrónicas.
   • Si utiliza una plataforma privada o un sistema propio que NO emite directamente a través de la Solución Pública de la AEAT, su sistema (o la plataforma) deberá remitir una copia electrónica fiel de cada factura en sintaxis UBL a la Solución Pública de Facturación Electrónica simultáneamente a su emisión.
   • Si utiliza una plataforma privada, esta debe ser capaz de interconectarse de forma gratuita con cualquier otra plataforma privada a petición de un cliente, y dicha interconexión debe estar operativa en un plazo máximo de un mes [15, 45, 46, 47, 52h].
   • Mientras una interconexión entre plataformas privadas no esté operativa, las facturas deben depositarse en la Solución Pública de Facturación Electrónica.
5. Comunicación de Estados de la Factura:
   • Su sistema, si es el destinatario de una factura electrónica, debe tener la capacidad de informar al emisor (a través de la plataforma privada o vía utilizada) de, al menos, los siguientes estados y sus fechas: Aceptación o rechazo comercial de la factura y Pago efectivo completo de la factura.
   • Esta información debe remitirse en un plazo máximo de 4 días naturales (excluyendo sábados, domingos y festivos nacionales) desde que se produce el estado.
   • Adicionalmente, y de forma OBLIGATORIA, como DESTINATARIO, su sistema debe comunicar el PAGO EFECTIVO COMPLETO de la factura a la Solución Pública de Facturación Electrónica de la AEAT. Esto es independiente de si la factura se recibió por la solución pública o una plataforma privada, y de si ya se informó al emisor por otra vía.
   • La comunicación del pago efectivo completo a la solución pública debe realizarse en un plazo máximo de 4 días naturales (excluyendo sábados, domingos y festivos nacionales) desde la fecha efectiva del pago.
   • Esta comunicación a la solución pública se realizará a través de un servicio electrónico de comunicación de pagos que proporcionará la solución pública. Su sistema puede estar autorizado por el destinatario para realizar esta comunicación.
   • La definición de «fecha efectiva de pago» es clave: es la fecha en que el proveedor cobra, no la mera puesta a disposición de un mecanismo de financiación.
6. Acceso a Información (Funcionalidad del Sistema):
   • Su sistema o plataforma debe permitir que el emisor y el destinatario (y sus autorizados) puedan descargar las facturas electrónicas emitidas y recibidas a través de la Solución Pública.
   • También debe permitir la consulta de los datos sobre el pago de las facturas obrantes en la Solución Pública.

En resumen, la adaptación de su sistema de facturación implica asegurar que puede manejar los formatos estructurados requeridos, generar facturas con el contenido y código único especificados, garantizar la autenticidad e integridad (mediante firma o procedimientos AEAT), gestionar la remisión de copias a la Solución Pública si no emite por esa vía, y fundamentalmente, automatizar la recepción de estados de factura del emisor y la comunicación obligatoria del pago efectivo completo a la Solución Pública de la AEAT dentro de los plazos establecidos.

La AEAT proporcionará una aplicación/formulario gratuito para generar facturas y comunicaciones de pago, que puede ser una alternativa, pero para integrar el proceso en su propio sistema, deberá desarrollar las capacidades mencionadas, especialmente la conexión con la Solución Pública para la comunicación de pagos.