Auto-submit policy
Whether an issued invoice reaches AEAT is decided by the taxpayer, not by the request — what that means when you issue, and how to read the result.
Whether an invoice reaches AEAT is a fact of the taxpayer, resolved when the invoice is issued. If the NIF is under the VeriFactu regime, every invoice it issues is registered; if it is not, none is. There is nothing to set per invoice, and no request can opt one document in or out.
BeeL. works this way because the VERI*FACTU modality is chosen by the taxpayer, not per document: under article 16.1 of the RD 1007/2023 it covers «todos los registros de facturación generados». A per-invoice switch allowed a mixed ledger — two invoices from the same NIF on the same day, one registered and one not.
What decides it
Two conditions, both read at issue time:
The NIF's VeriFactu configuration is enabled
Read it with GET /v1/companies/{company_id}/verifactu-configuration. The only
writable field is enabled, through the matching PUT — everything else
(status, signed, activated, nif_status, nif_registered_at,
pdf_generated) is resolved for you and is read-only.
Turning it off stops the submission of every invoice that NIF issues from then on: those invoices generate no billing record. It does not delete the configuration or the registration. Before you turn it off, read the rules on timing: a taxpayer that starts submitting in VERI*FACTU stays in it at least until the end of that calendar year (article 16.5 of the RD 1007/2023).
The NIF is registered, and nif_status says so
nif_status is ACTIVATED once the tax ID is registered and ready to submit.
Its other values, and why it can lag behind enabled in sandbox, are in
Enabling VeriFactu for a NIF.
A proforma is never submitted, whatever the NIF's regime: it is not an invoice yet. It gets a fiscal record when you convert it.
How it reads on the invoice
The invoice resource carries a nested verifactu object. enabled tells you
which side of the axis the invoice is on, and it is decided once, at issue time:
{
"id": "...",
"status": "ISSUED",
"verifactu": {
"enabled": true,
"submission_status": "PENDING",
"registration_number": "094365f5-9637-40e9-851a-4e964a939b0b",
"registered_at": "2026-09-19T09:27:44Z",
"invoice_hash": "1863E77D540083E4259F4AF44322E16B962CB5D72C2F949AB2B30FA83E93FF84",
"qr_url": "https://www2.agenciatributaria.gob.es/wlpl/TIKE-CONT/ValidarQR?nif=B27534239&numserie=S-2026-0001&fecha=19-09-2026&importe=121.00",
"qr_base64": "iVBORw0KGgoAAAANSUhEUgAAAMgAAADI...",
"skip_reason": null
}
}The hash, the QR and the BeeL. registration_number are already there while
AEAT has not answered — they belong to the record as submitted, not to AEAT's
verdict. See QR code and the invoice PDF.
An invoice from a NIF outside the regime has enabled: false and no
submission_status at all — it is outside the axis, not failing on it:
{
"id": "...",
"status": "ISSUED",
"verifactu": {
"enabled": false
}
}To select those over the API, filter with ?verifactu_enabled=false. No value
of verifactu_status matches them, because they have no submission to describe.
See Submission states for what
submission_status does next, including NOT_SUBMITTED — an invoice that
should have reached AEAT and has no live record.
skip_reason is historical. Invoices issued while VeriFactu was a
per-invoice decision can carry a skip_reason (CONNECTION_DISABLED,
CONFIG_MISSING, CONFIG_DISABLED, NIF_NOT_REGISTERED) naming which switch
was off at the time. Nothing writes it any more: there is no per-invoice
omission left to explain, so on invoices issued today it is always null.
Keep reading it if you display it for old documents; do not build new logic on
it.
Issuing a wave you don't want registered
There is no way to exclude individual invoices. The NIF's enabled flag is
all-or-nothing for that taxpayer, and it is not a tool for leaving invoices
unregistered: see the rules on timing.
A submission is not undoable as a batch. If a NIF is under the regime, its invoices are registered as they are issued. Use a sandbox NIF for test issuance rather than disabling a live one.
There's no public "submit now" endpoint
The public API does not expose a way to trigger a submission by hand. What to do depends on what you are looking at: