Verifactu and B2B e-invoicing are not the same obligation. The Reglamento de Requisitos de los Sistemas Informáticos de Facturación (RRSIF, Spain's invoicing software systems regulation) governs how software generates and retains complete, traceable records, and enables the VERI*FACTU mode of remission to the AEAT (Spain's Tax Agency). B2B e-invoicing regulates the issuance, sending and receipt of structured invoices between businesses and professionals, their interoperability, and the reporting of invoice status. An organisation may need to comply with both frameworks for the same transaction.
Two different problems, one invoice
The confusion arises because both projects touch the ERP and the invoice. Yet they serve different purposes:
- RRSIF/VERI*FACTU: integrity, immutability, retention, traceability and tax oversight of the records generated by the system.
- B2B e-invoicing: structured electronic exchange between businesses and professionals, interoperability between platforms, and status tracking to digitise commercial relationships and tackle late payment.
The first layer looks mainly at the invoicing system and its relationship with the tax authority. The second looks at the structured document itself, the issuer, the recipient and the platforms that exchange it.
Current regulatory framework
The requirements for invoicing software systems stem from Real Decreto 1007/2023 (Royal Decree), Orden HAC/1177/2024 (Ministerial Order), their amendments, and the deadline extension introduced by Real Decreto-ley 15/2025 (Royal Decree-Law).
B2B e-invoicing originates from Ley 18/2022 (Spain's Business Creation and Growth Law). Real Decreto 238/2026 (Royal Decree), published on 31 March 2026, develops the mandatory system between businesses and professionals and amends the invoicing regulation. Its rollout must follow the transitional provisions and the official technical development, including any pending regulation needed for the public solution.
Dates should not be calculated from articles predating Real Decreto 238/2026. Before signing a contract or publishing anything, verify the BOE (Spain's official gazette), the AEAT and the technical orders in force for each group of obliged parties.
Practical comparison
| Criterion | RRSIF / VERI*FACTU | B2B e-invoicing |
|---|---|---|
| Purpose | Integrity and traceability of the invoicing system | Structured, interoperable exchange and status control |
| Object | Invoicing records and software operation | Electronic invoice sent and received between businesses |
| Counterpart | System, taxpayer and AEAT | Issuer, recipient, platforms and public solution |
| Operations | Those within RRSIF scope | B2B relationships covered by the law and regulation |
| Main output | Issuance/cancellation record, QR and, in verifiable mode, remission | Structured invoice and associated statuses |
| Modes | VERI*FACTU and non-verifiable system subject to its own controls | Private platform, public solution or other approved interoperable channels |
| Correction | Record and traceability under RRSIF | Corrective invoice and exchange with the recipient |
| Project | Software adaptation and its controls | Issuance, receipt, integration and status management |
An invoice can generate an RRSIF-compliant record and also be sent to the customer as a structured B2B invoice. One layer does not replace the other.
What VERI*FACTU actually means
VERI*FACTU is a mode of the verifiable invoice-issuance system that remits records to the AEAT's electronic office according to the published specifications. It does not mean the invoice has been delivered to the customer, commercially accepted or paid.
The application must control:
- creation of the issuance record;
- cancellation records where applicable;
- chaining and hash fingerprint;
- QR code and applicable wording;
- remission, response, rejection and retries;
- reconciliation between invoice, record and AEAT status;
- security of credentials and evidence.
The tax submission does not replace the invoice register book or other filings unless a rule expressly states otherwise. The AEAT clarifies this in its FAQ.
What B2B e-invoicing requires
The B2B system aims to have the invoice circulate as structured data that can be processed automatically. The project covers both issuing and receiving. Many companies only prepare the outbound side and discover too late that they cannot integrate incoming invoices, rejections or status updates.
The architecture must resolve:
- supported structured formats and conversion;
- issuer and recipient identification;
- delivery and interoperability between platforms;
- authenticity, integrity and legibility;
- invoice statuses and their reporting;
- free access for the recipient under the applicable terms;
- retention and export;
- integration with purchasing, accounting, treasury and tax.
A B2B customer portal connected to the ERP is precisely what makes that recipient access and status reporting work without relying on loose emails. A PDF can be a visual representation, but it should not be mistaken for a processable structured invoice when the obligation requires that structure.
Invoice, record and status: three different things
Three objects need to be kept separate:
- Commercial and tax invoice: the document with the required content.
- RRSIF record: the structure generated to guarantee traceability of the system.
- B2B status: information on receipt, acceptance, rejection or payment under the applicable framework.
They must share identifiers but they are not the same object. If the ERP uses different keys for each, reconciliation becomes difficult. The design must include a unique identifier per invoice and explicit relationships with corrective invoices, records and statuses.
Two calendars that must be managed separately
Following the 2025 extension, invoicing software systems must be adapted by 1 January 2027 for entities filing corporate income tax, and by 1 July 2027 for the remaining obliged parties.
B2B e-invoicing has its own rollout calendar, derived from Ley 18/2022, Real Decreto 238/2026 and the corresponding technical milestones. The Verifactu calendar should not be copied across automatically.
The master plan needs two tracks:
| Track | Preparation milestone |
|---|---|
| RRSIF | Software, records, QR, mode, testing and contingency |
| B2B | Formats, platform, receipt, statuses, interoperability and counterpart onboarding |
Shared dependencies — master data, taxes, series, ERP and archiving — are handled once.
Recommended architecture
ERP as the single source of truth
The ERP should govern customers, products, taxes, series and accounting status. Sales applications may originate transactions, but responsibility for issuing and numbering must be clearly defined.
RRSIF compliance engine
Generates and retains records, chaining, QR codes, events and remission. It must correspond to a version declared by the producer and tested against the real configuration.
E-invoicing layer
Converts to supported formats, validates content, routes to the relevant platform or solution, receives invoices and synchronises statuses.
Reconciliation
An automated process compares daily:
- invoice issued in the ERP;
- issuance or cancellation record;
- AEAT response where applicable;
- delivery to the recipient;
- B2B statuses;
- posting and collection.
Discrepancies create an incident with an owner and a deadline. Process automation makes it possible to build this daily reconciliation without relying on manual reviews.
Master data: the invisible work
Both frameworks depend on correct data. Before integrating, you need to clean up:
- tax ID and legal name;
- address and country;
- business or professional status;
- codes and tax rates;
- payment methods and terms;
- platform identifiers;
- series and establishments;
- units, discounts and order references.
An incomplete field can pass a local validation and still be rejected by another platform. Data quality needs an owner, a rule and a correction process.
Combined test scenarios
Testing each system in isolation is not enough. Full end-to-end flows must be rehearsed:
| Scenario | RRSIF validation | B2B validation |
|---|---|---|
| Ordinary invoice | Record, hash and QR | Format, sending and receipt |
| Corrective invoice | Relationship and traceability | Delivery and link to original |
| Recipient rejection | Does not alter the original record | Status and commercial decision |
| AEAT outage | Queue and retry | B2B sending may continue depending on design |
| B2B platform outage | Tax record still correct | Queue, retry and alert |
| Duplicate | Record idempotency | Delivery idempotency |
| Data change | Correction via a valid channel | Synchronisation with the counterpart |
Testing must confirm what happens when one layer works and the other fails. The system should not mark a transaction "complete" just because one of the two responses came back.
Correction and rejection are not the same thing
A commercial or technical rejection of a B2B invoice does not authorise silently editing an invoice that has already been issued. You must analyse whether a tax error exists and apply the appropriate correction mechanism.
The workflow must distinguish between:
- rejection due to format or delivery;
- commercial discrepancy;
- tax error;
- permitted cancellation of the record;
- corrective invoice;
- return or credit note.
Each status needs an owner and a rule. Automating without this distinction can destroy traceability.
Providers and contracts
A company may use a different ERP, RRSIF provider and B2B platform. The contract must assign:
- availability and support;
- regulatory changes;
- liability for validations;
- security and data protection;
- sub-processors and location;
- export and portability;
- evidence and logs;
- reversibility on termination;
- incident coordination.
Avoid depending on a platform that will not let you export invoices, statuses and evidence in a usable format. The exit plan is part of the purchase.
Unified roadmap
Phase 1. Scope
- Inventory entities, channels and applications.
- Separate RRSIF and B2B obligations.
- Confirm exclusions and calendars with tax advice.
- Appoint a joint lead and an owner for each track.
Phase 2. Design
- Define the master ERP and the unique identifier.
- Choose the RRSIF mode and the B2B channel.
- Design receipt, statuses and reconciliation.
- Review security, contracts and archiving.
Phase 3. Build
- Clean up master data and series.
- Update software and develop integrations.
- Configure records, QR codes, formats and statuses.
- Set up monitoring and error queues.
Phase 4. Testing and pilot
- Run the combined test matrix.
- Test volume, period-end close, outages and rollback.
- Onboard pilot counterparts.
- Train sales, admin, purchasing and accounting teams.
Phase 5. Operation
- Daily reconciliation.
- Incident desk.
- Review of rejections and corrections.
- Monitoring of regulatory changes and versions.
Common mistakes
- Buying "Verifactu" believing it solves B2B invoicing too.
- Preparing B2B issuance and forgetting receipt.
- Using a PDF as the only format.
- Applying the same calendar to both obligations.
- Not linking the invoice, record and status.
- Confusing a commercial rejection with a tax cancellation.
- Delegating scope decisions to the technology provider.
- Not testing partial failures across platforms.
- Keeping master data without an owner.
- Lacking export capability and an exit plan.
Leadership checklist
- Frameworks and calendars kept separate.
- Scope validated by entity and transaction.
- Master ERP and unique identifier defined.
- RRSIF mode documented.
- B2B issuance, receipt and statuses designed.
- Correction and rejection kept apart.
- Combined tests passed.
- Reconciliation and alerts active.
- Providers, security and portability reviewed.
- Users trained by process.
Frequently asked questions
If I roll out VERI*FACTU, do I already comply with B2B e-invoicing?
No. It solves the tax mode for records, but not necessarily the structured exchange, receipt or B2B statuses.
If I send a B2B invoice, do I already comply with RRSIF?
No. The software must still meet whichever record-keeping and operational requirements apply to it.
Can one invoice go through both systems?
Yes. This is the normal scenario: the ERP generates the invoice, the system produces the tax record, and a platform delivers it to the customer in structured form.
Is a PDF a B2B electronic invoice?
It can be a representation, but the structured-exchange obligation requires meeting the official formats and requirements.
Do you need to hire two providers?
Not necessarily. One provider can cover both layers, but it must demonstrate scope, version, interoperability and evidence separately for each.
Official sources consulted
- Real Decreto 1007/2023.
- Orden HAC/1177/2024.
- Ley 18/2022 on business creation and growth.
- Real Decreto 238/2026 on B2B e-invoicing.
- AEAT: mandatory e-invoicing.
- AEAT: general questions and VERI*FACTU system FAQ.
Summum Sistemas can design a unified architecture for Verifactu and B2B e-invoicing without mixing responsibilities. Dates, scope and tax criteria must be verified before deployment.