Prepare SAP S/4HANA para la facturación electrónica B2B obligatoria en España con orientación práctica sobre DRC, integración, datos maestros, pruebas y decisiones de arquitectura.
España ya ha definido el marco principal de la facturación electrónica B2B obligatoria. El Real Decreto 238/2026, publicado el 31 de marzo de 2026, establece requisitos sobre formatos estructurados de factura, canales de intercambio, interoperabilidad, estados de las facturas e información de pago. Entró en vigor el 20 de abril de 2026, aunque su aplicación efectiva depende de la Orden Ministerial que regulará la solución pública de facturación electrónica.
Para las empresas que utilizan SAP S/4HANA, buena parte del trabajo preparatorio puede comenzar antes de que se concreten las especificaciones técnicas pendientes. Los equipos pueden identificar ya las entidades jurídicas afectadas, los sistemas de origen de las facturas, los sistemas SAP y no SAP implicados, los desarrollos a medida, las dependencias de datos maestros y las conexiones con proveedores de facturación electrónica.
El impacto va mucho más allá del formato de una factura emitida. La arquitectura final de facturación electrónica en SAP S/4HANA puede afectar a la facturación, las contabilizaciones en FI, las cuentas a cobrar, las cuentas a pagar, el procesamiento de documentos electrónicos, la información de pago, la integración y la gestión de excepciones.
España avanza hacia la facturación electrónica B2B obligatoria
La obligación de facturación electrónica B2B en España parte de la Ley 18/2022, conocida como Ley Crea y Crece. El Real Decreto 238/2026 desarrolla buena parte del modelo operativo aplicable al intercambio de facturas electrónicas entre empresarios y profesionales.
La obligación se aplica cuando debe emitirse una factura por una operación empresarial cuyo destinatario sea un empresario o profesional con sede de actividad económica, establecimiento permanente o, en su defecto, domicilio o residencia habitual en España, siempre que la operación se dirija a dicho establecimiento o residencia. El Real Decreto también contempla exclusiones y excepciones específicas, incluidas determinadas reglas relativas a las facturas simplificadas.
Los plazos de aplicación comenzarán a contar a partir de la entrada en vigor de la Orden Ministerial que regule la solución pública de facturación electrónica:
- Los empresarios y profesionales cuyo volumen de operaciones, calculado conforme al artículo 121 de la Ley del IVA, haya superado los 8 millones de euros en el año natural anterior quedarán sujetos a la obligación 12 meses después.
- El resto de empresarios y profesionales quedará sujeto a la obligación 24 meses después.
El Real Decreto vincula expresamente ambos plazos a la futura Orden Ministerial. Las fechas previstas para 2027 y 2028 pueden utilizarse con fines de planificación, pero no deben presentarse todavía como plazos legales definitivos.
Los empresarios y profesionales sujetos a los regímenes tributarios forales del País Vasco o Navarra deben analizar por separado cómo les afectará la solución pública. El Real Decreto 238/2026 establece que su aplicación se articulará de acuerdo con el Concierto Económico con el País Vasco y el Convenio Económico con Navarra, mediante los correspondientes acuerdos entre las administraciones tributarias forales y la AEAT.
El Real Decreto incorpora además requisitos transitorios que conviene tener en cuenta en los proyectos SAP. Durante los primeros 12 meses desde que la obligación resulte aplicable, los empresarios y profesionales cuyo volumen de operaciones, calculado conforme al artículo 121 de la Ley del IVA, haya superado los 8 millones de euros deberán acompañar sus facturas electrónicas con un PDF legible, salvo que el destinatario acepte expresamente recibir la factura en su formato electrónico original. Este PDF se envía al destinatario y no debe remitirse a la solución pública de facturación electrónica.
Existe también un periodo transitorio específico para determinadas personas físicas y entidades en régimen de atribución de rentas cuyo volumen de operaciones, calculado conforme al artículo 121 de la Ley del IVA, no haya superado los 8 millones de euros durante el año natural anterior. Sus obligaciones de comunicar estados de factura conforme a los artículos 10 y 12 comenzarán 12 meses después del plazo general de 24 meses correspondiente a este grupo. Hasta entonces, la comunicación de dichos estados seguirá siendo voluntaria para estos contribuyentes.
La solución pública deberá estar disponible al menos dos meses antes de la primera fecha de aplicación efectiva de la obligación. Esto proporcionará un periodo definido para completar la conectividad y las pruebas una vez publicado el entorno técnico.
Requisitos del modelo español de facturación electrónica B2B
El sistema español contempla un modelo híbrido de intercambio. Las empresas podrán utilizar la solución pública de la AEAT, plataformas privadas de facturación electrónica o una combinación de ambas.
Cuando un empresario o profesional no haya identificado públicamente un punto de entrada privado de facturas electrónicas, se considerará que utiliza la solución pública. La recepción de facturas a través de una o varias plataformas privadas requiere además un acuerdo expreso con los proveedores correspondientes. En ausencia de dicho acuerdo, se entenderá que el destinatario utiliza la solución pública.
Las facturas electrónicas deberán utilizar datos estructurados de acuerdo con el marco español aplicable y la norma EN 16931. El Real Decreto 238/2026 reconoce CII, UBL, los mensajes de factura EDIFACT y Facturae.
La solución pública utilizará UBL conforme a las especificaciones técnicas que se establezcan. Las plataformas privadas también deberán cumplir los requisitos normativos de interoperabilidad, sintaxis admitidas, transformación e intercambio seguro de documentos.
Las facturas emitidas a través de plataformas privadas deberán incorporar además una firma electrónica avanzada, aplicada directamente por el emisor o mediante un mecanismo autorizado de firma delegada.
Cuando una factura se emita fuera de la solución pública, por regla general deberá enviarse simultáneamente a dicha solución una copia fiel electrónica en UBL. Sin embargo, cuando la propia solución pública actúe como mecanismo de interconexión, la factura ya estará disponible en ella y no será necesario remitir una copia fiel adicional.
La normativa establece dos flujos relacionados con la comunicación de estados.
Según el artículo 10, el destinatario debe informar al emisor de la aceptación o rechazo comercial de la factura y de la fecha correspondiente, así como del pago íntegro y su fecha efectiva. También puede comunicar una aceptación o un rechazo parcial, un pago parcial y la cesión de la factura a un tercero. Con carácter general, estos mensajes deben comunicarse en un plazo de cuatro días desde que se produzca el hecho correspondiente, sin contar sábados, domingos ni festivos nacionales.
El artículo 12 añade una obligación independiente de comunicar a la solución pública el rechazo de la factura o su pago íntegro, con independencia de que el intercambio se haya realizado mediante la solución pública o a través de una plataforma privada.
Si no existe rechazo ni una factura rectificativa posterior, la factura se presumirá aceptada. En caso de pago íntegro, el destinatario deberá comunicar la fecha efectiva de pago y la fecha de vencimiento en un plazo de cuatro días desde la fecha efectiva del pago, sin contar sábados, domingos ni festivos nacionales.
El rechazo comercial de una factura no la anula ni la rectifica. Cuando sea necesario corregirla, deberá emitirse la correspondiente factura rectificativa.
Qué cambia para las empresas que utilizan SAP S/4HANA
El impacto sobre SAP depende del origen de las facturas y de las aplicaciones que intervengan en facturación, compras y finanzas.
Ventas y facturación
Las facturas de cliente generadas en SAP S/4HANA Sales deberán incluir los datos necesarios para crear la factura electrónica estructurada correspondiente. Los formularios PDF existentes pueden seguir siendo útiles desde el punto de vista operativo y también podrán tener relevancia durante el periodo transitorio establecido para las empresas de mayor volumen. Sin embargo, no sustituyen al documento electrónico estructurado exigido por la normativa.
El análisis de alcance debe incluir los documentos estándar de facturación, así como abonos, facturas rectificativas, documentos de liquidación, clases de factura personalizadas y los escenarios intercompany relevantes.
También conviene revisar las rutinas desarrolladas a medida. Las transformaciones creadas para documentos impresos, EDI o portales de clientes pueden solaparse con funciones que posteriormente se gestionen mediante el procesamiento de eDocuments o la capa de integración para cumplimiento normativo. El proyecto deberá determinar qué lógica debe permanecer en facturación y qué funciones conviene trasladar a otros componentes.
Contabilidad financiera
No todas las facturas de cliente se originan en SD. Las facturas de cliente contabilizadas directamente en FI también pueden entrar en el ámbito de aplicación. Los equipos deben identificar las clases de documentos contables relevantes y determinar cómo se incorporarán al proceso de documentos electrónicos.
También debe revisarse el proceso de cuentas a cobrar una vez enviada la factura. Los eventos de aceptación, rechazo y pago deben mantener un vínculo fiable con la factura original para que Finanzas pueda controlar excepciones y conciliar cada operación.
Cuentas a pagar
Las facturas recibidas requieren una arquitectura específica. El proyecto deberá definir dónde entran en el entorno las facturas estructuradas de proveedores, dónde se realizan las validaciones técnicas y de negocio y cómo llega el documento electrónico al proceso de cuentas a pagar.
Las plataformas de compras, las soluciones de automatización de facturas, las pasarelas EDI y las aplicaciones externas de cuentas a pagar (AP) deben incluirse desde la fase de análisis y no tratarse como sistemas ajenos al diseño de facturación electrónica.
Información de pago y estados
El modelo español introduce nuevos eventos de negocio sujetos a obligaciones de información después de la entrega de la factura. La información sobre aceptación comercial, rechazo y pago puede originarse en SAP S/4HANA o en otra aplicación. La ejecución del pago, el procesamiento bancario, la compensación y el reporting normativo también pueden realizarse en componentes diferentes.
La arquitectura debe identificar qué sistema es responsable de cada evento, qué componente lo comunica y cómo se mantiene su relación con la factura original. También deberá vincular la fecha efectiva de pago exigida legalmente con el evento correcto de SAP o del sistema externo. Conforme al Real Decreto 238/2026, esta fecha depende del método de pago. Por ejemplo, en una transferencia bancaria puede corresponder a la fecha de cargo en la cuenta del pagador o, en una compensación, a la fecha en que esta se acuerda. No debe equipararse automáticamente a una fecha de compensación o contabilización de SAP.
Sistemas externos de facturación
En muchos entornos SAP, parte de las facturas se genera fuera de la instancia principal de SAP S/4HANA. Las plataformas de suscripción, las aplicaciones sectoriales, los ERP heredados y los sistemas que se mantienen después de una adquisición pueden generar operaciones sujetas a la normativa. Cada fuente necesita, por tanto, una ruta definida hacia el proceso de cumplimiento.
De lo contrario, una implementación correcta desde el punto de vista técnico en SAP podría seguir dejando fuera de la solución una parte de las facturas sujetas a la obligación.
Evaluación del entorno SAP actual
Una evaluación del grado de preparación debe comenzar por los documentos de negocio y las entidades jurídicas antes de seleccionar componentes SAP concretos. El primer paso consiste en identificar las entidades españolas y las sociedades potencialmente afectadas. A continuación, conviene mapear los tipos de facturas emitidas y recibidas, los volúmenes de transacciones, los sistemas de origen, los canales de intercambio y los equipos responsables.
En el entorno SAP, revise:
- Versión y modelo de despliegue de SAP S/4HANA
- Localización de SAP para España actualmente implantada
- Configuración existente de SAP Document and Reporting Compliance
- Clases y procesos de eDocument activos
- Clases de documento fuente habilitadas para las sociedades correspondientes
- Asignaciones actuales entre documentos contables o de facturación y procesos de eDocument
- Procesos de SII, VeriFactu y facturación B2G
- Identificadores fiscales, incluido el NIF, y mapeos de valores
- Configuración de comunicaciones y rutas de integración
- Desarrollos personalizados de facturación en SD y FI
- Interfaces EDI y middleware
- Sistemas externos de facturación y AP
- Proveedores actuales de facturación electrónica
- Datos maestros de clientes y proveedores, datos fiscales y datos de las entidades jurídicas
- Flujos de SAP Business Network y SAP Ariba Buying and Invoicing, cuando proceda
Las configuraciones de facturación electrónica de SAP ya utilizadas en España proporcionan una referencia útil para este análisis. Permiten ver qué tipos de activación de documentos de origen, asignaciones de eDocument, datos de localización y configuraciones de comunicación pueden intervenir en un proceso de documentos electrónicos específico para un país.
Esto no implica que la futura configuración B2B utilice exactamente los mismos objetos. El objetivo de la evaluación consiste en detectar con antelación posibles carencias en la clasificación de documentos, la cobertura de sistemas de origen, los datos fiscales y la asignación de responsabilidades sobre las integraciones.
SII, VeriFactu y la facturación B2G también deben documentarse por separado. Cada uno responde a obligaciones distintas y no debe asumirse que cubre automáticamente el nuevo proceso B2B.
Sin embargo, sí existen conexiones a nivel de los sistemas de origen. El Real Decreto 238/2026 exige que las facturas electrónicas B2B obligatorias sean generadas por sistemas de facturación adaptados al artículo 29.2.j de la Ley General Tributaria y, cuando proceda, a su normativa de desarrollo.
Las organizaciones deben determinar si sus sistemas de generación de facturas entran en el ámbito del RD 1007/2023. Los contribuyentes acogidos al SII quedan excluidos de dicho reglamento, por lo que los requisitos aplicables al sistema de origen deben analizarse según la situación del contribuyente y del propio sistema.
Para entender mejor las diferencias y puntos de contacto entre estas obligaciones, consulte nuestra guía sobre VeriFactu, SII y facturación electrónica B2B obligatoria en España.
Las organizaciones que ya utilizan SAP Business Network también deberían incluir en el análisis los flujos relacionados con las facturas de proveedores y clientes. SAP ha comunicado públicamente sus planes de dar soporte a la facturación electrónica en España a través de SAP Business Network, por lo que el alcance disponible deberá contrastarse con la funcionalidad publicada antes de incorporarlo a la arquitectura definitiva.
Capacidades de SAP relevantes para la facturación electrónica B2B en España
SAP Document and Reporting Compliance ofrece funcionalidades para crear, procesar y supervisar documentos electrónicos e informes legales. Los documentos electrónicos se generan a partir de las transacciones de negocio y pueden prepararse posteriormente para su intercambio conforme al escenario de conformidad aplicable.
A fecha de publicación, SAP todavía no ha publicado el modelo definitivo de implementación en SAP S/4HANA para el nuevo mandato B2B en España. Las capacidades de SAP DRC siguen siendo relevantes para la planificación previa, mientras que la arquitectura definitiva de comunicación y procesamiento deberá ajustarse al contenido de SAP correspondiente a los cambios legales.
En los escenarios compatibles con SAP S/4HANA, la arquitectura puede incluir:
- SAP S/4HANA
- eDocument framework
- SAP Document and Reporting Compliance
- SAP Document and Reporting Compliance, cloud edition
- eDocument Cockpit o Manage Electronic Documents
- Contenido de integración proporcionado por SAP
- Localización, configuración y mapeos específicos para España
Hay un aspecto arquitectónico que requiere especial atención al planificar SAP DRC para España. SAP Document and Reporting Compliance, cloud edition, y un tenant de SAP Integration Suite gestionado por el cliente no funcionan como alternativas intercambiables para todos los escenarios de cumplimiento.
SAP determina el tipo de envío admitido para cada país y proceso. La documentación del producto especifica que los clientes no pueden elegir libremente entre ambos enfoques para un mismo escenario de país.
El inventario documental, la preparación de datos maestros, la asignación de responsabilidades, el mapeo de procesos y otras tareas preparatorias pueden avanzar antes de que SAP publique el proceso B2B específico para España. La configuración de comunicaciones podrá completarse posteriormente a partir del contenido de implementación publicado oficialmente.
Las empresas que también necesiten revisar su configuración de SAP para VeriFactu pueden consultar las consideraciones de implementación en nuestra guía de cumplimiento de VeriFactu con SAP para España.
Arquitectura conceptual de SAP para la facturación electrónica B2B en España
La arquitectura objetivo debe cubrir facturas emitidas y recibidas, estados, pagos y monitorización. Antes de seleccionar componentes técnicos concretos, conviene separar los requisitos en varias decisiones de diseño:
- ¿Qué documentos SAP y no SAP entran en el ámbito de aplicación?
- ¿Qué formatos será necesario generar o procesar?
- ¿Cómo se determinarán los destinatarios y los puntos de entrada de las facturas?
- ¿Qué canal se utilizará para transmitir cada factura?
- ¿En qué casos deberá enviarse una copia fiel a la solución pública?
- ¿Por dónde entrarán las facturas de proveedores?
- ¿Dónde se originarán los estados comerciales y los eventos de pago?
- ¿Cómo volverán las respuestas y los errores a SAP?
- ¿Qué aplicación será responsable de la monitorización y el reprocesamiento?
En el caso de empresarios y profesionales sujetos a los regímenes tributarios forales del País Vasco o Navarra, deberá confirmarse por separado la ruta aplicable a través de la solución pública, ya que el Real Decreto prevé acuerdos específicos entre la AEAT y las administraciones tributarias forales correspondientes.
Emisión a través de la solución pública
Un flujo conceptual podría ser:
Documento de origen en SAP S/4HANA → procesamiento de eDocument → servicio de comunicación admitido por SAP → solución pública de facturación electrónica aplicable → destinatario o plataforma del destinatario
El componente de comunicación SAP concreto dependerá del proceso B2B que SAP admita finalmente para España.
Emisión a través de una plataforma privada
La utilización de una plataforma privada introduce otro circuito:
Documento de origen en SAP S/4HANA → procesamiento de eDocument → ruta de comunicación admitida → plataforma privada → destinatario
Cuando sea necesario remitir una copia fiel independiente, el proceso deberá garantizar que la copia UBL llegue a la solución pública correspondiente. Si la propia solución pública se utiliza como mecanismo de interconexión, no será necesario enviar una copia adicional. La monitorización debe abarcar más que la entrega correcta al cliente. La empresa también debe poder hacer seguimiento de la copia exigida legalmente cuando corresponda.
Flujo de estados comerciales
La información sobre aceptación, rechazo y pago comunicada al emisor debe permanecer vinculada a la operación original:
Evento del destinatario → canal de intercambio → capa de integración → monitorización de factura/estado en SAP
La arquitectura debe diferenciar estos estados de negocio de los acuses técnicos de entrega.
Comunicación de pagos y rechazos a la solución pública
El flujo obligatorio hacia la solución pública también necesita un responsable claramente definido:
Evento de pago o rechazo del destinatario → sistema o plataforma autorizados → solución pública de facturación electrónica aplicable
Facturas de proveedores
Las facturas recibidas necesitan un circuito controlado propio:
Solución pública o plataforma privada aplicable → ruta de integración admitida → procesamiento de documentos electrónicos → proceso de AP en SAP
La arquitectura definitiva debe establecer cómo se realizarán la validación, contabilización y gestión de excepciones, así como la relación entre el documento electrónico recibido y la transacción contable resultante.
Decisiones de arquitectura antes de la implementación
Solución pública, plataforma privada o modelo híbrido
España permite los tres modelos. El marco normativo autoriza expresamente a las empresas a trabajar mediante plataformas privadas, la solución pública o una combinación de ambas. La elección debe valorar los volúmenes de facturas, los acuerdos existentes con proveedores de servicios, los acuerdos expresos con proveedores necesarios para recibir facturas mediante plataformas privadas, la conectividad con clientes y proveedores, la monitorización operativa, las responsabilidades de soporte y los canales actuales de facturación. No es necesario utilizar un único modelo para todos los flujos si los requisitos del negocio justifican circuitos distintos.
Arquitectura de cumplimiento centralizada, local o híbrida
Las organizaciones con varios sistemas SAP, varias entidades españolas o aplicaciones externas de facturación deben decidir dónde se gestionará el procesamiento asociado al cumplimiento normativo.
Un enfoque centralizado puede facilitar servicios compartidos de monitorización e integración. Un modelo local puede seguir teniendo sentido para determinados sistemas o procesos. Una arquitectura híbrida permite centralizar servicios comunes y mantener procesos específicos por entidad o aplicación cuando resulte necesario.
También deben tenerse en cuenta los procesos de cumplimiento ya implantados en España. Las rutas de comunicación admitidas por SAP para esos procesos pueden diferir de las que se utilicen en el futuro proceso B2B. No conviene imponer una uniformidad técnica si entra en conflicto con la arquitectura admitida por SAP.
Uno o varios proveedores
Algunas organizaciones ya trabajan con proveedores distintos según la entidad jurídica, unidad de negocio o aplicación. La normativa española exige que las plataformas privadas participantes permitan la interoperabilidad. Aun así, utilizar varios proveedores puede incrementar la complejidad del soporte, la gestión contractual y la conciliación. Conviene documentar el ecosistema de proveedores existente antes de añadir nuevas conexiones.
Varias entidades jurídicas españolas
Los grupos con varias entidades en España necesitan criterios coherentes para la activación por sociedad, los identificadores fiscales, los documentos de origen, el enrutamiento y la asignación de responsabilidades. Los servicios técnicos pueden compartirse, mientras que la configuración jurídica y fiscal seguirá dependiendo de cada entidad.
Fuentes de facturación SAP y no SAP
El proyecto también debe definir cómo se incorporarán a la arquitectura de cumplimiento las facturas generadas fuera de SAP S/4HANA. Las aplicaciones no SAP pueden enviar los datos de las facturas a SAP, conectarse mediante una capa de cumplimiento compartida o mantener otra ruta permitida. Independientemente del modelo elegido, Finanzas debe poder identificar qué documentos se han creado, transmitido, recibido, rechazado, aceptado y pagado.
Responsabilidad sobre los procesos
La facturación electrónica afecta a Fiscalidad, Finanzas, cuentas a cobrar (AR), cuentas a pagar (AP) e IT. Las responsabilidades deben cubrir las transmisiones fallidas, los rechazos comerciales, los estados incorrectos, los problemas de datos maestros, las incidencias con proveedores y el reprocesamiento tras la puesta en producción. Estas funciones deben asignarse durante el diseño y validarse durante las pruebas.
Errores habituales en proyectos de cumplimiento
Centrarse únicamente en las facturas emitidas
Durante las primeras fases del diseño suele prestarse mayor atención a las facturas del cliente. Las facturas de proveedores, los estados comerciales, la comunicación de pagos a la solución pública, las facturas rectificativas y las transacciones fallidas requieren el mismo nivel de planificación. Dejarlas para las fases finales puede revelar carencias de arquitectura durante las pruebas de integración.
Conectar directamente la lógica de facturación personalizada con un proveedor
Incorporar lógica específica de un proveedor directamente en el proceso principal de facturación puede aumentar el acoplamiento y el esfuerzo necesario para realizar cambios en el futuro. Cuando la arquitectura admitida por SAP lo permita, la comunicación asociada al cumplimiento normativo y las transformaciones específicas del proveedor deberían mantenerse fuera del proceso de facturación de origen.
Omitir fuentes de facturación externas a SAP S/4HANA
El inventario de cumplimiento debe incluir todos los sistemas capaces de generar facturas sujetas a la obligación. Los sistemas heredados, las aplicaciones sectoriales y los ERP procedentes de adquisiciones pueden aparecer demasiado tarde en la fase de análisis y generar trabajo de integración adicional.
Dejar los datos maestros para la fase de pruebas
Los identificadores fiscales, los datos de las entidades jurídicas, los datos del interlocutor comercial, las clasificaciones documentales y los atributos de enrutamiento pueden afectar al procesamiento de documentos electrónicos. Detectar estos problemas cuando las pruebas de integración ya han comenzado puede obligar a repetir ciclos de prueba y retrasar la validación de la propia interfaz.
Probar únicamente facturas estándar
Un conjunto de pruebas representativo debe abarcar bastante más que una factura estándar de cliente procesada correctamente. Debe incluir abonos, facturas rectificativas, facturas originadas en FI, variaciones fiscales, fuentes de facturación no SAP, facturas de proveedores, documentos rechazados, fallos de comunicación, actualizaciones de estados y reprocesamiento.
Las pruebas deben cubrir toda la cadena de comunicación. Que un mensaje salga correctamente de SAP no demuestra por sí solo que el destinatario lo haya recibido, que la copia reglamentaria haya llegado a la solución pública cuando corresponda o que las respuestas hayan vuelto al documento de origen correcto.
Posponer demasiado la configuración técnica
La configuración de SAP representa solo una parte de la preparación. Según el proceso definitivo, los equipos también pueden necesitar el alta de servicios cloud, configuración de comunicaciones, autorizaciones, credenciales o certificados, alta con el proveedor, configuración de endpoints y acceso a entornos de prueba.
Los escenarios de SAP Document and Reporting Compliance requieren activar procesos y completar pasos de integración específicos para cada escenario, en lugar de seguir una única configuración genérica. Estas dependencias deben identificarse con suficiente antelación para evitar que las tareas de infraestructura retrasen las pruebas end-to-end.
Diseñar sobre especificaciones técnicas aún no definitivas
El Real Decreto 238/2026 establece el modelo operativo principal, pero la Orden Ministerial todavía debe completar determinados aspectos técnicos de la solución pública.
Los equipos pueden avanzar con el mapeo de procesos, los principios de arquitectura, la preparación de datos maestros y el análisis de los sistemas de origen. Los detalles de interfaz que dependan de la especificación técnica definitiva deberían mantenerse configurables hasta que se publiquen el contenido normativo español y el contenido correspondiente de SAP.
Nuestra experiencia en facturación electrónica y cumplimiento fiscal con SAP
LeverX ayuda a las empresas a preparar sus entornos SAP para la facturación electrónica, el reporting normativo y los requisitos de fiscalidad digital.
Nuestros servicios incluyen:
- Evaluación del entorno y los procesos de SAP S/4HANA
- Implementación de SAP Document and Reporting Compliance
- Configuración de eDocument
- Localización SAP para España
- Alineación de procesos FI, SD, AR y AP
- Integración de SAP con sistemas externos
- Integración con proveedores de facturación electrónica
- Preparación de datos maestros y mapeos de valores
- Pruebas end-to-end
- Diseño de la gestión de excepciones y reprocesamiento
- Alta y configuración técnica
- Soporte tras la puesta en producción
En España, el punto de partida consiste en inventariar los procesos de facturación y los componentes de cumplimiento ya existentes. Este análisis permite determinar qué capacidades actuales de SAP pueden reutilizarse, dónde harán falta nuevas integraciones y qué decisiones técnicas conviene mantener abiertas hasta que SAP publique el proceso B2B correspondiente.
Cómo preparar la hoja de ruta SAP para la facturación electrónica B2B en España
La preparación puede estructurarse en cuatro fases.
1. Evaluar
Mapee las entidades jurídicas afectadas, los sistemas de origen, los tipos de documentos, los procesos de eDocument existentes, las conexiones con proveedores y los datos maestros. Documente por separado los procesos de cumplimiento ya utilizados en España para evitar trasladar automáticamente al diseño B2B supuestos procedentes de SII, VeriFactu o la facturación B2G.
2. Diseñar
Defina las futuras rutas de facturación, el proceso de recepción, la responsabilidad sobre los estados, el flujo de comunicación de pagos, el modelo de proveedores y las responsabilidades de monitorización. Documente dónde se prevé utilizar funcionalidad estándar de SAP y qué áreas podrían seguir necesitando integración externa o desarrollos específicos.
3. Configurar e integrar
Una vez publicados la Orden Ministerial y el contenido de SAP correspondiente a los cambios legales, complete la ruta de comunicación admitida, la configuración específica de España, los mapeos y las conexiones externas. Complete con suficiente antelación las altas y las configuraciones técnicas necesarias para disponer de tiempo para las pruebas end-to-end.
4. Probar y preparar la operación
Pruebe tanto escenarios estándar como excepciones en toda la cadena de comunicación. Compruebe que los equipos de Finanzas y soporte puedan hacer seguimiento de las facturas, interpretar los estados, reprocesar errores y diferenciar entre incidencias comerciales y problemas técnicos de comunicación.
El objetivo consiste en disponer de un proceso de facturación electrónica B2B que pueda gestionarse de forma estable en la operativa diaria tras la puesta en producción, en lugar de limitar el proyecto a generar y transmitir archivos que cumplan los requisitos aplicables.
