VERI*FACTU and B2B e-invoicing are not the same

Two nearby obligations can touch the same invoice while serving different objectives, technical flows and implementation schedules.

Guide reviewed

VERI*FACTU / RRSIF
How the system records and preserves invoicing
B2B e-invoicing
How a structured invoice is issued, exchanged and tracked
Architecture rule
Consistent data, separate state machines and transports

Context

Treating both adaptations as one integration creates incorrect dependencies. A sound design shares a consistent fiscal model while keeping the invoicing-system record and structured recipient exchange separate.

01

The essential difference

The same commercial transaction may activate both flows, but each retains its own purpose and evidence.

01

Fiscal record

RRSIF regulates systems supporting invoicing and requires integrity, traceability, preservation and creation or cancellation records.

02

B2B exchange

Royal Decree 238/2026 regulates structured invoicing between businesses and professionals, interoperability and invoice status messages.

03

Visible document

PDF, QR, fiscal record and structured message are not synonyms. Each artefact has a different technical function.

02

Different schedules

For RRSIF, AEAT currently states 1 January 2027 for Corporate Income Tax taxpayers and 1 July 2027 for the other taxpayers covered by the relevant scope.

For B2B e-invoicing, Royal Decree 238/2026 has been published, but effective application depends on the future order developing the public solution. The order starts a 12-month period for businesses above EUR 8 million in turnover and a 24-month period for the rest. Until that order exists, there is no closed calendar date to publish.

03

Architecture that avoids rework

Useful preparation separates the fiscal domain, representation, transport and lifecycle tracking.

01

Fiscal core

A canonical model for issuer, recipient, lines, tax, totals, series, corrections and references.

02

Adapters

Separate generators for RRSIF records and CII, UBL, EDIFACT or Facturae, without confusing their validation rules.

03

State machines

Independent tracking for AEAT, recipient delivery, commercial rejection, payment and reconciliation.

04

What to review now

  • Confirm scope, territory and exclusions with the tax adviser.
  • Inventory every route that can issue or modify an invoice.
  • Check tax identifiers, addresses, tax rates, series and references.
  • Separate generation, signing, transport, status and reconciliation.
  • Define synthetic data and dedicated test certificates.
  • Version schemas, validation rules and acceptance evidence.

One invoice, two controls

The design must demonstrate what was recorded for fiscal purposes and what was exchanged with the recipient without assuming both responses arrive together.

  1. 01The RRSIF record preserves sequence and its creation or cancellation relationship.
  2. 02The B2B message preserves format, signature, delivery and transformations.
  3. 03Commercial and payment status do not replace the fiscal response.
  4. 04Reconciliation detects differences without rewriting history.

Common questions

Short answers about scope, evidence and implementation boundaries.

Does VERI*FACTU compliance include B2B e-invoicing compliance?+

No. Some data can be shared, but the frameworks and flows are different and need separate analysis.

Is a PDF sent by email a structured B2B electronic invoice?+

Not under Royal Decree 238/2026. The regulation requires a structured message following the EN16931 semantic model and an admitted syntax.

Which formats does the B2B system include?+

Royal Decree 238/2026 lists CII, UBL, EDIFACT and Facturae. The public solution will use UBL under the terms defined by the future order.

Are all public-solution specifications available?+

No. The royal decree refers operation, authentication, UBL, coding and integration detail to a future technical order.

Official sources

Spanish regulations and criteria used to separate both projects. The position must be checked again when the B2B technical order is published.

Separate obligations before choosing tools.

A short review of the data model and issuing flows can identify which components are shared and which need their own integration.