NewStripe: a buyer with a NIF always gets a standard invoice, and the simplified threshold is deprecated
BeeL
Get startedMulti-NIFVeriFactuRulesStripeAPI referenceChangelog

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: