#La respuesta corta
Si tu software genera tickets o facturas para comercios y hostelería — un TPV, un vertical SaaS de restauración, un sistema de reservas con cobro — Verifactu es un requisito de tu producto, no solo de tus clientes. Cada ticket debe salir de un sistema con registros inalterables, hash encadenado, código QR verificable y capacidad de remitir los registros a la AEAT; el fabricante debe firmar una declaración responsable de cumplimiento, y las sanciones por comercializar software no conforme llegan a 150.000 € por ejercicio. Tus clientes están obligados desde el 1 de enero de 2027 (sociedades) y el 1 de julio de 2027 (autónomos) — y te van a pedir el cumplimiento mucho antes.
La decisión de producto es una: construir el motor de facturación Verifactu tú mismo o integrarlo por API. Esta guía cubre lo que exige la norma, lo que tu vertical concreto necesita y cómo se resuelve con una integración.
#El reparto de papeles: quién es quién con un TPV
Antes de diseñar nada, conviene tener claro qué componente queda dentro del perímetro de Verifactu:
| Componente | Qué hace | ¿Le afecta Verifactu? |
|---|---|---|
| Datáfono / pasarela de pago | Procesa el cobro con tarjeta | NO (cobrar no es facturar) |
| Tu software TPV / vertical SaaS | Genera tickets y facturas | SÍ — es el sistema informático de facturación (SIF) |
| Hardware (pantalla, impresora, cajón) | Imprime y muestra lo que el software le manda | NO (el requisito es del software) |
| Comandas, albaranes, documentos internos | Flujo interno (cocina, traspasos) | NO (solo los documentos entregados al cliente) |
Regla de oro
El datáfono cobra; tu software factura. Verifactu regula al sistema que genera el ticket o la factura — es decir, a tu producto. El hardware de tus clientes puede quedarse; lo que tiene que cumplir es tu código.
#Qué exige Verifactu al software que emite tickets
El Real Decreto 1007/2023 (RRSIF) y la Orden HAC/1177/2024 definen los requisitos del sistema informático de facturación. Traducidos a backlog:
1Registros inalterables
Cada ticket genera un registro de facturación que no se puede modificar ni borrar. Un error no se corrige editando: se emite una factura rectificativa o un registro de anulación vinculado.
En tu producto: olvídate del UPDATE sobre facturas emitidas. El modelo de datos es append-only.
2Encadenamiento por hash (SHA-256)
Cada registro incluye la huella del anterior, formando una cadena verificable. Si falta un eslabón o se altera, se detecta.
En tu producto: el encadenamiento es por emisor y debe sobrevivir a concurrencia, reintentos y caídas. Es de lo más delicado de implementar bien.
3Código QR en todos los tickets
Todos los documentos entregados al cliente — incluido el café de 1,20 € — llevan un QR que permite verificar la operación contra la AEAT. No vale un QR a tu web o a tu app.
4Remisión a la AEAT (o firma electrónica)
En modalidad VERI*FACTU, los registros se remiten automáticamente a la AEAT. En modalidad no-VERI*FACTU, no se envían, pero el sistema debe firmar electrónicamente cada registro y cumplir requisitos adicionales de trazabilidad y registro de eventos.
En tu producto: la modalidad de envío automático es, en la práctica, la más simple de implementar y la que menos superficie de requisitos deja de tu lado.
5Conservación y declaración responsable
Los registros se conservan al menos 4 años y deben poder exportarse en formato legible. Y tú, como fabricante, firmas una declaración responsable de que tu sistema cumple el RRSIF — con tu nombre y tu responsabilidad.
#Las fechas (y por qué la tuya ya pasó)
129 julio 2025 — fabricantes de software
Desde esta fecha, el software de facturación que se comercializa debe estar adaptado al RRSIF. Si vendes un TPV o un vertical SaaS con facturación, esta era tu fecha — ya es exigible.
21 enero 2027 — sociedades
Tus clientes con forma societaria (la mayoría de restaurantes organizados, cadenas, franquicias) están obligados a usar sistemas conformes.
31 julio 2027 — autónomos
El resto de tus clientes: el bar, la peluquería, la frutería. La cola larga de tu mercado.
Implicación comercial: durante 2026, “¿cumplís Verifactu?” se convierte en pregunta de checklist en cada venta y cada renovación. Los comercios ya están preguntando a sus proveedores por la declaración responsable. No tenerla es perder deals; tenerla antes que tu competencia es un argumento de venta.
#Sanciones: el fabricante arriesga más que el comercio
El régimen sancionador del RRSIF tiene dos niveles, y el más alto es el tuyo:
Sanciones del RRSIF
- Fabricante/comercializador de software no conforme: hasta 150.000 € por ejercicio y tipo de infracción
- Usuario (el comercio) de software no conforme: hasta 50.000 € por ejercicio
Además del riesgo directo, está el derivado: si tu software expone a multas a tus clientes, el daño contractual y reputacional en un mercado vertical — donde todos los hosteleros de una zona se conocen — es difícil de revertir. Detalle completo en multas y sanciones Verifactu.
#Construir vs integrar: la decisión real
Cumplir Verifactu desde cero implica: encadenamiento criptográfico correcto bajo concurrencia, generación del QR conforme a la especificación, cliente SOAP contra la API de la AEAT con sus reintentos y flujos de subsanación, gestión de rectificativas y anulaciones, conservación y exportación de registros, y mantenimiento normativo continuo (la especificación técnica evoluciona). Es un subsistema completo que no diferencia a tu producto: tu valor está en las comandas, el stock, las reservas o las colas — no en el XML de la AEAT.
La alternativa es delegar la emisión en una API de facturación certificada y tratar Verifactu como infraestructura:
| Construirlo tú | Integrar una API (ej. BeeL.) | |
|---|---|---|
| Tiempo hasta cumplir | Meses de desarrollo + pruebas con la AEAT | Días: una integración REST |
| Declaración responsable | La firmas tú, con su responsabilidad | La emisión recae en el sistema certificado |
| Mantenimiento normativo | Tuyo, para siempre | Del proveedor |
| Riesgo de sanción de fabricante | Directo (hasta 150.000 €) | Drásticamente acotado |
| Coste | Equipo + opportunity cost | Desde 15,90 €/mes (equivalente anual) por cuenta emisora |
#Cómo se integra en un TPV o vertical SaaS
Con la API de BeeL., el flujo de un ticket queda así:
curl -X POST https://app.beel.es/api/v1/invoices \
-H "Authorization: Bearer $BEEL_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"type": "SIMPLIFIED",
"lines": [
{ "description": "Menú del día", "quantity": 2, "unit_price": 12.50 }
]
}'- Tickets: la factura
SIMPLIFIEDcubre la venta sin identificar al cliente (hasta 400 €, o 3.000 € en los sectores autorizados como comercio minorista y hostelería). La respuesta incluye el QR (qr_url,qr_base64) listo para imprimir en el ticket. - Factura completa: cuando el cliente de tu cliente pide “factura con NIF”, emites tipo
STANDARDcon sus datos — mismo endpoint. - Devoluciones: una llamada a
POST /v1/invoices/{invoice_id}/correctivegenera la rectificativa vinculada y registrada. - Multi-tenant: cada comercio que usa tu vertical SaaS es un emisor con sus datos fiscales y sus series; el encadenamiento y el envío a la AEAT los gestiona BeeL. por cada uno.
- Eventos: los webhooks te avisan del ciclo de vida de cada factura para sincronizar tu base de datos.
Todo el desarrollo se hace contra el sandbox gratuito (claves beel_sk_test_): API completa, sin envíos reales a la AEAT y sin límite de facturas de prueba. La guía técnica de arranque está en implementar Verifactu en tu software.
El pitch para tu roadmap
Verifactu por API convierte un proyecto de meses con riesgo regulatorio en una integración REST de días — y “cumplimos Verifactu” pasa a ser una línea de tu página de precios en 2026, no un agujero en tu backlog de 2027.
#Casuística por vertical: lo que tu software debe resolver
#🍕 Restauración y bares
- Volumen alto y ráfagas: cientos de tickets en horas punta; la emisión no puede bloquear la línea de caja.
- Offline: la norma contempla sistemas que registran localmente y remiten al recuperar la conexión. Diseña una cola local de emisión con reintentos idempotentes.
- Comandas fuera del perímetro: los tickets de cocina no llevan QR; el ticket del cliente, siempre.
- Delivery: si tu vertical integra agregadores, define qué sistema emite la factura de cada canal para no duplicar.
#🛒 Comercio minorista (incl. venta por peso)
- La integración balanza-TPV no es obligatoria, pero el ticket final que sale de tu software sí debe ser conforme.
- Devoluciones de artículos = rectificativas parciales vinculadas, no “tickets negativos” sueltos.
#💇 Servicios (peluquería, estética, clínicas)
- Volumen bajo, mezcla de servicios y productos, y más peticiones de factura completa: tu UI debe permitir convertir el ticket en factura con NIF sin fricción.
#🌐 E-commerce y TPV virtual
- Si tu plataforma genera facturas de pedidos online, es un SIF igualmente. Si los cobros van por Stripe, valora el conector Stripe + Verifactu, que emite la factura de cada pago sin código, o la API si necesitas control fino. Guía: cómo facturar automáticamente desde Stripe en España.
#Checklist para el fabricante de TPV / vertical SaaS
- ✗Mapea qué documentos de tu producto entrega el cliente final (esos requieren Verifactu)
- ✗Decide: motor propio de facturación o integración por API
- ✗Modelo de datos append-only: emitidas no se editan, se rectifican
- ✗QR verificable en todos los tickets y facturas impresos o digitales
- ✗Cola de emisión offline con reintentos idempotentes (hostelería)
- ✗Flujo ticket simplificado → factura completa con NIF
- ✗Rectificativas y anulaciones vinculadas a la original
- ✗Multi-tenant: series y encadenamiento por comercio emisor
- ✗Prueba el ciclo completo en sandbox antes de tocar producción
- ✗Prepara la respuesta a '¿tenéis declaración responsable?' para tus comerciales
#Preguntas frecuentes
Mi producto es un SaaS de gestión que 'también' hace tickets. ¿Me afecta igual que a un TPV puro?
Sí. El criterio no es cómo se llama tu producto sino si genera facturas o tickets: cualquier sistema informático de facturación entra en el RRSIF, sea un TPV táctil, un SaaS de reservas con cobro o un módulo de caja dentro de un ERP vertical.
¿El datáfono o la impresora de tickets necesitan homologación?
No. El datáfono solo procesa pagos y la impresora imprime lo que tu software le envía. El requisito recae íntegramente en el software que genera el documento. Tus clientes conservan su hardware.
Si integro una API de facturación, ¿quién firma la declaración responsable?
La declaración responsable corresponde al sistema que produce los registros de facturación. Si delegas la emisión completa en una plataforma certificada como BeeL. (tu software llama a la API y la plataforma genera el registro, el hash, el QR y la remisión a la AEAT), el grueso del cumplimiento técnico recae en ella. Documenta en tu arquitectura qué componente emite: es lo primero que se revisa.
¿Qué pasa si se cae internet en plena hora punta?
La normativa contempla la operación con remisión diferida: tu TPV registra localmente, entrega el ticket y remite los registros al recuperar conexión. Diseña la cola local con idempotencia para que los reintentos no dupliquen facturas.
¿Los tickets de 2€ también llevan QR?
Sí. Todos los documentos de venta entregados al cliente llevan QR verificable, sin importe mínimo. Los documentos internos (comandas, albaranes de traspaso) quedan fuera.
¿Puedo seguir vendiendo mi TPV mientras lo adapto?
La obligación de comercializar solo software adaptado rige para fabricantes desde el 29 de julio de 2025. Cada mes de retraso es riesgo sancionador (hasta 150.000 € por ejercicio) y desgaste comercial: tus prospects ya preguntan por Verifactu. Si el desarrollo propio no llega, la integración por API es el atajo realista — días, no meses.
¿Verifactu y la factura electrónica B2B (Ley Crea y Crece) son lo mismo?
No. Verifactu (RD 1007/2023) regula cómo se generan y registran las facturas; la factura electrónica B2B (Ley Crea y Crece) regulará el intercambio electrónico de facturas entre empresas cuando su reglamento esté desplegado. Tu producto acabará necesitando ambas; Verifactu es la urgente.
¿Y si mi cliente final me pregunta si su TPV antiguo cumple?
Las cajas registradoras antiguas que no generan registros digitales trazables no cumplen por sí solas. La respuesta de producto: tu software conforme + su hardware existente (pantalla, impresora, cajón), que en general puede conservarse.
#Conclusión
Verifactu redefine qué significa “hacer un TPV” en España: el ticket deja de ser un papel y pasa a ser un registro criptográfico remitido a Hacienda. Para quien construye software de comercio y hostelería, eso es una amenaza (sanciones de fabricante, deals perdidos) o una ventaja competitiva (cumplimiento como feature), según lo pronto que se resuelva.
No hace falta construir el motor fiscal: la API de BeeL. pone la emisión conforme — tickets simplificados con QR, facturas completas, rectificativas, multi-emisor y envío a la AEAT — detrás de una integración REST, con sandbox gratuito para desarrollar desde hoy y producción desde 15,90 €/mes (equivalente anual). Empieza por la guía técnica: implementar Verifactu en tu software.
Última actualización: junio 2026. Este artículo se revisa cuando hay cambios normativos.