Doc. Ref. 32268 Título: Estructura de carpetas de Verifactu Autor: Philippe Calvó Última actualización: 27/07/2026 #blockchain #verifactu #registro #facturas #comunicacion #hacienda #AEAT

---

Carpetas y archivos de VeriFactu

Guía técnica para el mantenimiento de Hexa SGN
Librería mdiago/VeriFactu · 10 de noviembre de 2026

La carpeta de trabajo contiene el estado persistente de la librería: la cadena de registros, los registros fiscales conservados y, cuando hay comunicaciones, las solicitudes y respuestas de la AEAT. Sus archivos cumplen funciones distintas y deben conservarse de forma coherente.

Ubicación y organización

La ubicación habitual en Windows es C:\ProgramData\VeriFactu. Las rutas se pueden personalizar mediante la configuración. Los ejemplos siguientes usan el NIF ficticio B12345678 y el año 2026.

• Blockchains
  • Función principal: Persistencia del encadenamiento de registros fiscales.
  • Archivos habituales: CSV de control y archivos mensuales.
• Invoices
  • Función principal: Conservación de cada registro fiscal de alta o anulación.
  • Archivos habituales: XML del registro individual.
• Outbox
  • Función principal: Archivo de las solicitudes de comunicación.
  • Archivos habituales: XML del mensaje SOAP enviado.
• Inbox
  • Función principal: Archivo de las respuestas recibidas.
  • Archivos habituales: XML con la respuesta de la AEAT.

El año de la carpeta no siempre es el ejercicio de la factura

Invoices utiliza el año de expedición de la factura. Inbox y Outbox utilizan el año de generación del registro. Blockchains se separa por NIF y por archivos mensuales yyyyMM; en el código consultado no añade una subcarpeta anual. Una factura expedida en diciembre y registrada en enero puede quedar repartida entre años distintos según la carpeta.

Alcance: se describe la operativa de InvoiceEntry.Save() y de las anulaciones en el código público consultado. Los envíos por lotes, otras operaciones y distintas versiones pueden introducir variantes de nombres. No se ha inspeccionado la instalación de Hexa ni una copia concreta de sus carpetas.

Blockchains

Contiene la información necesaria para enlazar cada nuevo registro con el anterior del mismo emisor y mantener su secuencia. No es una carpeta de facturas completas ni una cadena distribuida externa: es la persistencia local del encadenamiento por huellas.

• _B12345678.csv: Estado del último eslabón. Permite recuperar la posición y los datos del último registro al volver a iniciar la librería.
• 202611.csv: Histórico de eslabones generados en noviembre de 2026. Cada fila identifica un registro y permite relacionarlo con su huella y su factura.
• 202611.PREV.csv: Copia interna del archivo mensual anterior a una inserción. Se utiliza en la lógica de reversión; puede no existir según la configuración y el estado de la cadena.

Los CSV usan punto y coma como separador. El archivo de estado guarda el identificador secuencial, la marca temporal, la huella, la fecha de expedición, el NIF del emisor y el número o serie de factura. El archivo mensual añade la cadena de entrada utilizada para calcular la huella, entre corchetes.

El conjunto de archivos mensuales conserva el historial de la cadena. Un archivo PREV no es una copia de seguridad completa ni un archivo que deba restaurarse manualmente como procedimiento ordinario.

Invoices

Ruta habitual: Invoices\B12345678\2026\{identificador codificado}.xml. El año procede de InvoiceDate, es decir, de la fecha de expedición.

Cada XML contiene un registro fiscal individual de alta o anulación: identificación de la factura, importes y datos tributarios aplicables, identificación del sistema, fecha y hora de generación, huella y encadenamiento. No equivale al PDF de la factura ni necesariamente contiene todas las líneas comerciales de Hexa.

El nombre se obtiene codificando InvoiceID en hexadecimal; no es la huella del registro ni su número secuencial. En una anulación se codifica InvoiceID seguido de .DEL, para distinguirla del alta. En NO VERI*FACTU, el XML se conserva con la firma electrónica generada por la librería.

Utilidad: conservar el registro original, comprobar su correspondencia con la cadena y permitir su exportación o remisión posterior. La propiedad entrada.InvoiceFilePath proporciona la ruta concreta; es preferible usarla antes que reconstruir el nombre en Hexa.

Outbox

Ruta habitual del envío individual: Outbox\B12345678\2026\00000000000000000001.xml.

Contiene el XML de la solicitud SOAP preparada para la AEAT, con su cabecera y el registro de facturación incluido en el mensaje. A diferencia de Invoices, documenta la comunicación, no solo el registro fiscal aislado.

En la operativa individual, el nombre normal es InvoiceEntryID: el identificador del eslabón expresado con 20 dígitos y completado con ceros a la izquierda. El año es el de FechaHoraHusoGenRegistro. La propiedad entrada.InvoiceEntryFilePath devuelve esta ruta.

Utilidad: revisar qué datos se comunicaron, comparar el envío con la respuesta y diagnosticar rechazos. No debe interpretarse como una cola de archivos pendientes: en el código consultado, esta copia se escribe durante el procesamiento de la respuesta. La mera existencia del archivo no acredita aceptación.

Inbox

Ruta habitual del envío individual: Inbox\B12345678\2026\00000000000000000001.xml.

Contiene la respuesta de la AEAT: el estado del envío y de sus registros, los códigos y descripciones de error y, cuando corresponda, el código seguro de verificación CSV y otros datos de recepción. También puede recoger respuestas de error del servicio.

En la operativa individual utiliza el mismo InvoiceEntryID que Outbox. Así pueden correlacionarse la solicitud y su respuesta. La propiedad entrada.ResponseFilePath devuelve la ruta prevista.

Utilidad: acreditar y revisar el resultado de la comunicación, identificar advertencias o rechazos y conservar la respuesta original. Para decidir si una operación ha sido aceptada hay que leer la respuesta o las propiedades de resultado; no basta con comprobar que existe un XML.

Archivos marcados como error

Pueden aparecer nombres del tipo {identificador}.ERR.{fecha y hora}.xml. La librería utiliza esta nomenclatura al archivar determinadas operaciones fallidas o rechazadas y durante sus procesos de reversión. Se pueden encontrar tanto en las carpetas de comunicación como en Invoices.

Su contenido permite investigar el intento, pero no debe tratarse automáticamente como un registro aceptado o vigente. El sufijo exacto y los archivos afectados dependen del punto de fallo y de la versión. No hay que renombrarlos ni reinsertarlos manualmente en la cadena.

Relación entre los archivos

En un alta individual ordinaria, Save() incorpora el registro a la cadena y conserva su XML en Invoices. En VERI*FACTU realiza además la comunicación; al procesar la respuesta archiva la solicitud en Outbox y la respuesta en Inbox. Según el resultado, puede marcar archivos como error y ejecutar la lógica de reversión.

Para seguir una operación, Hexa puede registrar conjuntamente el NIF del emisor, la identificación de la factura, InvoiceEntryID, Registro.Huella y las rutas de los archivos. El identificador secuencial pertenece a la cadena del emisor; no es un identificador global ni el CSV de la AEAT.

Diferencias en NO VERI FACTU

En NO VERI*FACTU, Save() firma y conserva localmente el registro sin realizar el envío ordinario. Por ello, Invoices y Blockchains siguen siendo necesarios, mientras que esa operación no genera el par habitual de comunicación en Inbox y Outbox. Las carpetas pueden existir vacías o contener comunicaciones anteriores.

Las versiones que soportan esta modalidad también gestionan EventChains y Events: la primera conserva la cadena independiente de eventos y la segunda sus XML firmados. Estas carpetas forman parte del estado que debe conservarse, aunque no estén entre las cuatro carpetas iniciales de la instalación.

Conservación y copias de seguridad

Debe incluirse todo el directorio de trabajo de la librería en una copia coherente, junto con la base de datos de Hexa y su configuración. No basta con copiar Blockchains: la cadena y los XML conservados se complementan. Se recomienda realizar las copias con la actividad detenida o mediante un mecanismo que mantenga la coherencia del conjunto.

No deben borrarse, editarse ni reconstruirse manualmente los archivos para corregir una factura. Tampoco debe restaurarse solo una carpeta o solo la base de datos sin valorar la correspondencia con los demás componentes. Los registros originales de NO VERI*FACTU deben conservar su firma, sin regenerarse ni firmarse de nuevo para exportarlos.

Settings.xml contiene la configuración de rutas y del sistema. Si existen Log, Events u otras carpetas gestionadas por la versión instalada, conviene incluirlas también. Las copias internas PREV no sustituyen las copias de seguridad externas.

Fuentes y versión de referencia

Revisión del código público mdiago/VeriFactu, rama main, commit 494196f. Archivos principales: Common/Chain.cs; Blockchain/Blockchain.cs; Business/Operations/InvoiceActionData.cs, InvoiceActionMessage.cs e InvoiceActionPost.cs; Business/InvoiceCancellation.cs. Referencia consultada el 10 de noviembre de 2026.

Repositorio: https://github.com/mdiago/VeriFactu
Documentación: https://github.com/mdiago/VeriFactu/wiki

Volver a la búsqueda anterior