# Testing the Spain regime

Exercise Spanish NIF verification, invoice validation and every public VERI*FACTU outcome.

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](/en/testing) 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](/en/tax-regimes/spain/verifactu) for the production workflow and public registration shape.