VeriFactu vs TicketBAI: diferencias, a quién afecta y cómo preparar tu software (actualizado 2025–2027)

VeriFactu busca que el sistema de facturación sea una caja negra (no manipulable y auditable). TicketBAI es el tacógrafo: reportas cada factura a la Hacienda Foral con su XML y acuse.

Qué es VeriFactu y qué es TicketBAI

VeriFactu es el marco estatal (AEAT) dentro del Reglamento de Sistemas Informáticos de Facturación (RD 1007/2023). Lo importante es que el software deje huella técnica: integridad, inalterabilidad, trazabilidad y registro de eventos. El envío automático a la AEAT es una modalidad (VERI*FACTU): puedes operar con envío o sin envío, pero el sistema debe cumplir requisitos técnicos y estar preparado.

TicketBAI es el sistema foral del País Vasco (Álava, Bizkaia y Gipuzkoa): exige remitir cada factura en un XML TicketBAI firmado (con su identificación/código) y con elementos de verificación (QR/código) según la Hacienda Foral correspondiente.

Ámbito, autoridad y sujetos obligados

• VeriFactu (AEAT, territorio común): afecta a empresarios y profesionales del régimen común. Lo determinante es el sistema informático que expide facturas/tickets y su cumplimiento.
• TicketBAI (Haciendas Forales, País Vasco): afecta a quienes desarrollan actividad económica en Álava, Bizkaia o Gipuzkoa (según norma foral y calendario aplicable).
• BATUZ: es el marco de Bizkaia que integra TicketBAI + obligaciones asociadas en Bizkaia. No es Navarra.

Mapa práctico: si tu punto de emisión está en Bilbao/Vitoria/Donostia, manda la norma foral (TicketBAI). Si además facturas en territorio común, exige al proveedor doble compatibilidad: TicketBAI donde aplique + VeriFactu para el resto.

Tabla rápida: diferencias clave

Requisitos técnicos comparados (lo que debes pedir al proveedor)

• VeriFactu: registro de facturación con integridad, trazabilidad y auditoría (encadenamiento/huellas, log de eventos, conservación, etc.).
• TicketBAI: XML TicketBAI firmado, numeraciones/series coherentes, trazabilidad, envío por factura y monitor de estados.

Regla de oro en revisiones: pide una prueba de encadenamiento entre dos registros consecutivos, una muestra del log de eventos y, si aplica TicketBAI, un XML real con su firma y acuse aceptado.

Offline y “modo incidente”

Los sistemas fallan y la conexión cae. Tu software debe tener un protocolo claro: seguir emitiendo con registro correcto, almacenar evidencias y gestionar reintentos (cola) hasta que el envío quede aceptado. En TicketBAI esto es especialmente sensible: el “modo incidente” debe estar documentado y probado.

VERI*FACTU vs NO-VERI*FACTU: cómo decidir (si estás en territorio común)

• VERI*FACTU (con envío): remisión automática a la AEAT. Útil si buscas máxima trazabilidad operativa y control continuo.
• NO-VERI*FACTU (sin envío): el sistema garantiza integridad y auditabilidad, almacena todos los datos pero no remite automáticamente.

Criterio rápido:

• Hostelería alto volumen: suele compensar VERI*FACTU por disciplina operativa, colas de envío y control.
• Servicios B2B de menor volumen: NO-VERI*FACTU puede ser suficiente, siempre con evidencias claras y buen control interno.

Convivencia y escenarios reales (¿puedo necesitar ambos?)

• Solo País Vasco: cumples TicketBAI (y, si estás en Bizkaia, su encaje dentro de BATUZ). Exige un software sólido y pruebas de envío/acuse.
• País Vasco + resto de España: exige doble compatibilidad por contrato: “TicketBAI (XML + envío + acuse) + VeriFactu (cumplimiento técnico)”.

Checklist antes de firmar:

• Declaración por escrito de compatibilidad territorial (TicketBAI por provincia + VeriFactu territorio común).
• Muestras reales: XML TicketBAI firmado + acuse de aceptación; y evidencias de auditoría del sistema.
• Contingencia: funcionamiento offline + cola de envíos + monitor de errores.
• Gestión de series, rectificativas, abonos y trazabilidad.

Calendario (actualizado) y cómo plantearlo como proyecto

Para el ámbito estatal, el Real Decreto-ley 15/2025 amplía los plazos del RD 1007/2023 a:

• 01/01/2027 para los obligados del art. 3.1.a).
• 01/07/2027 para el resto de obligados del art. 3.1.

Traducción práctica: úsalo para hacer un despliegue sin prisas (inventario → proveedor → piloto → formación → go-live). La mayoría de problemas llegan por dos vías: soporte del proveedor y falta de entrenamiento interno.

Mini-plan de implantación en 5 pasos

1. Inventario: puntos de emisión (TPV, ERP, e-commerce), series, entornos offline y quién emite qué.
2. Proveedor: exigir doble compatibilidad si aplica; pedir evidencias (log, encadenamiento, QR/códigos, XML+acuse).
3. Piloto: emitir casos reales (ventas, devoluciones, rectificativas) y validar trazas y reportes.
4. Formación: protocolo de modo incidente, series, rectificativas, abonos y cierres/arqueos.
5. Go-Live: checklist diario, monitor de envíos y revisión semanal de incidencias el primer mes.

Régimen sancionador: qué vigilar (con enfoque práctico)

Mi enfoque en talleres es simple: el coste de no cumplir suele ser mayor que adecuarse. La clave está en evidencias y en no improvisar “parches”.

Tabla comparativa (orientativa) de riesgos y foco sancionador

Conclusión

En resumen: VeriFactu asegura que el sistema no sea manipulable y deje evidencias; TicketBAI obliga a reportar cada factura a la Hacienda Foral. Si operas en ambos territorios, la decisión correcta es doble compatibilidad y validación con pruebas reales (XML+acuse, colas offline, trazabilidad y rectificativas).

FAQs

¿Necesito ambos?
Solo si operas/facturas en País Vasco y también en territorio común. En ese caso, exige doble compatibilidad al proveedor.

¿Qué pasa si me quedo sin internet?
Necesitas un protocolo de contingencia: emisión controlada, registro correcto, cola de envíos y reintentos hasta acuse (especialmente importante en TicketBAI).

¿Cómo pruebo que mi software cumple?
Pide evidencias: encadenamiento/huellas, log de eventos y trazabilidad; y en TicketBAI, un XML real firmado con acuse aceptado.