Cómo implementar Verifactu en tu software: API propia, Holded, Odoo o BeeL.

#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 2026, 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 Holded

#La promesa

Holded es uno de los softwares de gestión más populares en España. Tiene API, tiene documentación, y muchas empresas ya lo usan para facturar. Parece la opción obvia para integrar VeriFactu.

#La realidad

Hemos tenido clientes que empezaron con Holded y acabaron migrando. Y no por capricho. Estos son los problemas reales que nos han reportado:

Problema 1: Rate limits que no escalan

“Empezamos con Holded porque ya lo usábamos internamente. Todo iba bien en desarrollo y con pocos clientes. Pero cuando llegamos a 100 peticiones por minuto, el sistema se ralentizaba hasta ser inutilizable. Para un SaaS con 50 clientes activos facturando a la vez, 100 peticiones por minuto es nada.”

— Cliente real, empresa SaaS con +200 usuarios

100 peticiones por minuto. Suena a mucho hasta que haces las cuentas:

• Crear factura: 1 petición
• Obtener datos del cliente: 1 petición
• Validar serie: 1 petición
• Confirmar creación: 1 petición

Son 4 peticiones por factura. Con 100 req/min, puedes crear 25 facturas por minuto. Si tu SaaS tiene 50 clientes facturando al mismo tiempo a final de mes… haz las cuentas.

Y cuando llegas al límite, no es un error 429 limpio con un Retry-After. El rendimiento simplemente se degrada. Las peticiones tardan 10, 15, 30 segundos. Timeouts. Errores intermitentes. Es impredecible.

Problema 2: Documentación desactualizada

“La documentación de la API dice una cosa, el comportamiento real dice otra. Pasamos dos semanas debuggeando un error de validación porque el campo que la documentación marcaba como opcional era obligatorio en producción.”

Esto lo hemos escuchado de más de un cliente. Los endpoints cambian, los campos se renombran, los ejemplos no funcionan. Y cuando abres un ticket de soporte… la respuesta llega en días, no en horas.

Problema 3: No es una API pensada para integradores

La API de Holded fue diseñada para que sus clientes automaticen sus tareas. No para que un tercero construya un producto encima. Esto se nota en:

• No hay sandbox: Pruebas contra producción o nada
• No hay webhooks fiables: Polling constante para detectar cambios
• Autenticación limitada: Un token por cuenta, sin OAuth, sin scopes granulares
• Sin soporte multi-tenant nativo: Si tu SaaS gestiona 100 empresas, necesitas 100 cuentas de Holded

#El coste oculto

Holded cobra por usuario y por funcionalidad. Si tu modelo es ofrecer facturación como parte de tu SaaS, estás pagando una licencia de Holded por cada cliente tuyo. Los números no cuadran rápido.

#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

#Caso real: migración de Holded a BeeL.

Uno de nuestros clientes actuales es un SaaS de gestión para clínicas dentales con más de 200 clínicas como usuarios. Empezaron usando la API de Holded para la facturación.

#El problema

A final de mes, cuando las 200 clínicas generaban facturas simultáneamente, Holded se saturaba. Las peticiones que normalmente tardaban 200ms pasaban a tardar 15-30 segundos. Algunas fallaban directamente. Y los errores no eran consistentes: a veces timeout, a veces 500, a veces respuestas corruptas.

El equipo de desarrollo pasaba el primer día de cada mes apagando fuegos en vez de desarrollando funcionalidades nuevas.

#La migración

La integración con BeeL. les llevó 3 días. No 3 días de un equipo completo — 3 días de un solo desarrollador. El lunes leyó la documentación y configuró el entorno de sandbox. El martes migró el código de integración. El miércoles hicieron pruebas con datos reales en staging.

#El resultado

El primer fin de mes con BeeL.: cero incidencias. Las peticiones se procesaban en menos de 300ms de media, incluso con las 200 clínicas facturando a la vez. El equipo de desarrollo se pudo dedicar a lo que realmente importa: mejorar su producto.

#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, rate limits de Holded o módulos desactualizados de Odoo.

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

• ¿Necesitas control total y tienes equipo? Implementación directa contra la AEAT
• ¿Ya usas Holded/Odoo y tu volumen es bajo? Quédate donde estás
• ¿Eres un SaaS, un integrador o simplemente quieres que funcione? Prueba BeeL.