Testing the Spain regime — FiscalRail documentation

Use these values only with a Spanish Test account. FiscalRail runs the normal invoice and event workflow but replaces AEAT calls with deterministic simulated responses.

Spanish NIFs

These customer es_nif values separate local format validation from asynchronous AEAT census verification:

NIF	Customer request	Verification result
`B00000026`	Accepted	`completed`, `valid: true`
`B00000000`	Accepted	`completed`, `valid: false` (`NO IDENTIFICADO`)
`B00000001`	Rejected with `422 invalid_customer`	No verification is created because the control character is invalid

For eu_vat, use ESB00000026, ESB00000000 and ESB00000001 for the equivalent valid, registry-invalid and format-invalid outcomes.

Both completed registry results emit tax_id.verification.completed; inspect data.object.verification.valid to distinguish them. See the general testing guide for other EU VAT jurisdictions.

Synchronous invoice rejection

To exercise an invoice that FiscalRail rejects before numbering, omit customer and create a general-rate IVA line with unit_price: "400.00". Its total including IVA is €484.00, above the €400 simplified-invoice limit.

The API returns 422 invalid_invoice with a simplified_invoice_total_exceeded detail on totals.total_with_tax. No invoice, VERI*FACTU registration or invoice webhook is created. This is an API validation failure, not an AEAT outcome.

You can also exercise the other documented Spanish rules: a future issue_date, a non-positive quantity or unit price, a line without exactly one IVA classification, or an ordinary invoice whose customer has no complete address.

VERI*FACTU outcomes

Create a customer with a complete address and one of these es_nif values, then issue an invoice for that customer:

Customer NIF	Terminal registration status	Terminal event
`B00000026`	`accepted`	`invoice.verifactu_registration.accepted`
`B00000000`	`accepted_with_errors` with a simulated non-censused-recipient error	`invoice.verifactu_registration.accepted_with_errors`
`B00000034`	`rejected` with simulator-only raw error code `9999`	`invoice.verifactu_registration.rejected`
`B00000018`	First attempt receives HTTP 503; a retry becomes `accepted`	`invoice.verifactu_registration.accepted` after retry

Issuance itself still returns 201 and an immutable invoice with a pending registration. VERI*FACTU submission is asynchronous, so an AEAT rejection cannot turn the original invoice request into an API error. Retrieve the invoice and inspect tax_regime.es.verifactu.registrations, or consume the terminal event. The 9999 code is a deterministic simulator value, not a claimed production AEAT error code.

Sentinel records are submitted separately so a simulated transport failure cannot affect unrelated invoices in the same batch. Test QR codes continue to point to FiscalRail's visibly test-only verification page.

Continue with the VERI*FACTU guide for the production workflow and public registration shape.