VeriFactu is a fact of the taxpayer, not a flag per invoice
Whether an invoice reaches the AEAT is now decided by the NIF's regime at issue time. The per-invoice flag and three response fields are gone.
Where an invoice ends up used to be decided by a flag on the invoice. It is now decided by the taxpayer: if that NIF is under the VeriFactu regime in that mode, every invoice of theirs is registered; if it is not, none is. The law obliges a person, not a document, and a per-invoice flag let you build a mixed ledger — two invoices from the same NIF on the same day, one registered and one not.
The single switch is PUT /v1/companies/{company_id}/verifactu-configuration, and it is resolved when the invoice is issued, against the state of the account at that instant.
What else changed
- Request properties retired.
options.verifactu_enabledon invoice create and patch,verifactu_enabledon convert-to-invoice and on recurring templates,verifactu_auto_submiton a payment connection, andapply_by_defaulton the VeriFactu configuration. Unknown properties are ignored, so continuing to send them breaks nothing — they are discarded and the NIF's regime decides. - Response properties retired — these do stop arriving.
verifactu_enabledon a recurring template,verifactu_auto_submiton a payment connection, andapply_by_defaulton the configuration. ReadenabledfromGET /v1/companies/{company_id}/verifactu-configurationinstead: it is now the only switch. - The invoice's
verifactublock stays,verifactu.enabledincluded — but there it is no longer a preference, it is the record of what was applied. Theverifactu_enabledfilter on the invoice list keeps working against that record. nif_statusnarrows toACTIVATED | DEACTIVATED.PENDINGandERRORdescribed an "enabled but not registered yet" state that no longer exists: activating is registering the NIF, atomically — either the row ends upACTIVATED, or the call returns the reason and nothing is persisted. If youswitchon those two values, those branches are now unreachable.- Two new
422s onPUT .../verifactu-configuration.VERIFACTU_REPRESENTATION_REQUIRED—enabled: truein Live without the signed and validated AEAT representation, which is a precondition of registering the NIF.VERIFACTU_ALWAYS_ON_IN_SANDBOX—enabled: falsein sandbox, which is a permanent test bench and cannot be switched off. - What to do. Nothing urgent. To tidy up: stop sending the retired request properties, and read the regime from the configuration instead of from the retired response fields. If you ever chose per invoice, that choice no longer exists — it is made once, per NIF and per mode.
Endpoints
- PUT/v1/companies/{company_id}/verifactu-configurationThe single switch; two new 422 rejections
- GET/v1/companies/{company_id}/verifactu-configurationenabled is the regime of the NIF; apply_by_default is gone
- POST/v1/companies/{company_id}/invoicesoptions.verifactu_enabled is ignored
Where to go next
The PDF download waits instead of asking you to poll
`GET .../invoices/{id}/pdf` now waits for the PDF and answers `200`. `Prefer: wait=0` keeps the old pure polling behaviour.
The street number is no longer required in an address
`address.number` is now optional: omit it when the address has none, or when `street` already carries it.