VERI*FACTU is commonly used as shorthand for Spain’s invoice-software rules. More precisely, it is one of the two permitted modes: the one that sends each invoice registration record to the AEAT. It is not a new kind of invoice, tax filing, or the forthcoming mandatory B2B electronic invoice.
What changes, and when
The rules apply to invoice software used by covered Spanish taxpayers. The current dates are 1 January 2027 for Corporate Income Tax taxpayers and 1 July 2027 for the other covered taxpayers, including people carrying on economic activities. Check the current AEAT FAQ for a specific applicability decision.
Integrate an API, not fiscal infrastructure
Your product sends commercial facts through a documented JSON API. FiscalRail owns the work that otherwise turns a VERI*FACTU integration into its own project:
- Catch errors before issuance. It validates the invoice, required data and Tax ID format. Where the rules require it, a negative registry verification can stop issuance instead of leaving the problem to surface later at the AEAT.
- Calculate and round consistently. It resolves supported tax treatment, groups taxable bases and rounds fiscal totals centrally, so your integration does not recreate those rules line by line.
- Issue a record that cannot be rewritten. It numbers and stores the immutable invoice, creates its registration record and generates the fiscal QR in one operation.
- Handle the conversation with the AEAT. In Live, FiscalRail submits on behalf of the authorised taxpayer and automatically retries transient transport failures.
- Make the outcome observable. Poll the status when you need it or receive signed webhooks when the AEAT accepts, accepts with issues or rejects a record.
Your product does not need to operate AEAT client-certificate authentication, XML or SOAP-schema validation. FiscalRail keeps those concerns behind the API.
What the workflow looks like
- Your software sends the customer, lines and commercial facts.
- FiscalRail validates, calculates, numbers and stores the immutable invoice, then creates its registration record.
- In Live, FiscalRail submits the record to the AEAT for the authorised taxpayer.
- Your integration polls the status or receives the outcome webhook; where a correction is needed, it creates linked documents and records without rewriting the original.
For implementation detail, see the VERI*FACTU guide, webhook guide and Spain regime documentation.
Integrate VERI*FACTU without XML or certificates
Questions teams ask before they start
Do we give FiscalRail our certificate?
No. Your product does not need to operate an AEAT client certificate. Before a Spanish Live account can submit records, the taxpayer grants FiscalRail the required specific representation and FiscalRail verifies it. Follow the VERI*FACTU setup guide for the IZ860 process.
Does a Test account contact the AEAT?
No. Test exercises the Spanish invoice, QR and registration flow with deterministic simulated outcomes. Test QR codes point to a clearly marked FiscalRail test page, not the AEAT. The Spain testing guide lists the available scenarios.
What if the AEAT is unavailable, rejects or delays a record?
Issuance and submission are separate. FiscalRail retries transient transport failures; poll the registration status or subscribe to signed webhooks for the outcome. A rejection retains structured detail so your team can act without turning an already-issued invoice into an ambiguous request.