Si facturas con Stripe, no basta con guardar la factura en PDF. Yo tendría listo un archivo que una XML firmados, PDF con QR, respuestas de la AEAT, logs del sistema y los IDs de Stripe de cada cobro, factura, abono o rectificación.
En pocas palabras, esto es lo que dejaría atado desde el día 1:
- Qué guardar: XML de alta, anulación y rectificativa; PDF conforme; acuses de AEAT en VERI*FACTU; y registro de eventos.
- Cómo ordenarlo: carpetas por año, mes, serie y número, con estados como pendiente, aceptado, aceptado-con-errores y rechazado.
- Cómo enlazarlo con Stripe: guardar
invoice.id,payment_intent.id,charge.id,customer.id,credit_note.id,refund.idy, si aplica,subscription.id. - Qué revisar: numeración sin huecos, cadena SHA-256, QR, NIF, base imponible y firma.
- Cuánto tiempo conservarlo: 4 años por criterio fiscal y 6 años por criterio mercantil.
- Cómo protegerlo: copias diarias en dos ubicaciones y acceso por roles.
Hay una diferencia que cambia todo: en VERI*FACTU el registro se remite a la AEAT en tiempo real (similar al funcionamiento del conector Stripe TicketBai); en NO VERI*FACTU yo debo custodiar los XML firmados con su cadena hash intacta. Ese punto marca cómo archivo, cómo valido y cómo respondo ante una revisión.
Si quiero encontrar un expediente en segundos, necesito que cada registro se pueda buscar por factura, pago, cliente, serie y número o ID VeriFactu. Y si Stripe genera un abono o una anulación, el enlace con la factura original debe quedar guardado en ambos lados.
Mi idea base sería simple: un archivo fiscal ordenado, trazable y exportable en ZIP, con todo lo que pide una comprobación sin tener que reconstruir nada a mano después.
Archivo VeriFactu con Stripe: Estructura, Metadatos y Trazabilidad
2. Estructura de carpetas para XML firmados, PDFs, registros y mensajes de la AEAT
Una vez tengas claro qué documentos debes conservar, toca decidir dónde guardarlos y cómo nombrarlos para que una inspección no se convierta en una búsqueda eterna. Lo más sensato es separarlo desde el primer día por tipo de archivo.
2.1 Carpetas principales recomendadas
La estructura base para un archivo Stripe-VeriFactu separa cuatro tipos de contenido en carpetas independientes:
| Ruta | Contenido | Para qué sirve |
|---|---|---|
/verifactu/records/xml/ | XML firmados enviados a la AEAT | Archivo fiscal del alta |
/verifactu/invoices/pdf/ | PDFs con el QR obligatorio y el texto «VeriFactu» | Copia para el cliente |
/verifactu/logs/ | Registros de eventos: accesos, errores y actualizaciones | Trazabilidad del sistema |
/verifactu/aeat/ | Mensajes de envío y respuesta de la AEAT | Prueba de envío y respuesta |
Esta separación hace que localizar un expediente por factura, pago o cliente sea mucho más simple. Además, ayuda cuando toca revisar, filtrar o exportar documentación.
Con las carpetas ya divididas, el siguiente paso es dar a cada expediente una ruta y un nombre que no dejen lugar a dudas.
2.2 Convenciones de nombre y anidado por año, serie y estado
Dentro de cada carpeta principal, usa la estructura AAAA/MM/Serie/Número/. Este orden cronológico viene muy bien para detectar huecos en la secuencia numérica, algo que importa porque la numeración debe ser correlativa y sin saltos. También conviene que la ruta coincida con el identificador interno del registro, para que apunte de forma directa a la capa de metadatos.
Para los nombres de archivo, un patrón como SERIE-NUMERO_FECHA_NIF-RECEPTOR.pdf permite reconocer el documento sin tener que abrir la base de datos. Es de esas cosas que parecen pequeñas, pero cuando buscas una factura concreta entre cientos o miles de archivos, se nota.
Dentro de cada serie, mantén subcarpetas de estado:
/pendiente//aceptado//aceptado-con-errores//rechazado/
Así, el sistema puede mover cada registro desde /pendiente/ a /aceptado/ en cuanto llegue la respuesta de la AEAT. Y de ese modo, cada expediente queda listo para exportarse sin perder la trazabilidad.
2.3 Exportaciones ZIP y copias de seguridad periódicas
Para una inspección, prepara archivos ZIP que incluyan el XML, el PDF y la respuesta de la AEAT de cada factura. La exportación no sirve solo para “sacar una copia”. Sirve para conservar y mover un expediente completo sin romper el hilo documental.
Establece copias periódicas en dos ubicaciones distintas. Antes de exportar, valida estos datos: NIF, base imponible, QR y hash. Si falta uno solo, el paquete queda incompleto y puede no ser válido ante la AEAT.
Con la estructura ya fijada, el siguiente paso es unir cada expediente con los IDs de Stripe mediante un conector Stripe Verifactu y con sus datos fiscales.
sbb-itb-b01fb3c
3. Modelo de metadatos que vincula los registros VeriFactu con facturas, pagos y clientes de Stripe
Con la estructura de carpetas ya cerrada, aparece un problema menos visible, pero igual de serio: saber si el XML que tienes delante corresponde exactamente a ese pago de Stripe y a ese cliente. Ahí entra el modelo de metadatos. Sin ese modelo, el archivo acaba siendo un conjunto de ficheros sueltos, sin un nexo claro entre ellos.
3.1 Campos fiscales y de trazabilidad obligatorios
Cuando los ficheros ya están ordenados por tipo y fecha, cada expediente necesita metadatos comunes para poder localizarlo y comprobarlo. Cada registro debe incluir emisor, receptor, serie, número, fecha e impuestos. La trazabilidad, por su parte, se apoya en la huella SHA-256, el hash previo y la marca de tiempo en formato ISO 8601.
Los campos de trazabilidad obligatorios son:
- Huella SHA-256 del registro actual
- Huella SHA-256 del registro inmediatamente anterior
- Identificador del sistema emisor
- Fecha y hora en ISO 8601
3.2 Identificadores de Stripe que hay que guardar en cada registro
El archivo debe recoger los identificadores del objeto de Stripe que dio origen al registro. Así puedes unir el registro con la operación de Stripe sin dar rodeos.
| Campo de metadatos | Origen en Stripe | Función en el archivo |
|---|---|---|
stripe_invoice_id | invoice.id | Enlace principal con la factura |
payment_intent_id | payment_intent.id | Vincula el registro con la transacción |
charge_id | charge.id | Referencia al cargo concreto |
customer_id | customer.id | Permite buscar todos los registros de un cliente |
credit_note_id / refund_id | credit_note.id / refund.id | Trazabilidad de rectificativas y abonos |
subscription_id | subscription.id | Útil en facturación recurrente |
Con estos IDs guardados, ya puedes pasar al siguiente paso: enlazar devoluciones y rectificativas con el registro original.
3.3 Enlace bidireccional entre Stripe y el archivo
Guarda en los campos metadata de la factura de Stripe el identificador VeriFactu, el estado de envío a la AEAT y la URL del PDF con el QR obligatorio. El Stripe Verifactu Connector automatiza este proceso y mantiene el vínculo al día en ambos sentidos.
Con ese enlace guardado por las dos partes, la siguiente sección aplica las reglas de cadena y búsqueda.
4. Reglas de trazabilidad para facturas, abonos y documentos rectificativos
Con los metadatos bien enlazados, el siguiente paso es dejar el archivo listo para una revisión de principio a fin. La idea es simple: que una revisión interna o una inspección pueda seguir la secuencia de registros sin huecos ni choques entre datos. A partir de esos metadatos, toca encadenar cambios y ubicar cada expediente sin margen de duda.
4.1 Cadena de hashes y referencias al registro anterior
Cada registro debe guardar su propia huella SHA-256, la del registro anterior y la referencia a la serie, el número y la fecha del registro previo. También debe conservar la marca temporal exacta del registro: día, hora, minuto y segundo. Esta cadena sirve para detectar cambios o borrados durante una auditoría y, además, hace más fácil localizar el expediente por factura, pago o cliente.
Si el hash recalculado no coincide con el almacenado, el registro no es válido. Así de claro. Con la cadena cerrada, ya se puede pasar a separar bien abonos, anulaciones y rectificativas.
4.2 Enlace entre abonos, rectificativas y el registro original
Cuando Stripe genera un abono o una anulación, crea el documento fiscal que toque y enlázalo con la factura original. La secuencia siempre sigue el mismo orden: factura original → abono o anulación → documento rectificativo → enlace explícito al registro original con serie, número, fecha y huella.
Para que luego no toque rebuscar, guarda el invoice_id de Stripe y el identificador del registro original junto con la huella VeriFactu y el estado AEAT. Conviene guardar ese vínculo en ambos sentidos, tanto en los metadatos del archivo como en Stripe. Un flujo automatizado con webhooks ayuda a generar el XML y el PDF rectificativos sin intervención manual. Para lograr esta automatización, se puede emplear la API de itcons.app para el intercambio de datos.
4.3 Búsqueda por factura, pago o cliente
Un archivo bien montado permite localizar cualquier expediente desde varios puntos de entrada. Esta tabla muestra qué se puede recuperar según el criterio de búsqueda:
| Criterio de búsqueda | Elementos recuperados del archivo |
|---|---|
stripe_invoice_id | XML firmado, PDF con QR, respuesta de la AEAT, log de eventos |
payment_intent_id / charge_id | Factura original y rectificativa asociada, si existe |
customer_id / NIF | Historial fiscal del cliente |
| Serie + número | XML firmado, posición en la cadena de hashes, hash anterior y posterior |
| ID de registro VeriFactu | Estado de verificación en la AEAT, marca temporal de envío |
Guarda el NIF legal junto al customer_id. Con esa trazabilidad cerrada, el siguiente paso es validar exportaciones, firmas y copias de seguridad.
5. Exportación, verificación y lista de comprobación final
Con la trazabilidad ya cerrada, queda la última parte: mantener el archivo sano con el paso del tiempo. Exportar, verificar y controlar accesos no es algo que se haga una vez y ya está. Conviene tratarlo como una rutina y, si puedes, dejarlo automatizado desde el primer día. Puedes ver cómo funciona en esta demo del conector Stripe–VeriFactu.
5.1 Comprobaciones periódicas de archivos y firmas
Con el archivo ya trazado, toca revisarlo y conservar su integridad.
Cada envío a la AEAT debe figurar como aceptado. Si no lo está, el sistema tiene que reintentar el envío de forma automática y marcar ese registro con una incidencia.
También conviene programar revisiones automáticas semanales para comprobar tres cosas: que no haya saltos en la numeración, que la cadena de hashes SHA-256 siga intacta y que el PDF mantenga el formato legal correcto.
Si el sistema genera firma electrónica, revisa además que esa firma siga siendo verificable. Parece un detalle menor, pero no lo es: una firma que no se puede validar deja el expediente cojo.
5.2 Copias de seguridad y control de acceso
Las copias de seguridad deben hacerse cada día y mantenerse en dos copias, en ubicaciones físicas y proveedores distintos.
En cuanto al acceso, aplica un modelo por roles. Dicho de forma simple: solo el responsable fiscal o el asesor autorizado deberían poder consultar o exportar los registros. Para proteger la integridad y la confidencialidad, restringe también el acceso a los certificados digitales y conserva el log de eventos junto con las copias.
Sobre los plazos de conservación, hay dos referencias que no conviene perder de vista:
- 4 años según la Ley General Tributaria
- 6 años según el Código de Comercio
5.3 Primeros pasos para poner en marcha el archivo
Antes de emitir la primera factura, deja fijadas estas cinco reglas operativas:
- Estructura de carpetas estable: usa la jerarquía ya definida de año, mes, serie y número, y mantenla coherente para recuperar cualquier expediente con rapidez.
- Metadatos obligatorios desde el primer registro: desde el primer registro, guarda los metadatos fiscales y de trazabilidad obligatorios.
- Vinculación con identificadores de Stripe: cada registro debe incluir
stripe_invoice_idypayment_intent_id. - Cadena de hashes activa: no incorpores ningún registro sin la huella anterior; si falla la cadena, no incorpores el registro al archivo.
- Índice maestro exportable en una base de datos externa: enlaza IDs, archivos y estado AEAT.
El Stripe VeriFactu Connector automatiza captura, firma, envío y PDF con QR sin tocar el flujo de Stripe.
FAQs
¿Qué diferencia práctica hay entre VERIFACTU y NO VERIFACTU al archivar registros?
La diferencia principal está en quién se hace cargo de la conservación y la trazabilidad frente a la AEAT.
En VERI*FACTU, los registros se envían de forma automática, segura e inmediata a la sede electrónica.
En NO VERI*FACTU, ese envío no se hace en línea. Por eso, el empresario debe guardar los registros y poder acreditar ante una inspección su integridad, legibilidad y trazabilidad inalterable.
¿Qué pasa si falta un ID de Stripe o se rompe la cadena hash?
Si falta un ID de Stripe o se rompe la cadena hash, se pierde la integridad y la trazabilidad que exige VeriFactu. Y ahí empieza el problema.
Los registros deben ser inalterables. No puede haber omisiones ni cambios posteriores. Si falta una pieza, aunque parezca pequeña, el registro deja de cumplir lo que pide la norma.
Además, cualquier fallo en la secuencia o la ausencia de datos ligados al cobro impide generar el código QR reglamentario y cumplir con la remisión a la AEAT.
¿Cómo recupero rápido una rectificativa vinculada a una factura original?
Accede a la ficha de la factura original desde tu panel de Stripe. Desde ahí podrás ver qué factura se ha modificado y encontrar su rectificativa gracias a la estructura de datos que conecta ambos registros.
En esa misma ficha también puedes revisar el estado de la comunicación con la Agencia Tributaria, comprobar el código VeriFactu y descargar el PDF con el código QR.
