VERI*FACTU
FiscalRail uses the VERI*FACTU mode for Spanish accounts. When you issue an invoice, FiscalRail creates its immutable registration record and adds it to the account's fingerprint chain in the same transaction. The invoice is then complete; submission to the AEAT happens asynchronously.
VERIFACTU records are not electronic invoices. They are the standardized fiscal records generated from invoices and sent to the AEAT. The official overview explains this distinction and the two regulatory modes. FiscalRail implements the remittance-based VERIFACTU mode, not the alternative local-retention mode.
The producer's responsible declaration for FiscalRail version 1 identifies the system and its components. The authoritative declaration is the Spanish version linked from that page.
Start in Test
A Spanish Test account runs the complete FiscalRail workflow without contacting the AEAT. Issue an invoice normally and inspect tax_regime.es.verifactu.registrations in the response. The first entry is an alta record with a pending status. Retrieve the invoice again or receive a webhook to observe its simulated terminal result.
Test invoice PDFs contain a tax QR that opens FiscalRail's own verification page. It does not point to the AEAT and is visibly part of the Test environment. This makes Test safe for exercising QR, correction, rejection and webhook handling.
Authorize FiscalRail for Live submissions
Before a Live Spanish account can issue invoices, the taxpayer must authorize FiscalRail in the AEAT Registry of Powers. FiscalRail currently supports one representation method: a specific power for procedure IZ860, Remisión y consulta de registros de facturación por servicio web.
The power must be granted by the same Spanish NIF configured on the FiscalRail account, to the FiscalRail representative name and NIF shown under Settings → Tax regime in the Live account. Do not grant it to your own integration or to the Test account.
To register it:
- Open the AEAT Registry of Powers and choose Alta de poder mediante identificación electrónica.
- Choose a power for specific tax procedures, enter FiscalRail's representative NIF and select procedure
IZ860. - Review the validity period, sign and submit the grant.
- Download the AEAT receipt and keep it with the taxpayer's records.
- Copy the 16-character CSV from that grant document.
- Return to Settings → Tax regime in the Live FiscalRail account, enter the CSV and select Validate grant and verify.
The AEAT's registration instructions describe the electronic specific-power flow. AEAT also states that a third party sending VERI*FACTU records on behalf of the issuer must be authorized in its registry in its delegation FAQ.
What FiscalRail verifies
FiscalRail uses the CSV only to retrieve the signed AEAT grant. It checks that the document matches the CSV, names the correct taxpayer and FiscalRail representative, grants IZ860, and contains a successful grant reference. FiscalRail then discards the CSV and stores the 20-digit power reference and validity dates.
That document proves what was granted, but not that the power is still active. FiscalRail therefore performs a separate live authorization check with the AEAT. The dashboard status moves through:
| Status | Meaning | What to do |
|---|---|---|
| Not configured | FiscalRail has no validated grant. | Register IZ860 and enter its CSV. |
| Pending verification | The grant was read and the live authorization check is queued or inconclusive. | Wait and try Verify again if it does not settle. |
| Verified | The AEAT currently authorizes FiscalRail to act for the taxpayer. | Live issuance is enabled. |
| Invalid | The submitted grant or authorization does not apply. | Check both NIFs, the procedure and the grant status, then register the correct power. |
| Revoked | A previously verified authorization no longer works. | Restore the power and select Verify again. |
AEAT outages and transport failures do not prove that a power is invalid. FiscalRail keeps the verification pending in those cases rather than treating a temporary failure as a revocation.
Issue and follow a Live invoice
Once representation is verified, issue the invoice through the normal API. The response includes the immutable invoice and a pending VERI*FACTU registration. Issuance does not wait on the AEAT: a remote outage cannot make an already numbered invoice disappear or turn the API request into an ambiguous retry.
Follow the registration through one of these terminal events:
| Event | Meaning |
|---|---|
invoice.verifactu_registration.accepted |
The AEAT accepted the record. |
invoice.verifactu_registration.accepted_with_errors |
The AEAT accepted it but returned an issue that requires review. |
invoice.verifactu_registration.rejected |
The AEAT rejected it; inspect the structured and raw error. |
Subscribe through webhooks rather than polling every invoice. Delivery is at least once and unordered, so deduplicate by Event ID and retrieve the invoice for its current registration state. The public registration object exposes status, submitted_at, AEAT csv when supplied, and a structured error for non-clean results.
QR verification
Every Spanish invoice exposes tax_regime.es.qr.content and image_url. Live QR content points to the AEAT verification route and includes the supplier NIF, invoice number, issue date and total. FiscalRail places the rendered QR on the invoice PDF.
The QR is not proof that the registration has already reached a terminal state. Use the registration status or event for that. The underlying regulation requires a QR on invoices produced by covered systems and reserves the VERI*FACTU wording for systems that remit all records; see Royal Decree 1007/2023.
Correct or cancel an invoice
Never edit an issued invoice or delete its fiscal record. Use an amendment for refunds, discounts and incorrect customer, line or tax data. FiscalRail preserves the original and creates the credit note and replacement required by the selected correction.
Use issued_by_mistake only when the underlying operation never occurred. FiscalRail then creates an anulacion registration linked to the original alta. The AEAT likewise requires erroneous registration records to remain in the chain and be countered with a new cancellation or correction record; its cancellation FAQ explains the principle.
See Correcting invoices for the reason-specific workflow and the Invoice API for the complete registration shape.