VeriFactu para integradores de ERP: Sage, Odoo, a3 y sistemas propios
Si mantienes decenas de instalaciones de un ERP, VeriFactu no es un problema de una factura: es un problema de cuarenta clientes con cuarenta versiones, tres certificados caducados y un módulo oficial que no sabe nada de tu personalización. Esta página es para eso. Forma parte de la guía VeriFactu para integradores.
Qué ofrece cada fabricante, a grandes rasgos
Los fabricantes grandes han publicado su respuesta a VeriFactu. Lo que cubre cada uno cambia con la versión y con la edición, así que aquí solo va la forma general. Consulta la versión y el módulo con tu fabricante y pídelo por escrito antes de tomar decisiones.
| Origen | Forma general de la adaptación | Qué comprobar |
|---|---|---|
| Sage | Actualización de producto con la funcionalidad VeriFactu integrada en las versiones soportadas | Si tu instalación está en una versión soportada, si el producto concreto (no toda la familia) tiene la función y qué pasa con los añadidos de terceros |
| Odoo | Localización española con soporte VeriFactu en las versiones recientes; en instalaciones antiguas o autoalojadas puede depender de módulos de la comunidad o de partners | Versión de Odoo, si es SaaS o autoalojado, quién mantiene el módulo de localización y qué ocurre con tus módulos propios que tocan facturas |
| a3 (Wolters Kluwer) | Adaptación dentro de la suite, orientada a asesorías y sus clientes | Qué productos de la suite expiden facturas de verdad y cuáles solo las reciben; el flujo asesoría-cliente cuando el cliente factura fuera |
| Sistema propio | Lo que tú hayas hecho | Todo: registro, huella, QR, envío, estados, eventos, declaración responsable |
La regla general: si el módulo del fabricante existe, cubre tu instalación y el fabricante mantiene el producto, actualiza. Es la opción más barata y la que menos responsabilidad te deja a ti. El resto de esta página trata de los casos en que eso no basta.
Por qué las instalaciones personalizadas rompen el módulo oficial
El módulo VeriFactu de un fabricante se engancha al flujo estándar de expedición: la factura se confirma en la pantalla prevista, con los datos previstos, y en ese instante se genera el registro. Las personalizaciones que hemos visto romper eso:
- Facturación desde otro sitio. Un módulo de proyectos, un TPV, una web o un proceso nocturno que crea facturas sin pasar por la pantalla estándar. El módulo oficial no se entera.
- Series y numeración propias. Numeración por delegación, por cliente o por año fiscal distinto del natural. El registro exige serie y número coherentes con la cadena de huellas.
- Rectificativas a mano. Instalaciones en las que «rectificar» es editar la factura original. VeriFactu exige registro de alta para la rectificativa y, si toca, registro de anulación; nunca una edición silenciosa.
- Facturación por lotes. Cien facturas generadas a la vez por un script. La cadena de huellas es secuencial; dos procesos en paralelo producen dos cadenas rotas.
- PDF como fuente de verdad. Instalaciones donde el dato bueno está en el PDF y la base de datos va detrás. El registro tiene que salir del acto de expedir, no del documento.
- Versiones congeladas. Clientes en una versión de hace seis años porque la personalización no sobrevive a la actualización. Ahí el módulo oficial no existe para ti.
Ninguno de estos casos se resuelve «instalando el módulo». Se resuelven decidiendo dónde está el punto de expedición en tu instalación y enganchando ahí. Es lo que miramos en la evaluación técnica.
Operar decenas de clientes
Adaptar un ERP a VeriFactu una vez es un proyecto. Adaptar cuarenta instalaciones y operarlas después es otro tipo de trabajo, y es donde un integrador gana o pierde el año.
| Problema | Qué hace falta |
|---|---|
| Cada cliente es un emisor distinto | Una cadena de huellas por emisor, sin mezclar. Un identificador de cliente que viaje con cada registro |
| Reintentos | Idempotencia por emisor, serie y número. Consultar el estado antes de reenviar; «desconocido» no es «rechazado» |
| Visibilidad | Un panel con todos: enviados, pendientes, rechazados, sin actividad. El cliente que deja de enviar un lunes no llama |
| Certificados | Inventario con fecha de caducidad por cliente y aviso con dos meses de margen |
| Altas y bajas | Procedimiento para incorporar un cliente nuevo y para cerrar la cadena de uno que se va, con exportación de sus registros |
| Evidencias | Informe mensual por cliente que puedas entregar si lo piden |
Esto es lo que cubre la operación y control multicliente. Se puede construir en casa; lo que no se puede es improvisarlo en enero.
El certificado y la representación
El envío a la AEAT se firma con un certificado electrónico. Puede ser del obligado (tu cliente) o de un representante. Aquí aparecen los dos errores más caros que vemos:
- Usar el certificado del integrador para todos los clientes sin representación formalizada. Funciona técnicamente, y por eso se hace. No sostiene una revisión.
- Custodiar certificados de clientes sin procedimiento. Ficheros .p12 en un correo, contraseñas en un Excel, nadie sabe cuál caduca cuándo.
Decídelo antes de integrar: quién es el titular del certificado de cada cliente, dónde se custodia, quién lo renueva y con qué antelación, y si hay representación, que esté formalizada por escrito. Cambiar esto con cuarenta clientes en producción es doloroso.
Checklist de evaluación por origen
Antes de decidir la vía de adaptación de un ERP, responde esto para cada origen que mantienes:
- ¿Qué versión y edición tienen tus clientes? ¿Cuántas versiones distintas hay en la cartera?
- ¿El fabricante tiene módulo VeriFactu para esa versión? ¿Te lo ha confirmado por escrito?
- ¿Desde cuántos puntos se expiden facturas en tu instalación? ¿Todos pasan por el flujo estándar?
- ¿Qué series, rectificativas, anulaciones y simplificadas usa cada cliente?
- ¿Quién es el productor del programa? ¿Dónde está su declaración responsable y cubre tu personalización?
- ¿Qué clientes están en el SII o en territorio foral y quedan fuera?
- ¿Quién tiene el certificado de cada cliente y cuándo caduca?
- ¿Cómo vas a saber mañana que el cliente veintitrés ha dejado de enviar?
- ¿Puedes probar todo esto en el entorno de pruebas de la AEAT antes de tocar producción?
- ¿Qué fecha aplica a cada cliente? Mira los plazos VeriFactu 2027.
Cuándo tiene sentido una capa como Kenea, y cuándo no
| Tiene sentido | No tiene sentido |
|---|---|
| Mantienes muchos clientes sobre el mismo origen y no quieres que cada instalación sea un caso | Tienes tres clientes en la versión soportada y el módulo del fabricante los cubre |
| El módulo oficial no contempla tus personalizaciones, tus series o tus puntos de expedición | Tu instalación es estándar y actualizar es viable |
| Necesitas un único panel de control para toda la cartera, con alertas y evidencias | Tu fabricante ya te da el panel multicliente que necesitas |
| Tu sistema propio expide facturas y no quieres escribir y mantener el control de errores, duplicados y estados | Tienes equipo de desarrollo, pocos orígenes y prefieres integrar una API fiscal por tu cuenta |
| El origen permite enganchar en el momento de expedir | El origen solo produce PDF y no hay forma de interceptar la expedición: ahí lo honesto es cambiar de software |
Integramos un origen una vez y el conector sirve para todas las instalaciones de ese origen. Ahí está el ahorro. Si tu caso está en la columna de la derecha, te lo diremos en la evaluación y no te cobraremos una integración que no necesitas. Precios y alcance en servicios.
Fuentes
- Real Decreto 1007/2023, reglamento de los sistemas informáticos de facturación.
- Orden HAC/1177/2024, especificaciones técnicas.
- Sede de la AEAT: sistemas informáticos de facturación, preguntas frecuentes y entorno de pruebas.
Esta guía es información técnica general, no asesoramiento fiscal ni jurídico. Las referencias a Sage, Odoo y a3 son descriptivas; las marcas pertenecen a sus titulares y Kenea no tiene relación con ellos. Consulta tu caso con tu asesoría.