Cómo Implementar Verifactu en tu Software: AEAT, ERPs y APIs

#El problema real: tu software necesita cumplir Verifactu

Si desarrollas un ERP, un SaaS de gestión, una app de facturación o cualquier software que emita facturas en España, ya lo sabes: desde enero de 2027 (empresas) y julio de 2027 (autónomos), tu sistema debe cumplir con el reglamento VeriFactu (RD 1007/2023).

Y no, no vale con “generar un PDF bonito”. Tu software necesita:

• ✗Generar registros de facturación con firma electrónica (hash encadenado SHA-256)
• ✗Enviar los registros a la AEAT en formato XML firmado
• ✗Garantizar la inalterabilidad y trazabilidad de cada factura
• ✗Incluir un código QR verificable en cada factura
• ✗Mantener una cadena de bloques interna entre registros

La pregunta no es si tienes que hacerlo. Es cómo.

Y aquí es donde la mayoría de equipos de desarrollo pierden semanas (o meses) evaluando opciones, peleándose con documentación desactualizada y descubriendo rate limits en producción que nadie les avisó.

Este artículo es la guía que nos habría gustado tener. Vamos a comparar las 4 opciones reales que tienes, con sus ventajas, problemas y casos reales de clientes que ya han pasado por esto.

#Las 4 opciones para integrar Verifactu

Vamos una por una.

#Opción 1: Implementación directa contra la AEAT (raw)

#Qué implica

Implementar VeriFactu directamente significa que tu software se comunica con los servicios web de la Agencia Tributaria sin intermediarios. Suena bien en teoría. En la práctica, es un proyecto de ingeniería de varios meses.

#Lo que necesitas construir

• ✗Parser y generador de XML según el esquema SuministroLR de la AEAT
• ✗Firma electrónica con certificado digital (PKCS#12 / X.509)
• ✗Generación de hash SHA-256 encadenado entre registros
• ✗Sistema de cola de envío con reintentos y gestión de errores SOAP
• ✗Almacenamiento inmutable del registro de facturación (no solo la factura)
• ✗Generación de código QR con URL de verificación de la AEAT
• ✗Gestión de certificados digitales (renovación, múltiples empresas)
• ✗Validación contra el esquema XSD oficial
• ✗Manejo de los diferentes tipos de registro: alta, anulación, subsanación
• ✗Testing contra el entorno de pruebas de la AEAT (que tiene sus propios problemas)

#El código real que hay que escribir

Para que te hagas una idea, así se ve el XML que hay que generar para un solo registro de facturación:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:sii="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SusFacturas.wsdl">
  <soapenv:Header/>
  <soapenv:Body>
    <sii:SuministroLRFacturasEmitidas>
      <sii:Cabecera>
        <sii:IDVersionSif>1.0</sii:IDVersionSif>
        <sii:Titular>
          <sii:NombreRazon>Tu Empresa SL</sii:NombreRazon>
          <sii:NIF>B12345678</sii:NIF>
        </sii:Titular>
      </sii:Cabecera>
      <sii:RegistroFactura>
        <sii:IDFactura>
          <sii:IDEmisorFactura>B12345678</sii:IDEmisorFactura>
          <sii:NumSerieFacturaEmisor>2026/001</sii:NumSerieFacturaEmisor>
          <sii:FechaExpedicionFacturaEmisor>01-01-2026</sii:FechaExpedicionFacturaEmisor>
        </sii:IDFactura>
        <sii:PeriodoLiquidacion>
          <sii:Ejercicio>2026</sii:Ejercicio>
          <sii:Periodo>01</sii:Periodo>
        </sii:PeriodoLiquidacion>
        <!-- ... 50+ campos más -->
        <sii:Huella>
          <sii:Encadenamiento>
            <sii:PrimerRegistro>S</sii:PrimerRegistro>
          </sii:Encadenamiento>
          <sii:Hash>a1b2c3d4e5f6...</sii:Hash>
        </sii:Huella>
      </sii:RegistroFactura>
    </sii:SuministroLRFacturasEmitidas>
  </soapenv:Body>
</soapenv:Envelope>

Y esto es solo el envío. Luego tienes que gestionar la respuesta, los errores, los reintentos, las rectificativas, las anulaciones…

#Problemas reales

• Documentación de la AEAT: Técnicamente existe, pero está dispersa entre BOEs, PDFs técnicos y esquemas XSD. No hay una documentación de API moderna con ejemplos y sandbox funcional.
• Certificados digitales: Cada empresa necesita su certificado. Gestionar la renovación, el almacenamiento seguro y el multi-tenant es un proyecto en sí mismo.
• Entorno de pruebas: El entorno de pruebas de la AEAT no siempre refleja el comportamiento de producción. Y se cae más de lo que debería.
• Tiempo de desarrollo: Según nuestra experiencia y la de clientes que lo han intentado, estás mirando 3-6 meses de desarrollo para un equipo de 2-3 personas. Y eso sin contar el mantenimiento cuando la AEAT cambie algo.

#Cuándo tiene sentido

• Eres una empresa grande con un equipo de desarrollo dedicado
• Necesitas control absoluto sobre cada aspecto del proceso
• Ya tienes experiencia con servicios web de la AEAT (SII, etc.)
• Tu volumen justifica la inversión (miles de facturas al día)

#Opción 2: Integrar con la API de una plataforma ERP de propósito general

En el mercado español existen varias plataformas de gestión empresarial (ERP) que exponen una API para que sus propios usuarios automaticen tareas internas: sincronizar productos, generar facturas desde un flujo interno, exportar datos a contabilidad. Si tu producto es un ERP y tu objetivo es automatizar dentro de él, integrar contra esa API tiene sentido.

#Qué tener en cuenta si tu producto NO es un ERP

Cuando intentas montar un producto de terceros (un SaaS vertical, un marketplace, una pasarela de facturación dentro de tu propia aplicación) encima de una API que fue diseñada para los clientes finales del ERP, conviene validar varios puntos antes de comprometerse:

• Diseño de la API: ¿es una API “primera clase” del producto o un complemento? Revisa si dispone de OpenAPI, SDKs oficiales y un changelog mantenido.
• Sandbox: ¿puedes probar contra un entorno separado de producción?
• Webhooks vs polling: ¿hay eventos en tiempo real para los cambios que te importan o tienes que ir a buscarlos?
• Modelo multi-tenant: si tu producto gestiona varias empresas finales, ¿la API te permite hacerlo sin abrir una cuenta del ERP por cada empresa?
• Rate limits: revisa los límites publicados (peticiones por minuto/día) y cómo se comporta la API cerca del límite. Para muchos ERP los límites están dimensionados para uso interno, no para integraciones intensivas de terceros.
• Coste del modelo de licencia: muchos ERP facturan por usuario o por organización. Si tu propio producto va a multiplicar el número de cuentas necesarias, calcula el coste a escala antes de comprometerte.

Cada plataforma publica sus propios términos. Antes de elegirla como backend de facturación de tu producto, consulta su documentación pública vigente y, si es posible, valida con una prueba de concepto a tu volumen real.

#Cuándo tiene sentido

• Tu producto es ese ERP, o es una extensión sobre él, y vas a operar con uno o pocos tenants.
• Tu volumen es predecible y encaja con los límites publicados.
• Ya tienes una licencia y experiencia con esa plataforma.

#Cuándo conviene mirar alternativas

• Tu producto es un SaaS independiente que necesita emitir facturas Verifactu para muchos clientes finales distintos.
• Necesitas SLAs claros, sandbox y webhooks de primera clase desde el primer día.
• Tu modelo de pricing no soporta cargar el coste de una licencia de ERP por cada uno de tus clientes.

#Opción 3: Integrar con Odoo

#La promesa

Odoo es open source (Community Edition), tiene módulos de facturación española, y su API XML-RPC/JSON-RPC permite integraciones profundas. Parece la opción “libre” y flexible.

#La realidad

Problema 1: Rate limits ridículos

El problema número uno que nos reportan los que intentan usar Odoo como backend de facturación: los rate limits son extremadamente restrictivos.

En Odoo SaaS (la versión cloud), dependiendo del plan, puedes encontrarte con límites que hacen inviable cualquier operación en lote:

• Consultas limitadas que se agotan rápidamente con operaciones normales
• Si necesitas migrar datos, importar facturas históricas o sincronizar en tiempo real con tu sistema… prepárate para esperar

Y si hosteas Odoo tú mismo para evitar los rate limits… ahora tienes un servidor Odoo que mantener. Con sus actualizaciones, su seguridad, su rendimiento. Has intercambiado un problema por otro más grande.

Problema 2: Complejidad del módulo de facturación española

El módulo de localización española de Odoo (l10n_es) existe, pero:

• No siempre está al día con los cambios normativos: El reglamento VeriFactu tiene requisitos muy específicos y los módulos comunitarios tardan en adaptarse
• Configuración no trivial: Configurar correctamente series, tipos impositivos, retenciones, IRPF, recargo de equivalencia… requiere conocimiento profundo tanto de Odoo como de la fiscalidad española
• Módulos de terceros: Para VeriFactu completo, probablemente necesites un módulo de pago de un partner de Odoo. Y esos módulos tienen su propia calidad, documentación y soporte

Problema 3: Sin idempotencia — facturas duplicadas

Este es el problema que más dolores de cabeza causa: la API de Odoo no soporta idempotencia. No hay un Idempotency-Key ni ningún mecanismo nativo para evitar duplicados.

¿Qué significa esto en la práctica? Si tu petición de crear factura falla por un timeout de red pero Odoo sí la procesó internamente, al reintentar automáticamente creas una segunda factura idéntica. Y con VeriFactu, esa factura duplicada ya se ha enviado a la AEAT, con su hash encadenado y todo. Arreglarlo implica anulaciones, rectificativas y romper la cadena de registros.

En un SaaS que procesa cientos de facturas al día, esto pasa más de lo que imaginas. Conexiones inestables, timeouts, reintentos automáticos de tu HTTP client… cada uno es una factura duplicada potencial. Y descubrirlo después, cuando el cliente ya tiene dos facturas con números distintos por el mismo concepto, es un caos contable.

Problema 4: La API no es REST

Odoo usa XML-RPC (legacy) o JSON-RPC. No es REST. No hay OpenAPI spec. No hay SDKs oficiales modernos.

# Así se crea una factura en Odoo via XML-RPC
import xmlrpc.client
 
url = 'https://tu-odoo.com'
db = 'tu-base-de-datos'
uid = common.authenticate(db, 'user', 'password', {})
 
# Crear factura
invoice_id = models.execute_kw(db, uid, password,
    'account.move', 'create', [{
        'move_type': 'out_invoice',
        'partner_id': 42,
        'invoice_line_ids': [(0, 0, {
            'name': 'Servicio',
            'quantity': 1,
            'price_unit': 100.0,
            'tax_ids': [(6, 0, [tax_id])],
        })],
    }])
 
# Confirmar factura
models.execute_kw(db, uid, password,
    'account.move', 'action_post', [[invoice_id]])

Funciona, pero comparado con una API REST moderna con tipos, validaciones y documentación interactiva… es otra época.

#Cuándo tiene sentido

• Ya tienes Odoo desplegado y tu equipo lo conoce
• Tu volumen es bajo (pocas facturas al día)
• Tienes un partner de Odoo de confianza para el módulo VeriFactu
• No necesitas rendimiento en tiempo real

#Opción 4: API de BeeL.

#El enfoque

BeeL. se diseñó desde el día 1 como una API de facturación para desarrolladores e integradores. No es un ERP con API bolted-on. Es una API con un dashboard como interfaz adicional.

#Cómo se integra VeriFactu

curl -X POST https://app.beel.es/api/v1/invoices \
  -H "Authorization: Bearer tu_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "series": "F",
    "customer": {
      "name": "Cliente Ejemplo SL",
      "tax_id": "B87654321",
      "address": {
        "street": "Calle Mayor 1",
        "city": "Madrid",
        "postal_code": "28001",
        "country": "ES"
      }
    },
    "lines": [
      {
        "description": "Desarrollo web - Marzo 2026",
        "quantity": 1,
        "unit_price": 2500.00,
        "tax_rate": 21
      }
    ]
  }'

Eso es todo. Una petición. BeeL. se encarga de:

• ✓Generar el registro de facturación SIF compliant
• ✓Calcular y aplicar el hash SHA-256 encadenado
• ✓Firmar electrónicamente el registro
• ✓Enviar a la AEAT automáticamente (modo VERI*FACTU)
• ✓Generar el código QR de verificación
• ✓Almacenar el registro de forma inmutable

#Lo que lo diferencia

Rendimiento sin rate limits artificiales

No hay un límite de 100 peticiones por minuto. La API está diseñada para escalar con tu negocio. Hemos tenido integradores procesando miles de facturas por hora sin degradación.

Si tu SaaS tiene un pico a final de mes porque todos tus clientes facturan a la vez, la API aguanta. Sin timeouts, sin degradación, sin sorpresas.

Documentación que funciona

• OpenAPI 3.0 completa: Descárgala, impórtala en Postman, genera tu cliente tipado
• Documentación interactiva: Prueba los endpoints directamente desde el navegador
• Ejemplos reales: Cada endpoint tiene ejemplos de request y response que funcionan
• Changelog: Cada cambio documentado, sin sorpresas

Webhooks nativos

No necesitas hacer polling. Cuando una factura se crea, se modifica o se anula, recibes un webhook en tiempo real:

{
  "event": "invoice.created",
  "data": {
    "id": "inv_abc123",
    "number": "F-2026/001",
    "total": 3025.00,
    "status": "confirmed",
    "verifactu_status": "sent",
    "pdf_url": "https://app.beel.es/api/v1/invoices/inv_abc123/pdf",
    "qr_verification_url": "https://..."
  },
  "timestamp": "2026-04-01T10:30:00Z"
}

Firmados con HMAC-SHA256 para que puedas verificar que vienen de BeeL. y no de un tercero.

Multi-tenant nativo

Si tu SaaS gestiona múltiples empresas, no necesitas una cuenta por empresa. Una sola integración, múltiples organizaciones. Cada una con su certificado, sus series, su configuración fiscal.

Pensado para AI y automatización

BeeL. expone un archivo llms.txt compatible con agentes de IA (Claude, ChatGPT, Cursor, Copilot). Tus desarrolladores pueden usar sus herramientas de IA favoritas para explorar la API y generar código de integración sin salir de su IDE.

#Comparativa directa

Las características marcadas como “variable” dependen del producto concreto: revisa la web pública y la documentación oficial de cada plataforma antes de decidir.

#Tiempos de integración reales con BeeL.

Como referencia de orden de magnitud para equipos técnicos que estén evaluando opciones: en BeeL. hemos integrado proyectos completos (descubrimiento + sandbox + paso a producción) en cuestión de pocos días para un único desarrollador, cuando el caso de uso era estrictamente facturación Verifactu sobre una API REST con OpenAPI, webhooks firmados y multi-tenant nativo.

Esto no significa que tu integración vaya a tardar exactamente eso — depende del estado de tu propio sistema, de tus casos de uso fiscales (rectificativas, anulaciones, recargo de equivalencia, IRPF, multi-serie…) y de tu cobertura de pruebas. Pero sí es un punto de referencia útil para dimensionar el esfuerzo frente a una implementación raw contra la AEAT.

#Cómo empezar con BeeL. en 15 minutos

Si quieres probar la integración antes de comprometerte, esto es lo que necesitas:

#1. Crea una cuenta y obtén tu API key

Regístrate en beel.es y genera tu API key desde el dashboard. No necesitas tarjeta de crédito para empezar.

#2. Explora la documentación

Abre docs.beel.es y prueba los endpoints directamente desde el navegador. O descarga la especificación OpenAPI e impórtala en tu herramienta favorita.

#3. Crea tu primera factura en sandbox

curl -X POST https://app.beel.es/api/v1/invoices \
  -H "Authorization: Bearer test_key_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "series": "TEST",
    "customer": {
      "name": "Test Company",
      "tax_id": "B00000000"
    },
    "lines": [
      {
        "description": "Test service",
        "quantity": 1,
        "unit_price": 100.00,
        "tax_rate": 21
      }
    ]
  }'

#4. Genera un cliente tipado

Si usas TypeScript:

npx openapi-typescript https://docs.beel.es/api/openapi -o ./beel-api.d.ts

Si usas otro lenguaje, openapi-generator soporta 50+ lenguajes.

#5. Configura webhooks

Desde el dashboard, añade la URL donde quieres recibir eventos. Empieza con invoice.created y ve añadiendo según necesites.

#Preguntas frecuentes

#Conclusión

Integrar VeriFactu no debería ser un proyecto de 6 meses. Si tu negocio es desarrollar software, tu tiempo debería ir a mejorar tu producto, no a pelear con XMLs de la AEAT, con rate limits de una API genérica o con módulos contables desactualizados.

Hay opciones. Elige la que se adapte a tu caso:

• ¿Necesitas control total y tienes equipo? Implementación directa contra la AEAT.
• ¿Ya usas un ERP o un Odoo internamente y el volumen es bajo? Quizá ya tengas la pieza que necesitas — valida los límites con un PoC.
• ¿Eres un SaaS, un integrador o simplemente quieres que funcione? Prueba BeeL..