Descargar PDF

DECLARACIÓN RESPONSABLE
DEL SISTEMA INFORMÁTICO DE FACTURACIÓN

1.a) Nombre del sistema informático a que se refiere la declaración responsable.

Luqen, módulo de facturación con VERI*FACTU (componente principal de un sistema informático de facturación en arquitectura mixta, junto con el componente externo del apartado d).

1.b) Código identificador del sistema informático a que se refiere el apartado 1.a).

LQ. Código único de dos caracteres asignado por el productor conforme al artículo 15.1 de la Orden HAC/1177/2024. Este código identifica únicamente a este sistema informático, que no comparte con ningún otro producido por el mismo productor. Los registros de facturación los genera el componente externo y llevan el identificador de su propio sistema (A1), no este código.

1.c) Identificador completo de la versión concreta del sistema informático a que se refiere la declaración responsable.

Luqen 1.17, con fecha de esta versión 12 de octubre de 2026 y en desarrollo desde diciembre de 2025.

1.d) Componentes, hardware y software, de que consta el sistema informático a que se refiere la declaración responsable, junto con una breve descripción de lo que hace dicho sistema informático y de sus principales funcionalidades.

Software de gestión en la nube (SaaS), accesible por navegador, para negocios que atienden con cita (agenda, recordatorios, clientes y control de cobros). Incluye un módulo de facturación con VERI*FACTU que, junto con el sistema del proveedor Verifacti, constituye un sistema informático de facturación en arquitectura mixta: el módulo de Luqen es el componente principal y Verifacti, el componente externo. Existe un único despliegue, multiusuario, con separación entre las cuentas de cada negocio.

  • Aplicación web de gestión (agenda, clientes y cobros) desde la que se pide cada factura.
  • Base de datos relacional en la Unión Europea con los cobros, los comprobantes internos y, si el negocio activa el módulo, las facturas, el resultado de su registro y el histórico de cada cambio fiscal.
  • Módulo de facturación con VERI*FACTU (componente principal): compone los datos, reserva el número en la serie, solicita al proveedor el registro de alta, de anulación o de subsanación, conserva lo que devuelve y expide el documento. No calcula la huella ni genera el XML.
  • Generador de PDF: los comprobantes internos y, con el módulo activado, la factura con el código QR y la mención VERI*FACTU.
  • Componente externo (información complementaria, art. 15.4): Verifacti (BILBABIT, S.L.): genera y encadena el registro de facturación y lo remite a la Agencia Tributaria.

El detalle de las funcionalidades, de lo que queda fuera del sistema y de cómo se cumple cada garantía consta en la memoria técnica de cumplimiento, publicada junto a esta declaración en https://belleza.luqen.es/declaracion-responsable.

1.e) Indicación de si el sistema informático a que se refiere la declaración responsable se ha producido de tal manera que, a los efectos de cumplir con el Reglamento, solo pueda funcionar exclusivamente como «VERI*FACTU».

Sí. El módulo de facturación funciona exclusivamente como VERI*FACTU y no admite la modalidad de sistema no verificable.

1.f) Indicación de si el sistema informático a que se refiere la declaración responsable permite ser usado por varios obligados tributarios o por un mismo usuario para dar soporte a la facturación de varios obligados tributarios.

Sí. Un único despliegue en la nube da servicio a varios obligados tributarios, cada uno con su propia cuenta, su NIF y su serie de facturación, con separación entre las cuentas de cada negocio.

1.g) Tipos de firma utilizados para firmar los registros de facturación y de evento en el caso de que el sistema informático a que se refiere la declaración responsable no sea utilizado como «VERI*FACTU».

Dado que se trata de un producto de facturación que solo puede ser utilizado exclusivamente en la modalidad de «VERI*FACTU», no se realiza una firma electrónica expresa de los registros de facturación generados, ya que la normativa considera que quedan firmados al ser remitidos correctamente a los servicios electrónicos de la Agencia Tributaria con la debida autenticación mediante el adecuado certificado electrónico cualificado.

1.h) Nombre y apellidos de la persona o razón social de la entidad productora del sistema informático a que se refiere la declaración responsable.

Mario Fernández Luque

1.i) Número de identificación fiscal (NIF) español de la persona o entidad productora del sistema informático a que se refiere la declaración responsable.

54264113Y

1.j) Dirección postal completa de contacto de la persona o entidad productora del sistema informático a que se refiere la declaración responsable.

Calle Alonso de Ojeda, 2, Bloque 1, Bajo F, 28660, Boadilla del Monte, Madrid, España

1.k) Cumplimiento, en la versión indicada, de lo dispuesto en el artículo 29.2.j) de la Ley 58/2003, de 17 de diciembre, General Tributaria, en el Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre, en esta orden y en la sede electrónica de la Agencia Estatal de Administración Tributaria para todo aquello que complete las especificaciones de esta orden.

Mario Fernández Luque, en su condición de productor del componente principal Luqen, versión 1.17, declara bajo su responsabilidad que dicho componente, integrado con el componente externo identificado en esta declaración y dentro de las funcionalidades y límites descritos, cumple los requisitos que le resultan aplicables del artículo 29.2.j) de la Ley 58/2003, del Reglamento aprobado por el Real Decreto 1007/2023, de la Orden HAC/1177/2024 y de las especificaciones técnicas correspondientes publicadas en la sede electrónica de la Agencia Estatal de Administración Tributaria.

1.l) Fecha en que la persona o entidad productora del sistema informático suscribe esta declaración responsable del mismo.

12 de octubre de 2026.

Lugar en que la persona o entidad productora del sistema informático suscribe esta declaración responsable del mismo.

Boadilla del Monte, España.

Información complementaria (artículo 15.4 de la Orden HAC/1177/2024, componentes de terceros) Componentes funcionales (CF) de terceros: CF utilizado, versión, funcionalidad que asume, interacción entre componentes.

  • Componente funcional externo utilizado (nombre del sistema informático): Verifacti — BILBABIT, S.L., sistema «bilbabit», identificador A1.
  • Versión del sistema informático: 1.0.3.
  • Funcionalidad que asume: generación y remisión de los registros de facturación.
  • Interacción entre ambos componentes: Luqen realiza llamadas a través de la API en la nube del componente externo con los datos necesarios para la creación de cada registro de facturación. El componente externo genera el registro de facturación y devuelve de manera inmediata el código QR; procede entonces a su remisión a la Agencia Tributaria y ofrece la respuesta de la Agencia Tributaria a través de webhooks o de un endpoint específico.
  • Nombre legal: Bilbabit SL. NIF: B75777847. Email de contacto: soporte@verifacti.com.
  • Su declaración responsable: https://storage.googleapis.com/verifacti_non_sensitive_prod/declaracion/1.0.3.pdf (versión 1.0.3; la vigente en cada momento está en https://storage.googleapis.com/verifacti_non_sensitive_prod/declaracion/actual.pdf)

Anexo

2.a) Otras formas de contacto con la persona productora del sistema informático a que se refiere esta declaración responsable:

  • Correo electrónico: contacto@luqen.es

2.b) Direcciones de internet de la persona productora del sistema informático a que se refiere esta declaración responsable:

  • Sitio web de la empresa: https://luqen.es
  • Información sobre este producto en el sitio web: https://belleza.luqen.es/declaracion-responsable
  • Acceso al histórico de declaraciones responsables de las versiones de este producto: https://belleza.luqen.es/api/declaracion-responsable/historico

2.c) El sistema informático a que se refiere esta declaración responsable cumple las diferentes especificaciones técnicas y funcionales contenidas en la Orden HAC/1177/2024, de 17 de octubre, y en la sede electrónica de la Agencia Estatal de Administración Tributaria para todo aquello que complete las especificaciones de dicha orden, de la siguiente manera:

El módulo de facturación, junto con el sistema del proveedor, cumple las propiedades que exige el artículo 29.2.j) de la Ley 58/2003 y las especificaciones de remisión de VERI*FACTU, en concreto:

  • Integridad: el componente externo genera cada registro con una huella encadenada con la del anterior; este sistema conserva la huella y la base de datos impide modificarla.
  • Conservación: mientras la cuenta está vigente se conservan los registros y la respuesta del proveedor; la conservación legal de las facturas corresponde al obligado tributario.
  • Accesibilidad: el obligado tributario puede consultar y descargar sus facturas, exportar los datos fiscales que conserva Luqen (JSON o CSV) y descargar los XML originales que conserva el proveedor.
  • Legibilidad: los registros se conservan en formato estructurado y el documento de cada factura se lee sin la aplicación.
  • Trazabilidad: histórico de solo inserción de cada cambio de estado, anulación y subsanación, con su valor anterior, valor nuevo, fecha y versión del sistema.
  • Inalterabilidad: registrada el alta, la base de datos rechaza modificar sus datos fiscales; las correcciones se hacen con una rectificativa, una subsanación o una anulación, como operaciones posteriores y vinculadas.
  • Numeración correlativa por serie, con series propias para simplificadas, rectificativas y pruebas, y una serie real nueva si la configurada ya tiene facturas de pruebas; controles de idempotencia y unicidad en los puntos de emisión.
  • Fases diferenciadas: generación del registro, obtención del QR, transmisión a la Agencia Tributaria y resultado de su procesamiento; el QR no equivale a una aceptación.
  • Incidencias: proceso de reintento con periodicidad horaria (su ejecución depende de un planificador externo y se verifica en producción), conciliación antes de reenviar lo que lleva más de 24 horas sin confirmación (nunca a ciegas) y aviso con el número de registros pendientes de remitir o rechazados.
  • Mantenimiento de la modalidad (art. 17.2): con facturas reales en el ejercicio, el módulo no se desactiva hasta el 1 de enero; la renuncia (art. 17.3) no está automatizada.
  • Separación fiscal entre obligados tributarios y entre entorno de pruebas y producción.

El detalle de las funcionalidades, de lo que queda fuera del sistema y de cómo se cumple cada garantía consta en la memoria técnica de cumplimiento, publicada junto a esta declaración en https://belleza.luqen.es/declaracion-responsable.

2.d) Otra información adicional de interés sobre el sistema informático a que se refiere esta declaración responsable:

  • Los registros de facturación remitidos a la Agencia Tributaria los genera el proveedor indicado y llevan el identificador de su propio sistema, no este código. El número de instalación que acompaña a cada registro (en los registros observados, «NIF-A1-n») es el identificador interno de cada NIF en la plataforma del proveedor: es único y no se reutiliza (si un NIF se desactiva y se reactiva conserva el mismo número; si se elimina y se da de alta de nuevo recibe uno nuevo); este software no asigna ningún otro.
  • Identificación del sistema en los registros: Verifacti ha explicado por escrito que el bloque de identificación del sistema informático corresponde al sistema que genera el registro (huella, encadenamiento y XML) y que cada registro remite así a la declaración que lo cubre, con su propia versión; considera correcta la declaración de Luqen como componente principal, con el código LQ, que no viaja en los registros. Es el criterio del proveedor y esta declaración lo recoge como tal, sin presentarlo como un pronunciamiento de la Agencia Tributaria.
  • Indicador de múltiples obligados tributarios: Verifacti considera «usuario» del sistema a la cuenta que da de alta los NIF y llama a su API, que aquí es Luqen; como Luqen gestiona la facturación de varios NIF, el proveedor informa el indicador como «S» en todos los registros. Es el criterio del proveedor y Luqen no lo modifica.
  • El módulo de facturación de Luqen funciona exclusivamente en modalidad VERI*FACTU. Verifacti genera el registro de facturación y devuelve el código QR al sistema integrador, y realiza la remisión automatizada a la Agencia Estatal de Administración Tributaria de manera continuada, conforme a los requisitos reglamentarios y a los mecanismos previstos para las incidencias técnicas. No admite la modalidad de sistema no verificable. Mientras el módulo no está activado, Luqen no emite facturas ni remite ningún registro a la Agencia Tributaria: emite comprobantes de pago internos, meramente informativos, que no son facturas ni sustituyen a una factura.

El titular conserva la presente declaración responsable, así como las correspondientes a versiones anteriores, y las pone a disposición de quien las solicite.

Memoria técnica de cumplimiento

Explicación detallada de cómo cumple el sistema las especificaciones de la Orden HAC/1177/2024 (artículo 15.2.c). No forma parte del documento que se suscribe: se actualiza cuando cambia un detalle técnico.

Composición

  • Una aplicación web de gestión (agenda, clientes y cobros) desde la que se pide cualquier factura.
  • Una base de datos relacional en la Unión Europea, donde residen los cobros, los comprobantes de pago internos y, si el negocio activa el módulo, las facturas emitidas con su numeración, el resultado de su registro (identificador, estado, huella, código QR y dirección de verificación que devuelve el proveedor) y el histórico de cada cambio fiscal.
  • El módulo de facturación con VERI*FACTU (componente principal): compone los datos de cada factura, reserva su número correlativo en la serie del negocio, solicita al proveedor el registro de alta, de anulación o de subsanación, conserva lo que éste devuelve, y expide el documento. La huella, su encadenamiento con el registro anterior y el registro en formato XML los genera el componente externo con su propio sistema informático; este software no los calcula.
  • La integración con Verifacti (componente externo), que genera y encadena el registro de facturación, lo remite a la Agencia Estatal de Administración Tributaria y conserva los ficheros XML de petición y de respuesta (apartado «Componentes externos»).
  • Un generador de documentos en PDF: los comprobantes de pago internos y, con el módulo activado, el documento de la factura con el código QR tributario y la mención VERI*FACTU.

Funcionalidades (solo disponibles cuando el negocio activa el módulo)

  • Emisión de facturas completas (F1, F3), simplificadas (F2) y rectificativas (R1 y R5, por sustitución o por diferencias).
  • Numeración correlativa y consecutiva por serie del negocio, sin reutilización de números; la serie es continua y no se reinicia por ejercicio.
  • Solicitud del registro de facturación al proveedor en el momento de la emisión, con una clave de idempotencia por factura, y conservación de la huella y de los datos que éste devuelve.
  • Proceso automático de reintento programado con periodicidad horaria de lo que no llega al proveedor; recuperación de lo que queda a medias; y conciliación (consulta por serie, número y fecha) antes de reenviar lo que lleva más de 24 horas sin confirmación. Su ejecución depende de un planificador externo (las tareas programadas de la plataforma de alojamiento) y la periodicidad efectiva debe verificarse en el entorno de producción.
  • Solicitud de subsanación de un registro, sujeta a una habilitación técnica (interruptor de la plataforma): su disponibilidad efectiva en producción y su operativa frente a registros rechazados o aceptados con errores deben verificarse antes de ofrecerla como capacidad activa.
  • Anulación mediante el registro de anulación que corresponde (normal, sin registro previo o tras rechazo) y seguimiento de su resultado, sin borrado del registro original.
  • Consulta periódica del estado del registro ante la AEAT y avisos al negocio cuando es rechazado, aceptado con errores o no llega.
  • Descarga, por ejercicio y mes, de los XML originales de petición y de respuesta que conserva el proveedor (alta, subsanación y anulación), a través de su servicio de exportación y antes de que los elimine al desactivar el NIF.
  • Conservación, mientras la cuenta está vigente, de los registros y de su histórico de cambios, y exportación de los datos fiscales que conserva Luqen en formato estructurado (JSON o CSV, con huella de integridad).
  • Expedición del documento de la factura con el código QR, la mención VERI*FACTU y el estado real del registro, con la versión del sistema y los datos fiscales del emisor con los que se expidió.

Queda fuera del alcance del sistema

  • No genera el registro de facturación ni calcula ni encadena su huella; no genera los ficheros XML ni los remite a la Agencia Tributaria: lo hace el proveedor declarado.
  • No conserva los ficheros XML originales de petición y de respuesta de la Agencia Tributaria: los conserva el proveedor declarado, y este sistema solo permite descargarlos de él (por ejercicio y mes) mientras el proveedor los conserva. La exportación de los datos que conserva este sistema no los sustituye.
  • No firma los registros de facturación.
  • No lleva la contabilidad ni presenta declaraciones tributarias.
  • Luqen permite emitir facturas rectificativas R1 para los motivos legalmente previstos para esa clave y R5 para rectificar facturas simplificadas, por sustitución o por diferencias cuando corresponda. No admite las claves R2, R3 ni R4. En particular, los errores no monetarios de facturas completas que requieran una rectificativa R4 deberán corregirse mediante otro sistema de facturación conforme a la normativa. La subsanación de un registro VERI*FACTU no sustituye la expedición de una factura rectificativa cuando esta sea legalmente exigible. En los supuestos en los que proceda anular una factura emitida por error, se utilizará el procedimiento de anulación correspondiente.
  • El módulo permite la expedición de facturas correspondientes exclusivamente al obligado tributario identificado en cada cuenta de negocio. La administración centralizada de la integración con el proveedor no altera la identidad del emisor de cada factura ni convierte al titular de Luqen en emisor fiscal de las facturas de sus clientes.
  • No admite la introducción de registros de facturación generados por otro sistema.
  • No se compromete a custodiar las facturas del negocio tras la baja de la cuenta: la conservación de las facturas durante el plazo legal corresponde al obligado tributario.

Garantías, una por una

  • Integridad: cada registro de facturación se genera, en el componente externo, con una huella criptográfica encadenada con la del registro anterior, de modo que alterar uno rompe la cadena de todos los siguientes; este sistema conserva esa huella y la base de datos impide modificarla.
  • Conservación: mientras la cuenta está vigente, este sistema conserva los registros y la respuesta del proveedor y no los elimina desde la aplicación; una factura anulada se conserva marcada como anulada junto con los datos del registro de anulación (identificador, huella, estado, fecha y motivo). La conservación de las facturas durante el plazo legal corresponde al obligado tributario, y el sistema no se compromete a custodiarlas tras la baja de la cuenta.
  • Accesibilidad: el obligado tributario puede consultar y descargar sus facturas y exportar los datos fiscales que Luqen conserva en formato estructurado (JSON o CSV, con huella de integridad) desde la propia aplicación. Esa exportación recoge los datos que este sistema conserva y no contiene los ficheros XML originales de petición y de respuesta de la Agencia Tributaria, que conserva el proveedor: la aplicación permite descargarlos de él (ZIP, por ejercicio y mes; el proveedor los entrega mediante direcciones válidas 15 minutos, en páginas de 500) y el proveedor los elimina 30 días naturales después de desactivar el NIF, por lo que el negocio debe descargarlos antes. Luqen no desactiva automáticamente ningún NIF en el proveedor: la desactivación es una operación expresa y, conforme al procedimiento de baja, se hace después de entregar al negocio sus exportaciones.
  • Legibilidad: los registros se conservan en un formato estructurado y legible, y el documento de cada factura puede leerse sin la aplicación que lo generó.
  • Trazabilidad: este sistema conserva, en un registro de solo inserción, cada cambio del estado de envío, del registro, del veredicto de la Agencia Tributaria, de anulación y de subsanación, con su valor anterior, su valor nuevo, la fecha y hora y la versión del sistema.
  • Inalterabilidad: una vez registrado el alta fiscal de una factura, la base de datos rechaza —también al componente de servidor de la aplicación— el cambio de serie, número, fecha de expedición, fecha de operación, base, cuota, total, tipo, entorno, líneas, conceptos, datos de rectificación, huella, código QR, dirección de verificación, identificador del registro y datos fiscales del emisor. Las correcciones posteriores se realizan, según corresponda, mediante una factura rectificativa (R1 o R5), la subsanación de un registro de facturación o un registro de anulación, que se solicitan al proveedor como operaciones posteriores y vinculadas y dejan en el histórico de solo inserción el valor anterior y el nuevo; la subsanación del registro no sustituye a la factura rectificativa cuando esta es exigible. La fila local refleja el último registro y el original permanece en el proveedor. Los estados operativos (estado de envío, veredicto de la AEAT) se actualizan conservando su historial. No se reabre una factura registrada ni se reactiva una anulada. La aplicación no permite al usuario modificar ni eliminar directamente las facturas registradas, y las cuentas con facturas de producción no se suprimen automáticamente al darse de baja: quedan en retención conforme al procedimiento de baja. La copia que conserva Luqen no es el registro oficial: los registros originales en formato XML son generados y conservados por el proveedor conforme a sus condiciones de servicio, y los registros efectivamente remitidos constan en los sistemas de la Agencia Tributaria según su resultado de procesamiento; Luqen permite consultar los estados disponibles y descargar los XML originales que el proveedor pone a disposición.
  • La numeración correlativa y consecutiva de las facturas por serie, sin reutilización de números, y la separación de series: las facturas completas (F1, F3) se numeran en la serie del negocio, las simplificadas (F2) en una serie propia (la del negocio con el sufijo «-S») y las rectificativas en su serie de rectificativas. La serie es continua y no se reinicia por ejercicio. Las facturas del entorno de pruebas no son facturas expedidas: se generan en el entorno de pruebas del proveedor, que remite a un entorno de pruebas de la Agencia Tributaria distinto del de producción, llevan la marca «FACTURA DE PRUEBA — SIN VALIDEZ FISCAL» y se numeran en series distintas (con el sufijo «-PRUEBA») y con contador propio, de modo que no consumen la numeración real; un negocio en pruebas no puede emitir en producción hasta su paso expreso a producción. Ninguna de las facturas existentes a 11 de octubre de 2026 se remitió al entorno de producción de la Agencia Tributaria: todas las que llegaron al proveedor lo hicieron a su entorno de pruebas; los negocios que emitieron pruebas con la serie real antes de esa fecha las conservan (son inalterables), pero al activar la producción, si la serie configurada ya aparece en facturas del negocio, el sistema asigna una serie nueva y libre para lo que se emita a partir de entonces, de modo que la serie real no continúa la de las pruebas.
  • Controles de idempotencia y unicidad: en cada punto de emisión descrito en esta memoria (venta, bono, factura manual, factura completa sobre un ticket y ticket de cita) se utiliza una reserva con clave propia o una restricción específica para evitar duplicidades, de modo que una repetición, un doble envío o un corte del proceso no producen una segunda factura de la misma operación; ello no supone que todos los flujos compartan el mismo mecanismo. Antes del primer envío se comprueba que los datos guardados coinciden con los que se envían.
  • La solicitud del registro de facturación en el mismo momento de la emisión de cada factura y la remisión electrónica de cada registro a la Agencia Estatal de Administración Tributaria, a través del proveedor.
  • La gestión de los errores de comunicación: una factura que no llega al proveedor se reenvía automáticamente, con la misma clave de idempotencia, mediante un proceso programado con periodicidad horaria y sin número máximo de intentos (su ejecución depende de un planificador externo y se verifica en producción), y la aplicación informa de las incidencias de transmisión detectadas: muestra, en todas sus pantallas, desde el momento en que una factura de producción no llega al proveedor o no obtiene respuesta válida de la Agencia Tributaria, y mientras quede alguna, un aviso con el número de registros pendientes de remitir y, aparte, el de los rechazados que requieren actuación; además avisa a las 12 horas y a los 3 días. La supervisión completa del envío a la Agencia Tributaria comprende además los estados que comunica el proveedor. Una consulta que responde «factura no encontrada», o que no obtiene respuesta de la Agencia Tributaria, no demuestra que el registro no exista (el proveedor puede tenerlo aún en su cola) y nunca autoriza un reenvío. Los reintentos solo se ejecutan cuando son seguros: con la misma clave de idempotencia dentro de su plazo de vigencia y, pasadas 24 horas sin confirmación, previa consulta. Una factura que lleva más de 24 horas sin confirmación no se reenvía a ciegas: se consulta antes al proveedor por serie, número y fecha y, si no puede determinarse con seguridad si existe, se bloquea el reenvío y se deja para conciliación. Los errores que repetir no arregla (datos rechazados, duplicados) no se reintentan solos: se avisa al negocio, y la corrección de unos datos no se hace repitiendo la petición original (el proveedor rechaza una clave de idempotencia reutilizada con datos distintos), sino mediante la anulación o la subsanación que corresponda.
  • Fases diferenciadas: la generación del registro, la obtención de los datos del código QR, la transmisión a la Agencia Tributaria y el resultado de su procesamiento son fases distintas; Luqen conserva e informa de los estados que el componente externo comunica y no equipara la obtención del QR a una aceptación tributaria.
  • El estado ante la Agencia Tributaria: el documento de cada factura distingue «pendiente de registro», «registro pendiente de confirmación», «aceptado», «aceptado con errores» y «rechazado» (incluidos «duplicado» y «no registrado»); la creación del registro devuelve «pendiente» y no equivale a su aceptación, y «error servidor AEAT» (sin respuesta válida, que el proveedor reenvía solo) se trata como pendiente y no como rechazo; no afirma que es verificable salvo cuando la Agencia Tributaria lo ha aceptado, y conserva el código QR y la mención VERI*FACTU cuando existe registro; las facturas del entorno de pruebas llevan la marca «FACTURA DE PRUEBA — SIN VALIDEZ FISCAL».
  • La anulación: se solicita al proveedor el registro de anulación que corresponde (normal, sin registro previo o tras rechazo), se consulta después el veredicto de la Agencia Tributaria y se avisa si lo rechaza; una factura que no ha llegado al proveedor y puede estar en él no se anula hasta conocer su situación.
  • La versión del sistema por factura: el sistema registra la versión utilizada y los datos fiscales del emisor vinculados a cada operación de expedición, y esa persistencia es previa a la solicitud del registro: si no puede completarse, la factura no se envía en ese intento, queda en cola y el reintento posterior lo repite. El documento imprime esos datos y no los vigentes al imprimirlo; las facturas anteriores a este sellado no los tienen y el documento lo indica.
  • La separación fiscal entre los distintos obligados tributarios que usan el sistema, de modo que ninguno accede a los registros de otro.
  • El mantenimiento de la modalidad: conforme al artículo 17.2 de la Orden HAC/1177/2024, el sistema sigue funcionando como VERI*FACTU al menos hasta el 31 de diciembre del último año en que lo haya hecho, de modo que con facturas reales expedidas en el ejercicio el módulo no se puede desactivar hasta el 1 de enero siguiente. Esta permanencia se refiere al funcionamiento del sistema como VERI*FACTU y no es una permanencia comercial: la renuncia a la modalidad (artículo 17.3), que se comunica en los registros remitidos antes del cierre del año natural, es distinta de la baja del servicio, y ninguna de las dos elimina ni modifica las facturas ya registradas. La comunicación formal de la renuncia no está automatizada en este módulo.
  • El histórico: el texto íntegro de las versiones anteriores de esta declaración está disponible en https://belleza.luqen.es/api/declaracion-responsable/historico.