Cómo preparar una arquitectura que soporte VeriFactu y factura electrónica B2B sin confundir ambos contratos

La Orden HAC/1028/2026 se publicó el 5 de octubre de 2026 y entró en vigor el día 6. La propia orden establece que su entrada en vigor inicia el cómputo de los plazos de la Ley 18/2022 y del Real Decreto 238/2026 para la factura electrónica obligatoria entre empresarios y profesionales. Eso sitúa el primer gran hito, salvo modificación normativa posterior y sin olvidar la condición de excepción comunitaria prevista en la Ley 18/2022, en el 6 de octubre de 2027 para quienes superaron 8 millones de euros de volumen de operaciones y en el 6 de octubre de 2028 para el resto. En paralelo, RRSIF/VERI*FACTU sigue siendo el marco sobre comportamiento y registros de los sistemas informáticos de facturación. Ambos mundos comparten identidad documental, emisor, destinatario, importes, impuestos y trazabilidad, pero no deben implementarse como si un único endpoint o un único PDF resolviera todo. Esta guía propone una arquitectura por capas que permite reutilizar datos y adaptadores mientras mantiene separados los contratos fiscal y de intercambio B2B.

1. Empieza por separar contratos: registro fiscal no equivale a intercambio B2B

RRSIF/VERI*FACTU define requisitos que afectan al sistema que soporta el proceso de facturación: generación de registros, integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad. En la modalidad VERI*FACTU, además existe remisión de registros. El núcleo técnico necesita controlar identidad, secuencia, clasificación, preflight, envío, respuesta y reconciliación. Por eso una integración Kairoseth no deja esas decisiones repartidas entre plugins, hojas o agentes locales.

La factura electrónica B2B resuelve otra pregunta: cómo una factura electrónica se expide, se transmite, se recibe, se pone a disposición, se interconecta y comunica estados. El Real Decreto 238/2026 y la Orden HAC/1028/2026 desarrollan ese ecosistema con plataformas privadas y una solución pública. Compartir datos no elimina la diferencia de contrato. Un registro fiscal aceptado no implica que la factura B2B haya sido entregada o que su destinatario haya comunicado estado, y una factura electrónica intercambiada tampoco sustituye por sí sola las garantías del sistema de facturación.

2. El 6 de octubre de 2026 cambió el calendario B2B: ya existe un cómputo normativo en marcha

La Orden HAC/1028/2026 entró en vigor el 6 de octubre de 2026 y declara expresamente que esa entrada en vigor inicia los plazos previstos en la Ley 18/2022 y el Real Decreto 238/2026. La Ley diferencia a los empresarios y profesionales cuya facturación anual supera 8 millones de euros, para quienes el artículo 12 produce efectos al año del desarrollo reglamentario, y al resto, para quienes produce efectos a los dos años. La fecha de referencia operativa pasa así a ser 6 de octubre de 2027 y 6 de octubre de 2028 respectivamente, salvo cambios posteriores.

Hay que mantener una segunda cautela jurídica: la propia disposición final octava de la Ley 18/2022 condiciona la entrada en vigor de la obligación a la obtención de la excepción comunitaria respecto de los artículos 218 y 232 de la Directiva IVA. Por tanto, un roadmap comercial puede usar las fechas como calendario normativo actual, pero el gate de producción debe verificar BOE, AEAT y la condición comunitaria vigente en ese momento. El mensaje correcto es mucho más preciso que decir simplemente que 'todo llega en 2028'.

3. Reutiliza un modelo de factura común, no dos copias de la verdad comercial

ERP, ecommerce, CRM, Excel, TPV y software propio ya conocen hechos de negocio como emisor, destinatario, líneas, impuestos, importes, moneda, fechas y referencias. Esos hechos pueden normalizarse una vez en un modelo de dominio interno. A partir de ahí, el módulo VeriFactu genera o clasifica el registro fiscal que corresponda y el módulo B2B construye la factura electrónica estructurada y sus mensajes de intercambio. Duplicar mappings independientes para cada normativa multiplica errores de NIF, redondeo, series y rectificativas.

Compartir dominio no significa compartir autoridad. Campos derivados por el servidor, encadenamiento fiscal, entorno AEAT o credenciales no deben volver al sistema origen como reglas editables. Del mismo modo, identificadores de plataforma B2B, estados de entrega o pago y transformaciones UBL deben vivir en su contrato específico. El patrón correcto es una verdad comercial normalizada con dos adaptadores regulatorios separados y trazabilidad de qué versión de mapping produjo cada salida.

4. La factura B2B introduce formato estructurado, interoperabilidad y estados que VeriFactu no sustituye

La Orden HAC/1028/2026 desarrolla la solución pública con un modelo semántico apoyado en UBL y EN 16931, además de servicios para emisión, interconexión, copia fiel, consulta y comunicación de estados y pagos. Eso obliga a modelar mucho más que la presentación visual de una factura. El sistema debe saber qué documento estructurado fue transmitido, a través de qué canal, qué respuesta recibió y qué estado posterior comunicó el destinatario o la plataforma.

Por eso no es correcto presentar un QR o un XML de registros de facturación como si ya resolviera factura electrónica B2B. El PDF sigue pudiendo ser relevante como representación humana, pero el intercambio regulado se apoya en estructuras y servicios específicos. Kairoseth debe reutilizar su experiencia de colas, idempotencia y reconciliación, pero implementar el contrato B2B como una integración distinta, con sus propios schemas, validators, receipts y observabilidad.

5. Mantén dos máquinas de estados aunque compartan observabilidad

En VeriFactu importan estados como preparado, enviado, aceptado, rechazado, pendiente de reconciliación o bloqueado. En factura electrónica B2B aparecen además conceptos de puesta a disposición, recepción, aceptación, rechazo comercial, pago u otros estados definidos por el marco de intercambio. Si se colapsan en una sola columna status, tarde o temprano un equipo interpretará que 'aceptado' por AEAT significa 'aceptado por el cliente', o que una factura pagada ya no necesita resolver un fallo fiscal pendiente.

La solución es utilizar namespaces o agregados diferentes con una vista operativa común. Una factura puede mostrar fiscalState=accepted y b2bState=delivered, por ejemplo, sin perder la identidad compartida. La observabilidad puede correlacionar ambos journeys mediante invoiceId, sourceId y correlationId. De esa forma soporte ve el contexto completo y, al mismo tiempo, las automatizaciones nunca disparan una transición B2B a partir de un estado fiscal que no tiene ese significado.

6. Reutiliza idempotencia y outbox, pero no la misma clave ciegamente para todos los mensajes

Los dos marcos necesitan resistencia a timeouts, respuestas perdidas y reintentos. La infraestructura durable de Kairoseth ya utiliza identidad estable, outbox y reconciliación para evitar duplicados. Ese patrón es reutilizable en B2B, pero cada operación necesita su propia identidad semántica. Emitir un registro fiscal, transmitir una factura estructurada, comunicar un estado de pago o recuperar una respuesta son acciones distintas aunque pertenezcan a la misma factura comercial.

Una clave de idempotencia debería derivarse de actor, operación, documento y versión relevante, no únicamente del número de factura. Así una rectificación, un reenvío autorizado o un cambio de estado no colisiona con la emisión original. La arquitectura debe conservar receipts por canal y permitir reconciliación independiente. Compartir una cola física puede ser viable, pero los workers y políticas de retry deben respetar límites, backoff y semántica del servicio que realmente están llamando.

7. Los adapters de origen siguen siendo útiles: WooCommerce, PrestaShop, ERP, Excel y legacy no deben reescribirse dos veces

La inversión hecha para extraer hechos comerciales de WooCommerce, PrestaShop, ERP/CRM, software propio, CSV/XLSX o Local Agent puede seguir siendo válida para factura electrónica. El conector debe producir un contrato interno estable y no XML regulatorio específico. Así, cuando una obligación nueva requiere más campos, se amplía el mapping de dominio y el adapter regulatorio, no se duplica cada integración de origen desde cero.

Esta separación también facilita compatibilidad. HPOS, hooks de PrestaShop, una API de ERP o una consulta read-only SQL cambian por razones del sistema origen. UBL, estados B2B o reglas AEAT cambian por normativa. Si ambas capas están pegadas, cada actualización se convierte en una release transversal. Si están desacopladas, podemos probar el source adapter con Contract Suite y el regulatory adapter con fixtures y sandbox propios antes de combinarlos en aceptación end-to-end.

8. Certificados, credenciales y permisos deben permanecer centralizados y con mínimo privilegio

Añadir factura electrónica no justifica copiar secretos dentro de cada ERP, tienda o agente local. El patrón de Kairoseth mantiene certificado AEAT, claves privadas, passphrases, tenant y entorno en el runtime server-side. Para B2B se aplica la misma filosofía: credenciales de plataforma, autenticación de servicios y material sensible deben pertenecer al componente que ejecuta el transporte, no al adapter de negocio que solo aporta datos.

Local Agent conserva su frontera: outbound-only, DB read-only cuando corresponde y sin certificado fiscal. Los conectores ecommerce tampoco deben recibir secretos innecesarios. La reducción de superficie facilita rotación, auditoría y revocación. Cuando una empresa utiliza una plataforma privada B2B distinta de la solución pública, ese proveedor se modela como transport adapter con permisos concretos; no se entrega una credencial global a todo el ecosistema.

9. Prueba cada contrato por separado antes de una aceptación end-to-end

Un plan de pruebas serio necesita fixtures de facturas simples, múltiples tipos de IVA, rectificativas, exenciones, monedas, destinatarios nacionales y escenarios que provoquen rechazo. Para VeriFactu se valida preflight, recordId, idempotencia, transporte y reconciliación. Para B2B se validan estructura, sintaxis, validaciones de plataforma, transmisión, recepción, estados y recuperación. Después se añade un escenario combinado que parte del mismo hecho comercial y demuestra que ambas salidas mantienen identidad consistente.

El resultado no debe ser 'el XML se envió', sino evidencia reproducible. Guarda versión de schema, mapping, request hash, receipt, timestamp y estado final. Distingue TEST, sandbox o validación local de producción real. Ninguna prueba debe cambiar automáticamente flags productivos. El mismo principio que protege AEAT producción debe aplicarse al intercambio B2B: el go-live es una decisión explícita después de evidencia, soporte y rollback preparados.

10. Roadmap recomendado: preparar convergencia sin vender hoy una funcionalidad que todavía no existe en el producto

Kairoseth Fiscal v0.1.0 es hoy una capa VeriFactu/adaptación fiscal con conectores y rutas universales. W8.7 es contenido y arquitectura editorial; no convierte automáticamente el producto en plataforma B2B completa. El roadmap correcto es documentar el contrato interno común, inventariar campos adicionales del RD 238/2026 y HAC/1028/2026, diseñar un adapter B2B separado, preparar sandbox/fixtures y decidir después si se incorpora como extensión del producto o como módulo diferenciado.

Esta transparencia evita dos errores comerciales. El primero es prometer 'VeriFactu + factura electrónica' como una casilla genérica sin distinguir alcance. El segundo es diseñar dos productos totalmente aislados y perder reutilización. La dirección técnica razonable es convergencia controlada: mismo intake de hechos comerciales, observabilidad e identidad donde tenga sentido; contratos, transports, estados, seguridad y activación separados hasta que la evidencia y la normativa permitan unificar más.