La SPFE ya tiene forma: todo lo que revela el seminario de la AEAT sobre la Solución Pública de Facturación Electrónica

Nota: Este artículo se basa íntegramente en el documento presentado por la Agencia Tributaria en el Seminario del 19 de mayo de 2026 sobre el Proyecto de Orden Ministerial de la Solución Pública de Facturación Electrónica (SPFE). Se trata de material oficial de primera mano, todavía en fase de consulta pública, cuya Orden entrará en vigor el 1 de octubre de 2026.

El 17 de abril de 2026, el Ministerio de Hacienda sometió a trámite de audiencia e información pública el Proyecto de Orden por el que se regula la Solución Pública de Facturación Electrónica (SPFE), el mecanismo gratuito gestionado por la Agencia Tributaria que completará el ecosistema de facturación electrónica B2B español. Menos de un mes después, el 19 de mayo, la AEAT celebró un seminario técnico para presentar en detalle sus diez bloques fundamentales.

Lo que se presentó en esta sesión fue relativa a cómo funcionará la facturación electrónica obligatoria en España. Este artículo lo traduce en claves prácticas.

1. Por qué existe la SPFE y qué papel juega

La arquitectura del sistema español de facturación electrónica B2B se articula en torno a dos ejes: las plataformas privadas de intercambio (operadas por proveedores tecnológicos certificados) y la Solución Pública de Facturación Electrónica, que la AEAT gestionará directamente.

La SPFE no es una alternativa menor o de último recurso. Tiene cuatro funciones de pleno derecho:

• Repositorio universal de copias fieles de todas las facturas electrónicas intercambiadas en España, independientemente de por qué plataforma hayan circulado.
• Solución gratuita de emisión y recepción para empresarios y profesionales que no quieran o no puedan contratar una plataforma privada.
• Hub de interconexión entre plataformas privadas: cuando el emisor y el receptor operan en plataformas distintas, la SPFE actúa como nodo intermediario.
• Gestión de los estados de pago: registro centralizado de aceptaciones, rechazos, fechas de pago y de vencimiento, con el objetivo explícito de monitorizar la morosidad privada en España.

La habilitación legal para crear esta infraestructura proviene de la Disposición Final Tercera del Real Decreto 238/2026, de 25 de marzo, que encomendó a una Orden Ministerial la definición de los elementos técnicos, los formatos, las especificaciones de interoperabilidad y las reglas de comunicación de pagos.

El estándar técnico: UBL sobre EN 16931, sin excepciones

Una de las decisiones más relevantes del proyecto de Orden —y con mayor impacto en los sistemas ERP— es la elección del estándar técnico. La SPFE adopta el modelo semántico de datos basado en EN 16931 del Comité Europeo de Normalización (CEN), implementado bajo la sintaxis UBL (Universal Business Language).

Esto tiene tres consecuencias prácticas inmediatas:

1. Alineación con el estándar europeo. EN 16931 es la norma en la que se basa el mandato europeo ViDA para las transacciones intracomunitarias de 2030. España no inventa un formato propio: adopta el mismo modelo semántico que ya usan Alemania, Francia, Bélgica y otros países en sus mandatos. Para las empresas multinacionales con SAP, esto es una buena noticia: la parametrización de SAP que ya tengas implementadas podrán ser “casi” reutilizables para la norma española ya lo habremos realizado para otros países.
2. Sin ficheros embebidos. Las facturas no podrán incorporar otros ficheros integrados o embebidos —ni PDFs adjuntos, ni imágenes, ni anexos de ningún tipo dentro del XML. La factura es el XML, y solo el XML. Esto es importante porque la mayoría de las personas que operan con factura necesitan un formato amigable para poder interpretarla y manipularla, en este caso los desarrolladores de software tenemos que ofrecer las mejores alternativas para que nuestros usuarios puedan operar de la forma más simple y operativa posible.
3. Las especificaciones técnicas exactas y los volúmenes máximos de mensaje estarán publicados en la Sede electrónica de la AEAT, no en la Orden. Esto significa que podrán actualizarse sin necesidad de modificación normativa, algo que conviene vigilar de forma continua.

La copia fiel: la gran novedad arquitectónica

El concepto de copia fiel es el que define la arquitectura del sistema cuando la factura no circula a través de la SPFE. La regla es clara: cuando un emisor y un receptor intercambian una factura a través de una plataforma privada (sin pasar por la SPFE), deben enviar simultáneamente una copia fiel a la SPFE en el mismo momento de la emisión.

Esta copia fiel se identifica técnicamente mediante el campo UBL <cbc:CopyIndicator>false</cbc:CopyIndicator> (el valor false indica que se trata de una copia, no del original, en la convención adoptada por la norma). La SPFE la marcará como tal y quedará disponible en el repositorio universal.

Las implicaciones para los sistemas son significativas. Todo ERP que emita facturas a través de una plataforma privada deberá tener activa simultáneamente la conexión con esa plataforma y con la SPFE para el envío de la copia. No es una operación posterior o diferida: debe ser simultánea a la emisión.

Reglas de rechazo que todo sistema debe respetar

La SPFE aplica reglas de deduplicación estrictas. El proyecto de Orden detalla cuándo una factura o copia será rechazada:

Además, si se usó la SPFE como interconexión y ya se envió copia fiel, dar de baja esa copia es un paso previo obligatorio antes de poder reenviar. Si no se da de baja y se intenta reenviar, el sistema lo rechaza por incumplimiento del proceso.

El código único de factura: trazabilidad sin duplicidades

Cada factura electrónica en el sistema español llevará un código único de identificación, regulado en el artículo 7.5 del RD 238/2026. Se construye mediante la concatenación de tres elementos:

• NIF del emisor
• Número y serie de la factura
• Fecha de expedición (formato AAAA-MM-DD)

En la sintaxis UBL, el código único se inserta en los campos <cbc:ID>, <cbc:IssueDate> y <cbc:CompanyID> (NIF del vendedor en IssuerParty). Este código hace técnicamente imposible la duplicación de facturas en el sistema y es la clave de trazabilidad que la AEAT utilizará para cruzar información entre emisores y receptores.

Para SAP, esto significa que la numeración de facturas en SD y la fecha de expedición deben generarse de forma única: los sistemas que admitan retrabajos, renumeraciones o correcciones de fecha sobre facturas ya emitidas deberán revisarse para garantizar que el código único resultante no colisione con ningún registro ya existente en la SPFE.

La comunicación de estados de pago: el corazón antifraude de morosidad

Uno de los elementos más novedosos —y con mayor impacto operativo en general pero en SAP muy particularmente— de la SPFE es su servicio de comunicación de estados de pago. El objetivo declarado en el seminario es inequívoco: monitorizar los plazos de pago como base para el control de la morosidad privada.

El sistema distingue entre las comunicaciones que debe realizar el destinatario (el comprador) y las que puede realizar el emisor (el vendedor).

Obligaciones del destinatario

El destinatario tiene información obligatoria que debe comunicar:

• Rechazo de la factura (si procede). Si no se comunica rechazo, la SPFE presume que la factura está ACEPTADA.
• Fecha de pago efectivo completo.
• Fecha de vencimiento del plazo de pago.

Y puede comunicar información opcional:

• Fecha de recepción de las mercancías.
• Fecha de prestación de los servicios.
• Fecha de recepción de la factura.

La presunción de aceptación si no se informa el rechazo es un mecanismo de gran calado: elimina la posibilidad de que el comprador deje una factura en estado indefinido. Si no rechaza, acepta. Esta regla tendrá consecuencias importantes en la gestión de facturas recibidas en los módulos de cuentas a pagar (FI-AP / MM).

Lo que puede comunicar el emisor

El emisor puede informar de forma voluntaria sobre:

• Cobro efectivo de la factura.
• Impago de la factura.
• Diferencias respecto a las fechas comunicadas por el destinatario.

Esta última opción es particularmente relevante: si el comprador comunica una fecha de pago que el vendedor considera incorrecta, el emisor puede registrar su propia versión de los hechos. La AEAT dispondrá de ambas versiones para sus análisis de morosidad.

Tipos detallados de comunicaciones

Las comunicaciones del destinatario se estructuran en dos tipos:

Comunicación de Pago (Alta/Baja): incluye identificación de la factura, fecha de pago, fecha de vencimiento del plazo de pago, otras fechas opcionales, y también contempla el caso de facturas rectificativas (el pago de una rectificativa no es necesariamente por el importe de la original).

Comunicación de Rechazo (Alta/Baja): incluye identificación de la factura, fecha de rechazo y el motivo, que admite dos valores posibles: rechazo comercial o rechazo por ser un consumo particular o no estar afecto a la actividad.

Las comunicaciones del emisor siguen la misma lógica: cobro (identificación + fecha de cobro + fecha de vencimiento + fechas opcionales) e impago (identificación + fecha de impago).

El procedimiento de uso: cómo enviar, cómo recibir

La SPFE ofrece dos vías de acceso para todas las operaciones: formulario web (para uso individual) y servicios web (para integración automatizada con ERP o plataformas).

• La emisión de facturas a través de la SPFE se realizará mediante el formulario web, de forma individual y con validación inmediata. Las facturas emitidas por esta vía serán verificables.
• La interconexión (envío desde una plataforma privada hacia otra a través de la SPFE) se realizará exclusivamente por servicios web.
• El envío de copias fieles también se realizará por servicios web.

En todos los casos, el sistema valida sintaxis, semántica y especificaciones técnicas antes de admitir el mensaje. La respuesta es siempre en dos partes:

• Mensaje de respuesta: confirma si la factura o copia ha sido admitida, o informa del rechazo con identificación precisa de los errores.
• Acuse de recibo: cuando la admisión es correcta, se genera un Código Seguro de Verificación (CSV) que acredita el registro en la SPFE.

El mismo sistema de respuesta aplica a las comunicaciones de estados de pago.

Autenticación y representación

El acceso a la SPFE requiere certificado electrónico para cualquier operación de envío. Si el envío se realiza mediante los formularios web, también podrá utilizarse el sistema cl@ve cuando proceda.

En cuanto a la representación, el proyecto de Orden distingue dos situaciones:

• Para el envío: puede actuar el propio empresario o profesional, un apoderado o un colaborador social (gestor/asesor). Pero si se usan los formularios, la representación debe estar inscrita en el Registro de Apoderamiento de la AEAT.
• Para la consulta y recuperación de facturas: la representación solo puede acreditarse mediante apoderamiento, tanto para acceso directo como automatizado.

Las plataformas privadas que intercambien facturas a través de la SPFE tienen una obligación adicional: deben recuperar de forma automatizada las facturas intercambiadas y ponerlas a disposición inmediata de sus clientes. No es una opción: es una obligación de la plataforma hacia sus usuarios.

El calendario definitivo: cuatro fechas clave hasta 2029

La última diapositiva del seminario presentó por primera vez el calendario completo y oficial de la facturación electrónica B2B en España, incluyendo las obligaciones de comunicación de pagos —que se escalonan más allá de la obligación de emitir facturas electrónicas:

Este calendario revela algo que no había quedado claro hasta ahora: la obligación de comunicar estados de pago tiene su propio escalonamiento, más tardío que el de la emisión de facturas. Las grandes empresas deberán emitir facturas electrónicas y comunicar pagos desde octubre de 2027. Las pymes personas jurídicas tendrán un año adicional para la parte de pagos. Y los autónomos y ERARs tendrán hasta octubre de 2029 para la comunicación de pagos, aunque ya deberán emitir facturas electrónicas desde 2028.

Implicaciones clave para SAP

Con el proyecto de Orden ya definido, los equipos de SAP pueden empezar a trazar el mapa de adaptaciones necesarias:

SAP SD — Formato y emisión El paso de Facturae (XML español propietario) a UBL sobre EN 16931 implica revisar la configuración del output type de facturas en SD y el mapeo de campos al formato UBL. El código único de factura (NIF + número/serie + fecha) debe generarse de forma inequívoca y estable.

Copia fiel simultánea Para las empresas que operen a través de plataformas privadas, la solución que eliga deberá gestionar el envío simultáneo a la plataforma privada y a la SPFE de la AEAT. Esto requiere configurar dos canales de salida activos para cada factura emitida.

SAP FI-AP — Presunción de aceptación La regla de que la no-comunicación de rechazo equivale a aceptación impacta en los procesos de gestión de facturas recibidas. Los flujos de aprobación de facturas en SAP (MIRO, VIM o equivalentes) deben generar la comunicación de rechazo a la SPFE cuando una factura es rechazada internamente.

SAP FI-AR — Comunicación de cobros e impagos El módulo de cuentas a cobrar debe integrarse con la SPFE para informar del cobro efectivo o el impago de cada factura. Esto conecta el proceso de compensación de partidas abiertas en FI-AR con la obligación de comunicación al repositorio de la AEAT.

Representación y autenticación Para las integraciones vía servicios web, debe gestionarse el certificado electrónico de la empresa en SAP. Si la empresa delega en un colaborador social, el apoderamiento en el registro de la AEAT debe estar activo y auditado periódicamente.

Conclusión: la SPFE es la columna vertebral de la facturación B2B española

El seminario del 19 de mayo de 2026 confirma que la SPFE no es simplemente una plataforma de fallback para quienes no puedan pagar un servicio privado. Es la infraestructura central del sistema: el repositorio universal, el nodo de interconexión y el monitor de morosidad. Toda factura electrónica B2B emitida en España pasará por ella, de una forma u otra.

Con la Orden en vigor el 1 de octubre de 2026 y la primera obligación efectiva de emisión el 1 de octubre de 2027 para las grandes empresas, el margen para preparar los sistemas ERP se reduce a poco más de un año. Las empresas que empiecen hoy el análisis de impacto —formato UBL, código único, copia fiel simultánea, integración de estados de pago— estarán en una posición muy diferente a las que esperen a la publicación definitiva de la Orden en el BOE.