# 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](/verifactu/compliance-and-responsibilities#verifactu-modality-only):
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](/verifactu/enabling-verifactu#nif_status).
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:
```json
{
"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](/verifactu/qr-and-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:
```json
{
"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](/verifactu/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](/verifactu/compliance-and-responsibilities#verifactu-modality-only).
**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:
The regime is read when you issue, so fix the configuration first and then call
`POST /invoices/{id}/issue`. If the NIF is under the regime by then, the
invoice is issued with `submission_status: PENDING`.
It was issued by a NIF outside the regime, and that cannot be changed after the
fact — the invoice is a closed fiscal document. Write to
[it@beel.es](mailto:it@beel.es) with the invoice IDs or a date range if you
believe it should have been registered.
This one *was* expected to reach AEAT. Right after issuing it can still be in
flight, so re-read the invoice first. If it persists, it will not clear on its
own — open a ticket at [it@beel.es](mailto:it@beel.es) with the invoice IDs.
> **Rules that apply here:** [REC-002 · The record goes to AEAT as soon as the invoice is issued](/rules/records#rec-002)
## Related
- [Enabling VeriFactu for a NIF](/verifactu/enabling-verifactu) — getting a NIF under the regime, step by step
- [Submission states](/verifactu/submission-states) — what happens after the submission
- [Stripe / VeriFactu submission](/stripe/verifactu-submission) — the same rule applied to Stripe-generated invoices
- [Get a NIF's VeriFactu configuration](/verifactu/getCompanyVeriFactuConfiguration) — read a NIF's configuration
- [Update a NIF's VeriFactu configuration](/verifactu/updateCompanyVeriFactuConfiguration) — flip `enabled`, the only writable field
---
Full OpenAPI spec: https://docs.beel.es/api/openapi