Tengo un TPV propio y tengo que cumplir VERI*FACTU

Si tu TPV o tu programa de facturación es propio, casi siempre se puede adaptar a VERI*FACTU sin cambiarlo entero. Las sociedades tienen hasta el 1 de enero de 2027 y el resto, hasta el 1 de julio de 2027. Hay que añadirle cuatro piezas: un registro de cada factura encadenado con huella, el QR en el ticket, el envío a la AEAT (o firma y registro de eventos) y una declaración responsable.

Este artículo es para decidir, no para vender. Si ya sabes que quieres adaptar tu programa y buscas quién lo haga, ve directo a desarrollo de software a medida o cuéntanos cómo es tu TPV y te decimos qué haríamos.

Qué obliga y desde cuándo

La obligación sale del artículo 29.2.j) de la Ley General Tributaria y se desarrolla en el Real Decreto 1007/2023, el reglamento de los sistemas informáticos de facturación. Los detalles técnicos —formato de los registros, huella, QR, envío— están en la Orden HAC/1177/2024.

Las fechas se han movido dos veces. Primero las retrasó el Real Decreto 254/2025. Después, el Real Decreto-ley 15/2025, de 2 de diciembre, reescribió la disposición final cuarta del reglamento. Es la redacción vigente a 29 de septiembre de 2026, y dice esto:

• Contribuyentes del Impuesto sobre Sociedades: sistemas adaptados antes del 1 de enero de 2027.
• Resto de obligados (autónomos en IRPF con actividad económica, no residentes con establecimiento permanente, entidades en atribución de rentas): antes del 1 de julio de 2027.

La propia Agencia Tributaria lo recoge en su nota informativa sobre la ampliación del plazo, y añade que el tiempo hasta esas fechas funciona como periodo de pruebas.

Tres matices que cambian la respuesta según tu caso:

• Si ya llevas los libros de IVA por el SII, el reglamento te deja fuera (artículo 3.3).
• Si tu domicilio fiscal está en el País Vasco o en Navarra, se aplica su régimen foral, que tiene sus propios sistemas.
• Las fechas pueden volver a moverse. Antes de planificar, conviene mirar la página de la AEAT sobre VERI*FACTU y el texto consolidado del BOE. Aquí contamos lo que dicen hoy.

Si el programa lo hiciste tú, también eres su productor

Esta es la parte que más sorprende a quien tiene un TPV hecho a medida. El reglamento distingue entre quien usa un sistema de facturación y quien lo produce. Y la AEAT lo aclara en sus preguntas frecuentes sobre la declaración responsable: un software de desarrollo propio, aunque solo lo uses tú, necesita igualmente su certificación mediante declaración responsable de su productor.

En la práctica significa dos cosas:

1. La adaptación técnica es cosa tuya. Con un programa comercial, el fabricante adapta y tú actualizas. Con uno propio, nadie lo va a hacer por ti.
2. La declaración responsable también. Es un documento escrito que afirma que el sistema cumple el reglamento. Va visible dentro del propio programa, en cada versión, según el artículo 13. Se guarda y se enseña si la piden; la AEAT indica que se queda en el producto, sin registro previo.

Si tu TPV lo desarrolló un proveedor para ti, la conversación empieza por ahí: quién figura como productor y quién firma esa declaración.

Qué hay que cambiar en un TPV que ya funciona

La buena noticia es que casi todo lo que pide el reglamento se añade alrededor del momento de emitir el ticket. La lógica de venta, los precios, los descuentos y la caja se quedan como están. Estas son las piezas.

1. Un registro de facturación por cada ticket

Cada vez que el TPV emite una factura —completa o simplificada, que es el ticket de toda la vida— tiene que generar a la vez un registro de facturación de alta (artículos 9 y 10 del reglamento). Lleva el NIF del emisor, el número y la serie, la fecha, el tipo de factura, los importes, el desglose de IVA y los datos del propio sistema informático.

Si hay que anular una factura emitida por error, se crea un registro de anulación. Lo que ya se registró se queda como estaba: cualquier corrección entra como un registro nuevo, posterior.

El cambio de mentalidad está aquí. Muchos TPV antiguos permiten editar o borrar un ticket ya cobrado. Con el reglamento, esa puerta se cierra: el sistema tiene que detectar y avisar si alguien altera un registro (artículo 8).

2. La huella y el encadenamiento

Cada registro lleva una huella o hash: un resumen calculado a partir de su contenido. Y cada registro incluye parte de la huella del anterior. Así se forma una cadena desde el primer ticket hasta el último. Si alguien toca uno del medio, la cadena deja de cuadrar y se ve.

La Orden HAC/1177/2024 fija el algoritmo, qué campos entran en el cálculo y en qué orden. Es un trabajo pequeño en líneas de código y muy exigente en precisión: un espacio de más o un formato de fecha distinto y la huella sale diferente.

Aquí aparece la pregunta de diseño más importante en un TPV: dónde vive la cadena. Si tienes varios terminales, o tiendas que venden sin conexión y sincronizan después, hay que decidir qué componente genera los registros y en qué orden. Esa decisión condiciona todo lo demás, y conviene tomarla antes de escribir código.

3. El código QR en la factura

Las facturas emitidas con estos sistemas llevan un código QR con parte de su contenido: el NIF, el número, la fecha y el importe, junto con la dirección del servicio de cotejo de la AEAT. Lo establece la disposición final primera del Real Decreto 1007/2023, que modifica el reglamento de facturación, y la orden fija su formato. Quien recibe el ticket puede escanearlo y comprobarlo.

Para un TPV esto toca la plantilla de impresión. Parece menor y da guerra: impresoras térmicas antiguas, anchos de papel estrechos, plantillas que nadie ha abierto en años. Hay que probarlo con el papel y la impresora reales.

4. Enviar a la AEAT, o firmar y guardar

El reglamento admite dos modalidades, y eliges una:

Modalidad VERI*FACTU. El sistema envía a la AEAT cada registro, de forma automática, en el momento en que se genera (artículo 16). A cambio, se presume que cumple por diseño los requisitos de integridad y trazabilidad y queda dispensado de la firma electrónica de cada registro: basta la huella. El ticket lleva además la frase «VERI*FACTU» o «Factura verificable en la sede electrónica de la AEAT». Un detalle a tener en cuenta: una vez empiezas a enviar, la opción se mantiene al menos hasta el final de ese año natural.

Modalidad sin envío (lo que la AEAT llama sistemas no verificables). Los registros se quedan en tu sistema, pero cada uno va firmado electrónicamente (artículo 12). Además, el programa tiene que llevar un registro de eventos: arranques, paradas, exportaciones, restauraciones de copia y cualquier anomalía detectada. Y tiene que poder entregar todos los registros a la AEAT cuando te los pida.

¿Cuál conviene en un TPV? Depende del negocio, y hay argumentos para las dos. Las diferencias, una a una:

• Qué hace el TPV: en VERI*FACTU envía cada registro a la AEAT; sin envío, firma cada registro y lo guarda.
• Firma electrónica por registro: dispensada en VERI*FACTU; obligatoria sin envío.
• Registro de eventos: en VERI*FACTU se presume cumplido por diseño; sin envío, obligatorio.
• Conexión: VERI*FACTU depende de ella; si el envío falla, la orden obliga a reintentarlo al menos una vez cada hora y a avisar de la incidencia. Sin envío, para facturar basta el equipo.
• Trabajo de desarrollo: en VERI*FACTU, la integración con el servicio de la AEAT; sin envío, la firma, los eventos y la exportación.
• Presunción de cumplimiento: en VERI*FACTU, sí; sin envío, la AEAT puede pedirte copia de todos los registros para comprobarlo.

En nuestra experiencia, VERI*FACTU suele ser el camino más corto para un TPV con conexión estable: hay menos piezas que construir y menos que demostrar. La modalidad sin envío encaja mejor donde la conectividad es mala de verdad o donde ya existe una infraestructura de firma.

5. La declaración responsable y lo que se enseña en pantalla

Ya lo hemos visto arriba: si el sistema es tuyo, tú la firmas. Y el propio programa tiene que identificarse: cada registro lleva un código del sistema informático y los datos de su productor.

Qué pasa si llega la fecha y el TPV sigue igual

La Ley General Tributaria tiene un artículo para esto, el artículo 201 bis. Tipifica dos infracciones graves con multa fija:

• Producir un sistema que permita alterar registros, llevar cuentas paralelas o que incumpla las especificaciones técnicas: 150.000 euros por ejercicio y por cada tipo de sistema.
• Tener un sistema que debía estar certificado y no lo está, o que se ha alterado: 50.000 euros por ejercicio.

Con un TPV de desarrollo propio, la empresa es a la vez quien lo usa y quien lo produce. Por eso conviene leer las dos letras del artículo con tu asesor fiscal. Lo que aquí contamos es lo que dice la norma, y la aplicación a cada caso concreto le corresponde a él.

Más allá de la multa, hay un efecto práctico. Un ticket emitido con un sistema adaptado se presume auténtico e íntegro (así lo añade el reglamento de facturación). Esa presunción vale mucho el día que hay una discrepancia.

¿Adaptar el TPV que tienes o cambiar de programa?

Es la misma decisión que describimos en «tengo un sistema que funciona pero no hace lo que necesito», aplicada a una obligación legal con fecha. Y la respuesta sale de las mismas preguntas.

Compensa adaptar cuando:

• El TPV hace cosas que un producto del mercado resuelve peor: reglas de precio propias, integración con tu almacén o tu ERP, flujos de tu sector que la gente ya domina.
• Tienes el código y alguien que lo conoce, o se puede entender en un tiempo razonable.
• La emisión de tickets está en un solo sitio del código. Si todas las ventas pasan por la misma función, las piezas nuevas se enganchan ahí.
• El programa ya tiene otros motivos para seguir vivo varios años.

Compensa cambiar cuando:

• Nadie tiene el código, o está en una tecnología que ya no encuentra quien la mantenga.
• El TPV permite hoy editar y borrar tickets en muchos sitios distintos, y cerrar todas esas puertas equivale a rehacerlo.
• Lo que hace el programa lo cubre un producto estándar que ya viene adaptado, con su declaración responsable firmada por el fabricante.
• Ya estabas pensando en cambiarlo. VERI*FACTU es un buen momento para hacerlo, siempre que el cambio llegue antes de la fecha y no a la vez que ella.

Hay una tercera vía intermedia: mantener el TPV para vender y derivar la emisión de la factura a una pieza nueva que cumple el reglamento. El TPV le pasa los datos de la venta; la pieza genera el registro, calcula la huella, envía y devuelve el QR para imprimir. Es el patrón de «envolver» del artículo que citábamos arriba, y suele ser la opción con menos riesgo cuando el TPV es antiguo pero sostiene el negocio.

Una pregunta ordena mucho la decisión: ¿cuántos sitios del programa crean o modifican un ticket? Si la respuesta es «uno», adaptar suele ser una tarea acotada. Si nadie lo sabe, el primer trabajo es averiguarlo, y conviene presupuestarlo aparte.

Apoyarse en un proveedor con API

Entre construir todo tú y cambiar de programa hay otra opción: contratar un servicio que resuelve la parte normativa por API. Existen varios en el mercado; Fiskaly es uno de los conocidos. El TPV les envía cada venta y el servicio se encarga del registro, el encadenamiento, la huella y la comunicación con la AEAT.

Lo que te ahorra: implementar el formato exacto de los registros, el cálculo de la huella, la integración con el servicio de la AEAT y, sobre todo, seguir los cambios de especificación que vayan saliendo. Es la parte más cambiante y la que menos tiene que ver con tu negocio.

Lo que sigue siendo trabajo tuyo:

• Integrar el TPV con el servicio: llamar en el momento correcto, guardar lo que devuelve e imprimir el QR.
• Gestionar los fallos: qué hace el TPV si el servicio o la red tardan en contestar a las dos de la tarde de un sábado. Esa respuesta la diseñas tú.
• Las anulaciones y las rectificativas, que tienen su propio flujo.
• La declaración responsable de tu parte. La AEAT indica que, cuando un sistema se compone de varias piezas y cada una afecta al cumplimiento, lo lógico es que haya tantas certificaciones como componentes. El proveedor certifica la suya; tu integración sigue siendo tuya.
• La dependencia: una cuota recurrente y un tercero en el camino de cada venta. Merece la pena leer el contrato con la misma atención que la documentación técnica.

Con un volumen de tickets alto, varios terminales o varias tiendas, un proveedor así suele compensar. Con un TPV sencillo y una sola caja, la integración directa con la AEAT también es razonable. Lo sensato es comparar las dos con números: horas de desarrollo y mantenimiento frente a cuota anual.

Cómo se aborda en la práctica

Es lo que estamos haciendo con nuestro propio sistema de facturación, que también está obligado, y el orden que funciona es este:

1. Localizar dónde nace cada ticket. Todos los caminos: venta normal, devoluciones, tickets manuales, reimpresiones, cierres de caja. Es el mapa sobre el que se construye todo lo demás.
2. Elegir modalidad y, si procede, proveedor. Con el mapa delante, la decisión se toma en una reunión.
3. Cerrar las puertas de edición. Todo lo que hoy permite tocar un ticket emitido pasa a hacerse con registros nuevos.
4. Construir el registro, la huella y el QR en un entorno de pruebas, contra el entorno de pruebas de la AEAT.
5. Probar con las impresoras y la red reales, incluido cortar la conexión a propósito en mitad de una venta.
6. Redactar la declaración responsable y dejarla visible en el programa.
7. Poner en marcha con margen respecto a la fecha. El periodo de pruebas que ofrece la AEAT sirve justo para esto.

En un TPV bien mantenido y con la emisión centralizada, el grueso del trabajo se mide en semanas. Lo que alarga un proyecto así es casi siempre el paso 1: entender un programa que lleva años funcionando y que nadie ha documentado.

Qué llevar a la primera conversación

Si quieres que alguien te diga qué supone adaptar tu TPV, el presupuesto será mucho más fiable si llevas esto:

• Qué es el programa y quién lo hizo. Tecnología, año aproximado, y si tienes el código.
• Cuántos puntos de venta y terminales. Y si alguno trabaja sin conexión.
• Cómo se imprime el ticket. Modelo de impresora y quién mantiene la plantilla.
• Si ya usas el SII. Cambia completamente la respuesta.
• Tu forma jurídica. Sociedad o autónomo decide la fecha que te aplica.
• Qué opina tu asesor fiscal sobre la modalidad. Es una decisión técnica y fiscal a la vez.

Preguntas frecuentes

¿Tengo que cambiar mi TPV por VERI*FACTU? Casi nunca hace falta cambiarlo entero. Hay que añadirle el registro de facturación encadenado con huella, el QR en el ticket, el envío a la AEAT o la firma y el registro de eventos, y una declaración responsable. Cambiar compensa cuando nadie tiene el código o el programa permite alterar tickets por todas partes.

¿Desde cuándo es obligatorio VERI*FACTU? Según el Real Decreto 1007/2023, en la redacción que le dio el Real Decreto-ley 15/2025, las sociedades deben tener los sistemas adaptados antes del 1 de enero de 2027 y el resto de obligados, antes del 1 de julio de 2027. Conviene comprobarlo en la sede de la AEAT antes de planificar, porque las fechas ya se han movido dos veces.

Si el TPV es un desarrollo propio, ¿quién firma la declaración responsable? El productor del sistema. La AEAT aclara que un software de desarrollo propio, aunque solo lo use la empresa que lo hizo, necesita igualmente esa certificación. Si te lo desarrolló un proveedor, hay que acordar con él quién figura como productor.

¿Es obligatorio enviar las facturas a Hacienda? Es una de las dos modalidades. Con VERI*FACTU el sistema envía cada registro a la AEAT y queda dispensado de firmarlos. En la modalidad sin envío, los registros se firman electrónicamente, se lleva un registro de eventos y se entregan a la AEAT cuando los pida.

¿Puedo usar un servicio externo como Fiskaly en lugar de programarlo todo? Sí. Hay proveedores que ofrecen el registro, la huella y el envío a la AEAT por API. Te ahorran la parte normativa y sus cambios, pero la integración con el TPV, la gestión de fallos de conexión y la declaración responsable de tu parte siguen siendo trabajo tuyo.

Si quieres que lo miremos

Llevamos desde 2012 trabajando sobre sistemas que ya están en marcha, y ahora mismo estamos adaptando a VERI*FACTU nuestro propio sistema de facturación. Cuéntanos cómo es el tuyo y te decimos si conviene adaptarlo, envolverlo o cambiarlo, con la fecha que te aplica encima de la mesa.

Escríbenos y lo vemos. Y si lo que buscas es directamente quién lo haga, aquí tienes nuestro servicio de desarrollo de software a medida.