Modalidad VeriFactu vs No VeriFactu: Diferencias Técnicas y Operativas

1. Las dos modalidades del RD 1007/2023

La normativa contra el software de doble uso (RD 1007/2023) introduce obligaciones estrictas para todos los Sistemas Informáticos de Facturación (SIF). Todo SIF debe garantizar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros.

Para cumplir este objetivo, la Administración Tributaria ha dispuesto dos vías operativas distintas que el obligado tributario (la empresa o autónomo) y su software pueden elegir:

• Modalidad VeriFactu (Sistema VERI*FACTU): Implica el envío automático, continuo, seguro y en tiempo real de los registros de facturación (y de eventos) a la Sede Electrónica de la Agencia Tributaria. Al realizar este envío, la AEAT presume que el sistema cumple con las garantías requeridas sin necesidad de que el SIF implemente firmas electrónicas avanzadas para el almacenamiento local.
• Modalidad No VeriFactu (Conservación Local Segura): El software genera registros que cumplen con todos los requisitos (hash, encadenamiento, código QR), pero no los envía automáticamente. El sistema debe almacenar estos datos de forma local, firmados electrónicamente (firma no repudiable), asegurando que puedan ser descargados de forma estructurada en caso de que la Inspección Tributaria requiera su extracción.

2. Tabla comparativa exhaustiva

A continuación, se desglosan las diferencias técnicas y operativas clave entre operar un sistema homologado como VeriFactu frente a uno No VeriFactu.

3. La marca 'VeriFactu' en la factura

Uno de los aspectos más visibles para el consumidor final o cliente B2B es la inclusión de la mención 'VERI*FACTU' (o su logotipo oficial, si se determinase) en la representación gráfica de la factura (el PDF o el ticket en papel).

El Reglamento estipula que solo las facturas cuyos registros se remitan bajo la modalidad VeriFactu podrán (y deberán) exhibir la marca o expresión 'Factura verificable en la sede electrónica de la AEAT' o 'VERI*FACTU'.

Utilizar esta marca en un software que opera bajo modalidad "No VeriFactu" se considera un incumplimiento técnico de la normativa, ya que induce a error al receptor (y a la Agencia Tributaria) sobre el grado de integración del emisor con el fisco.

4. ¿Cuál elegir? Toma de decisiones

Para una PYME o autónomo, la elección dependerá del entorno tecnológico y operativo del negocio.

A la hora de decantarse, se deben tener en cuenta las implicaciones de desarrollo: en modalidad No VeriFactu, el SIF debe disponer de certificados digitales, gestionar el sellado de tiempo (timestamping) de forma interna, proteger las claves privadas criptográficas en el dispositivo del cliente y prever un mecanismo robusto de exportación .xml para cuando la Inspección lo requiera in situ.

5. Requisitos de conectividad en modalidad VeriFactu

La modalidad VeriFactu demanda una comunicación directa con la Administración. Se requiere, por tanto, acceso a Internet estable. Pero, ¿qué ocurre si hay una caída de red en medio de la emisión de una factura?

El sistema informático debe estar preparado para estas contingencias mediante mecanismos de encolado (queueing) y reintento:

1. Si falla el envío, el SIF debe generar el registro de forma normal (hash, evento).
2. La factura se imprime/envía al cliente con toda validez.
3. El SIF guarda el registro pendiente en un spooler local encriptado.
4. Al recuperar la conexión, el SIF transmitirá los registros atrasados automáticamente en un bloque.
5. El SIF generará y reportará un evento técnico de tipo "Caída de conectividad - Restablecimiento".

6. Implicaciones fiscales de cada modalidad

La propia exposición de motivos del Real Decreto sugiere que el envío en tiempo real aporta transparencia operativa. Las empresas que operan bajo VeriFactu transmiten a la Administración su facturación neta sin intervención humana, lo que la AEAT interpreta como un comportamiento de mínimo riesgo de fraude.

Esto podría traducirse en:

• Perfil de riesgo reducido: Menor probabilidad de sufrir inspecciones aleatorias y presenciales (los denominados 'peinados').
• Agilización de devoluciones: Al contar con los datos verificados, procesos como devoluciones de IVA podrían ser tramitados más ágilmente.
• Borradores impositivos: La posibilidad a futuro de que la AEAT facilite borradores parciales en liquidaciones de IVA y pagos fraccionados.

7. Flujo técnico de envío en modalidad VeriFactu

Para comprender la densidad técnica de la transmisión, el siguiente esquema (pseudocódigo conceptual) refleja los pasos que realiza internamente un software cuando un usuario hace clic en "Emitir Factura":

// 1. Datos básicos
const factura = SIF.crearFactura(datosUsuario, base, iva);

// 2. Hash encadenado (SHA-256)
const hashPrevio = DB.getUltimoHash(serie);
factura.hash = crypto.createHash('sha256')
                 .update(factura.datos + hashPrevio).digest('hex');

// 3. Generación del QR
factura.qr = SIF.generarURLQR(factura.nif, factura.numero, factura.fecha, factura.total);

// 4. Creación del registro estructurado
const xmlRegistro = XMLBuilder.buildVeriFactu(factura);

// 5. Envío vía Servicio Web (SOAP / REST)
try {
  const respuesta = await AEAT_WebService.send(xmlRegistro, SIF.certificadoSede);
  if(respuesta.status === 'OK') {
     // 6. AEAT retorna acuse
     DB.guardarAcuse(respuesta.id_acuse);
  }
} catch (errorRed) {
  // Encolar para más tarde (mecanismo retry)
  SIF.encolar(xmlRegistro);
  SIF.registrarEventoLog('Fallo conexion AEAT', errorRed);
}

Todo este complejo proceso ocurre en milésimas de segundo de manera invisible para el comerciante, garantizando el pleno cumplimiento del estándar técnico y evitando las cuantiosas sanciones asociadas al software de doble uso.