API de Verifactu de la AEAT: guía técnica en español

API de Verifactu de la AEAT: guía técnica en español

por

Publicado el 25/9/2026 · Actualizado el 22/10/2026

La «API de Verifactu» son, en realidad, unos servicios web SOAP de la AEAT a los que tu sistema de facturación envía los registros de facturación. Si desarrollas o mantienes un programa, aquí tienes lo esencial en español y en un solo sitio: endpoints, autenticación, estructura del mensaje, límites, respuestas y cálculo de la huella, con enlaces a cada documento oficial.

Actualización del 6 de octubre de 2026: Hacienda anunció el 5 de octubre que aplazará Verifactu hasta octubre de 2028. Aún no está en el BOE: hasta entonces siguen vigentes las fechas de 2027. Qué se sabe y qué cambia para ti: Verifactu aplazado a 2028.

Nota de transparencia: esta guía resume la documentación técnica publicada por la AEAT (descripción de los servicios web v1.0.3 de 28/07/2025, WSDL, especificación de la huella y Orden HAC/1177/2024), consultada el 25 de septiembre de 2026. No sustituye a esa documentación, que prevalece en caso de discrepancia. El ejemplo de huella lo hemos reproducido y coincide con el valor oficial.

Respuesta rápida: la AEAT expone un servicio SOAP 1.1 (estilo document/literal, UTF-8) descrito en el WSDL SistemaFacturacion.wsdl, con la operación RegFactuSistemaFacturacion para enviar altas y anulaciones y ConsultaFactuSistemaFacturacion para consultar. Te autenticas con un certificado electrónico cualificado. Cada envío admite hasta 1.000 registros y debes respetar el control de flujo (inicialmente 60 segundos entre envíos, valor que devuelve la AEAT en TiempoEsperaEnvio). Hay entorno de pruebas en prewww1.aeat.es y portal de pruebas externas.

Qué servicio necesitas según la modalidad

Modalidad Qué envías Servicio
VERI*FACTU Todos los registros de alta y anulación, de forma continua VerifactuSOAP (remisión voluntaria)
No VERI*FACTU Nada de forma continua; conservas los registros firmados (XAdES Enveloped) y los envías solo si la AEAT te lo requiere RequerimientoSOAP

El esquema XML es el mismo en ambos casos, lo que facilita pasar de una modalidad a otra. Según las preguntas frecuentes de la AEAT, la modalidad VERI*FACTU no exige firmar electrónicamente los registros; los sistemas «No VERI*FACTU», en cambio, deben firmarlos y llevar además un registro de eventos. La consulta de registros presentados solo está disponible en remisión voluntaria VERI*FACTU. Diferencias funcionales entre modalidades en qué es Verifactu.

Endpoints (según el WSDL oficial)

Uso URL
VERI*FACTU, producción https://www1.agenciatributaria.gob.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP
VERI*FACTU, producción (certificado de sello) https://www10.agenciatributaria.gob.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP
VERI*FACTU, pruebas https://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP
VERI*FACTU, pruebas (certificado de sello) https://prewww10.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP
Requerimiento (No VERI*FACTU), producción https://www1.agenciatributaria.gob.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/RequerimientoSOAP (y equivalentes en www10, prewww1 y prewww10)

Descarga el WSDL y los XSD (SuministroLR.xsd, SuministroInformacion.xsd, ConsultaLR.xsd, RespuestaSuministro.xsd, RespuestaConsultaLR.xsd) desde la página de WSDL de los servicios web y genera tu cliente a partir de ellos; no copies URLs de terceros sin contrastarlas.

Autenticación y quién puede enviar

  • Conexión HTTPS con certificado electrónico cualificado (de persona física, representante o sello).
  • Puede enviar el propio obligado tributario, un apoderado para este trámite o un colaborador social. En la cabecera existe un campo Representante para casos de colaboración social.
  • Todos los NIF se validan contra la base de datos de la AEAT: en pruebas, usa NIF que existan o los de ejemplo de la documentación.

Estructura del mensaje

El cuerpo SOAP contiene un elemento RegFactuSistemaFacturacion con una Cabecera (obligado a la emisión: nombre y NIF) y una lista de RegistroFactura, cada uno con un RegistroAlta o un RegistroAnulacion. Un mismo envío puede mezclar altas y anulaciones. Versión simplificada de un alta, basada en el ejemplo oficial:

<sum:RegFactuSistemaFacturacion>
  <sum:Cabecera>
    <sum1:ObligadoEmision>
      <sum1:NombreRazon>EMPRESA EJEMPLO SL</sum1:NombreRazon>
      <sum1:NIF>B00000000</sum1:NIF>
    </sum1:ObligadoEmision>
  </sum:Cabecera>
  <sum:RegistroFactura>
    <sum1:RegistroAlta>
      <sum1:IDVersion>1.0</sum1:IDVersion>
      <sum1:IDFactura>
        <sum1:IDEmisorFactura>B00000000</sum1:IDEmisorFactura>
        <sum1:NumSerieFactura>2026-A-0087</sum1:NumSerieFactura>
        <sum1:FechaExpedicionFactura>25-09-2026</sum1:FechaExpedicionFactura>
      </sum1:IDFactura>
      <sum1:NombreRazonEmisor>EMPRESA EJEMPLO SL</sum1:NombreRazonEmisor>
      <sum1:TipoFactura>F1</sum1:TipoFactura>
      <sum1:DescripcionOperacion>Servicios de consultoría</sum1:DescripcionOperacion>
      <sum1:Destinatarios>...</sum1:Destinatarios>
      <sum1:Desglose>
        <sum1:DetalleDesglose>
          <sum1:ClaveRegimen>01</sum1:ClaveRegimen>
          <sum1:CalificacionOperacion>S1</sum1:CalificacionOperacion>
          <sum1:TipoImpositivo>21</sum1:TipoImpositivo>
          <sum1:BaseImponibleOimporteNoSujeto>100</sum1:BaseImponibleOimporteNoSujeto>
          <sum1:CuotaRepercutida>21</sum1:CuotaRepercutida>
        </sum1:DetalleDesglose>
      </sum1:Desglose>
      <sum1:CuotaTotal>21</sum1:CuotaTotal>
      <sum1:ImporteTotal>121</sum1:ImporteTotal>
      <sum1:Encadenamiento>...</sum1:Encadenamiento>
      <sum1:SistemaInformatico>...</sum1:SistemaInformatico>
      <sum1:FechaHoraHusoGenRegistro>2026-09-25T10:15:00+02:00</sum1:FechaHoraHusoGenRegistro>
      <sum1:TipoHuella>01</sum1:TipoHuella>
      <sum1:Huella>...</sum1:Huella>
    </sum1:RegistroAlta>
  </sum:RegistroFactura>
</sum:RegFactuSistemaFacturacion>

Puntos que suelen dar guerra:

  • El registro se identifica por IDEmisorFactura + NumSerieFactura + FechaExpedicionFactura (formato DD-MM-AAAA).
  • Encadenamiento: en el primer registro del sistema se indica PrimerRegistro = S; en los demás, los datos y la huella del registro anterior.
  • SistemaInformatico identifica tu software (productor, NIF, nombre, identificador, versión, número de instalación y tipo de uso). Debe coincidir con lo declarado en tu declaración responsable.
  • Valores numéricos sin ceros a la izquierda, punto como separador decimal.

Límites y control de flujo

  • Máximo 1.000 registros por envío.
  • Control de flujo (art. 16.2 de la Orden HAC/1177/2024): tras cada envío, la AEAT devuelve TiempoEsperaEnvio (inicialmente 60 segundos). El siguiente envío solo puede hacerse cuando pasen esos segundos o cuando acumules 1.000 registros, lo que ocurra primero.
  • Implementa una cola: la factura se expide aunque el envío espere, y el registro se remite en el siguiente lote permitido.

Respuestas y errores

Nivel Valores Qué hacer
Envío completo Correcto, ParcialmenteCorrecto, Incorrecto Procesa la respuesta registro a registro
Cada registro Correcto, AceptadoConErrores, Incorrecto Subsana los rechazados y los aceptados con errores (salvo que proceda rectificativa o anulación) y reenvíalos
SOAP Fault soapenv:Client XML mal formado o cabecera errónea Corrige según faultstring antes de reenviar
SOAP Fault soapenv:Server o sin respuesta Incidencia en el servicio Reenvía el mensaje

Si se acepta al menos un registro, la respuesta incluye un CSV (código seguro de verificación) que acredita la remisión: la documentación pide que tu sistema lo almacene. En remisiones por requerimiento, en cambio, no debes subsanar errores de negocio: se envían los registros tal como se conservaron.

La huella (hash) encadenada

Cada registro lleva una huella SHA-256 calculada sobre una cadena con campos concretos, en este orden para un alta:

IDEmisorFactura=…&NumSerieFactura=…&FechaExpedicionFactura=…&TipoFactura=…&CuotaTotal=…&ImporteTotal=…&Huella=…&FechaHoraHusoGenRegistro=…

  • Huella es la del registro anterior; en el primer registro va vacío (Huella=).
  • Se eliminan espacios al inicio y al final de cada valor; en importes, 123.1 y 123.10 son equivalentes.
  • La cadena se codifica en UTF-8 y el resultado se expresa en hexadecimal, en mayúsculas (64 caracteres).
  • Las anulaciones y los registros de evento usan otros campos; consúltalos en la especificación.

Ejemplo reproducible (caso 1 de la especificación oficial) en Python:

import hashlib
cadena = ("IDEmisorFactura=89890001K&NumSerieFactura=12345678/G33"
          "&FechaExpedicionFactura=01-01-2024&TipoFactura=F1"
          "&CuotaTotal=12.35&ImporteTotal=123.45&Huella="
          "&FechaHoraHusoGenRegistro=2024-01-01T19:20:30+01:00")
print(hashlib.sha256(cadena.encode("utf-8")).hexdigest().upper())
# 3C464DAF61ACB827C65FDA19F352A4E3BDC2C640E9E9FC4CC058073F38F12F60

Ese es exactamente el valor que publica la AEAT. Úsalo como test unitario de tu implementación.

QR y cotejo

La factura impresa o en PDF incluye un QR con una URL del servicio de cotejo de la AEAT (NIF, número de serie, fecha e importe). Lo explicamos campo a campo en el código QR de Verifactu, y puedes validar las URL que genera tu software con nuestro comprobador de QR.

Entorno de pruebas

  • Los endpoints prewww1.aeat.es y prewww10.aeat.es permiten enviar sin efectos tributarios.
  • El portal de pruebas externas de la AEAT reúne los servicios de prueba (incluida una versión de la aplicación gratuita).
  • Necesitas igualmente un certificado cualificado válido.
  • Prueba especialmente: primer registro, encadenamiento tras una anulación, lotes de 1.000, respeto de TiempoEsperaEnvio, reintentos ante SOAP Fault y subsanación de AceptadoConErrores.

Checklist de implementación

  1. Genera el cliente SOAP desde el WSDL y los XSD oficiales.
  2. Guarda en una única transacción la factura y su registro de facturación.
  3. Calcula la huella con los tests oficiales y encadena correctamente.
  4. Implementa cola, control de flujo y reintentos.
  5. Almacena respuestas y CSV; gestiona subsanaciones.
  6. Genera el QR según la especificación y añade «VERI*FACTU» en modalidad VERI*FACTU.
  7. Publica la declaración responsable de tu sistema (fabricantes).

Más recursos técnicos en la sección de desarrolladores.

Si no vas a desarrollar tu propia integración y prefieres un programa que ya envíe los registros por ti, revisa nuestra comparativa de programas compatibles con Verifactu.

Preguntas frecuentes

¿Es una API REST?

No. Son servicios web SOAP 1.1 con mensajes XML definidos por esquemas XSD.

¿Puedo usar un certificado de sello de empresa?

Sí: el WSDL incluye endpoints específicos para certificado de sello (www10 y prewww10).

¿Cuándo es obligatorio para los fabricantes?

Los productores de software debían ofrecer sistemas adaptados desde el 29 de julio de 2025. Para los usuarios, las fechas son el 1/1/2027 (sociedades) y el 1/7/2027 (resto), según el RDL 15/2025, en tramitación parlamentaria. Ver fechas de Verifactu.

¿Existen APIs de terceros que simplifiquen esto?

Sí, varios proveedores ofrecen APIs propias sobre los servicios de la AEAT. Si usas una, sigue siendo tu responsabilidad que el sistema cumpla; pide su declaración responsable.

Fuentes oficiales

Aviso: contenido informativo que no constituye asesoramiento fiscal, jurídico ni técnico vinculante. Revisado el 25 de septiembre de 2026 con la documentación técnica de la AEAT y el BOE. La documentación oficial prevalece: consúltala antes de desplegar en producción. Más información en nuestra metodología editorial.