Si tu SaaS, marketplace o ecommerce emite facturas desde TU plataforma (no desde Holded ni desde otro SIF compliant), por ley tu sistema tiene que cumplir Verifactu directamente. Implementamos firma SHA-256, cadena de huellas, QR de verificación y conexión SOAP a AEAT cumpliendo RD 1007/2023 + Orden HAC/1177/2024.
Una sociedad emisora, modo Verifactu o no-Verifactu. Casos multi-emisor: presupuesto custom.
Discovery → core → pre-producción AEAT → go-live con producción real.
Monitorización conjunta y resolución de incidencias mientras se estabiliza el sistema.
Si vuestra plataforma genera facturas (no solo las muestra), el sistema que las genera es el Sistema Informático de Facturación (SIF) y por ley tiene que cumplir Verifactu directamente. No vale poner Holded encima.
Tu producto factura desde su propio sistema (Stripe + lógica fiscal propia, billing engine custom, suscripciones gestionadas internamente). Por ley estás obligado a usar un Sistema Informático de Facturación (SIF) compliant — Verifactu o no-Verifactu — y tu Stripe nativo NO basta.
Marketplace donde los vendedores son terceros pero las facturas las emites tú. Caso complejo porque tienes que mantener la cadena de huellas por emisor (cada vendedor = su propia cadena) y enviar a AEAT en nombre de cada uno. Diseño no trivial.
Has construido tu emisor de facturas dentro de tu Shopify Plus / Magento / custom y NO usas Holded como SIF. O facturas desde n8n a partir de webhooks de Stripe. Necesitas que TU sistema sea SIF compliant — Holded en paralelo no resuelve el problema.
Asesorías que han desarrollado herramienta propia para gestionar cartera de clientes y que emite facturas. Ahora toca SIF compliant — sea por modo Verifactu o por no-Verifactu local con retención de huellas.
Cada factura genera su huella SHA-256 que incluye el hash de la anterior (encadenado tamper-evident). Implementación según la especificación exacta de la Orden HAC/1177/2024: orden de campos, normalización, encoding. Tests con casos límite (primera factura, rectificativas, anulaciones).
Generación del código QR con la URL de verificación de AEAT correcta (sede.agenciatributaria.gob.es). Incluido en el PDF/HTML de cada factura emitida. El cliente final puede escanearlo y validar contra AEAT que la factura es real.
Cliente SOAP que firma cada registro con tu certificado y lo envía al endpoint correspondiente (pre-producción y producción de AEAT). Manejo de respuestas, reintentos con backoff exponencial, logging de auditoría. Soporte para ambos endpoints (sociedades / autónomos).
Si decides operar en modo no-Verifactu (huellas se mantienen locales, AEAT las pide bajo inspección), implementamos la retención segura, la consulta por endpoints autorizados, y la generación de los registros de respuesta cuando la AEAT los solicite. Decisión Verifactu vs no-Verifactu la analizamos contigo según tu modelo de negocio.
Las facturas Verifactu NO se modifican ni eliminan — se rectifican con factura rectificativa que apunta a la original (con su propio hash, encadenado). Implementamos los flujos de rectificativa por sustitución, rectificativa por diferencias, y anulación según el caso fiscal correcto.
Tests automatizados que validan cada flujo contra los esquemas XSD oficiales de AEAT. Documentación técnica del módulo. Runbook de operación: qué monitorizar, qué hacer si AEAT devuelve error, cómo regenerar huellas si descubres bug retroactivo. Conocimiento traspasable a tu equipo.
Stack por defecto. Si vuestro backend es Python, PHP o Go, también lo hacemos — el patrón es el mismo, cambia el SDK. Para PHP especialmente común en ecommerce custom.
Implementación del cliente SOAP cumpliendo la firma electrónica que AEAT exige (XAdES-BES por defecto). Sin usar libs propietarias — código que cualquier dev competente pueda mantener.
Los esquemas XSD que publica AEAT son la fuente de verdad. Cada envío se valida contra ellos antes de salir. Si AEAT actualiza el schema, los tests fallan y sabemos qué tocar.
Carga, renovación, alertas de expiración. Si vuestro certificado caduca, lo sabéis con 30 días de antelación (no descubrís el día que falla un envío).
Cada huella generada, cada envío a AEAT, cada respuesta. En tu base de datos, con timestamps y firmas. Inspección AEAT = abrir el log. No reconstruir nada en caliente.
Módulo en TU repo, en TU CI/CD, en TU producción. Cero dependencia de servicios nuestros una vez entregado. Nosotros tenemos el código que escribimos para ti, pero el sistema funciona sin nosotros.
Análisis de tu flujo actual de facturación, identificación del SIF (qué sistema emite hoy), decisión Verifactu vs no-Verifactu, diseño del módulo dentro de tu arquitectura, definición de tests de aceptación. Salimos con spec técnica firmada antes de tocar producción.
Firma SHA-256 + cadena de huellas + QR. Tests unitarios sobre todos los casos: primera factura, factura N, rectificativa, anulación, edge cases de encoding/normalización. Validación contra XSD oficiales. Aún sin tocar AEAT real.
Conexión al entorno pre-producción de AEAT. Envíos de prueba con facturas ficticias. Validación de respuestas, manejo de errores, reintentos. Cuando todo funciona en pre-producción, certificación de que el código está listo para producción.
Switch a endpoint de producción AEAT con tu certificado real. Primeras facturas reales emitidas con Verifactu activo. Monitorización activa los primeros días. Documentación + runbook + traspaso a tu equipo. 30 días de soporte post go-live incluidos.
Porque vuestro SIF (Sistema Informático de Facturación) es VUESTRA plataforma, no Holded. La regulación obliga a que el sistema que EMITE la factura sea SIF compliant — no basta con que después la factura se importe a un sistema compliant. Si vuestro ecommerce / SaaS / marketplace genera la factura, ese sistema es el SIF y debe cumplir Verifactu directamente. Holded en paralelo no resuelve la obligación legal del sistema emisor original. (Sí podríais arquitectar el flujo para que Holded sea el emisor real y vuestra plataforma solo dispare la emisión vía API — pero eso suele ser cambio de arquitectura mayor que implementar Verifactu directamente).
El alcance estándar cubre un emisor Verifactu compliant para UNA plataforma con un solo emisor fiscal: firma SHA-256, cadena de huellas, QR, envío SOAP a AEAT en modo Verifactu, gestión de rectificativas, tests y documentación. Casos más complejos (multi-emisor en marketplace, múltiples sociedades emitiendo en paralelo, alta volumetría que requiere arquitectura de cola, integración con ERP existente que NO se puede tocar) aumentan el precio — lo evaluamos en discovery sin compromiso. Cifra concreta tras 60 min de discovery técnico.
No. TicketBai es el sistema equivalente en País Vasco (Bizkaia, Gipuzkoa, Álava) y es DISTINTO de Verifactu aunque conceptualmente similar (XSD propio, endpoints propios, calendarios propios por diputación). Para TicketBai sí lo hacemos pero es proyecto aparte (la regulación foral es distinta, las especificaciones técnicas también). Si tienes operación en País Vasco + resto de España, ambos sistemas pueden coexistir en la misma plataforma — lo evaluamos en discovery.
Navarra tiene su propio sistema (similar a TicketBai). Canarias tiene IGIC y sus propios requisitos de facturación pero NO un sistema equivalente a Verifactu específico — operáis bajo Verifactu nacional para AEAT. Para Navarra, proyecto aparte. Para Canarias, este servicio cubre — con la consideración de IGIC en el modelado de impuestos.
Sí, con plan de migración bien diseñado. Las primeras facturas Verifactu se emiten en paralelo (modo dry-run que genera huellas y QR pero no envía a AEAT) para validar que la lógica funciona contra tus casos reales. Cuando hay confianza, activamos envío real. El switch típico es en cambio de mes o cambio de año fiscal — antes del switch, facturáis como hasta ahora; después del switch, todas las nuevas facturas son Verifactu. El histórico anterior NO se reformatea (no es obligatorio retroactivamente).
Cambios en la especificación se anuncian con margen (mínimo 6-12 meses). El código está estructurado para que los cambios afecten a una capa concreta (validación, serialización, firma) sin reescribir el módulo entero. Mantenimiento futuro vía bolsa de horas o cuota cuando llegue el momento — coste proporcional al cambio. La regulación está estable desde RD 1007/2023 + RD-ley 15/2025 con la última revisión.
Lo hace Juan Cantón directamente, no juniors ni consultoría que subcontrata. Mismo perfil técnico que mantiene n8n-nodes-holded en npm y escribe los posts técnicos de este blog. Para proyectos de larga duración o muy complejos, podemos involucrar developers de confianza con experiencia equivalente, siempre con Juan como tech lead responsable.
60 minutos. Auditamos vuestro flujo de facturación actual, validamos si encajáis con el precio base o necesitamos custom, y salimos con plan y plazo cerrado.
