Conectar tu sistema a la API de Verifactu
La parte difícil no es enviar el registro. Es que la facturación siga funcionando cuando el envío falla, que la cadena de huellas no se rompa con varios puntos de emisión y que alguien pueda ver el estado sin abrir la base de datos.
Esta página describe la arquitectura de la integración. La especificación técnica —campos, formato y condiciones del servicio— está en Orden HAC/1177/2024 y en la documentación técnica de la AEAT , que es la fuente que seguimos.
Qué hay que construir, capa por capa
Cada capa lleva asociada la trampa que hemos visto romper implementaciones reales.
Generación del registro
El registro de alta se crea en el mismo acto de emisión de la factura, no después. La regla que rompe más implementaciones: no puede existir una factura emitida sin su registro asociado. Un proceso nocturno que recorre la tabla de facturas y genera registros a posteriori no cumple.
Dónde se rompe: Si tu sistema permite emitir por varias vías (módulo de ventas, TPV, API de terceros), cada vía necesita pasar por el mismo punto de generación.
Cadena de huellas
Cada registro incorpora la huella del anterior. El cálculo es determinista y el eslabón se almacena: un hueco en la cadena es detectable y no se puede rellenar más tarde. Antes de escribir código hay que decidir la estrategia de series, porque la cadena se define por serie y punto de emisión.
Dónde se rompe: Varias cajas facturando en paralelo contra una única cadena es una condición de carrera esperando a ocurrir. La decisión de series es de arquitectura, no de configuración.
Envío a la AEAT
En modalidad VERI*FACTU los registros se remiten de forma inmediata. «Inmediata» no significa síncrona dentro de la transacción de venta: significa que el registro sale en cuanto está disponible, a través de una cola con reintento espaciado, idempotencia por registro y control de estado individual.
Dónde se rompe: Un envío síncrono acoplado a la emisión convierte cualquier incidencia de la AEAT o de tu conexión en una caída de tu facturación. Es el error de diseño más caro de los que vemos.
Estado y reconciliación
Cada registro necesita un estado observable —pendiente, enviado, aceptado, rechazado— y un panel donde alguien de administración pueda ver qué falta sin abrir la base de datos. Los rechazos hay que reconciliarlos, no reintentarlos a ciegas.
Dónde se rompe: Reintentar un registro rechazado por contenido, en vez de corregirlo, genera ruido indefinido contra la AEAT y esconde el problema real.
QR y mención en la factura
El QR verificable y la mención «VERI*FACTU» o «Factura verificable» tienen que aparecer en todas las plantillas de salida: PDF, impresión térmica de TPV, email y portal de cliente. Cada plantilla es un punto de fallo distinto.
Dónde se rompe: El ticket de 58 mm de una impresora térmica es donde más veces se rompe el QR: entra, pero deja de ser legible.
Registro inalterable y exportación
La evidencia se guarda en almacenamiento append-only, separado de las tablas que el ERP edita a diario, con retención y exportación en formato legible por la Administración.
Dónde se rompe: Un registro que vive en la misma tabla que tu aplicación actualiza no es inalterable, por mucho que nadie lo toque en la práctica.
Las cuatro decisiones que hay que tomar antes
Ninguna se resuelve leyendo el reglamento: dependen de cómo factura tu empresa.
¿VERI*FACTU o sistema no verificable?
La modalidad VERI*FACTU remite en el momento y, a cambio, te ahorra las exigencias locales de firma electrónica, registro de eventos, verificación de integridad y gestión de alarmas. El sistema no verificable te libera de la remisión inmediata pero te carga todo eso. Se decide por conectividad real de tus puntos de emisión, no por preferencia.
¿Dónde vive el conector?
Como módulo dentro de tu sistema, o como servicio externo al que tu sistema llama. La segunda opción aísla el cumplimiento de tus despliegues y facilita el mantenimiento normativo, pero exige que tu sistema tenga un punto de enganche fiable.
¿Qué vía de integración expone tu sistema?
API, webhooks, eventos o acceso a base de datos, por ese orden de preferencia. Si tu ERP es una caja negra sin ningún punto de enganche, la conversación cambia y hay que valorar otras opciones. Eso se resuelve en la auditoría, antes de comprometer alcance.
¿Quién firma la declaración responsable?
La emite el productor del sistema informático. Si tu software es propio o a medida para uso interno, ese productor eres tú: la responsabilidad de certificar la conformidad se queda de tu lado. Nosotros construimos el sistema y documentamos la conformidad; la firma es tuya.
Casi nunca es solo Verifactu
Cuando abrimos un sistema de facturación para acoplarle el conector, aparece el resto: el ERP que no habla con el e-commerce, el TPV que exporta a mano, el CRM que vive aparte. El proyecto de cumplimiento suele ser la primera vez que alguien mapea de verdad cómo se mueven los datos.
Cómo integramos y automatizamos sistemas →Preguntas frecuentes
¿Existe una API pública de Verifactu? +
La AEAT publica el servicio de remisión de los registros de facturación junto con su especificación técnica. El formato de los registros, el detalle de los campos y las condiciones del servicio están en la orden de desarrollo (Orden HAC/1177/2024) y en la documentación técnica de la sede electrónica, que es la fuente que hay que seguir: cualquier resumen de terceros —este incluido— envejece con cada actualización.
¿Puedo integrar Verifactu sin cambiar de software de facturación? +
Sí, y es exactamente el trabajo que hacemos. El conector se acopla a tu sistema actual: no lo sustituye, lo hace conforme. Lo que decide la viabilidad no es la marca del ERP sino si expone una vía de integración razonable.
¿Qué pasa si la AEAT no responde o se cae la conexión? +
La facturación no puede pararse por eso. El diseño correcto encola los registros, reintenta con espaciado creciente y los envía cuando el servicio se restablece, manteniendo el estado de cada uno. Por eso el envío nunca debe ir acoplado a la transacción de venta.
¿Se puede probar antes de ir a producción? +
El plan de pruebas es parte del proyecto: se valida la generación de registros, la integridad de la cadena, el comportamiento ante caídas y la casuística de anulaciones y rectificativas antes de tocar producción. El entorno concreto y sus condiciones se toman de la documentación técnica vigente de la AEAT.
¿Cuánto tarda una integración por API? +
Entre cuatro y siete semanas contando la auditoría del sistema, según el número de puntos de emisión y la complejidad de series y rectificativas. Lo que alarga los proyectos casi nunca es el envío: son las anulaciones, las rectificativas y los flujos de venta que nadie documentó.
Cuéntanos cómo factura tu sistema
Empezamos por la auditoría: puntos de emisión, series, rectificativas y dónde vive hoy cada dato. De ahí sale el alcance cerrado y la modalidad recomendada.
Información técnica sobre implementación de sistemas. No constituye asesoramiento fiscal ni jurídico. La calificación de tu caso concreto y la interpretación del régimen sancionador corresponden a tu asesoría.