Cómo lanzar un proyecto SaaS con IA cumpliendo VeriFactu: de la idea a producción sin riesgo legal

Cursor, GitHub Copilot, v0, Bolt... Las herramientas de desarrollo asistidas con IA han acortado brutalmente el tiempo entre la idea y el MVP funcional. En días puedes tener una aplicación de facturación operativa, con interfaz decente y lógica de negocio funcionando.

El problema llega cuando te das cuenta de que el software de facturación en España no solo tiene que funcionar: tiene que cumplir con VeriFactu. Es decir, debe estar alineado con el Real Decreto 1007/2023, que regula los requisitos que deben cumplir los sistemas y programas informáticos que soportan los procesos de facturación de empresarios y profesionales. A día de hoy la obligación para los softwares ya es real y no un futurible. Para los obligados tributarios entrará en vigor desde el 1 de enero de 2026 para las sociedades y desde el 1 de julio de 2026 para autónomos en estimación directa.

Este es el punto en el que muchos proyectos se estancan.

Este artículo te explica cómo estructurar el desarrollo de un SaaS de facturación con IA integrando VeriFactu desde el principio con nuestra API VeriFactu, no como parche posterior. 

Qué cambia VeriFactu en tu arquitectura

VeriFactu no es una API más que integras al final. Los requisitos para cumplir con la Ley Antifraude son muy concretos y tocan tres capas de tu aplicación:

1. Modelo de datos

Cada registro de facturación debe incluir campos obligatorios para la AEAT: huella (hash SHA-256), fecha y hora de alta del registro, identificadores de factura anterior en la cadena, tipo de factura según clasificación fiscal. Si tu modelo actual no contempla esto, tendrás que incluirlo.

2. Lógica de encadenamiento

El reglamento exige que los registros de facturación estén encadenados mediante hashes, y esto aplica siempre, sin excepción. Cada registro debe calcular su huella incluyendo la huella del registro anterior. Esto implica:

• Orden estricto en la generación de registros
• Imposibilidad de modificar registros históricos sin romper la cadena
• Sincronización si generas facturas en paralelo o en múltiples instancias

3. Comunicación con AEAT

Aquí hay un matiz importante que conviene tener claro antes de diseñar nada: el reglamento contempla dos modalidades. En la modalidad VERI*FACTU, cada registro se envía a la AEAT en tiempo real, en formato XML, con certificado digital, mediante un servicio web SOAP —no es REST, no es JSON, y los esquemas XSD son estrictos, un error en la estructura y el envío rebota—. A cambio, tu software goza de presunción de veracidad ante la Administración. En la modalidad NO VERI*FACTU, no envías nada en tiempo real: mantienes los registros encadenados, con su huella y su código QR, listos para exhibirlos si la AEAT los pide.

El encadenamiento de huellas es obligatorio en ambas modalidades. El envío SOAP inmediato solo lo es si optas por VERI*FACTU. En este tutorial nos centramos en esa modalidad porque es la que resuelve una API externa como la nuestra, y en la práctica es la que la mayoría de SaaS de facturación adoptan por la tranquilidad legal que da el envío en tiempo real.

Si tu aplicación generada con IA no contempló estos puntos desde el diseño, tendrás que refactorizar partes críticas.

Estrategia de integración: capa de cumplimiento separada

La forma más eficiente de lanzar rápido es delegar el cumplimiento normativo a una capa externa. Tu aplicación se centra en la lógica de negocio (clientes, presupuestos, cobros, reportes), y una API externa gestiona la parte de VeriFactu.

Esto te permite:

• Desarrollar y probar tu MVP sin certificados digitales
• Mantener tu stack actual (Node, Python, PHP, lo que uses) — el patrón es el mismo en cualquier lenguaje: evento de factura emitida → llamada HTTP a la API → guardas la respuesta
• Actualizar el cumplimiento normativo sin tocar tu código cuando la AEAT cambie requisitos

La arquitectura básica queda así:

Tu aplicación (SaaS)
    |
    v
[Evento: factura emitida]
    |
    v
POST a API de VeriFactu
    |
    v
AEAT (envío SOAP con certificado)

Tu responsabilidad: enviar los datos de la factura a la API. Responsabilidad de la API: calcular huellas, encadenar, generar XML, firmar, enviar a AEAT, gestionar reintentos si falla la comunicación.

Implementación práctica en Node.js

Supongamos que tu SaaS genera facturas con este flujo básico:

// Tu lógica actual
async function crearFactura(clienteId, lineas) {
  const factura = await db.facturas.create({
    numero: generarNumero(),
    cliente_id: clienteId,
    lineas: lineas,
    total: calcularTotal(lineas),
    fecha: new Date()
  });

  return factura;
}

Para cumplir VeriFactu, necesitas enviar un registro a AEAT cada vez que generes una factura. Añades una llamada a la API:

async function crearFactura(clienteId, lineas) {
  const factura = await db.facturas.create({
    numero: generarNumero(),
    cliente_id: clienteId,
    lineas: lineas,
    total: calcularTotal(lineas),
    fecha: new Date()
  });

  // Envío a VeriFactu
  await enviarAVerifactu(factura);

  return factura;
}

async function enviarAVerifactu(factura) {
  const cliente = await db.clientes.findById(factura.cliente_id);

  const payload = {
    emisor: {
      nif: process.env.NIF_EMPRESA,
      nombre: process.env.NOMBRE_EMPRESA
    },
    factura: {
      numero: factura.numero,
      fecha: factura.fecha.toISOString(),
      tipo: "F1", // Factura completa
      destinatario: {
        nif: cliente.nif,
        nombre: cliente.nombre
      },
      desglose: factura.lineas.map(l => ({
        concepto: l.descripcion,
        base: l.base,
        tipo_iva: l.tipo_iva,
        cuota_iva: l.cuota_iva
      })),
      total: factura.total
    }
  };

  const response = await fetch('https://api.verifactuapi.es/v1/registros', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.VERIFACTU_API_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(payload)
  });

  if (!response.ok) {
    throw new Error(`Error VeriFactu: ${response.status}`);
  }

  const resultado = await response.json();

  // Guardas el ID del registro para trazabilidad
  await db.facturas.update(factura.id, {
    verifactu_id: resultado.id,
    huella: resultado.huella
  });
}

El código real dependerá del formato exacto de tu modelo de datos, pero la estructura es esta: tras crear la factura, envías los datos a la API que gestiona el cumplimiento.

Gestión de errores y reintentos

La comunicación con AEAT puede fallar por diversos motivos como caídas de servicio, problemas de red carga en picos de actividad. Tu aplicación debe contemplar que estas situaciones pueden darse de forma más o menos habitual.

Es importante que tu sistema no bloquee la emisión de facturas en caso de que falle el envío a AEAT o a la API. Deberás guardar el registro como pendiente y reintentar:

async function enviarAVerifactu(factura) {
  try {
    // ... código de envío ...

    await db.facturas.update(factura.id, {
      verifactu_estado: 'enviado',
      verifactu_id: resultado.id
    });
  } catch (error) {
    // Marcas como pendiente de reintento
    await db.facturas.update(factura.id, {
      verifactu_estado: 'pendiente',
      verifactu_error: error.message
    });

    // Opcionalmente, encolas para reintento automático
    await cola.add('reintento-verifactu', { factura_id: factura.id });
  }
}

Otra opción: usar webhooks para recibir confirmaciones asíncronas del envío a AEAT. Envías el registro, la API te responde inmediatamente con un ID, y luego te notifica por webhook cuando AEAT acepta o rechaza el registro.

Validación en desarrollo: entorno sandbox

Antes de ir a producción, necesitas validar que tus datos cumplen los requisitos de AEAT. Hacerlo directamente en el entorno real es arriesgado: envíos erróneos, registros de prueba mezclados con reales, consumo de certificados digitales en desarrollo.

La solución es trabajar con un entorno sandbox que replique la validación de AEAT sin enviar nada real. Puedes probar:

• Formatos de NIF/CIF
• Cálculo de huellas y encadenamiento
• Estructura de XML según XSD de AEAT
• Casos especiales: facturas rectificativas, simplificadas, intracomunitarias

El flujo de desarrollo queda:

1. Desarrollas tu SaaS localmente
2. Apuntas a sandbox de VeriFactu (sin certificado digital, sin tarjeta)
3. Pruebas casos reales: factura simple, con varios tipos de IVA, rectificativa
4. Validas que recibes respuestas correctas
5. Cambias a producción solo cuando está todo probado

Esto te evita descubrir problemas de formato cuando ya tienes clientes facturando.

Consideraciones para SaaS multitenant

Si tu aplicación da servicio a múltiples empresas (cada cliente del SaaS factura bajo su propio NIF), cada tenant necesita:

• Su propio certificado digital para firmar envíos a AEAT
• Cadenas de huellas independientes (no mezclas registros de distintas empresas)
• Configuración específica: series de facturación, datos fiscales

Al usar una API externa, la arquitectura típica es:

const payload = {
  emisor: {
    nif: tenant.nif, // NIF específico del tenant
    nombre: tenant.razon_social
  },
  certificado_id: tenant.certificado_id, // Referencia al certificado subido
  factura: { /* ... */ }
};

Cada tenant sube su certificado digital una vez, y todos sus registros se firman con ese certificado. La API gestiona el almacenamiento seguro de certificados y la firma por tenant.

Qué hacer con registros históricos

Si lanzas tu SaaS ahora, ¿qué pasa con las facturas emitidas antes de integrar el cumplimiento?

Según la lectura general de la normativa, los registros deben enviarse desde el momento en que el software cumple los requisitos de VeriFactu; las facturas anteriores no es necesario retrotraerlas. En la práctica:

• Activas VeriFactu en una fecha específica
• Desde esa fecha, todos los registros nuevos se encadenan y envían
• Registros anteriores quedan fuera del sistema VeriFactu (no se encadenan)

Si un cliente quiere regularizar histórico, tendrías que generar registros para esas facturas antiguas, pero no es obligatorio legalmente. Dicho esto, esta es una zona donde conviene confirmar con un asesor fiscal el caso concreto de cada cliente, sobre todo si hay periodos de adaptación o particularidades del sector de por medio.

Cuándo lanzar a producción

Tienes tu MVP funcionando, la integración con VeriFactu probada en sandbox, y estás listo para abrir el SaaS. ¿Qué necesitas antes de lanzar?

1. Certificado digital de producción. Si es tu propia empresa la que factura, necesitas el certificado de tu NIF. Si es un SaaS multitenant, necesitas que cada cliente suba el suyo.

2. Alta como colaborador social (opcional pero recomendable). Si tu SaaS gestiona facturación para terceros, es útil estar dado de alta como colaborador social de la AEAT. No es obligatorio, pero da cobertura legal adicional. En VerifactuAPI ya somos colaborador social, así que si delegas el cumplimiento en nosotros esta parte queda resuelta sin que tengas que tramitarla tú.

3. Pruebas de carga en entorno real. Sandbox replica validaciones, pero no carga real. Si tu SaaS espera emitir cientos de facturas diarias, prueba antes en producción con un cliente piloto.

4. Monitorización de envíos. Implementa logs de cada envío a AEAT: fecha, estado, errores. Si un cliente reporta un problema, necesitas trazabilidad completa.

Preguntas frecuentes

¿Es obligatorio VeriFactu para autónomos? Sí, desde el 1 de julio de 2026 para autónomos en estimación directa. Las sociedades están obligadas desde el 1 de enero de 2026.

¿Qué pasa si mi SaaS ya tiene clientes facturando sin VeriFactu? No necesitas regularizar el histórico: desde el momento en que activas el cumplimiento, los registros nuevos se encadenan y envían; los anteriores quedan fuera del sistema.

¿Necesito certificado digital para desarrollar? No. El sandbox permite probar todo el flujo: NIF, huellas, encadenamiento, XML. Sin certificado ni tarjeta.

¿VERI*FACTU y NO VERI*FACTU son lo mismo? No. Ambas modalidades exigen encadenar los registros con huella, pero solo VERI*FACTU envía cada registro a la AEAT en tiempo real vía SOAP; NO VERI*FACTU mantiene los registros listos para exhibirlos si se piden.