# The census is checked before the invoice is numbered

Issuing with VeriFactu on checks the recipient against the AEAT census first: an uncensused recipient answers `422`, and no number is spent.

Aug 23, 2026 · Breaking

When you issue an invoice with VeriFactu on, the recipient's NIF is now checked against the AEAT census **before** the invoice consumes quota and a series number. Until now that check was skipped in sandbox, and skipped in every environment when the recipient came from a stored customer.

No invoice that used to reach the AEAT stops reaching it. What changes is that a recipient the AEAT does not know is refused up front instead of being numbered and then failing out of sight.

## What else changed

- **The one case that changes.** VeriFactu on, recipient not in the census: you used to get `201`, a spent series number and a registration that died later without telling you. You now get `422` before anything is numbered.
- **With VeriFactu off nothing changes at all** — the census is not consulted. An invoice that is not declared does not need a censused recipient.
- **Sandbox is not exempt**, and never really was: a sandbox issue is submitted to VeriFactu, which validates against the real census. If your test suite issues with VeriFactu on against a made-up NIF and asserts `201`, that assertion becomes `422`.
- **A census that cannot answer does not block issuing.** Not being able to ask is not a `no` from the AEAT.
- **Check a NIF up front** with `POST /v1/nif/validate`, which returns the real census status with a test key too.

## Endpoints

- `POST /v1/companies/{company_id}/invoices/{invoice_id}/issue` — With VeriFactu on, an uncensused recipient is rejected with 422 before quota and numbering
- `POST /v1/nif/validate` — Returns the real census status for a NIF, test keys included

## Where to go next

- [Issue an invoice](/invoices/issueCompanyInvoice)
- [Validate a NIF](/nif-validation/validateNif)

---

Full OpenAPI spec: https://docs.beel.es/api/openapi