Elegir software para TicketBAI

TicketBAI no es una casilla única para todo el país

TicketBAI pertenece al marco foral vasco y su aplicación se concreta por provincia. Álava y Gipuzkoa desplegaron sus calendarios propios; en Bizkaia, TicketBAI se integra en Batuz junto con el Libro Registro de Operaciones Económicas. Un proveedor que muestra «TicketBAI: sí» sin territorio, versión ni flujo deja preguntas esenciales abiertas.

La selección debe partir del domicilio y normativa aplicables al contribuyente, no de la ubicación física del usuario o del comercial. Referencias primarias revisadas el 5 de agosto de 2026: calendario oficial de Álava e implantación definitiva de Batuz en Bizkaia. Para Gipuzkoa debe consultarse su sede y normativa foral vigente.

Escenario: una consultora abre oficina en Bilbao

Una consultora con sede fiscal en territorio común abre un espacio de trabajo en Bilbao y recibe una propuesta de software «válido para País Vasco». La dirección asume que la nueva oficina activa TicketBAI. Sin embargo, la aplicación de la normativa no se decide únicamente por disponer de un local. Antes de cambiar, su asesoría debe determinar competencia tributaria y obligaciones concretas.

Si finalmente una entidad del grupo queda sometida a Bizkaia, el proyecto tendrá que contemplar no solo emisión y QR, sino el encaje con Batuz y LROE. Otra entidad podría seguir bajo RRSIF común. El sistema multiempresa necesita separar configuraciones y evidencias.

Prueba provincial del producto

Pide que el proveedor identifique producto, versión, territorio y documentación que sustentan el claim. Configura una serie realista, emite factura ordinaria, genera una rectificativa y reproduce una incidencia de comunicación. Comprueba fichero, identificador, QR, respuesta, reintento y archivo. En Bizkaia, añade el flujo hacia LROE.

Los criterios son alcance provincial, mantenimiento, correcciones, funcionamiento ante caída, soporte del distribuidor y exportación. Registra quién responde si la versión instalada no coincide con la anunciada. Una captura de pantalla sin entorno ni número de versión no demuestra capacidad operativa.

Caso límite: varias sociedades y dos territorios

Un grupo puede tener sociedades sometidas a administraciones distintas. Compartir catálogo y clientes no autoriza a mezclar series, certificados o libros. La prueba debe cambiar de entidad, emitir documentos en cada régimen y verificar que usuarios y automatizaciones no cruzan configuraciones.

Otro límite aparece cuando el software soporta TicketBAI para una provincia, pero un distribuidor vende la misma marca en otra con distinto módulo. La marca no es la unidad de evidencia: lo son producto, versión, implantación y territorio. Ante duda, la administración foral y la asesoría competente prevalecen sobre el argumento comercial.

Conclusión: exige una respuesta con apellido territorial

Elige únicamente después de poder completar la frase «esta versión cubre este flujo para esta administración». En Álava o Gipuzkoa, contrasta normativa y servicio aplicables; en Bizkaia, incluye Batuz y LROE. Descarta comparativas que sumen TicketBAI como una función nacional. Un software adecuado hará visibles sus límites, conservará respuestas y permitirá corregir sin perder la trazabilidad de cada entidad.

El acta de elección debería recoger NIF, administración competente, producto, versión, distribuidor, certificado, series afectadas y fecha del ensayo. Ese documento breve evita que una futura incidencia termine causando una discusión entre fabricante, implantador y asesoría. Si cambia cualquiera de esos elementos, reabre la validación en lugar de reutilizar un «sí» antiguo.