# VeriFactu records

The billing record behind each invoice under VeriFactu: how it is generated, chained and sent to AEAT, and what to do with AEAT's answer.

[← All rules](/rules#all-rules)

Under VeriFactu every issued invoice produces a billing record that goes to AEAT. BeeL. generates, chains and submits it; these rules cover what that asks of your integration and of the issuing business.

13 rules: 8 from the law, 4 AEAT criteria, 1 BeeL. rule. [How to read a rule](/rules#how-to-read-a-rule).

## REC-001 · Each issued invoice gets a billing record built from its data

`Required` · Law · Impact: high · Checked by the API: BeeL. applies it.

When an invoice is issued, its billing record (registro de alta) is generated at that moment from the invoice's own data: issuer, recipient, number, dates, type, description, totals, regime and the tax breakdown of each line. BeeL. generates it; you classify each line correctly.

**Why:** The record is what AEAT registers. A line classified wrongly on the invoice is registered wrongly too, and only a later document can change it.

**Applies to:** operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice); Invoices of a company under VeriFactu.

**Legal basis:**

- RD 1007/2023 (RRSIF), art. 9 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a9)

  > «deberán generar automáticamente un registro de facturación de alta de forma simultánea o inmediatamente anterior a la expedición de cada factura.»

- RD 1007/2023 (RRSIF), art. 10.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a1-2)

  > «El registro informático de facturación de alta incluirá la siguiente información:»

**Incorrect:** Classifying an exempt line as a 0 % taxed line: AEAT registers a taxed operation.

**Correct:** Sending the exemption reason on the line, so the record carries the exempt base and its cause.

**Related:** [REC-002 · The record goes to AEAT as soon as the invoice is issued](/rules/records#rec-002) · [REC-004 · BeeL. generates the hash and the chain](/rules/records#rec-004) · [LIF-001 · An issued invoice is never edited or deleted](/rules/lifecycle#lif-001)

**Explained in:** [Compliance and responsibilities › What BeeL. does for each invoice](/verifactu/compliance-and-responsibilities#what-beel-does-for-each-invoice) · [What AEAT receives from your invoice](/verifactu/what-aeat-receives)

## REC-002 · The record goes to AEAT as soon as the invoice is issued

`Required` · Law · Impact: high · Checked by the API: BeeL. applies it.

Every billing record is sent to AEAT continuously and automatically, as the invoice is issued. BeeL. submits it without a call from you; issue each invoice when the operation happens rather than holding drafts to issue in batches.

**Why:** Under VERI*FACTU the immediacy of the submission is part of the record's security. There is no per-invoice switch and no later submit step.

**Applies to:** operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice); Invoices of a company under VeriFactu.

**Legal basis:**

- RD 1007/2023 (RRSIF), art. 16.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a1-8)

  > «de forma continuada, segura, correcta, íntegra, automática, consecutiva, instantánea y fehaciente todos los registros de facturación generados»

- AEAT, Preguntas frecuentes SIF y VERI*FACTU, Sistemas VERI*FACTU — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/sistemas-verifactu.html)

  > «La inmediatez del envío a VERI*FACTU es parte del sistema de seguridad de los registros de facturación, por lo que se aplica en todos los casos.»

**Incorrect:** Keeping a day's sales as drafts and issuing them all at midnight.

**Correct:** Issuing each invoice when the sale happens, so its record goes out with it.

**Related:** [REC-001 · Each issued invoice gets a billing record built from its data](/rules/records#rec-001) · [REC-007 · Keep invoicing when AEAT is unreachable](/rules/records#rec-007) · [DAT-005 · Invoice consumers when the operation takes place](/rules/dates#dat-005)

**Explained in:** [Auto-submit policy](/verifactu/auto-submit)

## REC-003 · VERI*FACTU is kept until the end of the year

`Required` · Law · Impact: medium · Responsibility: the issuing business.

Once a NIF has sent its first record under VERI*FACTU, it keeps that modality at least until 31 December of that year. Leaving it is declared in a submission before the year ends.

**Why:** The option is annual: switching a NIF off in the middle of the year breaks the obligation it took on with its first submission.

**Applies to:** A NIF that has started sending records under VERI*FACTU.

**Legal basis:**

- RD 1007/2023 (RRSIF), art. 16.5 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a1-8)

  > «La opción en el uso de los «Sistemas de emisión de facturas verificables» se prolongará, al menos, hasta la finalización del año natural en el que se haya producido, de forma efectiva, el primer envío de los registros de facturación.»

- Orden HAC/1177/2024, art. 17.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138#a1-9)

  > «El funcionamiento como «VERI*FACTU» deberá mantenerse siempre al menos hasta el final del último año en que haya funcionado como tal, es decir, hasta el 31 de diciembre de dicho año.»

**Incorrect:** Planning to leave VERI*FACTU in the same year the NIF sent its first record.

**Correct:** Deciding before year end whether the NIF continues next year.

**Related:** [REC-002 · The record goes to AEAT as soon as the invoice is issued](/rules/records#rec-002) · [DAT-011 · Adapted billing systems are mandatory from 1 January 2027 or 1 July 2027](/rules/dates#dat-011)

**Explained in:** [Compliance and responsibilities › VERI*FACTU modality](/verifactu/compliance-and-responsibilities#verifactu-modality-only) · [Enabling VeriFactu for a NIF](/verifactu/enabling-verifactu)

## REC-004 · BeeL. generates the hash and the chain

`Required` · Law · Impact: high · Checked by the API: BeeL. applies it.

Do not compute a hash or chain records yourself. Each record carries a hash and refers to the previous record of the same issuer; BeeL. generates both when the invoice is issued.

**Why:** The chain is what makes the records traceable from the first to the last. A second chain kept by your system would not be the one AEAT receives.

**Applies to:** Invoices of a company under VeriFactu.

**Legal basis:**

- RD 1007/2023 (RRSIF), art. 8.2.b) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a8)

  > «La trazabilidad de los registros de facturación, que deberán estar encadenados de manera que pueda verificarse su rastro siguiendo su secuencia de creación desde el primero al último.»

- RD 1007/2023 (RRSIF), art. 12 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a1-4)

  > «deberán añadir una huella o «hash» a los registros de facturación de alta y de anulación»

- Orden HAC/1177/2024, art. 7.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138#a7)

  > «4.º Los primeros 64 caracteres de la huella o «hash» del registro de facturación inmediatamente anterior.»

**Incorrect:** Computing a SHA-256 over your own invoice fields and sending it with the invoice.

**Correct:** Issuing through BeeL. and reading `verifactu.invoice_hash` from the invoice if you need it.

**Related:** [REC-001 · Each issued invoice gets a billing record built from its data](/rules/records#rec-001) · [REC-005 · One chain per NIF, one company per NIF](/rules/records#rec-005)

**Explained in:** [Integrating BeeL. into your ERP › Who generates the record, the hash and the chain](/guides/erp-integration#who-generates-the-record-the-hash-and-the-chain)

## REC-005 · One chain per NIF, one company per NIF

`Required` · Law · Impact: high · Responsibility: your integration.

Records of each taxpayer are kept apart, in a chain of their own. Create one company per NIF and issue each invoice from the company of the NIF that issues it; show your users which one they are operating.

**Why:** A system used by several taxpayers must keep their records separate and meet the requirements for each one; an invoice issued from the wrong company lands in another taxpayer's chain.

**Applies to:** Accounts that invoice for several NIFs.

**Legal basis:**

- RD 1007/2023 (RRSIF), art. 7.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a7)

  > «siempre que los registros de facturación de cada obligado tributario se encuentren diferenciados y se cumplan los requisitos exigidos en este Reglamento por separado para cada uno de los obligados tributarios»

- Orden HAC/1177/2024, art. 7.c) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138#a7)

  > «Para un determinado obligado tributario, cada sistema informático producirá una única cadena de registros de facturación»

**Incorrect:** Issuing the invoices of two businesses from one company, told apart by a series prefix.

**Correct:** Creating a company per NIF and targeting each call at the right one.

**Related:** [REC-004 · BeeL. generates the hash and the chain](/rules/records#rec-004) · [REC-011 · The NIF holder signs the AEAT representation first](/rules/records#rec-011)

**Explained in:** [Overview › The model](/multi-nif#the-model)

## REC-006 · No certificate is needed to sign records

`Recommended` · Law · Impact: low · Checked by the API: BeeL. applies it.

Records sent under VERI*FACTU need no electronic signature: their hash is enough. Neither the issuer nor the integrator hands BeeL. a digital certificate for the submissions.

**Why:** Integrations that plan a signing step, or ask their customers for a certificate, add work the regulation does not require.

**Applies to:** Invoices of a company under VeriFactu.

**Legal basis:**

- RD 1007/2023 (RRSIF), art. 16.3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a1-8)

  > «no tendrán la obligación de realizar la firma electrónica de los registros de facturación a la que se refiere el artículo 12 de este Reglamento, siendo suficiente con que calculen la huella o «hash» de dichos registros.»

**Incorrect:** Asking each customer to upload a certificate so that their invoices can be signed.

**Correct:** Asking the NIF holder to sign the AEAT representation once, and nothing else.

**Related:** [REC-011 · The NIF holder signs the AEAT representation first](/rules/records#rec-011) · [REC-004 · BeeL. generates the hash and the chain](/rules/records#rec-004)

**Explained in:** [FAQ › Do I or my customers need a digital certificate?](/faq#do-i-need-a-digital-certificate) · [Compliance and responsibilities › Representation, not a certificate](/verifactu/compliance-and-responsibilities#representation-not-a-certificate)

## REC-007 · Keep invoicing when AEAT is unreachable

`Required` · Law · Impact: medium · Checked by the API: BeeL. applies it.

Do not stop invoicing because AEAT is unavailable. The invoice is issued and numbered as usual, the submission is retried, and a record that goes out on a later day than the issue date is flagged as a late submission.

**Why:** An incident in the submission never justifies stopping invoicing, and records have to be sent as soon as it is possible, in order and flagged as late.

**Applies to:** Invoices of a company under VeriFactu.

**Legal basis:**

- Orden HAC/1177/2024, art. 16.4 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138#a1-8)

  > «se deberá proceder a la remisión de los registros de facturación en cuanto sea posible, respetando el orden temporal de generación de los registros de facturación.»

- AEAT, Preguntas frecuentes SIF y VERI*FACTU, Sistemas VERI*FACTU — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/sistemas-verifactu.html)

  > «Incidencias como las mencionada, que afectan a la remisión a la AEAT , NO suponen en ningún caso que deba interrumpirse la facturación de la empresa.»

**Incorrect:** Queueing sales in your system until AEAT is back, then issuing them with the day's date.

**Correct:** Issuing through BeeL. as usual and following each invoice with the `verifactu.status.updated` webhook.

**Related:** [REC-002 · The record goes to AEAT as soon as the invoice is issued](/rules/records#rec-002) · [REC-008 · Follow submission_status and fix what AEAT rejects](/rules/records#rec-008) · [DAT-002 · The issue date is the day the billing record is generated](/rules/dates#dat-002)

**Explained in:** [Integrating BeeL. into your ERP › AEAT does not answer](/guides/erp-integration#aeat-does-not-answer) · [What AEAT receives from your invoice › Dates and late submission](/verifactu/what-aeat-receives#dates-and-late-submission)

## REC-008 · Follow submission_status and fix what AEAT rejects

`Required` · BeeL. rule · Impact: critical · Responsibility: your integration.

Track each issued invoice's `verifactu.submission_status` (`NOT_SUBMITTED`, `PENDING`, `ACCEPTED`, `REJECTED`, `VOIDED`) through the `verifactu.status.updated` webhook and a periodic reconciliation. A transient AEAT error keeps the invoice `PENDING` while BeeL. retries it. A `REJECTED` invoice is not registered: read its `error_message`, and its `error_code` when AEAT gave one, and fix it. `GET /v1/companies/{company_id}/invoices/{invoice_id}/verifactu-records` lists each record of the invoice, its cancellation included, with its own status.

**Why:** A `200` on issue means BeeL. accepted the invoice, not that AEAT registered it. A rejection nobody reads leaves an invoice outside AEAT's records.

**Applies to:** operations [`GET /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/getCompanyInvoice); Invoices of a company under VeriFactu.

**Incorrect:** Treating the `200` of the issue call as proof that AEAT registered the invoice.

**Correct:** Subscribing to `verifactu.status.updated` and, on a schedule, listing invoices `REJECTED` or still `NOT_SUBMITTED` to reconcile them.

**Related:** [REC-009 · Check the data AEAT accepted with errors](/rules/records#rec-009) · [REC-010 · Subsanación is only for errors that need no corrective](/rules/records#rec-010) · [QRC-002 · Wait for the QR before you distribute the PDF](/rules/qr#qrc-002)

**Explained in:** [Submission states › The fiscal states](/verifactu/submission-states#the-fiscal-states) · [Handling AEAT rejections › Reconcile, do not only listen](/verifactu/handling-rejections#reconcile-do-not-only-listen)

## REC-009 · Check the data AEAT accepted with errors

`Required` · AEAT criterion · Impact: medium · Responsibility: your integration.

When AEAT accepts a record but reports an error (`ACCEPTED` with an `error_code`), check the data it flagged, usually the recipient's tax ID and name. If it was right, nothing else is needed. If it was wrong, fix it in the customer's data and correct the invoice already recorded with an `R4` corrective that carries the corrected recipient ([COR-017](/rules/corrective#cor-017)); the following invoices take the fixed data.

**Why:** A record accepted with errors stays in AEAT with those errors until a later document fixes them, and for a recipient's data that document is a corrective.

**Applies to:** Invoices `ACCEPTED` with an `error_code`.

**Legal basis:**

- AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 4.3.1 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf)

  > «Los registros de facturación con errores admisibles serán “aceptados” y registrados por los sistemas de la AEAT, pero deberán ser subsanados para poder llevar a cabo el tratamiento y validación de los mismos.»

**Incorrect:** Reading `ACCEPTED` and ignoring the `error_code` next to it.

**Correct:** Reading `error_message`, confirming the customer's tax ID was mistyped, fixing it in the customer's data and issuing the `R4` corrective of the recipient's data for the invoice already recorded.

**Related:** [REC-008 · Follow submission_status and fix what AEAT rejects](/rules/records#rec-008) · [COR-017 · A corrective keeps the recipient, except to correct the recipient's data](/rules/corrective#cor-017)

**Explained in:** [Handling AEAT rejections › Accepted with errors](/verifactu/handling-rejections#accepted-with-errors)

## REC-010 · Subsanación is only for errors that need no corrective

`Required` · AEAT criterion · Impact: medium · Responsibility: your integration.

A subsanación replaces a registration record with a corrected one, and applies only when the error needs no corrective invoice. When AEAT refused the record for a cause outside the invoice's data, such as an issuer not yet in the census, fix the cause and contact BeeL. with the invoice. Any error in what the invoice says is fixed with a corrective.

**Why:** AEAT allows a subsanación only when the cause does not require a corrective invoice; a wrong amount, customer or description does.

**Applies to:** Records rejected or accepted with errors.

**Legal basis:**

- AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 4.3.1 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf)

  > «Solo podrá llevarse a cabo una subsanación cuando no se trate de una causa que exija la emisión de una factura rectificativa (u otro mecanismo contemplado en el Reglamento de Facturación).»

- AEAT, Preguntas frecuentes SIF y VERI*FACTU, Registros de facturación: alta — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/registros-facturacion-alta.html)

  > «podrá ser una anulación completa del registro inicial o una subsanación / sustitución (es decir sustitución del “registro de alta” por otro registro subsanado)»

**Incorrect:** Asking for a subsanación of an invoice whose recipient NIF was wrong.

**Correct:** Getting the issuing NIF registered in the AEAT census, then contacting BeeL. with the invoice ID.

**Related:** [REC-008 · Follow submission_status and fix what AEAT rejects](/rules/records#rec-008) · [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [VOI-001 · Void only an invoice that should never have been issued](/rules/void#voi-001)

**Explained in:** [Handling AEAT rejections › When to contact support](/verifactu/handling-rejections#when-to-contact-support) · [Cancel vs amend](/verifactu/cancel-and-fix)

## REC-011 · The NIF holder signs the AEAT representation first

`Required` · Law · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed.

Before a NIF issues real invoices under VeriFactu, its holder signs the AEAT representation that lets BeeL. submit the records on the taxpayer's behalf. Enabling VeriFactu without it is rejected with [`VERIFACTU_REPRESENTATION_REQUIRED`](/errors/VERIFACTU_REPRESENTATION_REQUIRED); issuing is rejected with [`EMISSION_NOT_READY`](/errors/EMISSION_NOT_READY), with [`NIF_REPRESENTATION_REQUIRED`](/errors/NIF_REPRESENTATION_REQUIRED) among the blockers in `details`.

**Why:** Records are sent by the taxpayer or by someone acting as its representative. Without the signed representation there is nobody entitled to send them.

**Applies to:** operations [`POST /v1/companies/{company_id}/representation`](/companies/generateCompanyRepresentation), [`POST /v1/companies/{company_id}/representation/submit`](/companies/submitCompanyRepresentation), [`PUT /v1/companies/{company_id}/verifactu-configuration`](/verifactu/updateCompanyVeriFactuConfiguration), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice); Production (Live) NIFs; sandbox needs no representation.

**Error codes:** [`VERIFACTU_REPRESENTATION_REQUIRED`](/errors/VERIFACTU_REPRESENTATION_REQUIRED) (`422`), [`EMISSION_NOT_READY`](/errors/EMISSION_NOT_READY) (`422`), [`NIF_REPRESENTATION_REQUIRED`](/errors/NIF_REPRESENTATION_REQUIRED)

**Legal basis:**

- Orden HAC/1177/2024, art. 5 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138#a5)

  > «La remisión podrá ser efectuada por el propio obligado tributario o por un tercero que actúe en su representación»

**Incorrect:** Enabling VeriFactu in Live for a new NIF straight after creating it: the API answers [`VERIFACTU_REPRESENTATION_REQUIRED`](/errors/VERIFACTU_REPRESENTATION_REQUIRED).

**Correct:** Generating the representation document, having the holder sign it, uploading it, and then enabling VeriFactu.

**Related:** [REC-006 · No certificate is needed to sign records](/rules/records#rec-006) · [REC-005 · One chain per NIF, one company per NIF](/rules/records#rec-005)

**Explained in:** [Compliance and responsibilities › Representation, not a certificate](/verifactu/compliance-and-responsibilities#representation-not-a-certificate) · [Enabling VeriFactu for a NIF › Sign the AEAT representation](/verifactu/enabling-verifactu#sign-the-aeat-representation)

## REC-012 · Tax amounts are base times rate

`Required` · AEAT criterion · Impact: low · Checked by the API: BeeL. applies it.

The tax amount of each breakdown equals its base times its rate, with the same sign as the base. BeeL. computes it from the rate of each line: the API takes rates, never tax amounts.

**Why:** AEAT checks the tax amount against base × rate, allowing 10 € of difference, and rejects the record beyond it.

**Applies to:** Every taxed line.

**Legal basis:**

- AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.7 CuotaRepercutida — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf)

  > «CuotaRepercutida y BaseImponibleOimporteNoSujeto deben tener el mismo signo.»

**Incorrect:** Keeping a tax amount computed by your system and expecting BeeL. to register it.

**Correct:** Sending the rate on each line (`main_tax`) and reading the computed amounts from the response.

**Related:** [REC-001 · Each issued invoice gets a billing record built from its data](/rules/records#rec-001) · [TAX-001 · Apply the VAT rate in force when the operation took place](/rules/taxes#tax-001)

**Explained in:** [Amounts and rounding › Taxes are rounded per group, not per line](/guides/amounts-and-rounding#taxes-are-rounded-per-group-not-per-line)

## REC-013 · An invoice AEAT would reject is not numbered

`Required` · AEAT criterion · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed.

Before an invoice recorded with VeriFactu takes its number, BeeL. builds the billing record it will send and checks it against AEAT's validations: the invoice type, the recipient, the correction, the tax breakdown (at most 12 groups, rates with two decimals, the rate and surcharge accepted on the operation date, what each regime key admits) and the operation date. If AEAT would reject the record, the invoice is not issued and the number is not used: the API answers `422` with the specific code, or [`VERIFACTU_RECORD_NOT_DECLARABLE`](/errors/VERIFACTU_RECORD_NOT_DECLARABLE) with the AEAT section in its message when there is no specific one. The record that is checked is exactly the one that is sent.

**Why:** AEAT rejects a record after the invoice already has its number, and a gap in the numbering cannot be repaired.

**Applies to:** operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice); Invoices recorded with VeriFactu.

**Error codes:** [`VERIFACTU_RECORD_NOT_DECLARABLE`](/errors/VERIFACTU_RECORD_NOT_DECLARABLE), [`INVOICE_TAX_BREAKDOWN_TOO_LONG`](/errors/INVOICE_TAX_BREAKDOWN_TOO_LONG), [`INVOICE_TAX_RATE_TOO_MANY_DECIMALS`](/errors/INVOICE_TAX_RATE_TOO_MANY_DECIMALS) (`422`), [`EXEMPTION_INCOMPATIBLE_WITH_REGIME`](/errors/EXEMPTION_INCOMPATIBLE_WITH_REGIME) (`400`), [`VAT_RATE_NOT_ACCEPTED_ON_DATE`](/errors/VAT_RATE_NOT_ACCEPTED_ON_DATE) (`422`), [`SURCHARGE_RATE_NOT_ACCEPTED_ON_DATE`](/errors/SURCHARGE_RATE_NOT_ACCEPTED_ON_DATE) (`422`), [`OPERATION_DATE_TOO_OLD`](/errors/OPERATION_DATE_TOO_OLD), [`INVOICE_REQUIRES_AT_LEAST_ONE_NORMAL_LINE`](/errors/INVOICE_REQUIRES_AT_LEAST_ONE_NORMAL_LINE) (`422`)

**Legal basis:**

- AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.13 Agrupación Destinatarios — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf)

  > «Si TipoFactura es “F2” o “R5”, la agrupación Destinatarios no puede estar cumplimentada.»

- AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.4 CalificacionOperacion — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf)

  > «Si CalificacionOperacion es “S2”, TipoFactura solo puede ser “F1”, “F3”, “R1”, “R2”, “R3” y “R4”.»

- AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.5 OperacionExenta — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf)

  > «Si Impuesto = “01” (IVA), “03” (IGIC) o no se cumplimenta (considerándose “01” - IVA), y ClaveRegimen es igual a “01”, no pueden marcarse los valores de OperacionExenta “E2” y “E3”.»

**Incorrect:** Issuing a draft saved before a rule existed, with an exemption under article 21 and regime key `01`: the API answers [`EXEMPTION_INCOMPATIBLE_WITH_REGIME`](/errors/EXEMPTION_INCOMPATIBLE_WITH_REGIME) and the draft keeps no number.

**Correct:** Fixing the draft (regime key `02` for an export) and issuing it again.

**Related:** [REC-001 · Each issued invoice gets a billing record built from its data](/rules/records#rec-001) · [TAX-014 · Only the VAT rates AEAT accepts on the operation date](/rules/taxes#tax-014) · [TAX-017 · Special regime keys carry the classification AEAT requires](/rules/taxes#tax-017)

[← All rules](/rules#all-rules)

## Related

<Related>

- [Compliance and responsibilities](/verifactu/compliance-and-responsibilities) — what BeeL. does for each invoice, who signs its declaración responsable, the rules that apply to software built on the API and to the issuing business, the VERI*FACTU modality, and what BeeL. keeps for each record
- [Handling AEAT rejections](/verifactu/handling-rejections) — how to read a REJECTED invoice (and an accepted one that carries an error code), what to do for each family of AEAT codes, and how to make sure you never miss one
- [Integrating BeeL. into your ERP](/guides/erp-integration) — the decisions every ERP integration makes — who issues the invoice, who renders the PDF and sends the email, how to continue your numbering, how to correct an invoice, and how to hear back from AEAT
- [Enabling VeriFactu for a NIF](/verifactu/enabling-verifactu) — put a NIF under the VeriFactu regime in Live — the steps, the configuration fields that tell you where you are, the errors you can hit, and the blockers that stop issuing

</Related>

---

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