# 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.

Sep 3, 2026 · Breaking

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_enabled` on invoice create and patch, `verifactu_enabled` on convert-to-invoice and on recurring templates, `verifactu_auto_submit` on a payment connection, and `apply_by_default` on 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_enabled` on a recurring template, `verifactu_auto_submit` on a payment connection, and `apply_by_default` on the configuration. Read `enabled` from `GET /v1/companies/{company_id}/verifactu-configuration` instead: it is now the only switch.
- **The invoice's `verifactu` block stays**, `verifactu.enabled` included — but there it is no longer a preference, it is the **record of what was applied**. The `verifactu_enabled` filter on the invoice list keeps working against that record.
- **`nif_status` narrows to `ACTIVATED | DEACTIVATED`.** `PENDING` and `ERROR` described an "enabled but not registered yet" state that no longer exists: activating **is** registering the NIF, atomically — either the row ends up `ACTIVATED`, or the call returns the reason and nothing is persisted. If you `switch` on those two values, those branches are now unreachable.
- **Two new `422`s on `PUT .../verifactu-configuration`.** `VERIFACTU_REPRESENTATION_REQUIRED` — `enabled: true` in Live without the signed and validated AEAT representation, which is a precondition of registering the NIF. `VERIFACTU_ALWAYS_ON_IN_SANDBOX` — `enabled: false` in 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-configuration` — The single switch; two new 422 rejections
- `GET /v1/companies/{company_id}/verifactu-configuration` — enabled is the regime of the NIF; apply_by_default is gone
- `POST /v1/companies/{company_id}/invoices` — options.verifactu_enabled is ignored

## Where to go next

- [VeriFactu configuration](/verifactu/updateCompanyVeriFactuConfiguration)
- [Auto-submit policy](/verifactu/auto-submit)

---

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