En los proyectos de factura electrónica en SAP hay una situación bastante curiosa, no todos los clientes reaccionan igual cuando saben que llegan tarde.

Algunos se ponen en marcha con tiempo, contratan al partner, adaptan SAP, prueban integraciones y cruzan los dedos para llegar a la fecha exigida. Otros empiezan tarde, el proyecto se complica y llega un momento en el que hacen números, “Si no llegamos, ¿cuánto nos puede costar la sanción?”.

Y aquí aparece una realidad poco comentada, en algunos casos, el cliente termina asumiendo el riesgo de una posible multa porque considera que el coste o la urgencia de acelerar el proyecto es mayor que ese riesgo.

Pero existe otra situación todavía más curiosa. El proyecto empieza tarde, el partner no llega exactamente a la fecha prevista y, aun así, existe un periodo transitorio o una aplicación escalonada de la obligación que da cierto margen para completar la adaptación antes de que la obligación sea plenamente exigible.

Por eso, en estos proyectos no basta con preguntar “¿cuándo entra en vigor la norma?”. Hay que distinguir entre entrada en vigor, fecha de aplicación efectiva, periodos transitorios y régimen sancionador.

Desde fuera parece un simple proyecto de adaptación de SAP. Desde dentro, a veces se convierte en una decisión empresarial de riesgo,¿invertimos ahora para llegar a tiempo o asumimos el coste potencial de llegar tarde?

Y sí, en más de un proyecto la respuesta acaba siendo, “Vamos tirando y ya veremos qué pasa”. Una estrategia curiosamente frecuente cuando hay un ERP de por medio.

Durante años hemos hablado de automatizar la nómina, menos tareas manuales, más controles, más integraciones y menos posibilidades de error. Pero SAP está planteando el siguiente paso, que la nómina no solo ejecute procesos, sino que sea capaz de detectar problemas, entenderlos y actuar sobre ellos.

La idea de Autonomous Payroll dentro de SAP SuccessFactors parte precisamente de ahí. SAP está incorporando agentes de IA especializados capaces de revisar información de payroll y tiempo, detectar anomalías, explicar errores y ayudar a resolverlos antes de que terminen afectando al empleado.

Uno de los ejemplos más interesantes es el Payroll Explanation Agent. En lugar de que un empleado tenga que preguntar a RR. HH. por qué su nómina ha cambiado, el agente puede explicar en lenguaje natural conceptos del recibo y relacionarlos con los datos de tiempo, horas extra o complementos. La información deja de estar escondida detrás de reglas y cálculos que solo unos pocos entienden.

También está el Payroll Alert Resolution Agent, pensado para analizar alertas, identificar posibles causas y proponer las correcciones prioritarias. Y el Payroll Validation Rule Agent, que permite crear reglas de validación utilizando lenguaje natural.

Y aquí está, en mi opinión, lo más interesante, el objetivo no es simplemente ahorrar unos cuantos clics al equipo de nómina. Es aumentar la confianza del empleado en el sistema.

Porque cuando hablamos de nóminas, un error no es como un error cualquiera en un ERP. Estamos hablando del dinero que una persona espera recibir a final de mes. Si el sistema puede detectar una anomalía antes de ejecutar la nómina y explicar por qué se produce, el papel de RR. HH. cambia, menos tiempo buscando errores y más tiempo supervisando que el proceso funciona correctamente.

SAP está llevando esta visión hacia un modelo en el que varios agentes trabajan coordinados para preparar el payroll, revisar controles, detectar problemas y escalar al humano únicamente cuando realmente hace falta.

Y quizá ahí está el verdadero cambio. La evolución no es pasar de una nómina manual a una nómina automática. Es pasar de una nómina que espera a que alguien encuentre un problema a una que intenta encontrarlo antes.

En otras palabras, menos “¿qué ha pasado con esta nómina?” y más “hemos detectado esto antes de que afectara a nadie”.

Ese es probablemente el verdadero significado de Autonomous Payroll.

La acción de SAP ha empezado septiembre con algo menos de entusiasmo que el que había mostrado durante las semanas anteriores. Después de cerrar agosto cerca de los 191 €, la acción se ha movido hacia la zona de los 182–183 € a comienzos de esta semana.

El movimiento no parece responder a un único problema de SAP, sino a una combinación de factores. Por un lado, los mercados están mucho más pendientes de la inflación, los tipos de interés y la evolución del petróleo. La tensión geopolítica en Oriente Medio ha llevado el precio del crudo hacia niveles muy elevados y ha vuelto a aumentar el temor a una inflación persistente. Al mismo tiempo, la rentabilidad del bono estadounidense a 10 años se mantiene elevada, algo que suele presionar especialmente a las compañías tecnológicas y de crecimiento.

A esto se suma que SAP venía de una fuerte recuperación durante el verano. Después de una subida importante, es normal que algunos inversores recojan beneficios y vuelvan a evaluar si las expectativas de crecimiento justifican las valoraciones actuales. De hecho, la acción llegó a perder alrededor de un 3,5% el 1 de septiembre y ha continuado con cierta volatilidad durante los primeros días del mes.

Pero hay un detalle importante para los que seguimos SAP desde el punto de vista del negocio, la historia fundamental de la compañía no ha cambiado radicalmente esta semana. SAP mantiene para 2026 una previsión de ingresos cloud de entre 25.800 y 26.200 millones de euros, con un crecimiento previsto del 23%-25% a tipo de cambio constante. También mantiene una previsión de unos 10.000 millones de euros de flujo de caja libre.

Por eso, la pregunta interesante ahora no es tanto “¿por qué ha bajado SAP?”, sino “¿hasta qué punto esta bajada es una corrección del mercado y hasta qué punto refleja dudas sobre el crecimiento futuro?”.

Y ahí entra uno de los grandes debates actuales del sector software, cuánto valor económico conseguirá realmente generar la IA y cuánto tardará en convertirse en ingresos. SAP está apostando fuerte por agentes, Business AI y automatización de procesos, pero los inversores quieren comprobar que esa apuesta se traduce en crecimiento y rentabilidad. Esa será una de las historias que probablemente seguiremos viendo durante los próximos meses.

Para un consultor SAP, la conclusión es bastante sencilla, mientras nosotros estamos preocupados por si el transporte llega a TEST, en Frankfurt están intentando decidir cuánto valdrá SAP dentro de cinco años.

Hay una conversación que muchos consultores SAP todavía no han tenido con sus clientes y que cada vez va a ser más difícil evitar, la factura electrónica ya no es simplemente una cuestión de enviar un PDF por email.

Cada vez más países están introduciendo modelos de facturación electrónica obligatoria, pero aquí empieza la parte complicada, no todos lo están haciendo de la misma manera. Algunos exigen el intercambio de facturas a través de plataformas públicas, otros utilizan redes de intercambio como Peppol, otros obligan a reportar determinados datos a la Administración Tributaria y otros combinan diferentes modelos dependiendo del tipo de operación.

Y para un cliente SAP esto significa algo bastante importante, no existe una única “factura electrónica” que podamos activar y olvidarnos del problema.

Desde el punto de vista de SAP, una factura puede nacer en SD o FI, pero después necesita transformarse al formato requerido por el país, incorporar la información fiscal necesaria, pasar las validaciones correspondientes y llegar al destinatario o a la Administración a través del canal establecido. Y todo esto tiene que funcionar sin romper el proceso de facturación que ya existe en el cliente.

Aquí es donde soluciones como SAP Document and Reporting Compliance (DRC) adquieren especial importancia. DRC permite gestionar diferentes escenarios de documentos electrónicos y requisitos de reporting desde SAP, apoyándose en las localizaciones y contenidos específicos de cada país.

El concepto es relativamente sencillo, la factura se genera en SAP, se crea el documento electrónico correspondiente, se transforma al formato requerido, se realizan las validaciones necesarias y se transmite utilizando el mecanismo exigido en ese país. Pero la dificultad real aparece cuando una empresa trabaja en varios mercados.

Imaginemos un grupo internacional que factura desde España, Francia, Italia, Polonia y México. El documento comercial puede ser prácticamente el mismo, pero las obligaciones fiscales pueden ser completamente diferentes. Un país puede requerir un XML concreto, otro una plataforma gubernamental, otro una red de intercambio y otro un reporting prácticamente en tiempo real.

Por eso, cuando un cliente pregunta “¿podemos poner factura electrónica en SAP?”, la respuesta de un consultor experimentado no debería ser simplemente “sí, instalamos DRC”.

La primera pregunta debería ser, “¿En qué países y para qué escenarios?”

Después vienen otras igual de importantes, ¿es B2B, B2C o B2G? ¿Hay obligación de emitir, de recibir o de reportar? ¿Qué formato exige cada Administración? ¿Qué plataforma o proveedor de intercambio hay que utilizar? ¿Qué ocurre si la factura es rechazada? ¿Cómo se registra el estado en SAP? ¿Qué hacemos con las facturas recibidas? ¿Y qué ocurre cuando la empresa tiene varias sociedades y cada una está sometida a una normativa diferente?

Y aquí aparece una de las partes más interesantes para los consultores FI y SD, la factura electrónica no termina cuando SAP genera el XML.

Hay que pensar en todo el ciclo de vida del documento, generación, validación, envío, aceptación o rechazo, corrección, reenvío, recepción, trazabilidad y, en algunos países, comunicación de información adicional a la Administración.

Esto cambia bastante la forma de plantear estos proyectos. Ya no estamos hablando únicamente de configurar una salida de factura. Estamos hablando de conectar el proceso financiero de SAP con el ecosistema fiscal de cada país.

Y probablemente esta sea una de las tendencias que más trabajo va a generar en los próximos años para los consultores SAP. No porque exista una única gran normativa mundial de factura electrónica, sino precisamente por lo contrario, cada vez hay más países, más modelos y más requisitos diferentes.

Para una multinacional, el reto no será simplemente tener factura electrónica. Será conseguir que SAP pueda decir, dependiendo de dónde se genere la factura, “esta sociedad está en este país, por tanto este es el formato, este es el canal, estas son las validaciones y este es el proceso que tenemos que seguir”.

Porque la factura puede ser la misma para el negocio.

La normativa, desde luego, no.

Cuando trabajas con autorizaciones en SAP, una de las transacciones que merece la pena conocer bien es SU24. Es especialmente útil desde el lado técnico porque permite mantener las propuestas de autorización asociadas a transacciones y aplicaciones.

La idea es sencilla, cuando asignas una transacción a un rol, SAP puede proponer determinados objetos de autorización relacionados con ella. Estas propuestas se gestionan en SU24.

Por ejemplo, imagina que estás creando un rol para un usuario que va a trabajar con una transacción de pedidos. Añades la transacción al rol y, al generar las autorizaciones, SAP propone determinados objetos. Si esas propuestas están correctamente mantenidas, el trabajo del administrador de roles es mucho más sencillo y, sobre todo, se reduce la tentación de empezar a añadir objetos manualmente hasta que el usuario deje de recibir errores.

En un proyecto, una secuencia bastante habitual sería,

SU24 → PFCG → SU53/STAUTHTRACE

Primero revisas qué propuestas existen para la aplicación o transacción. Después construyes el rol en PFCG y generas el perfil. Si el usuario sigue teniendo un error de autorización, puedes utilizar SU53 para obtener una primera pista o STAUTHTRACE cuando necesitas investigar con más detalle qué está comprobando el sistema.

Y hay una diferencia importante entre SU24 y PFCG, SU24 no es donde creas el rol. PFCG es la transacción para crear y mantener los roles. SU24 sirve para mantener las propuestas de autorización que ayudan a que esos roles se construyan correctamente.

Un buen consultor de seguridad no debería solucionar todos los problemas añadiendo autorizaciones directamente en PFCG. Cuando una propuesta estándar está mal mantenida o falta una propuesta para un desarrollo propio, conviene analizar primero si el problema está realmente en el diseño de la autorización.

Para un consultor funcional, la transacción que probablemente más va a utilizar cuando hablamos de roles es PFCG.

PFCG es el punto donde se construye y mantiene el rol que posteriormente se asignará a los usuarios. Pero lo importante no es saber simplemente dónde pulsar “Crear rol”. Lo importante es entender qué debe contener ese rol desde el punto de vista del proceso de negocio.

Supongamos que estamos implantando SAP para un equipo de compras. El usuario necesita crear y modificar pedidos, pero únicamente para determinadas organizaciones de compras. Desde funcional no deberíamos pedir simplemente “un rol con ME21N y ME22N”. Hay que definir qué actividades realiza, qué organizaciones puede utilizar y qué limitaciones debe tener.

En PFCG puedes crear el rol, acceder al menú y añadir las transacciones o aplicaciones necesarias. Después, en la pestaña Autorizaciones, SAP mostrará los objetos relacionados con esas funcionalidades. Es ahí donde se concretan valores como sociedad, centro, organización de compras, actividad, etc., dependiendo del proceso.

Después de mantener las autorizaciones, se genera el perfil y, en la pestaña Usuarios, se asigna el rol a los usuarios correspondientes.

Una forma muy práctica de trabajar en un proyecto es pensar en PFCG siguiendo este orden,

Proceso de negocio → actividades del usuario → transacciones/aplicaciones → objetos de autorización → valores organizativos → usuarios.

Y aquí aparece uno de los errores clásicos de los proyectos, “Este usuario necesita exactamente lo mismo que Juan, así que cópiale el rol”. Puede ser correcto, pero también puede significar que estamos heredando autorizaciones que Juan tenía por una necesidad completamente diferente.

Por eso, cuando se diseñan roles funcionales, no conviene preguntar solamente “¿qué transacciones utiliza?”, sino “¿qué puede hacer y sobre qué datos puede hacerlo?”. Esa segunda pregunta es la que realmente define el acceso.

Hay una instrucción ABAP que aparece constantemente cuando hablamos de seguridad en desarrollos, AUTHORITY-CHECK.

Su función es comprobar si el usuario que está ejecutando el programa dispone de una determinada autorización. Y aunque la sintaxis es sencilla, utilizarla correctamente requiere entender qué estamos comprobando.

Por ejemplo, imaginemos que tenemos un desarrollo Z que permite modificar información de un pedido. Antes de realizar la modificación podemos comprobar si el usuario tiene autorización para esa actividad,

Aquí estamos comprobando el objeto de autorización y los valores concretos que necesitamos. ACTVT = '02', por ejemplo, representa la actividad de modificación.

El resultado de la comprobación se devuelve en sy-subrc. Si es 0, el usuario tiene la autorización solicitada. Si el resultado es distinto de 0, la comprobación no se ha superado.

Una cosa importante, AUTHORITY-CHECK no concede ninguna autorización. Simplemente comprueba las autorizaciones que ya tiene el usuario a través de sus roles y perfiles.

Por eso, cuando un usuario recibe un error después de ejecutar un AUTHORITY-CHECK, el problema normalmente no está en el AUTHORITY-CHECK en sí. Hay que revisar qué roles tiene asignados el usuario y qué valores contiene el objeto de autorización. Para investigar el problema, herramientas como SU53 o STAUTHTRACE son especialmente útiles.

También es importante no hacer comprobaciones demasiado genéricas. Si nuestro proceso depende de una sociedad, centro, organización de ventas o cualquier otro ámbito organizativo, deberíamos comprobar los valores que realmente condicionan la operación.

En definitiva, AUTHORITY-CHECK es una de esas instrucciones que parecen sencillas, pero que marcan una diferencia importante entre un desarrollo que simplemente funciona y un desarrollo que respeta el modelo de seguridad de SAP.

Y una regla bastante útil para cualquier desarrollo Z, si una funcionalidad permite consultar, modificar, crear o eliminar información sensible, la pregunta no debería ser únicamente “¿puede llegar el usuario a esta pantalla?”, sino también “¿está autorizado a realizar esta operación sobre estos datos?”.

Hay un tipo de proyecto SAP que no nace de una necesidad estratégica del negocio sino de una obligación legal. Y esos proyectos tienen una característica que los hace especialmente interesantes para el consultor que sabe gestionarlos bien, el cliente no puede decir que no. La única decisión que tiene es con quién lo hace y cuándo empieza.

La factura electrónica obligatoria en España es exactamente ese tipo de proyecto. No es opcional. Tiene fechas. Tiene sanciones. Y la mayoría de las empresas con SAP todavía no han empezado a planificarlo seriamente.

Eso crea una ventana de oportunidad muy concreta para el consultor o la consultora que se adelanta. No para vender algo que el cliente no necesita, sino para llegar primero con una propuesta honesta y bien dimensionada antes de que llegue otro con una propuesta apresurada y mal calibrada.

¿Cómo se hace esa conversación bien? Hay tres cosas que marcan la diferencia entre el consultor que aprovecha esta oportunidad y el que la deja pasar.

La primera es llegar con diagnóstico, no con propuesta. Antes de hablar de soluciones hay que entender en qué situación está ese cliente concreto. ¿Supera los ocho millones de facturación? ¿Tiene SII ya implementado? ¿Qué versión de SAP tiene y está dentro del rango de soporte de SAP DRC? ¿Cómo recibe actualmente las facturas de proveedores? Un diagnóstico de veinte minutos te da la información que necesitas para dimensionar honestamente lo que ese cliente tiene que hacer. Sin diagnóstico estás hablando de obligaciones genéricas que el cliente ya ha leído en LinkedIn.

La segunda es ser muy claro con los tiempos reales. El error más habitual en proyectos de cumplimiento normativo es subestimar el tiempo de implementación porque "el alcance parece pequeño." SAP DRC con Verifactu tiene su propia complejidad, la conectividad con el servicio cloud, la configuración del cockpit, las pruebas con la AEAT en entorno de pruebas antes de activar en producción, la formación al equipo de administración. Y luego está la parte de la factura electrónica B2B que afecta a los procesos de compras y de cuentas a pagar. Decirle al cliente que tiene tiempo de sobra cuando los plazos reales de proyecto no lo garantizan no es ser optimista. Es comprarte un problema.

La tercera es plantear el proyecto en fases con valor incremental. Primero Verifactu, que tiene fecha más temprana y alcance más técnico. Después la adaptación para emitir facturas en formato estructurado. Después la parte de recepción y procesamiento automatizado de facturas de proveedores, que es donde hay más trabajo funcional y más resistencia del cliente porque toca procesos que llevan años funcionando igual. Esa secuencia le da al cliente visibilidad de qué está pagando y cuándo lo necesita, y a ti te da un proyecto estructurado que puedes entregar con garantías en lugar de un megaproyecto que nadie sabe cuándo termina.

La normativa no avisa dos veces. El cliente que llega tarde paga el proyecto con menos calma, menos margen para decisiones de diseño y más presión sobre el equipo. El que empieza a tiempo lo hace bien y con criterio. Y el consultor que le ayuda a empezar a tiempo... ese es el que recuerda cuando viene el siguiente proyecto.

En SAP muchas veces el valor de la experiencia aparece precisamente ahí, en detectar el problema antes de que llegue a producción. Saber que una interfaz puede fallar, que un dato no está informado, que un transporte tiene más riesgo del que parece o que ese “pequeño cambio” puede afectar a tres procesos distintos.

Con los años aprendes que ser buen consultor no consiste únicamente en solucionar problemas. También consiste en anticiparlos.

Y hasta aquí el boletín de esta semana.

Hoy hemos hablado de algo que muchas veces vemos todos los días… pero que no siempre analizamos con calma.

Y cuanto más tiempo pasas en él, más te das cuenta de que SAP no va solo de tecnología.

Va de personas, de procesos, de negocio… y muchas veces de saber adaptarse constantemente a cómo cambia todo.

Gracias por dedicar unos minutos a leerlo y por seguir formando parte de esta pequeña comunidad donde intentamos hablar de SAP de una forma un poco más cercana y real.

La semana que viene volveremos con más historias de proyectos, algún tema interesante y seguramente otra de esas situaciones que todos hemos vivido alguna vez trabajando en este ecosistema.

Nos leemos en el próximo boletín 👋

Envíame un correo sobre un tema que quieras que salga en la newsletter a [email protected] o contesta a este email.