Saber qué es Verifactu es solo la mitad del trabajo. La otra mitad es convertir esa obligación en un proyecto con alcance, responsables, pruebas y fecha de puesta en marcha dentro de un sistema SAP que lleva años funcionando y que tiene personalizaciones, interfaces y canales de facturación que nadie ha revisado juntos. Adaptar SAP a Verifactu no consiste en instalar una nota y olvidarse: exige decidir qué documentos se ven afectados, cómo se generan los registros de facturación, cómo se envían o conservan y quién los vigila una vez en producción.
Este artículo plantea el proceso como lo vive un equipo SAP: desde el diagnóstico inicial hasta las pruebas, repartiendo el trabajo entre consultores funcionales, desarrolladores, integración y Basis. Para quienes quieren incorporarse a este tipo de proyectos, la oferta de cursos SAP de Profesional Online ofrece la base funcional y técnica con la que se abordan las adaptaciones normativas en entornos S/4HANA.
Antes de tocar ninguna configuración conviene responder a cuatro preguntas. La primera es si la compañía está realmente dentro del ámbito de Verifactu o queda fuera por estar en el Suministro Inmediato de Información o en un régimen foral. La segunda es qué versión de SAP se ejecuta y qué solución de cumplimiento ofrece SAP o el partner para ella. La tercera es cuántos puntos de emisión de facturas existen: facturación de SD, facturas manuales en FI, abonos, facturas desde tiendas online, terminales de punto de venta o sistemas externos que contabilizan en SAP. La cuarta es qué desarrollos propios intervienen en el proceso, porque cualquier código que modifique importes, fechas o numeración después de generar el registro puede comprometer el cumplimiento.
Con esas respuestas se toma la decisión más importante del proyecto: usar una solución estándar o de partner, o desarrollar la adaptación a medida. La opción estándar reduce el riesgo y traslada al proveedor la responsabilidad de mantener el cumplimiento cuando la norma cambia. El desarrollo propio da más control, pero exige asumir el mantenimiento y aclarar con la asesoría fiscal si te convierte en productor del sistema y te obliga a emitir la declaración responsable. Es una decisión que condiciona costes y plazos, por lo que no debería tomarse sin haber completado el inventario.
En SD, el centro del cambio es el documento de facturación. Cada factura de venta, abono o anulación debe generar su registro de facturación correspondiente y quedar encadenada con el anterior, lo que obliga a revisar cómo se numeran las facturas, cómo se determinan las series, cuándo se contabiliza el documento y qué ocurre cuando se cancela. Una cancelación deja de ser un simple documento inverso: debe reflejarse como un registro de anulación trazable. También hay que revisar los formularios de salida y la determinación de mensajes para que cada factura incorpore el código QR y las leyendas exigidas, tanto en la copia impresa como en el PDF que se envía al cliente.
En FI, el trabajo se centra en las facturas que no nacen en ventas: facturas manuales, rectificativas, facturas simplificadas y asientos que representan ingresos facturados. Hay que decidir si esos documentos pasan por el mismo circuito de registro y cómo se controla que ningún usuario pueda modificar un documento ya registrado sin dejar rastro. Las autorizaciones también cobran protagonismo, porque la trazabilidad exige poder demostrar quién hizo qué y cuándo, y eso afecta a la gestión de roles, algo que el equipo funcional debe coordinar con seguridad y Basis.
El equipo de desarrollo se ocupa de los formularios, de los puntos de extensión donde se genera el registro y de la revisión del código propio que toca el proceso de facturación. Si la adaptación incluye el envío a la Agencia Tributaria, interviene el equipo de integración: hay que consumir los servicios web de la Administración, gestionar la respuesta de cada envío, tratar los rechazos y reintentos y dejar una monitorización que permita saber, en cualquier momento, qué registros están pendientes o con error. En muchas compañías, esa capa se resuelve con la plataforma de integración, y es una de las razones por las que los perfiles de integración están muy demandados en este tipo de proyectos.
A Basis le corresponde lo que no se ve pero sostiene el cumplimiento: la instalación y renovación de certificados electrónicos, la conectividad segura con los servicios de la Administración, los registros de eventos, la conservación de los datos durante los plazos exigidos y la posibilidad de recuperarlos ante un requerimiento. Un certificado caducado o un puerto bloqueado por un cambio de red puede detener el envío de registros, de modo que la monitorización y las alertas forman parte del diseño desde el primer día, no un añadido posterior.
| Fase | Actividades principales | Perfiles | Riesgo habitual |
|---|---|---|---|
| Diagnóstico | Ámbito legal, inventario de puntos de emisión, revisión de desarrollos propios | Consultores SD y FI, fiscal | Olvidar canales satélite que emiten facturas |
| Decisión de solución | Estándar o partner frente a desarrollo propio | Dirección de TI, arquitectura | Subestimar el mantenimiento a medio plazo |
| Diseño y configuración | Series, numeración, anulaciones, formularios con QR | Consultores SD y FI, ABAP | Procesos de anulación sin trazabilidad |
| Integración | Conexión con la Agencia Tributaria, gestión de errores | Integración, Basis | Rechazos sin tratar ni monitorizar |
| Infraestructura | Certificados, conectividad, logs, conservación | Basis, seguridad | Certificados caducados |
| Pruebas y puesta en marcha | Casos completos, pruebas de usuario, formación | Todo el equipo y usuarios clave | Probar solo el caso feliz |
Las pruebas deben cubrir mucho más que la emisión de una factura estándar. Hay que probar abonos, anulaciones, rectificativas, facturas con varios tipos impositivos, facturas en moneda extranjera, cancelaciones tras el envío y el comportamiento del sistema cuando la Administración rechaza un registro o el servicio no está disponible. También es recomendable simular la entrega de registros ante un requerimiento, porque ahí es donde se comprueba si la conservación y la recuperación funcionan de verdad.
Los errores más frecuentes se repiten: planificar el proyecto como si fuera solo un cambio de formulario, dejar fuera los canales que emiten facturas fuera de SD, no formar a los usuarios sobre cómo anular o rectificar correctamente y empezar tarde, cuando los consultores disponibles son pocos y los plazos de los partners se alargan. Reservar un periodo de operación paralela antes del plazo obligatorio, con seguimiento diario de envíos y errores, es una de las medidas que más reduce el riesgo en la puesta en marcha.
Para participar en proyectos de adaptación normativa como este, conviene dominar los módulos de ventas y finanzas, el desarrollo en el entorno SAP y las arquitecturas de integración. La oferta de cursos SAP de Profesional Online permite construir ese perfil con itinerarios funcionales y técnicos orientados a los entornos S/4HANA.
Adaptar SAP a Verifactu es un proyecto transversal que reparte el trabajo entre consultoría funcional, desarrollo, integración y Basis, y cuyo éxito depende más de un buen diagnóstico y de una planificación realista que de la complejidad técnica de cada pieza. Las compañías que inventarían sus puntos de facturación, deciden pronto su estrategia de solución y reservan tiempo para probar llegan al plazo con margen; las que esperan se enfrentan a un mercado saturado.
Para los profesionales SAP, estos proyectos son una oportunidad concreta de ganar experiencia en cumplimiento normativo, un campo en el que la combinación de conocimiento fiscal, funcional y técnico es escasa y muy valorada. Quien sepa moverse entre facturación, desarrollo e integración tendrá un perfil especialmente competitivo en los próximos años.
Utilizamos cookies propias y de terceros para realizar el análisis de la navegación de los usuarios y mejorar nuestros servicios. Si continúa navegando, consideramos que acepta su uso.
Más información