Página de estado viva. Última verificación: septiembre de 2026.
Si buscas "TicketBAI Odoo 17" la respuesta corta es esta: TicketBAI está cubierto en Odoo Community desde la versión 16 por el módulo oficial l10n_es_edi_tbai, que forma parte del núcleo LGPL (es decir, de Community) y envía facturas a las tres diputaciones forales, incluido el LROE de Bizkaia (Batuz). La familia histórica de módulos OCA (l10n_es_ticketbai*) sigue existiendo, pero solo hasta la rama 16.0 y sin migraciones abiertas a 17, 18 o 19: el módulo oficial la ha sustituido en la práctica. A continuación, el detalle versión por versión, con fecha de verificación, y qué opciones reales tienes según el Odoo que uses.
TicketBAI, Batuz y LROE: qué exige cada hacienda foral
Antes de hablar de módulos conviene ordenar la normativa, porque los nombres se mezclan:
- TicketBAI es el sistema común de las tres haciendas forales vascas (Araba/Álava, Bizkaia y Gipuzkoa): cada factura emitida genera un XML firmado, encadenado por huella (hash) con la anterior, que se envía telemáticamente a la diputación correspondiente. La factura impresa o en PDF debe incluir un código QR que permite a cualquiera verificar que fue declarada.
- Batuz es el nombre del modelo de tributación de Bizkaia que integra TicketBAI con la presentación del LROE (Libro Registro de Operaciones Económicas): en Bizkaia no solo envías la factura, sino también registros de operaciones (emitidas y, en ciertos casos, recibidas) con un diseño propio.
- Navarra no es TicketBAI estrictamente: la Hacienda Tributaria de Navarra implantó su propio sistema (NaTicket), con requisitos similares pero administración distinta.
La consecuencia práctica: un ERP que opere en el País Vasco necesita firmar, encadenar, enviar y generar QR; y si opera en Bizkaia, además, generar el LROE. Es exactamente lo mismo espíritu que VeriFactu a nivel estatal, pero gestionado por las haciendas forales. Si te interesa el paralelismo, lo desarrollamos en la guía definitiva de VeriFactu en Odoo Community y en el análisis de cómo cumplir la normativa española con software libre.
Tabla de estado de módulos por versión (16/17/18/19)
Verificado en septiembre de 2026 contra el código de OCA/l10n-spain, el repositorio oficial odoo/odoo y PyPI:
| Módulo / familia | 16 | 17 | 18 | 19 |
|---|---|---|---|---|
Oficial l10n_es_edi_tbai (núcleo, LGPL → Community) |
Sí | Sí | Sí | Sí |
Oficial POS: l10n_es_pos_tbai (17) / l10n_es_edi_tbai_pos (18-19) |
Sí (integrado en TPV localización) | Sí | Sí | Sí |
OCA l10n_es_ticketbai + l10n_es_ticketbai_api |
Sí | No | No | No |
OCA l10n_es_ticketbai_api_batuz / _batuz (Batuz/LROE) |
Sí | No | No | No |
OCA l10n_es_ticketbai_pos (TicketBAI desde el TPV) |
Sí | No | No | No |
Tres lecturas importantes de esta tabla:
- El módulo oficial cubre Community.
l10n_es_edi_tbaivive en el repositorioodoo/odoocon licencia LGPL-3, no en el repositorio Enterprise. Su propio manifiesto agradece el trabajo a Landoo y a la comunidad española: Odoo integró en el núcleo la solución que nació en la comunidad vasca. Envía facturas emitidas y recibidas a las tres diputaciones, mantiene la cadena de huellas, añade el QR y genera el LROE de Bizkaia (Batuz) mediante su plantilla específica. - La familia OCA quedó congelada en 16.0. En PyPI,
odoo-addon-l10n-es-ticketbaiyodoo-addon-l10n-es-ticketbai-api-batuzsolo tienen releases de la serie 16.0, y a fecha de verificación no hay ni un solo PR abierto de migración a 17.0, 18.0 o 19.0 en OCA/l10n-spain. La investigación anterior hablaba de "migraciones abiertas"; hoy lo correcto es decir que no hay actividad de migración visible: la comunidad considera el módulo oficial como el camino. - Navarra no está cubierta ni por el módulo oficial (que solo contempla las tres diputaciones vascas) ni por módulos OCA conocidos en l10n-spain.
Si estás en 17, 18 o 19: opciones reales hoy
Con la tabla encima, las opciones se reducen a tres escenarios:
Escenario 1: usas el módulo oficial (recomendado). Si tu Odoo 17, 18 o 19 es Community, activa la localización española e instala l10n_es_edi_tbai (aparece como "Spain - TicketBAI" en aplicaciones). Configura el certificado electrónico de la empresa y la agencia tributaria foral que corresponda en los ajustes de contabilidad, y prueba siempre primero contra el entorno de pruebas que cada diputación mantiene. Si tienes TPV, instala además la variante POS de tu versión.
Escenario 2: vienes de 16 con los módulos OCA. Aquí está el punto delicado y conviene ser honesto: si tu instalación de Odoo 16 funciona con l10n_es_ticketbai de la OCA y piensas actualizar a 17 o superior, no existe una ruta de migración OCA de esos módulos. El salto implica desinstalar la familia OCA, instalar el módulo oficial y rehacer la configuración (certificado, agencia, secuencias encadenadas). Es un proyecto con datos fiscales vivos: hazlo en un entorno de staging, valida la cadena de huellas de la primera factura enviada y guarda evidencias de los envíos históricos del sistema anterior.
Escenario 3: necesitas algo que el oficial no cubre. El módulo oficial es más joven que la familia OCA y puede no cubrir casos muy específicos (ciertos regímenes, personalizaciones heredadas). Antes de desarrollar a medida, revisa los issues de odoo/odoo y de OCA/l10n-spain: gran parte de las diferencias se han ido corrigiendo versión a versión. Si el hueco es real, la vía razonable es extender el módulo oficial, no resucitar la familia OCA en una rama nueva.
Y si tu empresa está en Navarra: ni el core ni la OCA tienen hoy un módulo NaTicket mantenido. Las opciones reales pasan por desarrollo a medida sobre el esqueleto del módulo oficial o por un conector con un servicio externo de envío. Es el único territorio foral donde "Community resuelve solo" no es cierto a día de hoy.
Cómo seguir las migraciones y el estado real en OCA/l10n-spain
Esta página se revisa trimestralmente, pero si quieres vigilarlo por tu cuenta:
- Entra en github.com/OCA/l10n-spain y filtra los pull requests por
ticketbaien el título: si algún día aparece un[17.0][MIG] l10n_es_ticketbai, es la señal de que la comunidad retoma la familia. - Comprueba las ramas 17.0/18.0/19.0 del repositorio: la aparición de la carpeta
l10n_es_ticketbaien una rama indica módulo migrado y mergeado. - Revisa en PyPI el paquete odoo-addon-l10n-es-ticketbai-api-batuz: si publica releases de la serie 17/18/19, el módulo ya es instalable por pip en esas versiones.
- Para el módulo oficial, el termómetro es el changelog de cada versión de Odoo y el historial de commits de la carpeta
addons/l10n_es_edi_tbaienodoo/odoo.
El resto del ecosistema fiscal español de la OCA (modelos AEAT, SII comunitario, Facturae) lo mantenemos en la guía de módulos OCA para la AEAT, y el montaje completo de la contabilidad en la guía de contabilidad española en Odoo Community con OCA. Si te estás preguntando quién mantiene todo esto, la respuesta corta es la comunidad organizada: te lo contamos en nuestra página sobre la comunidad Odoo.
FAQ
¿Odoo oficial cubre TicketBAI? Sí, y además en Community: l10n_es_edi_tbai está en el núcleo LGPL desde la versión 16 (verificado en las ramas 16.0 a 19.0 de odoo/odoo). No necesitas Enterprise ni módulos de pago para enviar a Álava, Bizkaia o Gipuzkoa.
¿Y Batuz (LROE de Bizkaia)? También. El módulo oficial incluye la plantilla LROE de Bizkaia; la variante OCA específica (l10n_es_ticketbai_api_batuz) solo existe hasta 16.0 y ya no es necesaria en versiones actuales.
¿Y en Navarra? No. NaTicket no tiene módulo mantenido ni en el núcleo ni en la OCA a fecha de septiembre de 2026. Toca desarrollo a medida o servicio externo.
Estoy en Odoo 16 con los módulos OCA y funcionan. ¿Debo cambiar? Si funcionan y no piensas actualizar de versión, no toques nada. El problema aparecerá cuando quieras subir a 17+: planifica entonces el cambio al módulo oficial.
¿Puedo configurarlo yo solo? Si ya gestionas tu Odoo self-hosted, sí: es comparable en dificultad a configurar el SII. La parte crítica es el certificado electrónico y las pruebas contra el entorno de test de tu diputación antes del primer envío real.
Contenido verificado en septiembre de 2026 contra OCA/l10n-spain, odoo/odoo (ramas 16.0-19.0) y PyPI.