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.
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 get422before 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 becomes422. - A census that cannot answer does not block issuing. Not being able to ask is not a
nofrom 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}/issueWith VeriFactu on, an uncensused recipient is rejected with 422 before quota and numbering
- POST/v1/nif/validateReturns the real census status for a NIF, test keys included
Where to go next
Four collections paginate, and branding goes wrapped
Four collections now paginate — without `limit` you get the first 20 — and the three branding responses come wrapped in `{success, data, meta}`.
OAuth2 leaves the public contract
OAuth2 is gone from the spec. Each operation now states the scope it requires in its own description. API key auth is unchanged.