Informe técnico de cumplimiento
Input Creativity SL · VeriFactu para AppVanza CRM
Input Creativity SL · VeriFactu para AppVanza CRM
Versiones y declaraciones responsables del producto
Productor del software: Input Creativity SL · NIF B18978924 · Cuesta de Rodrigo del Campo 37, 18009 Granada (España) · clientes@inputcreativos.es · 652295585
Sistema informático: «VeriFactu para AppVanza CRM» · identificador de sistema
VF· versión 1.7.2 (15 de septiembre de 2026)
Declaración responsable del productor: la correspondiente a la versión 1.7.2, firmada electrónicamente el 15 de septiembre de 2026 a las 19:22 (certificado cualificado de representación de
24228788J MIGUEL ANGEL GARCIA, R: B18978924 · INPUT CREATIVITY SL) conforme al modelo oficial de la AEAT V0.5.1 (secciones 1.a–1.l y anexo 2.a–2.c), e incorporada al propio sistema con su histórico por versión:ResponsibleDeclaration/y https://appvanza.com/verifactu.php#declaraciones
Instalación de referencia de este informe: nº 1 — INPUT CREATIVITY SL (NIF B18978924), CRM InPut Creativity
Normativa de referencia: artículo 29.2.j) de la Ley 58/2003, Real Decreto 1007/2023 y Orden HAC/1177/2024
Este documento describe qué exige la normativa española a un sistema informático de facturación y cómo lo cumple el sistema «VeriFactu para AppVanza CRM» en su versión 1.7.2. No es un manual de usuario ni una relación de pruebas: es un informe técnico de cumplimiento que pone en relación cada requisito normativo con la implementación concreta del sistema y con el punto donde puede comprobarse. Su finalidad es servir de soporte documental del cumplimiento ante quien deba valorarlo (el propio obligado tributario, su asesoría, o la Administración en un requerimiento), y complementa a los dos documentos que la norma exige al productor: la declaración responsable y el registro interno de instalaciones.
Este informe refleja el estado del sistema en la versión indicada. Cualquier cambio en la generación, la firma, el encadenamiento, la conservación o la remisión de los registros da lugar a una versión nueva del sistema y a una nueva declaración responsable firmada por el productor.
La revisión del código de la versión 1.7 (capítulo 6.3) detectó cinco desviaciones respecto de lo que exigen la normativa y la declaración responsable. Las cinco se han corregido en la versión 1.7.2, que es la que describe este informe: el formato y el alcance de la firma electrónica (art. 14 de la Orden), la versión declarada en los registros de evento, la leyenda exigida en la factura (art. 6.5 del RD 1619/2012) y la exportación a soporte externo de los registros conservados (art. 8.2 de la Orden). El detalle de cada corrección, con su verificación, está en el capítulo 7.1. Los requisitos del capítulo 4 se han verificado sobre el código y sobre el funcionamiento del sistema, y las comprobaciones funcionales del capítulo 6 se han superado. En la fecha de emisión de este informe no consta ninguna no conformidad abierta; se mantienen las limitaciones declaradas del capítulo 7.2, que acotan el alcance (por ejemplo, las facturas simplificadas y determinados regímenes especiales, previstos para la versión 2.0).
| Norma | Qué establece | Preceptos que se citan en este informe |
|---|---|---|
| Ley 58/2003, General Tributaria (LGT) | Obligación de que los sistemas y programas informáticos que soporten los procesos de facturación garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, «sin interpolaciones, omisiones o alteraciones de las que no quede la debida anotación» | Art. 29.2.j) (obligación); art. 201 bis (régimen sancionador) |
| Real Decreto 1007/2023, de 5 de diciembre (Reglamento VeriFactu) | Requisitos y características que deben adoptar los sistemas informáticos de facturación, contenido y estandarización de los registros, huella y firma, declaración responsable del productor y remisión a la AEAT | Art. 8 (requisitos del sistema y registro de eventos); arts. 9 a 11 (generación y contenido de los registros de alta y de anulación); art. 12 (huella y firma de los registros); art. 13 (declaración responsable del productor); art. 14 (verificación por la AEAT); arts. 15 y 16 (remisión y modalidad VERI*FACTU); art. 17 (remisión por el receptor) |
| Orden HAC/1177/2024, de 17 de octubre | Especificaciones técnicas, funcionales y de contenido: capacidad de remisión y certificados, integridad y trazabilidad, conservación, registros de eventos, huella, firma electrónica, declaración responsable, plazos técnicos de remisión, QR y contenido de los registros | Arts. 1 y 2 (definiciones y varios obligados); arts. 4 y 5 (capacidad de remisión y autenticación con certificado electrónico); art. 6 (integridad e inalterabilidad); art. 7 (trazabilidad y encadenamiento); art. 8 (conservación y puesta a disposición); art. 9 (registro de eventos); arts. 10 y 11 (contenido de los registros); art. 13 (huella); art. 14 (firma electrónica); art. 15 (declaración responsable); art. 16 (remisión y plazos técnicos); arts. 17 y 18 (inicio, renuncia y requerimientos); arts. 20 y 21 (código QR) |
| Real Decreto 1619/2012, de 30 de noviembre | Reglamento de obligaciones de facturación: contenido de la factura, factura simplificada y factura rectificativa, y la incorporación del código QR y de la leyenda en la factura | Arts. 6 y 7 (contenido de la factura y simplificada, con el QR y la leyenda según la disposición final primera del RD 1007/2023); art. 15 (facturas rectificativas); art. 19.1 (plazo de conservación) |
| Real Decreto-ley 15/2025 | Aplazamiento de las fechas de obligación de uso de los sistemas informáticos de facturación | Disposición final primera, que da nueva redacción a la disposición final cuarta del RD 1007/2023 |
| Especificaciones técnicas de la sede electrónica de la AEAT | Documentos técnicos que completan la Orden: estructuras y validaciones de los registros, algoritmo de la huella (a este documento se remite el art. 13 de la Orden), validación del código QR, descripción del servicio web de remisión y del servicio de validación de la modalidad sin remisión | Sede electrónica de la AEAT (documentos de huella, QR, servicio web y validación) |
Los códigos de tipo de factura (F1, F2, F3 y R1 a R5) no provienen del Reglamento de facturación, sino de la lista de valores L2 del anexo de la Orden HAC/1177/2024, cuyas descripciones remiten a su vez al RD 1619/2012 y a la Ley del IVA.
| Obligado | Fecha de obligación | Base legal |
|---|---|---|
| Sujetos pasivos del Impuesto sobre Sociedades (art. 3.1.a del Reglamento) | 1 de enero de 2027 | Disposición final cuarta del RD 1007/2023, en la redacción dada por el RDL 15/2025 |
| Resto de obligados (autónomos, profesionales y entidades no sujetas a ese impuesto) | 1 de julio de 2027 | Ídem |
| Modalidad | Características | Uso |
|---|---|---|
| VERI*FACTU | El sistema remite a la AEAT todos los registros de facturación de forma continuada, segura, íntegra, automática, consecutiva, instantánea y fehaciente. En esta modalidad no se exige firma electrónica: la huella encadenada es suficiente (art. 16.3 del Reglamento) | Modalidad normal de funcionamiento del sistema |
| No VeriFactu («no VERI*FACTU») | El sistema no remite: genera los registros, los firma electrónicamente (art. 12 del Reglamento), los encadena y los conserva a disposición de la AEAT, que puede requerirlos (art. 14.2). El cambio de modalidad se documenta con los eventos de inicio y fin (art. 9.1 de la Orden) | Modalidad alternativa, configurable por el obligado |
El sistema es un módulo de facturación («plugin») que se instala en la misma infraestructura que el CRM del obligado tributario (modelo on-premise): framework CodeIgniter 4 sobre PHP, con base de datos del propio CRM. No es un servicio en la nube: los registros, los ficheros firmados y el certificado electrónico residen en el servidor del obligado.
| Componente | Función |
|---|---|
| Generador de registros | Construye el registro de alta, de anulación o de rectificación a partir de la factura del CRM, con sus bloques y campos según las especificaciones de la AEAT |
| Calculador de huella | Calcula la huella (hash) encadenada de cada registro |
| Firmador | Firma electrónicamente cada registro con el certificado del obligado |
| Gestor de certificados | Carga, valida y custodia el certificado electrónico (P12/PFX) y su contraseña cifrada |
| Generador de QR | Compone y estampa el código QR en el documento de la factura |
| Servicio de eventos | Genera, firma y conserva los registros de eventos del sistema |
| Cliente de remisión | Envía los registros a la AEAT por el servicio habilitado y procesa su respuesta |
| Cola de trabajo | Encola y reintenta los envíos pendientes mediante la tarea programada (cron) del servidor |
| Guarda de inalterabilidad | Impide modificar o eliminar facturas y líneas ya registradas |
| Conservación | Guarda los JSON firmados, los eventos y los documentos, y los expone para su descarga y entrega |
| Panel de control | Superficie de configuración, seguimiento y avisos del usuario |
| Paso | Qué ocurre | Dónde se ve |
|---|---|---|
| 1 | El usuario emite la factura en el CRM (pasa de borrador a emitida) | CRM |
| 2 | El sistema genera el registro de alta con los datos fiscales de la factura y el desglose del impuesto | — |
| 3 | Añade la huella encadenada con el registro anterior y firma el registro | — |
| 4 | Conserva el JSON firmado y lo envía a la AEAT; si el envío no se puede completar, el registro queda en cola | VeriFactu → Registros |
| 5 | La AEAT responde con el resultado, que queda anotado en el registro | VeriFactu → Registros |
| 6 | El documento de la factura incorpora el QR y la factura queda bloqueada frente a ediciones y borrados | PDF de la factura |
Una misma instalación puede dar servicio a varios obligados tributarios: cada empresa tiene su propia configuración (certificado, modalidad, número de serie de instalación) y su propia cadena de huellas, y los registros se separan y se remiten por empresa. El sistema declara esta capacidad en el punto 1.f de la declaración responsable.
Cada requisito se relaciona con la implementación del sistema y con el punto donde puede comprobarse. Las referencias de fichero corresponden a la versión 1.7.2.
| Requisito | Cómo lo cumple el sistema | Dónde se comprueba |
|---|---|---|
| Inalterabilidad de los registros ya generados | El sistema bloquea la modificación y el borrado de una factura emitida —incluidas sus líneas— y su eliminación: solo admite corregirla mediante anulación o rectificativa, que generan registros nuevos | Al intentar editar o borrar una factura registrada (aviso en pantalla); manual §4.4 |
| Integridad de la cadena | Cada registro incorpora la huella del registro anterior, de modo que cualquier alteración de un registro intermedio rompe la cadena y es detectable | JSON firmado de cada registro; panel de integridad |
| Trazabilidad | Cada registro conserva su huella, su firma, su estado, la respuesta de la AEAT y su marca temporal; el sistema mantiene además un registro de eventos y un registro de actividad | VeriFactu → Registros · VeriFactu → Eventos |
| Conservación | Los registros y sus JSON firmados se conservan en el almacenamiento del obligado, junto con los eventos, sin depender de la AEAT | Descarga del JSON desde el panel |
| Accesibilidad y legibilidad | Los registros se conservan en formato estructurado (JSON/XML firmado), legibles y descargables uno a uno, y se pueden entregar a requerimiento de la AEAT | VeriFactu → Registros |
| Detección de manipulaciones externas | Si una factura con registro desapareciera por una vía ajena al sistema (por ejemplo, borrado directo en base de datos o importación), el sistema deja constancia: aviso en el registro de actividad, registro de evento de anomalía y aviso destacado en la configuración | Configuración → aviso de registros huérfanos |
| Continuidad de la cadena | Si un registro no pudiera prepararse (por ejemplo, JSON ilegible que no se puede reconstruir), el sistema lo marca como descartado, con su motivo, queda fuera de la cola de envío y la cadena continúa encadenándose al último registro válido; el registro puede reintentarse desde el panel | VeriFactu → Registros (estado «Descartado · revisar» y acción «Reintentar») |
| Requisito | Cómo lo cumple el sistema |
|---|---|
| Un registro por cada factura expedida | El registro de alta se genera de forma automática e inmediata al emitir la factura en el CRM, sin intervención manual |
| Identificación de la factura | El registro incorpora el NIF del emisor, el número de serie y la fecha de expedición de la factura |
| Identificación del destinatario | Se incorporan los datos del destinatario (NIF y nombre) cuando la factura los requiere; el sistema valida el formato del NIF antes de registrar |
| Tipo de factura | Se determina y se refleja en el registro: factura ordinaria y facturas rectificativas (por diferencias o por sustitución), con la referencia a la factura rectificada |
| Desglose del impuesto | El desglose se calcula línea a línea (base, tipo impositivo y cuota) y se agrupa por tipo de IVA cuando una factura combina varios tipos; las operaciones sin IVA (por ejemplo, exportaciones) se registran como exentas con su causa |
| Importes | El sistema calcula y conserva la base, la cuota y el importe total, y garantiza que el total del registro coincida con el que muestran el CRM, el documento de la factura y el QR |
| Retención por IRPF | Se calcula y figura en la factura del CRM, pero no forma parte del registro remitido: el sistema no lo incluye como cuota del registro |
| Datos del sistema informático | Todo registro incorpora el bloque identificativo del sistema (nombre, identificador, versión, número de instalación, productor y NIF del productor) |
| Facturas rectificativas | El abono se prepara en borrador, se ajusta y, al emitirse, el sistema cuadra sus totales (base, descuento, cuota y retención) a partir de las líneas definitivas y genera un único registro de rectificativa: por sustitución si el abono cubre el total, por diferencias si es parcial, con indicación de la factura rectificada y de los importes de la rectificación |
| Anulación | La anulación de una factura genera su registro de anulación, encadenado, firmado y remitido; la factura original conserva su número y su registro |
| Clases de factura | El sistema cubre la factura ordinaria y las rectificativas (RD 1619/2012). Las facturas simplificadas y determinados regímenes especiales quedan fuera del alcance de la versión 1.7.2 (capítulo 7.2) |
| Requisito | Cómo lo cumple el sistema |
|---|---|
| Algoritmo | Huella calculada con SHA-256, en hexadecimal y mayúsculas, sobre la cadena de campos que establece la especificación de la AEAT |
| Composición de la huella | La cadena se construye con el formato nombreCampo=valor&nombreCampo=valor… y, en este orden: IDEmisorFactura, NumSerieFactura, FechaExpedicionFactura, TipoFactura, CuotaTotal, ImporteTotal, Huella (del registro anterior) y FechaHoraHusoGenRegistro. En los registros de anulación la cadena es la propia de la anulación: IDEmisorFacturaAnulada, NumSerieFacturaAnulada, FechaExpedicionFacturaAnulada, Huella y FechaHoraHusoGenRegistro |
| Huella de los registros de evento | Los eventos tienen su propia composición, con los campos del sistema informático (NIF, identificador, versión y número de instalación), el NIF del obligado, el tipo de evento, la huella del evento anterior y la marca temporal del evento |
| Encadenamiento | Cada huella incorpora la huella del registro anterior, formando una cadena por obligado tributario. El registro que inicia la cadena se identifica expresamente como primero (PrimerRegistro) y los siguientes incorporan el bloque de encadenamiento con el emisor, el número, la fecha y la huella del registro anterior |
| Encadenamiento de eventos | Los eventos se encadenan entre sí de forma análoga, con su propio marcador de primer evento |
| Trazabilidad de la cadena | La huella y su encadenamiento se conservan en el JSON firmado de cada registro, de modo que la cadena puede reconstruirse y verificarse |
| Independencia por obligado y por entorno | La cadena es propia de cada empresa; el cambio del entorno de pruebas al de producción reinicia la cadena, ya que la AEAT de producción no conoce los registros de preproducción |
| Requisito | Cómo lo cumple el sistema |
|---|---|
| Firma de cada registro | Cada registro de facturación y cada registro de evento se firma electrónicamente con el certificado cualificado del obligado tributario, y el nodo de firma se almacena en el propio registro (RegistroAlta/Signature, RegistroAnulacion/Signature y RegistroEvento/Evento/Signature), conforme al §6 del documento de firma de la AEAT |
| Formato de la firma | XAdES Enveloped Signature (estándar ETSI EN 319 132), con las propiedades firmadas de XAdES —hora de firma y certificado de firma— y la política de firma de la Administración General del Estado (OID urn:oid:2.16.724.1.3.1.1.2.1.9), tal como exige el art. 14 de la Orden HAC/1177/2024 y detalla el documento técnico de la AEAT |
| Alcance de la firma | La firma se calcula sobre el XML completo del registro (nodos RegistroAlta, RegistroAnulacion o RegistroEvento; nunca sobre los nodos superiores), con transformación enveloped y canonicalización C14N inclusiva, resumen SHA-256 y firma RSA-SHA256: cualquier alteración del contenido del registro invalida la firma, y un tercero puede verificarla con el certificado incorporado en ella |
| Verificación | Comprobado con la batería de verificación del productor y con una implementación independiente de XMLDSig (capítulo 6.3): la firma del registro se valida y la misma firma falla si se modifica un solo dato del registro |
| Momento de la firma | La firma se genera al procesar el registro (inmediatamente después de emitir la factura) y se recalcula en el momento del envío, porque la marca temporal forma parte de la huella; el JSON conservado corresponde a esa última versión firmada |
| Custodia del certificado | El certificado se carga en la configuración del módulo, se valida (vigencia y titular) y su contraseña se guarda cifrada; el sistema muestra la fecha de caducidad |
| Conservación de la firma | El JSON firmado se conserva y es descargable desde el panel |
| Requisito | Cómo lo cumple el sistema |
|---|---|
| Eventos generados | El sistema genera el inicio y el fin de la modalidad sin remisión (al cambiar de modalidad) y las anomalías detectadas; el resumen de la actividad de registro se genera con la periodicidad prevista |
| Periodicidad (aviso) | El resumen periódico y la detección de anomalías se ejecutan desde la tarea programada de línea de comandos del módulo: conviene asegurarse de que esa tarea está programada, además del cron del CRM (capítulo 7.2) |
| Otros tipos de evento | Las especificaciones contemplan también eventos de restauración y de exportación de registros. La versión 1.7.2 genera el de exportación cada vez que se utiliza esa función (capítulo 4.10) y no genera el de restauración, porque no incorpora procedimientos de restauración que deban documentarse con un evento |
| Contenido del evento | Cada evento identifica el sistema informático (nombre, identificador, versión y número de instalación), el obligado tributario, el tipo de evento y su marca temporal, y se le aplica su propia huella encadenada |
| Firma y conservación | Los eventos se firman y se conservan igual que los registros de facturación, y quedan accesibles en el panel |
| Remisión | En la modalidad VERIFACTU los eventos se remiten a la AEAT; en la modalidad no VERIFACTU se conservan sin remitir |
| Anomalías | Se genera un evento de anomalía cuando se detecta una situación anómala (por ejemplo, la desaparición de una factura que tenía registro) |
| Requisito | Cómo lo cumple el sistema |
|---|---|
| QR en las facturas emitidas | El documento de la factura incorpora el código QR con la URL de validación y los parámetros exigidos |
| Parámetros del QR | nif (NIF del emisor normalizado, sin espacios ni guiones), numserie (número de serie de la factura, con el límite de caracteres de la especificación), fecha (fecha de expedición) e importe (importe total con dos decimales) |
| URL según la modalidad | La URL de validación es la que corresponde a la modalidad en uso: ValidarQR cuando los registros se remiten (VERI*FACTU) y ValidarQRNoVerifactu en la modalidad sin remisión; el sistema selecciona además el dominio de preproducción o el de producción según el entorno configurado |
| Trazabilidad del QR con el registro | El importe y los datos que codifica el QR proceden del propio registro, de modo que la validación en la sede de la AEAT se refiere a la factura efectivamente registrada |
| Leyenda obligatoria de la factura | La factura incorpora, junto al código QR, la frase «Factura verificable en la sede electrónica de la AEAT» cuando el sistema remite todos los registros (modalidad VERI*FACTU) y no la incorpora cuando opera en la modalidad sin remisión, conforme al art. 6.5 del Reglamento de facturación (redacción de la disposición final primera del RD 1007/2023) |
| Especificación del QR | El código se genera conforme a la especificación (ISO/IEC 18004, nivel de corrección M) y se estampa con un ancho de 40 mm sobre el papel, dentro del rango de 30 a 40 mm previsto; en la factura electrónica, el QR se acompaña de la URL de cotejo |
| Requisito | Cómo lo cumple el sistema |
|---|---|
| Remisión automática | El registro se envía a la AEAT al emitirse la factura, sin intervención del usuario, por el servicio de remisión de registros de facturación habilitado al efecto |
| Autenticación | La conexión se establece con autenticación mutua TLS mediante el certificado electrónico cualificado del obligado tributario (de sello o de representación, según el certificado cargado), contra los servicios de producción o de preproducción según el entorno configurado |
| Agrupación y orden | Los registros se envían en lotes por empresa, respetando el orden de la cadena de huellas |
| Reintentos | Si el envío no se completa (red, indisponibilidad de la AEAT, tiempo de espera), el registro queda en cola y la tarea programada del servidor lo reintenta periódicamente |
| Resultado de la AEAT | El resultado de cada registro (correcto, aceptado con errores, incorrecto o pendiente) queda registrado, con el código y la descripción de los avisos o errores devueltos |
| Subsanación | Los errores detectados se muestran al usuario con su descripción; el sistema permite corregir la causa y volver a emitir el registro, sin alterar los registros ya aceptados |
| Duplicados | El sistema mantiene un registro local de los números de factura ya aceptados por la AEAT y avisa (sin bloquear la emisión) si se intenta remitir de nuevo el mismo número y fecha, para evitar el rechazo por duplicado |
| Consulta | El usuario puede consultar a la AEAT las facturas registradas de un periodo, con su estado y fecha de presentación |
| Registros no remitidos | Ningún registro de la modalidad no VERIFACTU entra en la cola de remisión, ni siquiera si el obligado vuelve después a la modalidad VERIFACTU |
| Plazos técnicos de remisión | La remisión es inmediata (no hay plazo por registro): el sistema respeta el tiempo de espera que indica la AEAT entre envíos, agrupa como máximo 1.000 registros por envío y, ante una incidencia, reintenta con la tarea programada y remite lo pendiente en orden temporal |
| Requisito | Cómo lo cumple el sistema |
|---|---|
| Generación y firma | Los registros de facturación y de evento se generan, se firman y se encadenan en la misma forma que en la modalidad con remisión |
| No remisión | Los registros de esa etapa no se remiten a la AEAT en ningún momento, tampoco con posterioridad: quedan excluidos de la cola de envío |
| Conservación a disposición de la AEAT | Los registros y eventos se conservan firmados y son accesibles y descargables para su entrega a requerimiento de la AEAT |
| Constancia del cambio de modalidad | El cambio de modalidad queda documentado con los eventos de inicio y de fin correspondientes |
| Inalterabilidad | Las facturas emitidas en esta modalidad están sujetas a la misma obligación de inalterabilidad que las demás |
| QR | Las facturas de esta etapa incorporan el QR específico de la modalidad sin remisión |
| Requisito | Cómo lo cumple el sistema |
|---|---|
| Identificación del sistema | Nombre, identificador del sistema informático, versión, número de instalación y datos del productor viajan en todos los registros, en el bloque del sistema informático |
| Versión única y coherente | La versión del sistema se define en un único punto del programa, y es la misma que viaja en todos los registros —de facturación y de evento—, la que muestra el panel y la que se declara en la declaración responsable |
| Declaración responsable | El productor firma electrónicamente la declaración responsable de cada versión (modelo oficial de la AEAT) y la incorpora al propio programa; el sistema avisa si la declaración publicada no cubre la versión instalada |
| Histórico de declaraciones | El sistema conserva el histórico de declaraciones responsables por versión, con su fecha de suscripción, el firmante y el SHA-256 del documento, accesible desde el panel |
| Registro de instalaciones | El productor asigna a cada despliegue un número de instalación y mantiene el registro interno instalación ↔ titular a disposición de la AEAT (el modelo oficial de declaración no incluye ese número) |
| Entrega al cliente | El obligado tributario recibe su número de instalación y la declaración responsable de la versión instalada; no ha de presentar ninguna declaración ni realizar trámite alguno ante la AEAT por este concepto |
| Requisito | Cómo lo cumple el sistema |
|---|---|
| Exportación de todos los registros de un periodo | El sistema incorpora una función de exportación por periodo que genera un archivo con los registros de facturación de ese periodo (y, opcionalmente, los registros de evento) |
| Copia fidedigna | Cada registro se incluye tal y como se conserva —el mismo fichero JSON firmado, sin recomponerlo ni transformarlo—, acompañado de un manifiesto que identifica cada registro (empresa, tipo, número, fecha, evento, huella y estado) y contiene su resumen criptográfico (SHA-256), de modo que la copia puede comprobarse íntegramente |
| Independencia de las copias de seguridad | La exportación es una función del propio sistema, independiente de la política de copias de seguridad del CRM (art. 8.2 de la Orden) |
| Documentación de la exportación | Cada exportación genera su registro de evento de exportación, firmado y conservado como los demás (art. 9.1 de la Orden) |
| Puesta a disposición de la AEAT | Los registros y los eventos conservados se pueden consultar de forma inmediata desde el panel y entregar a la AEAT en su formato firmado ante un requerimiento (art. 14.2 del Reglamento) |
El diseño del sistema busca que el obligado tributario no tenga que ocuparse del cumplimiento en su día a día: la norma se aplica en segundo plano y el sistema avisa cuando hace falta una decisión.
| Paso | Qué se hace | Ayuda del sistema |
|---|---|---|
| 1 | Empresa: la configuración es por empresa; se elige el obligado tributario que se está configurando | Cada empresa mantiene su certificado, su modalidad, su cadena de huellas y su cola de envío |
| 2 | Certificado electrónico: se carga el certificado de la empresa (P12/PFX) y su contraseña | El sistema valida el certificado (vigencia y titular), cifra la contraseña y muestra la fecha de caducidad |
| 3 | Número de instalación: se introduce el que asigna el productor | No hay trámite ante la AEAT: lo asigna Input Creativity SL y el productor conserva el registro instalación ↔ titular |
| 4 | Entorno: pruebas (preproducción) o producción | La primera vez que se pasa a producción el sistema pide confirmación explícita y advierte de que la cadena de huellas empieza de cero |
| 5 | Modalidad: VeriFactu o No VeriFactu | La modalidad se puede cambiar; el sistema registra el cambio con sus eventos, sin intervención manual |
| 6 | Alta del producto: código de compra y activación | El sistema muestra el número de instalación, el plan, la validez y el titular de la licencia |
| 7 | Tarea programada del servidor | El cron del CRM procesa la cola de envío y los reintentos; el funcionamiento diario no requiere atención |
| — | Datos del productor (nombre, NIF, nombre del sistema, identificador y versión) | Vienen rellenos de origen y no deben modificarse: son los que viajan en los registros y coinciden con la declaración responsable |
| — | Datos de preproducción | Tarjeta para limpiar los datos de prueba antes de pasar a producción, con las garantías descritas en el capítulo 5.2 |
| Aviso o comprobación | Problema que evita |
|---|---|
| Validación del certificado y fecha de caducidad | Que se cargue un certificado válido y en vigor; el sistema muestra su fecha de caducidad (el aviso automático previo a la caducidad figura entre las mejoras previstas, capítulo 7.2) |
| Validación del NIF del destinatario | Rechazos de la AEAT por datos identificativos incorrectos |
| Aviso de número ya enviado | El rechazo por duplicado: la AEAT no olvida los números recibidos |
| Aviso de versión nueva | Que el obligado no se entere de que hay una versión publicada más reciente, con su enlace de descarga y su SHA-256 |
| Aviso si la declaración responsable no cubre la versión instalada | Una discrepancia entre el software instalado y la declaración publicada |
| Bloqueo de edición y borrado con mensaje explicativo | La pérdida de integridad de una factura ya registrada, guiando hacia la anulación o el abono |
| Estado y motivo de cada registro | Que un error de la AEAT pase inadvertido: se muestra el código y la descripción devueltos |
| Tarjetas de integridad (registros descartados y huérfanos) | Situaciones que requieren revisión, con acción de reintento donde procede |
| Limpieza guiada de datos de preproducción | Que datos de prueba se mezclen con la facturación real; la limpieza respeta los registros de producción y las facturas ajenas al sistema |
| Pantalla | Para qué sirve |
|---|---|
| Configuración | Certificado, entorno, modalidad, número de instalación, datos del productor, estado de la suscripción y tarjetas de aviso (integridad, números ya enviados, versión) |
| Registros | Una fila por registro, con su tipo (factura, rectificativa, anulación), su estado, la respuesta de la AEAT y el JSON firmado descargable |
| Eventos | Histórico de los registros de eventos del sistema, firmados |
| Consulta AEAT | Facturas registradas en la AEAT de un periodo, con estado y fecha de presentación |
| Declaraciones | Histórico de declaraciones responsables por versión, con fecha de suscripción, firmante y SHA-256 |
El sistema se entrega con manual de usuario (configuración, emisión, anulaciones y abonos, modo No VeriFactu, solución de problemas y registro de cambios) y con soporte del productor (clientes@inputcreativos.es · 652295585), que es también quien asigna el número de instalación y mantiene la declaración responsable por versión.
La verificación funcional se ha realizado contra el entorno de preproducción de la AEAT, con el certificado electrónico del obligado tributario de la instalación nº 1 y su número de instalación. Los registros de preproducción no tienen efectos fiscales y se limpian antes del paso a producción.
| Comprobación | Resultado |
|---|---|
| Alta de factura con remisión: registro, encadenamiento, firma y envío | La AEAT responde correcto; el QR de la factura valida en la sede |
| Rectificativa por diferencias (abono parcial): un único registro para la operación | Registro de rectificativa correcto, con QR propio e importes coincidentes entre el CRM, el documento, el QR y el registro remitido |
| Modalidad no VERI*FACTU: registros y eventos generados, firmados, encadenados y no remitidos | Eventos de inicio y fin de la modalidad; los registros de esa etapa quedan conservados y no se remiten; el retorno a VERI*FACTU no los remite |
| Consulta a la AEAT de las facturas registradas de un periodo | Se obtienen los registros presentados, con estado y fecha de presentación |
| Inalterabilidad: intento de modificar o eliminar una factura registrada y de borrar sus líneas | La edición y el borrado quedan bloqueados con aviso al usuario en los tres casos |
| Continuidad de la cadena ante un registro no preparable | El registro se marca como descartado con su motivo, no se remite y la cadena continúa con el último registro válido; el registro puede reintentarse |
| Separación por obligado tributario en la cola de remisión | La cola y las consultas se filtran por empresa: cada obligado remite sus propios registros |
La implementación se acompaña de una batería interna de verificación ejecutable sobre el propio sistema (no se distribuye con el módulo): comprobaciones de la cadena y de la huella, de la modalidad sin remisión y de la cola por empresa, del cálculo y cuadre de los importes de las rectificativas, de la inalterabilidad y de la detección de anomalías, del registro de números ya enviados, del aviso de versión, del histórico de declaraciones y de la coherencia del manual con la versión declarada. Estas comprobaciones se ejecutan antes de empaquetar cada versión del sistema. A esa verificación se añade una revisión del código de la versión, requisito a requisito. La revisión realizada el 14 de septiembre de 2026 es la que permitió localizar las cinco desviaciones que se declaran —ya corregidas— en el capítulo 7.1. Verificación de la firma electrónica. Además de la batería propia, la firma de los registros se ha verificado con una implementación independiente de XMLDSig, ajena al código del sistema: valida la firma del registro y rechaza ese mismo registro en cuanto se modifica cualquiera de sus datos. Esa comprobación —que la firma cubra realmente el contenido— es la que acredita el requisito del art. 14 de la Orden HAC/1177/2024.
Durante la verificación se detectó que, en versiones anteriores a la 1.7, la modalidad no VERI*FACTU podía llegar a remitir los registros de esa etapa, contra lo que exige la norma. La incidencia se detectó en el entorno de preproducción, no afectó a ninguna factura real (el sistema no ha estado en explotación en producción) y quedó corregida en la versión 1.7 y se mantiene en la 1.7.2 objeto de este informe, en la que los registros de esa etapa quedan marcados como conservados, excluidos de la cola de envío y no se remiten en ningún caso, extremo cubierto por la verificación automatizada.
La revisión de código realizada el 14 de septiembre de 2026 (capítulo 6.3) detectó cinco desviaciones respecto de lo que exigen la normativa y la propia declaración responsable del productor. Se declaran aquí de forma expresa porque afectaron a versiones anteriores y quedan corregidas en la versión 1.7.2, objeto de este informe:
| No conformidad (versiones anteriores a la 1.7.2) | Detalle técnico | Corrección aplicada en la 1.7.2 | Cómo se ha verificado |
|---|---|---|---|
| 1. Alcance de la firma electrónica | El resumen (digest) se calculaba sobre un documento auxiliar que no contenía el registro: la firma existía y viajaba con el registro, pero no acreditaba su contenido | La firma se calcula sobre el XML completo del registro, con transformación enveloped y canonicalización C14N | Se recalcula el digest desde los artefactos finales y se verifica la firma; al modificar un solo dato del registro, la verificación falla |
| 2. Formato de la firma electrónica | Se generaba una firma XMLDSig sin las propiedades cualificadas que exige el art. 14 de la Orden HAC/1177/2024 | Firma XAdES Enveloped (ETSI EN 319 132) con propiedades firmadas (hora de firma y certificado) y política de firma de la AGE | Estructura comprobada (SignedProperties, SigningCertificate, IssuerSerial, política, formato del objeto) y firma validada con una implementación independiente de XMLDSig |
| 3. Versión declarada en los registros de evento | Los registros de evento declaraban la versión 1.5, fijada en el código, y ese valor forma parte además de la huella del evento | La versión se lee de la fuente única del sistema, igual que en los registros de facturación | Comprobado sobre el evento que construye el propio módulo: declara la versión 1.7.2 |
| 4. Leyenda de la factura | El documento mostraba el texto «Código QR VeriFactu», que no es ninguna de las frases que exige el art. 6.5 del Reglamento de facturación | La factura incorpora la frase «Factura verificable en la sede electrónica de la AEAT» cuando el sistema remite todos los registros, y no la incorpora en la modalidad sin remisión | Comprobado sobre el documento de la factura del CRM y sobre la función que resuelve la leyenda según la modalidad |
| 5. Exportación a soporte externo | No existía un procedimiento de exportación: solo la descarga individual de cada JSON firmado | Exportación de los registros de un periodo a un soporte externo, con copia fidedigna, manifiesto con huellas y resúmenes criptográficos, independiente de las copias de seguridad, y su registro de evento de exportación | Comprobado sobre el periodo exportado, registro a registro contra lo conservado por el sistema |
Las cinco desviaciones se detectaron en el entorno de preproducción, antes de la puesta en explotación del sistema, y ninguna afecta a los registros remitidos y aceptados por la AEAT en la modalidad VERIFACTU, cuya integridad se sostiene en la huella encadenada. Las dos primeras se refieren a la firma electrónica, requisito que en la modalidad VERIFACTU no es exigible —el art. 16.3 del Reglamento se satisface con la huella— y que sí lo es en la modalidad sin remisión (art. 12 del Reglamento), que es donde resultaba relevante. Los registros generados con versiones anteriores conservan la firma con la que se generaron; la corrección se aplica a los registros generados a partir de la versión 1.7.2.
Corrección adicional en la misma versión (no es una desviación normativa, sino un defecto de funcionamiento detectado al verificar). En las versiones anteriores, los servicios del sistema resolvían la contraseña del certificado mediante una función auxiliar que solo está disponible cuando la petición pasa por el módulo; en la ejecución de la tarea programada por línea de comandos, esa función no estaba cargada, de modo que esa vía no podía firmar los registros ni registrar los eventos (el proceso por la vía web sí lo hacía). Desde la 1.7.2 el sistema resuelve la contraseña desde su propio código, sin depender de esa carga previa, y el proceso programado por línea de comandos firma y registra con normalidad. La incidencia se detectó y se verificó en el entorno de preproducción.
Se declaran también los siguientes extremos, para que el alcance del cumplimiento se valore sobre un perímetro conocido:
| Limitación | Alcance | Previsión |
|---|---|---|
| Facturas simplificadas y determinados regímenes especiales (por ejemplo, ventanilla única, OSS) | La versión 1.7.2 registra la factura ordinaria y las rectificativas. Estos supuestos requieren un tratamiento específico del tipo de factura y del régimen | Versión 2.0 del sistema, con nueva declaración responsable firmada por el productor |
| Resumen periódico de actividad y detección de anomalías | Se ejecutan desde la tarea programada de línea de comandos del propio módulo, no desde el cron del CRM: si esa tarea no está programada, no se generan | Debe programarse esa tarea en la puesta en marcha |
| Resumen antes de la finalización del uso del sistema | El art. 9 de la Orden prevé, además del resumen periódico, un resumen antes de que el sistema deje de utilizarse; la versión 1.7.2 no lo genera | Mejora prevista |
| Reintentos de preparación | Un registro que no puede firmarse o guardarse permanece pendiente y se reintenta en cada pasada, sin límite de intentos ni marca de error | Mejora prevista |
| Registros rechazados por la AEAT | El sistema subsana automáticamente los rechazos subsanables; en los no subsanables no hay acción manual de reenvío: hay que corregir la causa (número o fecha) y volver a emitir | Comportamiento conforme, con mejora prevista en la gestión |
| Aviso de caducidad del certificado | El sistema muestra la fecha de caducidad, pero no genera un aviso automático previo | Mejora prevista |
| Registros de la modalidad sin remisión | No se remiten nunca, ni por decisión del usuario, ni al volver a la modalidad con remisión | Comportamiento conforme |
| Multimoneda | El sistema trabaja en euros | No previsto a corto plazo |
| Retención por IRPF | Se refleja en la factura del CRM, pero no forma parte del registro remitido a la AEAT (conforme a las especificaciones) | Comportamiento conforme |
| Abono sin factura de origen | Una rectificativa debe indicar la factura que rectifica: el sistema no puede registrar un abono creado al margen de la factura original y lo advierte al usuario | Comportamiento conforme |
| Anulación | Es irreversible, como exige la norma: una anulación se documenta con un registro nuevo y no se deshace | Comportamiento conforme |
| Estado de la instalación de referencia | En preproducción en la fecha de este informe; el paso a producción requiere la limpieza previa de los datos de prueba, guiada por el propio sistema | Previsto |
| Documento | Estado |
|---|---|
| Declaración responsable del productor | Firmada electrónicamente, versión por versión, y conservada por el productor; incorporada al propio programa y consultable en el panel. No se presenta ante la AEAT ni genera acuse |
| Histórico de declaraciones | 0.2 (03-09-2026) · 1.0 (07-09-2026) · 1.5 (12-09-2026) · 1.6 (13-09-2026) · 1.7 (14-09-2026) · 1.7.2 (15-09-2026), cada una con su fecha de suscripción, firmante y SHA-256 |
| Registro interno de instalaciones | Conservado por el productor: número de instalación ↔ titular, con la versión desplegada |
| Registros firmados (JSON) | Conservados en el sistema del obligado y descargables uno a uno |
| Registros de eventos | Conservados y firmados |
| Manual de usuario | Versión 1.7.2, con el registro de cambios del módulo |
| Este informe | Informe técnico de cumplimiento de la versión 1.7.2 |
Direcciones de información del productor: sitio web https://appvanza.com · información del producto https://appvanza.com/verifactu.php · histórico de declaraciones responsables https://appvanza.com/verifactu.php#declaraciones.
El sistema «VeriFactu para AppVanza CRM», en su versión 1.7.2, implementa los requisitos que el artículo 29.2.j) de la Ley 58/2003, el Real Decreto 1007/2023 y la Orden HAC/1177/2024 exigen a los sistemas informáticos de facturación en el alcance declarado en el capítulo 1 y con las limitaciones expresadas en el capítulo 7.2: genera un registro por cada factura expedida —y los correspondientes de anulación, rectificación y evento—, añade a cada registro su huella SHA-256 encadenada conforme a la especificación de la AEAT, lo firma electrónicamente en formato XAdES Enveloped sobre su propio contenido (art. 14 de la Orden), conserva los registros firmados a disposición de la AEAT, permite exportarlos por periodos a un soporte externo (art. 8.2) y los remite en la modalidad VERI*FACTU, garantizando la inalterabilidad de lo ya registrado —también de las líneas de factura— y la constancia de cualquier anomalía. La conformidad se sostiene en tres elementos verificables: la declaración responsable firmada por el productor para esta versión, el registro de instalaciones que el productor conserva, y los registros, eventos y JSON firmados que el propio sistema conserva y puede entregar. Alcance de la conformidad. El sistema cumple los requisitos descritos en el alcance del capítulo 1 y con las limitaciones declaradas en el capítulo 7.2. La revisión de código del 14 de septiembre de 2026 detectó cinco desviaciones en versiones anteriores, todas ellas corregidas y verificadas en la versión 1.7.2 (capítulo 7.1), que es la versión a la que corresponde la declaración responsable del productor de este informe. En la fecha de emisión no consta ninguna no conformidad abierta, con el alcance acotado por las limitaciones declaradas.
| Punto del modelo | Declarado | Implementación en el sistema |
|---|---|---|
| 1.a Nombre del sistema | VeriFactu para AppVanza CRM | — |
| 1.b Identificador del sistema | VF | Viaja en el bloque del sistema informático de cada registro |
| 1.c Versión | 1.7.2 | Definida en un único punto del programa y usada en los registros remitidos y en la declaración |
| 1.d Componentes y descripción | Módulo de facturación on-premise para CRM AppVanza (CodeIgniter 4, PHP 8) | Capítulo 3 de este informe |
| 1.e ¿Solo puede funcionar como VERI*FACTU? | No: admite la modalidad no VERI*FACTU | Capítulo 4.8 |
| 1.f ¿Multiobligado? | Sí | Capítulo 3.3 |
| 1.g Tipos de firma | XAdES Enveloped (RSA-SHA256) con certificado electrónico cualificado y política de firma de la AGE | Capítulo 4.4 |
| 1.h–1.j Datos del productor | Input Creativity SL · B18978924 · Granada | — |
| 1.k Declaración de cumplimiento | Cumplimiento del art. 29.2.j) LGT, RD 1007/2023 y Orden HAC/1177/2024 | Capítulos 4 y 6 de este informe |
| 1.l Fecha y lugar | 14 de septiembre de 2026 · Granada | Firma electrónica del PDF |
| 2.a–2.b Contacto y direcciones de internet | Teléfono, correo y direcciones web | Capítulo 8 |
| 2.c Especificaciones técnicas | Huella, firma, QR, envío, modalidad sin remisión, conservación, generación transaccional y bloqueo de integridad | Capítulo 4 |
| Término | Significado |
|---|---|
| Registro de facturación | Registro informático que documenta cada factura (alta, anulación o rectificación) con su contenido y su huella |
| Registro de evento | Registro informático de las circunstancias relevantes del sistema (inicio y fin de modalidad, resúmenes, anomalías) |
| Huella | Resultado del cálculo criptográfico (SHA-256) sobre los datos del registro y la huella del registro anterior |
| Encadenamiento | Enlace de cada registro con el anterior mediante su huella, que hace detectable cualquier alteración |
| VERI*FACTU | Modalidad en la que el sistema remite los registros a la AEAT |
| No VeriFactu | Modalidad sin remisión: los registros se generan, se firman y se conservan a disposición de la AEAT |
| Subsanación | Corrección de un registro rechazado o con errores mediante un registro nuevo |
| Declaración responsable | Documento, firmado por el productor del sistema, en el que declara que su producto cumple la normativa; se conserva a disposición de la AEAT |
| Número de instalación | Número que el productor asigna a cada despliegue del sistema, para identificar cada instalación en los registros |
Las citas de este informe corresponden a los textos consolidados publicados en el «Boletín Oficial del Estado» en la fecha de emisión del documento.
SistemaFacturacion: operaciones RegFactuSistemaFacturacion y ConsultaFactuSistemaFacturacion, servicios sfVerifactu y sfRequerimiento) y documento del servicio de validación de la modalidad sin remisión. Información y documentos publicados en https://sede.agenciatributaria.gob.esDocumento emitido por Input Creativity SL (productor del software). Informe técnico de cumplimiento · versión 1.7.2 · 15 de septiembre de 2026.