How to prepare an architecture for both VeriFactu and B2B electronic invoicing without confusing the two contracts

Order HAC/1028/2026 was published on 5 October 2026 and entered into force on 6 October. The order itself states that its entry into force starts the countdown defined by Law 18/2022 and Royal Decree 238/2026 for mandatory electronic invoicing between businesses and professionals. Subject to later regulatory changes and to the EU-derogation condition contained in Law 18/2022, the first major milestones therefore fall on 6 October 2027 for businesses above EUR 8 million turnover and 6 October 2028 for the rest. In parallel, RRSIF/VERI*FACTU remains the framework governing the behavior and records of invoicing software systems. Both worlds share document identity, issuer, recipient, amounts, taxes and traceability, but they should not be implemented as if one endpoint or one PDF solved everything. This guide proposes a layered architecture that reuses data and adapters while keeping the fiscal and B2B-exchange contracts separate.

1. Start by separating contracts: fiscal records are not the same as B2B exchange

RRSIF/VERI*FACTU defines requirements affecting the system supporting the invoicing process: record generation, integrity, preservation, accessibility, readability, traceability and immutability. Under the VERI*FACTU mode, records are also submitted. The technical core must control identity, sequence, classification, preflight, submission, response and reconciliation. A Kairoseth integration therefore avoids distributing those decisions across plugins, spreadsheets or local agents.

B2B electronic invoicing answers another question: how an electronic invoice is issued, transmitted, received, made available, interconnected and accompanied by status information. Royal Decree 238/2026 and Order HAC/1028/2026 develop that ecosystem using private platforms and a public solution. Shared data does not erase the contractual distinction. An accepted fiscal record does not mean the B2B invoice was delivered or that its recipient reported a status, and an exchanged electronic invoice does not automatically replace the safeguards required from invoicing software.

2. 6 October 2026 changed the B2B timetable: a statutory countdown is now running

Order HAC/1028/2026 entered into force on 6 October 2026 and explicitly states that its entry into force starts the deadlines defined by Law 18/2022 and Royal Decree 238/2026. The Law separates businesses and professionals whose annual turnover exceeds EUR 8 million, for whom Article 12 takes effect one year after regulatory development, from the rest, for whom it takes effect two years later. The operational reference dates therefore become 6 October 2027 and 6 October 2028 respectively unless later regulation changes them.

A second legal caveat must remain visible: Final Provision Eight of Law 18/2022 conditions the obligation on obtaining the EU derogation from Articles 218 and 232 of the VAT Directive. A commercial roadmap can therefore use these dates as the current statutory timetable, while the production gate must recheck BOE, the Spanish Tax Agency and the relevant EU condition at that time. This is much more accurate than saying simply that 'everything happens in 2028'.

3. Reuse a shared invoice domain model rather than two copies of commercial truth

ERP, ecommerce, CRM, Excel, POS and custom software already know business facts such as issuer, recipient, lines, taxes, totals, currency, dates and references. Those facts can be normalized once into an internal domain model. From there, the VeriFactu module creates or classifies the corresponding fiscal record while the B2B module creates the structured electronic invoice and exchange messages. Maintaining separate independent mappings for each regulation multiplies NIF, rounding, series and corrective-invoice errors.

Sharing a domain model does not mean sharing authority. Server-derived fields, fiscal chaining, AEAT environment or credentials must not return to source systems as editable business rules. Likewise, B2B platform identifiers, delivery/payment states and UBL transformations belong to their own contract. The correct pattern is one normalized commercial truth with two separate regulatory adapters and traceability showing which mapping version produced each output.

4. B2B invoicing adds structured format, interoperability and states that VeriFactu does not replace

Order HAC/1028/2026 develops the public solution around a semantic model using UBL and EN 16931 together with services for issuance, interconnection, faithful copies, queries and communication of invoice/payment states. This requires modeling much more than the visual representation of an invoice. The system must know which structured document was transmitted, through which channel, which response was received and which later status was reported by the recipient or platform.

A QR code or an XML fiscal-record payload therefore cannot be marketed as if it already solved B2B electronic invoicing. PDF can remain useful as a human-readable representation, while regulated exchange relies on specific structures and services. Kairoseth can reuse its queue, idempotency and reconciliation engineering, but the B2B contract should be implemented as a separate integration with its own schemas, validators, receipts and observability.

5. Keep two state machines even when observability is shared

VeriFactu cares about states such as prepared, submitted, accepted, rejected, reconciliation pending or blocked. B2B electronic invoicing adds concepts such as availability, receipt, commercial acceptance, rejection, payment or other exchange-framework states. If these are collapsed into one status field, teams will eventually interpret 'accepted by AEAT' as 'accepted by the customer', or assume a paid invoice no longer needs a pending fiscal failure resolved.

Use separate namespaces or aggregates with a shared operational view. An invoice can show fiscalState=accepted and b2bState=delivered without losing shared identity. Observability can correlate both journeys using invoiceId, sourceId and correlationId. Support then sees the complete context while automations never trigger a B2B transition from a fiscal state that carries a different meaning.

6. Reuse idempotency and outbox patterns without blindly reusing one key for every message

Both frameworks need resilience against timeouts, lost responses and retries. Kairoseth's durable infrastructure already uses stable identity, outbox patterns and reconciliation to prevent duplicates. The pattern is reusable for B2B, but each operation needs its own semantic identity. Issuing a fiscal record, transmitting a structured invoice, reporting a payment state or retrieving a response are different actions even when they belong to the same commercial invoice.

An idempotency key should derive from actor, operation, document and relevant version rather than only the invoice number. This prevents a correction, authorized resend or status update from colliding with original issuance. Architecture should keep receipts per channel and allow independent reconciliation. A shared physical queue can be viable, but workers and retry policies must respect the limits, backoff and semantics of the service they actually call.

7. Source adapters remain useful: WooCommerce, PrestaShop, ERP, Excel and legacy should not be rewritten twice

The investment used to extract business facts from WooCommerce, PrestaShop, ERP/CRM, custom software, CSV/XLSX or Local Agent can remain useful for electronic invoicing. A connector should output a stable internal contract rather than regulation-specific XML. When a new obligation requires more fields, the domain mapping and regulatory adapter are extended instead of duplicating every source integration from scratch.

The separation also improves compatibility management. HPOS, PrestaShop hooks, an ERP API or a read-only SQL query change for source-system reasons. UBL, B2B states or AEAT rules change for regulatory reasons. Coupling those layers turns every update into a cross-stack release. Decoupling lets us test the source adapter with a Contract Suite and the regulatory adapter with dedicated fixtures and sandboxes before combining them in end-to-end acceptance.

8. Certificates, credentials and permissions should remain centralized and least-privileged

Adding electronic invoicing does not justify copying secrets into every ERP, store or local agent. Kairoseth's existing pattern keeps AEAT certificates, private keys, passphrases, tenant identity and environment inside server-side runtime. The same philosophy applies to B2B: platform credentials, service authentication and sensitive material should belong to the component executing transport, not to a business adapter that only supplies data.

Local Agent keeps its boundary: outbound-only, read-only database access when applicable and no fiscal certificate. Ecommerce connectors should not receive unnecessary secrets either. Reducing credential surface makes rotation, auditing and revocation easier. When a company uses a private B2B platform instead of the public solution, that provider becomes a transport adapter with explicit permissions rather than receiving one global credential shared across the ecosystem.

9. Test each contract separately before end-to-end acceptance

A serious test plan needs fixtures for simple invoices, multiple VAT cases, corrective invoices, exemptions, currencies, domestic recipients and scenarios designed to trigger rejection. For VeriFactu, validate preflight, recordId, idempotency, transport and reconciliation. For B2B, validate structure, syntax, platform rules, transmission, receipt, states and recovery. Then add a combined scenario starting from the same business fact and proving both outputs preserve consistent identity.

The result should not merely be 'XML was sent' but reproducible evidence. Store schema version, mapping version, request hash, receipt, timestamp and final state. Distinguish TEST, sandbox or local validation from real production. No test should automatically change production flags. The principle protecting AEAT production should also protect B2B exchange: go-live is an explicit decision made after evidence, support and rollback are ready.

10. Recommended roadmap: prepare for convergence without selling functionality the product does not yet provide

Kairoseth Fiscal v0.1.0 is currently a VeriFactu/fiscal-adaptation layer with connectors and universal integration routes. W8.7 is editorial and architectural work; it does not automatically turn the product into a complete B2B platform. The correct roadmap is to document the shared internal contract, inventory additional fields required by Royal Decree 238/2026 and Order HAC/1028/2026, design a separate B2B adapter, prepare sandbox fixtures and then decide whether it becomes a product extension or a distinct module.

This transparency prevents two commercial errors. The first is promising 'VeriFactu + electronic invoicing' as a generic checkbox without defining scope. The second is building two completely isolated products and losing reuse. The sensible technical direction is controlled convergence: shared intake of commercial facts, observability and identity where appropriate; separate contracts, transports, states, security and activation until evidence and regulation justify deeper unification.