Record generation
Each invoice issued through the invoicing system generates the corresponding billing record under the technical framework.
VERIFACTU REQUIREMENTSUpdated 2026 guide
VeriFactu requirements for invoicing software.
Meeting the RRSIF framework is not only about adding a QR. The system must generate billing records and preserve properties such as integrity, immutability, and traceability, together with the rules specific to the chosen mode.
In VERI*FACTU, submitting records to AEAT is central to the design. Other modes have different technical obligations.
VERIFACTU GUIDE
The blocks the system needs to solve.
Official rules and FAQs separate several responsibilities that should be treated explicitly in the architecture.
Integrity and immutability
The system must prevent or detect improper changes to records and keep controls consistent with applicable rules.
Traceability
The sequence must be reconstructable and gaps or jumps detectable. AEAT describes chaining as a central mechanism.
Preservation and access
Records must remain accessible and readable for the applicable periods and available for consultation when required.
QR and representation
The invoice may require a tax QR and, in VERI*FACTU mode, the verifiable-invoice wording when the case falls within scope.
Submission and state
In VERI*FACTU the system submits records to AEAT and must handle responses, errors, retries, and states correctly.
STEP BY STEP
How to review software before calling it adapted.
Installing a plugin does not by itself prove that the full workflow is covered. Review the complete process.
Identity and numbering
Check issuer, series, number, dates, and the source of fiscal numbering.
Records and chain
Verify that the system generates the correct records and preserves required traceability.
Submission and recovery
Test acceptance, rejection, timeout, retry, and reconciliation, not only the happy path.
Final invoice
Check QR, wording, and presentation in the actual representation delivered to the customer.
ARCHITECTURE
One fiscal core reduces inconsistencies across channels.
Kairoseth Fiscal applies the same logic to WooCommerce, PrestaShop, ERP, Excel, and API. Adapters change data ingress, not the fiscal rules in the core.
FAQ
Frequently asked questions.
Short answers grounded in official sources.
What are the basic requirements for an invoicing system?
RRSIF requires, among other things, integrity, immutability, traceability, preservation, accessibility, and readability of billing records under the applicable rules.
Is VeriFactu only about sending invoices to AEAT?
No. The mode involves billing records and submission, but it still sits within a broader set of requirements for invoicing software.
Does traceability involve chaining?
AEAT explains traceability through a record sequence in which each record contains data that can point to the previous one, forming a chain.
Does every invoice require a QR?
The scope must be checked. AEAT clarifies that the QR requirement applies to invoices issued through covered invoicing systems and that some situations fall outside that scope, including certain SII taxpayers or regional regimes.
Can fiscal logic be split across many plugins?
Several technical components can exist, but keeping one authority for rules, identity, idempotency, and state reduces inconsistencies. That is an architectural choice, not a literal legal requirement.
KEEP EXPLORING
Canonical VeriFactu guides.
Each guide owns a distinct intent to avoid duplication and make the path from question to solution clear.
What is VeriFactu
Open guide →QR VeriFactu
Open guide →Self-employed and SMEs
Open guide →Free VeriFactu / AEAT app
Open guide →Current 2027 dates
Open guide →2028 announcement and horizon
Open guide →OFFICIAL SOURCES
Always check the current official version.
This guide summarizes official rules and documentation; it does not replace tax advice or checking the exact scope that applies to each organization.
AEAT · Integrity and immutability
Open official source →AEAT · Traceability
Open official source →AEAT · Concepts and scope
Open official source →BOE · Order HAC/1177/2024
Open official source →TRUST & CONTROL
Authority stays explicit as the platform grows.
Kairoseth separates identity, organization scope, product roles and product capabilities. A login route, browser state or AI response never becomes an authorization boundary by itself.
KAIROSETH PLATFORMCONTROL PLANE
- Identity
- Shared account
- Verified
- Organization
- Tenant scope
- Required
- Product
- RBAC assignment
- Explicit
- Sensitive actions
- Policy gate
- Controlled
Organization scope
Customer resources and access are resolved inside an active organization context rather than treated as global account state.
Product-scoped roles
Owner, Admin and Member authority is assigned per product. Organization membership alone does not automatically grant every product.
Server authority
Sensitive access, policy and capability decisions remain authoritative on the server instead of trusting client UI state or model output.
Controlled execution
Capabilities that can act are introduced behind explicit grants, staged gates and audit rather than implied autonomy.
Public trust evidence
Review the customer-facing policies that define privacy, security reporting, acceptable use and the current legal operating framework.
SOFTWARE VERIFACTU
Want to review whether your software actually covers the VeriFactu workflow?
Kairoseth Fiscal starts from the system you already use and separates adapter, mapping, preflight, and fiscal core so each requirement has a clear responsibility.