# BeeL. API Documentation — Rules Every page of the Rules area, in full. Index: /llms.txt --- # Fiscal rules 143 fiscal and VeriFactu rules for invoicing integrations, as pages and as data for your AI assistant, the MCP server or CI. **A set of 143 rules your invoicing integration has to follow, as data your AI agent can check your code against.** Each one comes from the law, from AEAT or from BeeL., has a stable id (`LIF-001`), says who checks it, and lists the errors the API answers when it catches it. The guides explain how to do things; these pages say what must and must not happen. ## Use the rules in your tools **In Claude Code**, install the [BeeL. plugin](/claude-code) and ask it for a rule: ```text /plugin marketplace add beel-es/claude-plugins /plugin install beel-api@beel /beel-api:rules COR-002 ``` **With the BeeL. MCP server** (shown for Claude Code; [other clients](/mcp)), add it and ask in plain words. Its [rules tools](/mcp/tools#helper-tools) answer, and a failed call names the rule behind its error: ```bash claude mcp add --transport http beel https://mcp.beel.es/mcp ``` ```text Which BeeL. rules apply to voiding an invoice, and which are up to my integration? ``` **In any AI assistant** (Cursor, Copilot, ChatGPT…), paste this prompt, or keep the critical rules in every session with the [AGENTS.md block](/ai-agents#give-your-agent-the-rules): ```text Review my BeeL. integration against https://docs.beel.es/api/rules.json and list every rule it breaks, with its id and the fix. ``` **In your CI**, read the catalogue as JSON ([its format](/api/rules.schema.json)): ```bash curl -s https://docs.beel.es/api/rules.json ``` Each rule is also Markdown at `/rules/.md` (for example [`/rules/LIF-001.md`](/rules/LIF-001.md)), and all of them are in [`/rules/llms-full.txt`](/rules/llms-full.txt). ## How to read a rule - **Severity.** *Required* or *Recommended*. - **Source.** *Law* and *AEAT criterion* quote the norm verbatim, with its link. *BeeL. rule* is how BeeL.'s API works. - **Error codes.** What the API answers when it catches the rule. Each one links to its page. ### What each responsibility asks of you | Responsibility | What you do | |---|---| | **Checked by the API** (`api`) | Handle the error codes the rule lists: the API rejects the request or applies the rule for you. | | **Checked by AEAT** (`aeat`) | Track the invoice's submission status. See [Handling rejections](/verifactu/handling-rejections). | | **Your integration** (`integrator`) | Meet it in your code, and check it in review and tests. See [Software built on the API](/verifactu/compliance-and-responsibilities#software-built-on-the-api). | | **The issuing business** (`issuer`) | A decision of the business that issues the invoice: your integration can ask for it or show it. See [The issuing business](/verifactu/compliance-and-responsibilities#the-issuing-business). | ## All rules ### [Invoice lifecycle](/rules/lifecycle) - [LIF-001 · An issued invoice is never edited or deleted](/rules/lifecycle#lif-001) — `Required`, Law, Checked by the API - [LIF-002 · Only a draft can be issued](/rules/lifecycle#lif-002) — `Required`, BeeL. rule, Checked by the API - [LIF-003 · Test in the sandbox, never with real invoices](/rules/lifecycle#lif-003) — `Required`, AEAT criterion, Responsibility: your integration - [LIF-004 · Retry writes with the same Idempotency-Key](/rules/lifecycle#lif-004) — `Recommended`, BeeL. rule, Responsibility: your integration - [LIF-005 · Duplicating an invoice creates a new one, not a copy](/rules/lifecycle#lif-005) — `Required`, BeeL. rule, Responsibility: your integration ### [Voiding](/rules/void) - [VOI-001 · Void only an invoice that should never have been issued](/rules/void#voi-001) — `Required`, AEAT criterion, Responsibility: the issuing business - [VOI-002 · Void an issued invoice through the void operation; delete a draft](/rules/void#voi-002) — `Required`, BeeL. rule, Checked by the API - [VOI-003 · A void adds a cancellation record; the original stays](/rules/void#voi-003) — `Required`, Law, Checked by the API - [VOI-004 · A sent or paid invoice is voided only confirming it was issued by mistake](/rules/void#voi-004) — `Required`, AEAT criterion, Checked by the API - [VOI-005 · A corrected invoice, or a total corrective, is not voided](/rules/void#voi-005) — `Required`, AEAT criterion, Checked by the API ### [Corrective invoices](/rules/corrective) - [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) — `Required`, Law, Checked by the API - [COR-002 · Pick the reason code: R1–R4 for standard invoices, R5 for simplified](/rules/corrective#cor-002) — `Required`, Law, Checked by the API - [COR-003 · A corrective shows the difference or the amounts after the correction](/rules/corrective#cor-003) — `Required`, Law, Checked by the API - [COR-004 · The corrective record says whether it substitutes or adds a difference](/rules/corrective#cor-004) — `Required`, AEAT criterion, Checked by the API - [COR-005 · A corrective identifies the invoice it rectifies](/rules/corrective#cor-005) — `Required`, Law, Checked by the API - [COR-006 · Issue the corrective as soon as you know, within 4 years](/rules/corrective#cor-006) — `Required`, Law, Checked by the API - [COR-007 · A wrong corrective is fixed against the original, not corrected itself](/rules/corrective#cor-007) — `Required`, BeeL. rule, Checked by the API - [COR-008 · A bad-debt corrective (R3) needs the legal conditions first](/rules/corrective#cor-008) — `Required`, Law, Responsibility: the issuing business - [COR-009 · An insolvency corrective (R2) needs a declaration of insolvency](/rules/corrective#cor-009) — `Required`, Law, Responsibility: the issuing business - [COR-010 · A provisional price is rectified once the final one is known](/rules/corrective#cor-010) — `Required`, Law, Responsibility: the issuing business - [COR-011 · Discounts and rebates granted after the sale go on a corrective](/rules/corrective#cor-011) — `Required`, Law, Responsibility: the issuing business - [COR-012 · Returns can be netted only on a later supply to the same customer](/rules/corrective#cor-012) — `Recommended`, Law, Responsibility: the issuing business - [COR-013 · A corrective is only for the causes the law lists](/rules/corrective#cor-013) — `Required`, Law, Responsibility: the issuing business - [COR-014 · A corrective keeps the operation date of the original](/rules/corrective#cor-014) — `Required`, AEAT criterion, Checked by the API - [COR-015 · Do not raise the VAT charged to a consumer through a corrective](/rules/corrective#cor-015) — `Required`, Law, Responsibility: the issuing business - [COR-016 · Some unpaid debts never allow an R2 or R3 corrective](/rules/corrective#cor-016) — `Required`, Law, Responsibility: the issuing business - [COR-017 · A corrective keeps the recipient, except to correct the recipient's data](/rules/corrective#cor-017) — `Required`, Law, Checked by the API - [COR-018 · A corrective can always correct what the original declared](/rules/corrective#cor-018) — `Required`, Law, Checked by the API - [COR-019 · Insolvency and bad-debt correctives need a recipient established in Spain](/rules/corrective#cor-019) — `Required`, Law, Checked by the API - [COR-020 · A bad-debt corrective waits six months and needs a business recipient under 50 €](/rules/corrective#cor-020) — `Required`, Law, Checked by the API - [COR-021 · An identical corrective a moment after another is taken as a double submission](/rules/corrective#cor-021) — `Recommended`, BeeL. rule, Checked by the API - [COR-022 · An invoice whose record AEAT rejected is fixed before it is corrected](/rules/corrective#cor-022) — `Required`, AEAT criterion, Checked by the API - [COR-023 · A corrective never rectifies more than was invoiced](/rules/corrective#cor-023) — `Required`, Law, Checked by the API - [COR-024 · A corrective does not change only the withholding](/rules/corrective#cor-024) — `Required`, Law, Checked by the API ### [Numbering and series](/rules/numbering) - [NUM-001 · The number is assigned when the invoice is issued](/rules/numbering#num-001) — `Required`, BeeL. rule, Checked by the API - [NUM-002 · An issued number is never reused, even when the invoice is voided](/rules/numbering#num-002) — `Required`, AEAT criterion, Checked by the API - [NUM-003 · Numbers are correlative within each series](/rules/numbering#num-003) — `Required`, Law, Checked by the API - [NUM-004 · Separate series may be used when there is a reason for them](/rules/numbering#num-004) — `Recommended`, Law, Responsibility: the issuing business - [NUM-005 · Simplified invoices are numbered in their own series](/rules/numbering#num-005) — `Required`, Law, Checked by the API - [NUM-006 · Corrective invoices are numbered in their own series](/rules/numbering#num-006) — `Required`, Law, Checked by the API - [NUM-007 · A series cannot be renumbered once it has issued](/rules/numbering#num-007) — `Required`, BeeL. rule, Checked by the API - [NUM-008 · An invoice number fits AEAT's length and character set](/rules/numbering#num-008) — `Required`, AEAT criterion, Checked by the API - [NUM-009 · Reverse-charge supplies of metals and electronics go in a special series](/rules/numbering#num-009) — `Required`, Law, Responsibility: the issuing business ### [Invoice contents](/rules/contents) - [CNT-001 · Every operation of the business is invoiced, exempt ones included](/rules/contents#cnt-001) — `Required`, Law, Responsibility: the issuing business - [CNT-002 · A business customer always gets an invoice, identifying it when asked](/rules/contents#cnt-002) — `Required`, Law, Responsibility: the issuing business - [CNT-003 · A full invoice names both parties by their legal name](/rules/contents#cnt-003) — `Required`, Law, Checked by the API - [CNT-004 · Every invoice shows the issuer's NIF](/rules/contents#cnt-004) — `Required`, Law, Checked by the API - [CNT-005 · A full invoice identifies the recipient by NIF](/rules/contents#cnt-005) — `Required`, Law, Checked by the API - [CNT-006 · A full invoice shows the address of both parties](/rules/contents#cnt-006) — `Required`, Law, Responsibility: your integration - [CNT-007 · Each line describes the operation, its unit price and any discount](/rules/contents#cnt-007) — `Required`, Law, Responsibility: your integration - [CNT-008 · The tax rate and the tax amount are shown apart from the base](/rules/contents#cnt-008) — `Required`, Law, Checked by the API - [CNT-009 · The base is broken down by rate and by kind of operation](/rules/contents#cnt-009) — `Required`, Law, Checked by the API - [CNT-010 · An exempt operation states why it is exempt](/rules/contents#cnt-010) — `Required`, Law, Checked by the API - [CNT-011 · Only one original of each invoice exists](/rules/contents#cnt-011) — `Required`, Law, Responsibility: the issuing business - [CNT-012 · A reverse-charge invoice carries the mention «inversión del sujeto pasivo»](/rules/contents#cnt-012) — `Required`, Law, Checked by the API - [CNT-013 · A cash-basis invoice carries the mention «régimen especial del criterio de caja»](/rules/contents#cnt-013) — `Required`, Law, Checked by the API - [CNT-014 · A used-goods, art or antiques invoice carries its regime mention](/rules/contents#cnt-014) — `Required`, Law, Responsibility: the issuing business - [CNT-015 · A travel-agency invoice carries the mention «régimen especial de las agencias de viajes»](/rules/contents#cnt-015) — `Required`, Law, Checked by the API - [CNT-016 · An intra-EU supply of a new means of transport describes the vehicle](/rules/contents#cnt-016) — `Required`, Law, Responsibility: the issuing business - [CNT-017 · An invoice may be in any language](/rules/contents#cnt-017) — `Recommended`, Law, Responsibility: the issuing business - [CNT-018 · Invoices go by email only with the recipient's consent](/rules/contents#cnt-018) — `Required`, Law, Responsibility: the issuing business - [CNT-019 · Only a corrective invoice totals less than zero](/rules/contents#cnt-019) — `Required`, BeeL. rule, Checked by the API - [CNT-020 · A Spanish recipient's NIF is in the AEAT census](/rules/contents#cnt-020) — `Recommended`, AEAT criterion, Checked by the API - [CNT-021 · A recipient without a Spanish NIF is identified by an alternative id](/rules/contents#cnt-021) — `Required`, AEAT criterion, Checked by the API - [CNT-022 · Invoices to Spanish public administrations are electronic](/rules/contents#cnt-022) — `Required`, Law, Responsibility: the issuing business - [CNT-023 · Some operations are always invoiced, whoever the customer](/rules/contents#cnt-023) — `Required`, Law, Responsibility: the issuing business - [CNT-024 · A duplicate for several recipients shows each one's share](/rules/contents#cnt-024) — `Required`, Law, Responsibility: the issuing business - [CNT-025 · State the establishment when it decides how the operation is taxed](/rules/contents#cnt-025) — `Required`, Law, Responsibility: the issuing business ### [Simplified invoices](/rules/simplified) - [SIM-001 · A simplified invoice never exceeds 3,000 €](/rules/simplified#sim-001) — `Required`, AEAT criterion, Checked by the API - [SIM-002 · Above 400 €, a simplified invoice needs an art. 4.2 activity](/rules/simplified#sim-002) — `Required`, Law, Responsibility: the issuing business - [SIM-003 · Some operations can never go on a simplified invoice](/rules/simplified#sim-003) — `Required`, Law, Checked by the API - [SIM-004 · A simplified invoice still carries its minimum contents](/rules/simplified#sim-004) — `Required`, Law, Checked by the API - [SIM-005 · The record of a simplified invoice carries no recipient](/rules/simplified#sim-005) — `Required`, AEAT criterion, Checked by the API - [SIM-006 · An identified customer gets a standard invoice (F1)](/rules/simplified#sim-006) — `Required`, BeeL. rule, Checked by the API - [SIM-007 · Exchanging a simplified invoice for a full one](/rules/simplified#sim-007) — `Required`, Law, Checked by the API - [SIM-008 · A simplified invoice carries the same legal mentions as a full one](/rules/simplified#sim-008) — `Required`, Law, Responsibility: the issuing business - [SIM-009 · A customer who asks to be identified gets an invoice that identifies it](/rules/simplified#sim-009) — `Required`, Law, Responsibility: the issuing business - [SIM-010 · A simplified invoice with several VAT rates shows the base of each](/rules/simplified#sim-010) — `Required`, Law, Responsibility: your integration ### [Taxes and exemptions](/rules/taxes) - [TAX-001 · Apply the VAT rate in force when the operation took place](/rules/taxes#tax-001) — `Required`, Law, Responsibility: the issuing business - [TAX-002 · Reverse-charge operations are invoiced without charging VAT](/rules/taxes#tax-002) — `Required`, Law, Checked by the API - [TAX-003 · Reverse-charge lines carry no tax and never go on a simplified invoice](/rules/taxes#tax-003) — `Required`, AEAT criterion, Checked by the API - [TAX-004 · Intra-EU supplies of goods are exempt only with the buyer's EU VAT number](/rules/taxes#tax-004) — `Required`, Law, Checked by the API - [TAX-005 · Exempt and non-subject lines carry no VAT rate](/rules/taxes#tax-005) — `Required`, AEAT criterion, Checked by the API - [TAX-006 · Services to a business abroad are not subject to Spanish VAT](/rules/taxes#tax-006) — `Required`, Law, Responsibility: the issuing business - [TAX-007 · Sales declared through OSS use regime key 17](/rules/taxes#tax-007) — `Required`, AEAT criterion, Responsibility: the issuing business - [TAX-008 · Disbursements go as SUPLIDO lines, without tax](/rules/taxes#tax-008) — `Required`, AEAT criterion, Checked by the API - [TAX-009 · IRPF withholding is not part of the total AEAT receives](/rules/taxes#tax-009) — `Required`, AEAT criterion, Checked by the API - [TAX-010 · Set the IRPF withholding when the customer must withhold](/rules/taxes#tax-010) — `Recommended`, BeeL. rule, Responsibility: your integration - [TAX-012 · The tax and the billing record are expressed in euros](/rules/taxes#tax-012) — `Required`, Law, Checked by the API - [TAX-013 · Send every amount in euros](/rules/taxes#tax-013) — `Required`, BeeL. rule, Responsibility: your integration - [TAX-014 · Only the VAT rates AEAT accepts on the operation date](/rules/taxes#tax-014) — `Required`, AEAT criterion, Checked by the API - [TAX-015 · Regime key 08 means not subject to the line's tax](/rules/taxes#tax-015) — `Required`, AEAT criterion, Checked by the API - [TAX-016 · Regime keys 03, 06 and 14 are not accepted](/rules/taxes#tax-016) — `Required`, AEAT criterion, Checked by the API - [TAX-017 · Special regime keys carry the classification AEAT requires](/rules/taxes#tax-017) — `Required`, AEAT criterion, Checked by the API - [TAX-018 · An issued invoice does not use the intra-EU acquisition exemption](/rules/taxes#tax-018) — `Required`, Law, Checked by the API - [TAX-019 · An issuer that is not an individual never bears the IRPF rates of individuals](/rules/taxes#tax-019) — `Required`, Law, Checked by the API - [TAX-022 · Reduced withholding rates of Ceuta and Melilla derive from their base rate](/rules/taxes#tax-022) — `Required`, Law, Checked by the API ### [Equivalence surcharge](/rules/surcharge) - [SUR-001 · The surcharge rate matches the VAT rate of its line](/rules/surcharge#sur-001) — `Required`, Law, Checked by the API - [SUR-002 · Supplies with the surcharge go on separate invoices](/rules/surcharge#sur-002) — `Required`, Law, Responsibility: the issuing business ### [Dates and deadlines](/rules/dates) - [DAT-001 · Do not send an issue date](/rules/dates#dat-001) — `Required`, BeeL. rule, Checked by the API - [DAT-002 · The issue date is the day the billing record is generated](/rules/dates#dat-002) — `Required`, AEAT criterion, Checked by the API - [DAT-003 · The operation date is never after the issue date nor over twenty years old](/rules/dates#dat-003) — `Required`, AEAT criterion, Checked by the API - [DAT-004 · Send the operation date when it differs from the issue date](/rules/dates#dat-004) — `Required`, Law, Responsibility: your integration - [DAT-005 · Invoice consumers when the operation takes place](/rules/dates#dat-005) — `Required`, Law, Responsibility: the issuing business - [DAT-006 · Invoice businesses before day 16 of the following month](/rules/dates#dat-006) — `Required`, Law, Responsibility: the issuing business - [DAT-007 · One invoice for a month of operations, issued in time](/rules/dates#dat-007) — `Required`, Law, Responsibility: the issuing business - [DAT-008 · Deliver the invoice to the customer in time](/rules/dates#dat-008) — `Required`, Law, Responsibility: the issuing business - [DAT-009 · VAT is charged by invoice within 1 year of accrual](/rules/dates#dat-009) — `Required`, Law, Responsibility: the issuing business - [DAT-010 · Invoice advance payments when you receive them](/rules/dates#dat-010) — `Required`, Law, Responsibility: the issuing business - [DAT-011 · Adapted billing systems are mandatory from 1 January 2027 or 1 July 2027](/rules/dates#dat-011) — `Required`, Law, Responsibility: the issuing business - [DAT-012 · Plan for mandatory B2B electronic invoices](/rules/dates#dat-012) — `Recommended`, Law, Responsibility: the issuing business - [DAT-013 · Intra-EU supplies of goods are invoiced by the month after transport starts](/rules/dates#dat-013) — `Required`, Law, Responsibility: the issuing business - [DAT-014 · Under the cash-basis regime, the deadline runs from the operation, not the payment](/rules/dates#dat-014) — `Required`, Law, Responsibility: the issuing business ### [QR code and PDF](/rules/qr) - [QRC-001 · Every invoice carries the tax QR code](/rules/qr#qrc-001) — `Required`, Law, Responsibility: your integration - [QRC-002 · Wait for the QR before you distribute the PDF](/rules/qr#qrc-002) — `Required`, BeeL. rule, Responsibility: your integration - [QRC-003 · The QR measures between 30 mm and 40 mm](/rules/qr#qrc-003) — `Required`, Law, Responsibility: your integration - [QRC-004 · The QR follows ISO/IEC 18004 with error correction M](/rules/qr#qrc-004) — `Required`, Law, Responsibility: your integration - [QRC-005 · Use qr_url exactly as returned](/rules/qr#qrc-005) — `Required`, Law, Checked by the API - [QRC-006 · The VeriFactu legend goes just below the QR](/rules/qr#qrc-006) — `Required`, Law, Responsibility: your integration - [QRC-007 · «QR tributario:» goes just above the QR](/rules/qr#qrc-007) — `Required`, AEAT criterion, Responsibility: your integration - [QRC-008 · The QR goes once, at the start of the first page](/rules/qr#qrc-008) — `Required`, AEAT criterion, Responsibility: your integration - [QRC-009 · Keep a blank margin around the QR](/rules/qr#qrc-009) — `Required`, AEAT criterion, Responsibility: your integration - [QRC-010 · A structured e-invoice carries the QR URL as a field](/rules/qr#qrc-010) — `Required`, Law, Responsibility: your integration ### [VeriFactu records](/rules/records) - [REC-001 · Each issued invoice gets a billing record built from its data](/rules/records#rec-001) — `Required`, Law, Checked by the API - [REC-002 · The record goes to AEAT as soon as the invoice is issued](/rules/records#rec-002) — `Required`, Law, Checked by the API - [REC-003 · VERI*FACTU is kept until the end of the year](/rules/records#rec-003) — `Required`, Law, Responsibility: the issuing business - [REC-004 · BeeL. generates the hash and the chain](/rules/records#rec-004) — `Required`, Law, Checked by the API - [REC-005 · One chain per NIF, one company per NIF](/rules/records#rec-005) — `Required`, Law, Responsibility: your integration - [REC-006 · No certificate is needed to sign records](/rules/records#rec-006) — `Recommended`, Law, Checked by the API - [REC-007 · Keep invoicing when AEAT is unreachable](/rules/records#rec-007) — `Required`, Law, Checked by the API - [REC-008 · Follow submission_status and fix what AEAT rejects](/rules/records#rec-008) — `Required`, BeeL. rule, Responsibility: your integration - [REC-009 · Check the data AEAT accepted with errors](/rules/records#rec-009) — `Required`, AEAT criterion, Responsibility: your integration - [REC-010 · Subsanación is only for errors that need no corrective](/rules/records#rec-010) — `Required`, AEAT criterion, Responsibility: your integration - [REC-011 · The NIF holder signs the AEAT representation first](/rules/records#rec-011) — `Required`, Law, Checked by the API - [REC-012 · Tax amounts are base times rate](/rules/records#rec-012) — `Required`, AEAT criterion, Checked by the API - [REC-013 · An invoice AEAT would reject is not numbered](/rules/records#rec-013) — `Required`, AEAT criterion, Checked by the API ### [Conservation](/rules/conservation) - [CON-001 · Keep copies of issued invoices for the limitation period](/rules/conservation#con-001) — `Required`, Law, Responsibility: the issuing business - [CON-002 · AEAT keeps the records, not your invoices](/rules/conservation#con-002) — `Required`, AEAT criterion, Responsibility: the issuing business - [CON-003 · Export your invoices before leaving](/rules/conservation#con-003) — `Required`, Law, Responsibility: the issuing business - [CON-004 · Invoices kept electronically are reachable on request](/rules/conservation#con-004) — `Required`, Law, Responsibility: the issuing business ### [Sanctions](/rules/sanctions) - [SAN-001 · Do not hold non-compliant or altered billing software](/rules/sanctions#san-001) — `Required`, Law, Responsibility: the issuing business - [SAN-002 · Invoicing breaches are fined in proportion to the operations](/rules/sanctions#san-002) — `Required`, Law, Responsibility: the issuing business - [SAN-003 · A substantial breach doubles the invoicing fine](/rules/sanctions#san-003) — `Required`, Law, Responsibility: the issuing business ## By domain --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # Invoice lifecycle What can happen to an invoice before and after it is issued: editing, issuing, duplicating, testing and retrying. [← All rules](/rules#all-rules) Issuing is the fiscal line: before it, a draft is yours to change or delete; after it, the invoice and its record are fixed and only a later document can change what they say. These rules say what each side allows. 5 rules: 1 from the law, 1 AEAT criterion, 3 BeeL. rules. [How to read a rule](/rules#how-to-read-a-rule). ## What each status allows The fiscal actions on an invoice, by status. Each column comes from the rule that governs it; a refused action leaves the invoice as it was. | Status | Edit ([LIF-001](/rules/lifecycle#lif-001)) | Delete ([LIF-001](/rules/lifecycle#lif-001)) | Issue ([LIF-002](/rules/lifecycle#lif-002)) | Correct ([COR-001](/rules/corrective#cor-001)) | |---|---|---|---|---| | `DRAFT` | ✓ | ✓ | ✓ | — [`INVOICE_NOT_CORRECTIBLE_IN_CURRENT_STATUS`](/errors/INVOICE_NOT_CORRECTIBLE_IN_CURRENT_STATUS) | | `SCHEDULED` | ✓ | ✓ | — [`ONLY_DRAFT_EMITTABLE`](/errors/ONLY_DRAFT_EMITTABLE) | — [`INVOICE_NOT_CORRECTIBLE_IN_CURRENT_STATUS`](/errors/INVOICE_NOT_CORRECTIBLE_IN_CURRENT_STATUS) | | `ISSUED` | — [`STATUS_NOT_MODIFIABLE`](/errors/STATUS_NOT_MODIFIABLE) | — [`STATUS_NOT_DELETABLE`](/errors/STATUS_NOT_DELETABLE) | — [`ONLY_DRAFT_EMITTABLE`](/errors/ONLY_DRAFT_EMITTABLE) | ✓ | | `SENT` | — [`STATUS_NOT_MODIFIABLE`](/errors/STATUS_NOT_MODIFIABLE) | — [`STATUS_NOT_DELETABLE`](/errors/STATUS_NOT_DELETABLE) | — [`ONLY_DRAFT_EMITTABLE`](/errors/ONLY_DRAFT_EMITTABLE) | ✓ | | `PAID` | — [`STATUS_NOT_MODIFIABLE`](/errors/STATUS_NOT_MODIFIABLE) | — [`STATUS_NOT_DELETABLE`](/errors/STATUS_NOT_DELETABLE) | — [`ONLY_DRAFT_EMITTABLE`](/errors/ONLY_DRAFT_EMITTABLE) | ✓ | | `RECTIFIED` | — [`STATUS_NOT_MODIFIABLE`](/errors/STATUS_NOT_MODIFIABLE) | — [`STATUS_NOT_DELETABLE`](/errors/STATUS_NOT_DELETABLE) | — [`ONLY_DRAFT_EMITTABLE`](/errors/ONLY_DRAFT_EMITTABLE) | ✓ | | `VOIDED` | — [`STATUS_NOT_MODIFIABLE`](/errors/STATUS_NOT_MODIFIABLE) | — [`STATUS_NOT_DELETABLE`](/errors/STATUS_NOT_DELETABLE) | — [`ONLY_DRAFT_EMITTABLE`](/errors/ONLY_DRAFT_EMITTABLE) | — [`INVOICE_NOT_CORRECTIBLE_IN_CURRENT_STATUS`](/errors/INVOICE_NOT_CORRECTIBLE_IN_CURRENT_STATUS) | ## LIF-001 · An issued invoice is never edited or deleted `Required` · Law · Impact: critical · Checked by the API: a request that breaks it is rejected with the error codes listed. Once an invoice is issued, neither the invoice nor its billing record is changed or removed. Any correction goes through a later document: a corrective invoice or a void. **Why:** The billing record is chained and, under VeriFactu, already with AEAT. An edit would make the invoice say something its record does not, and deleting it would leave a hole in the series. **Applies to:** statuses `ISSUED`, `SENT`, `PAID`, `OVERDUE`, `RECTIFIED`, `VOIDED`; operations [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`DELETE /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/deleteCompanyInvoice) **Error codes:** [`STATUS_NOT_MODIFIABLE`](/errors/STATUS_NOT_MODIFIABLE) (`422` or `400`), [`STATUS_NOT_DELETABLE`](/errors/STATUS_NOT_DELETABLE) (`400`) **Legal basis:** - RD 1007/2023 (RRSIF), art. 8.2.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a8) > «Cualquier necesidad de corrección o anulación de los datos registrados deberá ser realizada mediante al menos un registro de facturación adicional posterior, de forma que se conserven inalterables los datos originalmente registrados.» **Incorrect:** Patching the amount of an invoice that is already `ISSUED`: the API answers [`STATUS_NOT_MODIFIABLE`](/errors/STATUS_NOT_MODIFIABLE). ```http PATCH /v1/companies/{company_id}/invoices/{invoice_id} { "lines": [{ "description": "Consulting", "quantity": 1, "unit_price": 900, "main_tax": { "type": "IVA", "percentage": 21 } }] } ``` **Correct:** Issuing a corrective invoice against it, which leaves the original as it was. ```http POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective { "rectification_type": "PARTIAL", "rectification_code": "R1", "reason": "Price agreed after delivery was lower", "lines": [{ "description": "Consulting (adjustment)", "quantity": -1, "unit_price": 100, "main_tax": { "type": "IVA", "percentage": 21 } }] } ``` **Related:** [LIF-002 · Only a draft can be issued](/rules/lifecycle#lif-002) · [VOI-001 · Void only an invoice that should never have been issued](/rules/void#voi-001) · [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) **Explained in:** [Invoice lifecycle › What each status allows](/guides/invoice-lifecycle#what-each-status-allows) · [Amounts and rounding › Issued invoices are never recalculated](/guides/amounts-and-rounding#issued-invoices-are-never-recalculated) ## LIF-002 · Only a draft can be issued `Required` · BeeL. rule · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. Issue an invoice from `DRAFT`, or create and issue it in one call. Issuing assigns the number, sets the issue date to today and freezes every amount; a scheduled invoice is issued on its date, or returned to draft first. **Why:** Issuing is the step that creates the fiscal document. Everything the invoice says is fixed at that moment, so it can happen only once and only from a draft. **Applies to:** statuses `DRAFT`, `SCHEDULED`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice) **Error codes:** [`ONLY_DRAFT_EMITTABLE`](/errors/ONLY_DRAFT_EMITTABLE) (`422`) **Incorrect:** Calling the issue operation on a scheduled invoice to send it out today: it answers [`ONLY_DRAFT_EMITTABLE`](/errors/ONLY_DRAFT_EMITTABLE). **Correct:** Removing the schedule, which returns the invoice to `DRAFT`, and then issuing it. **Related:** [LIF-001 · An issued invoice is never edited or deleted](/rules/lifecycle#lif-001) · [NUM-001 · The number is assigned when the invoice is issued](/rules/numbering#num-001) · [DAT-001 · Do not send an issue date](/rules/dates#dat-001) **Explained in:** [Invoice lifecycle › Issuing](/guides/invoice-lifecycle#issuing) ## LIF-003 · Test in the sandbox, never with real invoices `Required` · AEAT criterion · Impact: critical · Responsibility: your integration. Do not issue test invoices with a production key. An invoice issued in production is a real invoice, sent to AEAT and numbered in your series, even if it was meant as a test; one issued by mistake has to be voided. **Why:** AEAT does not accept fictitious invoices from a billing system in production. A test issued there stays in the series and in AEAT's records, and only a void takes it out of the books. **Applies to:** Production API keys (`beel_sk_live_…`). **Legal basis:** - AEAT, Aclaraciones a dudas de los desarrolladores (v1.3), 11. Borradores de factura, pre-facturas, facturas proforma, albaranes, facturas de prueba — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/FAQs-Desarrolladores.pdf) > «las facturas de prueba o facturas de formación, elaboradas con un SIF adaptado, siempre que lleguen a ser facturas propiamente hablando (es decir que se generen de forma real, y que no sean simples borradores o prefacturas no confirmadas), deben ser tratadas como si de facturas reales se tratara a los efectos del RD 1007/23 y resto de normativa de desarrollo.» **Incorrect:** Running an end-to-end test suite against production that issues invoices to a dummy customer. **Correct:** Running the same suite with a sandbox key (`beel_sk_test_…`): invoices go to AEAT's test environment and never count. **Related:** [VOI-001 · Void only an invoice that should never have been issued](/rules/void#voi-001) · [NUM-002 · An issued number is never reused, even when the invoice is voided](/rules/numbering#num-002) **Explained in:** [Testing VeriFactu in sandbox](/verifactu/testing-in-sandbox) · [Proformas](/guides/proformas) ## LIF-004 · Retry writes with the same Idempotency-Key `Recommended` · BeeL. rule · Impact: critical · Responsibility: your integration. The API also answers the error codes listed. Send an `Idempotency-Key` header on every call that creates, issues, corrects or voids an invoice, and repeat the same key when you retry. A retried request returns the stored response of the first one, a `5xx` included, for 24 hours; a `4xx` answer frees the key, so the corrected request can reuse it. **Why:** Without it, a timeout followed by a retry can create or issue a second invoice. An issued duplicate consumes a number and a billing record, and can only be voided. A key longer than 255 characters, or with characters other than letters, digits, `-` and `_`, is refused with [`INVALID_IDEMPOTENCY_KEY`](/errors/INVALID_IDEMPOTENCY_KEY). **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/void`](/invoices/voidCompanyInvoice) **Error codes:** [`IDEMPOTENCY_KEY_MISMATCH`](/errors/IDEMPOTENCY_KEY_MISMATCH) (`409`), [`IDEMPOTENCY_KEY_PROCESSING`](/errors/IDEMPOTENCY_KEY_PROCESSING) (`409`), [`INVALID_IDEMPOTENCY_KEY`](/errors/INVALID_IDEMPOTENCY_KEY) (`400`), [`INVOICE_DUPLICATE_EXTERNAL_REFERENCE`](/errors/INVOICE_DUPLICATE_EXTERNAL_REFERENCE) (`409`) **Incorrect:** Retrying a timed-out create call without a key, or with a new random key on each attempt. **Correct:** Deriving the key from your own order id, so every retry of the same order sends the same key. ```bash curl -X POST https://app.beel.es/api/v1/companies/{company_id}/invoices \ -H "Authorization: Bearer $BEEL_API_KEY" \ -H "Idempotency-Key: order-1042-invoice" \ -H "Content-Type: application/json" \ -d @invoice.json ``` **Related:** [LIF-001 · An issued invoice is never edited or deleted](/rules/lifecycle#lif-001) · [NUM-002 · An issued number is never reused, even when the invoice is voided](/rules/numbering#num-002) **Explained in:** [Idempotency](/guides/idempotency) ## LIF-005 · Duplicating an invoice creates a new one, not a copy `Required` · BeeL. rule · Impact: medium · Responsibility: your integration. Do not use the duplicate operation to replace a lost or damaged invoice. It creates a new draft that, once issued, is a different invoice with its own number and its own billing record; to hand over an invoice again, download the same PDF. **Why:** Issuing the copy would invoice the same operation twice, in the series and in AEAT's records. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices/derivations`](/invoices/createCompanyInvoiceDerivation) **Incorrect:** The customer lost the invoice, so you duplicate it and issue the copy. **Correct:** You download the PDF of the original invoice again and send it. ```http GET /v1/companies/{company_id}/invoices/{invoice_id}/pdf ``` **Related:** [CNT-011 · Only one original of each invoice exists](/rules/contents#cnt-011) · [NUM-002 · An issued number is never reused, even when the invoice is voided](/rules/numbering#num-002) **Explained in:** [Invoice lifecycle › Duplicating an invoice](/guides/invoice-lifecycle#duplicating-an-invoice) [← All rules](/rules#all-rules) ## Related - [Invoice lifecycle](/guides/invoice-lifecycle) — every invoice status, which operations each one allows, and the difference between the fiscal steps (issue, void, correct) and the commercial ones (sent, paid) - [Amounts and rounding](/guides/amounts-and-rounding) — how BeeL. turns quantities, prices and rates into bases, taxes and totals: precision, the three ways to price a line, per-group tax rounding, IRPF, and the amounts that are rejected - [Idempotency](/guides/idempotency) — how to use idempotency keys to prevent duplicate operations in the BeeL. API - [Proformas](/guides/proformas) — send a customer a formal quote with no fiscal validity, then turn it into a real invoice once they accept — as a draft or issued in the same call --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # Voiding When an issued invoice can be voided, how, and what a void leaves behind. [← All rules](/rules#all-rules) A void takes out of the books an invoice that should never have been issued. It is not the way to fix an invoice whose operation did happen: that is a corrective invoice. 5 rules: 1 from the law, 3 AEAT criteria, 1 BeeL. rule. [How to read a rule](/rules#how-to-read-a-rule). ## Void or correct What to do with an issued invoice that should not stand as it is. Each row comes from the rule that decides it. | Situation | Do this | Rule | |---|---|---| | You spot the mistake before issuing: the invoice is still a draft or scheduled. | Edit or delete the draft. Nothing has been issued, so nothing needs correcting. | [LIF-001](/rules/lifecycle#lif-001) | | The invoice should never have been issued: the operation did not take place, it was a test, or it is an accidental duplicate. | Void it. Its number stays used; if a valid invoice is still due, issue it as a new one. | [VOI-001](/rules/void#voi-001) | | The operation took place, but the invoice carried an income tax withholding it should not have. | Void it and issue a new invoice without the withholding. A corrective is not the way: the withholding is not a cause for one. | [VOI-001](/rules/void#voi-001) | | The invoice already has corrective invoices. | It can no longer be voided: issue another corrective against it. | [VOI-005](/rules/void#voi-005) | | The sale happened, but the amounts, the tax or a detail on the invoice are wrong. | Issue a corrective against it: R1–R4 for a standard invoice, R5 for a simplified one. | [COR-001](/rules/corrective#cor-001) | | A corrective you already issued is itself wrong. | Issue another corrective against the original invoice, not against the corrective. | [COR-007](/rules/corrective#cor-007) | | The customer has not paid, the legal waiting period has passed and you have claimed the debt in court or by notarial demand. | Issue an `R3` corrective within the legal window and report it to AEAT. | [COR-008](/rules/corrective#cor-008) | | The customer has been declared insolvent by a court after the invoice's tax accrued, and has not paid. | Issue an `R2` corrective within the legal period and report it to AEAT. | [COR-009](/rules/corrective#cor-009) | | You grant a discount or a volume rebate after the invoice was issued. | Issue an `R1` `PARTIAL` corrective with the discount as a negative line. | [COR-011](/rules/corrective#cor-011) | | The invoice recorded the right recipient with a wrong name, tax ID or address. | Issue an `R4` `PARTIAL` corrective with the corrected `recipient` and no lines: the amounts stay as they are. | [COR-017](/rules/corrective#cor-017) | | The invoice was issued to another person, not the actual customer. | Issue a `TOTAL` corrective on it, then a new invoice to the right customer. | [COR-017](/rules/corrective#cor-017) | | The customer asks for a full invoice with their details in place of a simplified one already issued. | Exchange the simplified invoice for a full one with the exchange operation; do not correct it. | [SIM-007](/rules/simplified#sim-007) | ## VOI-001 · Void only an invoice that should never have been issued `Required` · AEAT criterion · Impact: critical · Responsibility: the issuing business. Void an invoice only when it was issued by mistake: the sale or service it describes never took place, it was a test, or it is an accidental duplicate. An invoice for an operation that did happen is not voided to fix its amounts, VAT or details; it is corrected with a corrective invoice. The one exception is a withholding that should not have been applied: the withholding is not a cause for a corrective ([COR-024](/rules/corrective#cor-024)), so that invoice is voided and issued again without it. The API asks for the confirmation once the invoice was sent or paid ([VOI-004](/rules/void#voi-004)) and refuses to void a corrected invoice ([VOI-005](/rules/void#voi-005)). **Why:** A void removes the invoice's fiscal effect altogether. Using it on a real operation, even to reissue it right after, takes a real sale out of the books; the law provides the corrective invoice for that. **Applies to:** statuses `ISSUED`, `SENT`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/void`](/invoices/voidCompanyInvoice) **Legal basis:** - RD 1007/2023 (RRSIF), art. 11.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a1-3) > «Procederá la generación de un registro de facturación de anulación cuando se haya emitido erróneamente una factura y sea por lo tanto necesario anular su correspondiente registro de facturación de alta.» - AEAT, Aclaraciones a dudas de los desarrolladores (v1.3), 17. Forma de proceder ante errores cometidos al facturar — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/FAQs-Desarrolladores.pdf) > «Con carácter general, todas las facturas emitidas, en la medida en que respondan a operaciones realmente efectuadas (como es el caso habitual) no pueden anularse. En el caso de que exista alguna diferencia entre lo facturado y la realidad, por ejemplo, que por un defecto de cantidades o de calidades, o por otras razones, y se deba modificar su importe, procederá la emisión de una factura rectificativa» **Incorrect:** The customer's VAT rate was wrong on an invoice for work you did deliver, so you void it and issue a new one. **Correct:** The same invoice is corrected with a corrective invoice; a duplicate fired twice by a retry is voided. ```http POST /v1/companies/{company_id}/invoices/{invoice_id}/void { "reason": "Duplicate of invoice F-2026-0142, issued twice by mistake" } ``` **Related:** [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [COR-024 · A corrective does not change only the withholding](/rules/corrective#cor-024) · [LIF-003 · Test in the sandbox, never with real invoices](/rules/lifecycle#lif-003) · [NUM-002 · An issued number is never reused, even when the invoice is voided](/rules/numbering#num-002) · [VOI-002 · Void an issued invoice through the void operation; delete a draft](/rules/void#voi-002) · [VOI-004 · A sent or paid invoice is voided only confirming it was issued by mistake](/rules/void#voi-004) · [VOI-005 · A corrected invoice, or a total corrective, is not voided](/rules/void#voi-005) **Explained in:** [Cancel vs amend › The 30-second decision](/verifactu/cancel-and-fix#the-30-second-decision) · [Cancel vs amend › Void (anulación)](/verifactu/cancel-and-fix#anulación-void) ## VOI-002 · Void an issued invoice through the void operation; delete a draft `Required` · BeeL. rule · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. An issued invoice is voided only with the void operation, with a reason of 10 to 500 characters, and only when it was issued by mistake ([VOI-001](/rules/void#voi-001), [VOI-004](/rules/void#voi-004)). A draft or a scheduled invoice is not voided: it is deleted, and it had no number to lose. An invoice issued to the wrong person is not voided either: it is corrected ([COR-017](/rules/corrective#cor-017)). **Why:** The void operation is what records the cancellation and, under VeriFactu, sends it to AEAT; a status change cannot. A second void of the same invoice is refused, so a retried void is safe to treat as done. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/void`](/invoices/voidCompanyInvoice), [`DELETE /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/deleteCompanyInvoice), [`PUT /v1/companies/{company_id}/invoices/{invoice_id}/status`](/invoices/setCompanyInvoiceStatus) **Error codes:** [`TRANSITION_NOT_SUPPORTED`](/errors/TRANSITION_NOT_SUPPORTED) (`400`), [`INVOICE_ALREADY_VOIDED`](/errors/INVOICE_ALREADY_VOIDED) (`409`), [`VALIDATION_ERROR`](/errors/VALIDATION_ERROR) (`422` or `400`) **Incorrect:** Setting the status to `VOIDED` with the status operation, which does not take that value: the API answers [`VALIDATION_ERROR`](/errors/VALIDATION_ERROR). ```http PUT /v1/companies/{company_id}/invoices/{invoice_id}/status { "status": "VOIDED" } ``` **Correct:** Calling the void operation with the reason, confirming it was issued by mistake. ```http POST /v1/companies/{company_id}/invoices/{invoice_id}/void { "reason": "Duplicate of invoice F-2026-0142, issued twice by mistake", "issued_in_error": true } ``` **Related:** [COR-017 · A corrective keeps the recipient, except to correct the recipient's data](/rules/corrective#cor-017) · [LIF-001 · An issued invoice is never edited or deleted](/rules/lifecycle#lif-001) · [VOI-001 · Void only an invoice that should never have been issued](/rules/void#voi-001) · [VOI-003 · A void adds a cancellation record; the original stays](/rules/void#voi-003) · [VOI-004 · A sent or paid invoice is voided only confirming it was issued by mistake](/rules/void#voi-004) · [VOI-005 · A corrected invoice, or a total corrective, is not voided](/rules/void#voi-005) **Explained in:** [Invoice lifecycle › Voiding and correcting](/guides/invoice-lifecycle#voiding-and-correcting) ## VOI-003 · A void adds a cancellation record; the original stays `Required` · Law · Impact: medium · Checked by the API: BeeL. applies it. Voiding an invoice under VeriFactu generates a cancellation record (registro de anulación) that identifies the original by its number and issue date; the original registration record is never removed. The invoice's `verifactu.submission_status` becomes `VOIDED` once AEAT has accepted the cancellation. **Why:** AEAT keeps both records, linked. A successful void call means the cancellation was submitted, not that AEAT accepted it. **Applies to:** statuses `VOIDED`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/void`](/invoices/voidCompanyInvoice), [`GET /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/getCompanyInvoice); Invoices of a company under VeriFactu. **Legal basis:** - RD 1007/2023 (RRSIF), art. 11.2.c) y d) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a1-3) > «c) El número y, en su caso, serie de la factura correspondiente al registro de facturación de alta que se anule. d) La fecha de expedición de la factura correspondiente al registro de facturación de alta que se anule.» - RD 1007/2023 (RRSIF), art. 8.2.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a8) > «Cualquier necesidad de corrección o anulación de los datos registrados deberá ser realizada mediante al menos un registro de facturación adicional posterior, de forma que se conserven inalterables los datos originalmente registrados.» **Incorrect:** Treating the `200` of the void call as proof that AEAT accepted the cancellation. **Correct:** After voiding, reading the invoice until its `verifactu.submission_status` is `VOIDED`. ```http GET /v1/companies/{company_id}/invoices/{invoice_id} ``` **Related:** [VOI-002 · Void an issued invoice through the void operation; delete a draft](/rules/void#voi-002) · [REC-008 · Follow submission_status and fix what AEAT rejects](/rules/records#rec-008) · [LIF-001 · An issued invoice is never edited or deleted](/rules/lifecycle#lif-001) **Explained in:** [Cancel vs amend › Did AEAT accept the cancellation?](/verifactu/cancel-and-fix#did-aeat-accept-the-cancellation) ## VOI-004 · A sent or paid invoice is voided only confirming it was issued by mistake `Required` · AEAT criterion · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. Voiding an invoice that has already been sent or paid requires `issued_in_error: true`: the confirmation that it was issued by mistake, because the operation never took place, it was a test, or it is an accidental duplicate. Without it the void is refused with `VOID_REQUIRES_ISSUED_IN_ERROR`. An invoice that was neither sent nor paid can be voided without it, though a void is only for those same cases ([VOI-001](/rules/void#voi-001)). **Why:** A void removes the invoice from the books as if it had never been issued. Once the customer has received or paid it, that is a sign the operation was real; AEAT reads a void of an undelivered invoice as the clearest case of an invoice that should never have existed. The confirmation makes the issuer state that it was not real, instead of voiding a real sale by habit. **Applies to:** statuses `SENT`, `PAID`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/void`](/invoices/voidCompanyInvoice) **Error codes:** [`VOID_REQUIRES_ISSUED_IN_ERROR`](/errors/VOID_REQUIRES_ISSUED_IN_ERROR) (`422`) **Legal basis:** - RD 1007/2023 (RRSIF), art. 11.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a1-3) > «Procederá la generación de un registro de facturación de anulación cuando se haya emitido erróneamente una factura y sea por lo tanto necesario anular su correspondiente registro de facturación de alta.» - AEAT, Aclaraciones a dudas de los desarrolladores (v1.3), 17. Forma de proceder ante errores cometidos al facturar, caso 2.d) — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/FAQs-Desarrolladores.pdf) > «Sobre el caso 2.d): un aspecto que puede influir en el uso de este mecanismo es si la factura expedida (con errores) ya se ha entregado o no al cliente. Si NO se hubiera entregado, este hecho favorecería la consideración de que se trata de una factura defectuosa e incorrecta que no debería existir ni llegar al cliente (una expedición "fallida") y, por lo tanto, que fuera susceptible de anularse» **Incorrect:** Voiding a paid invoice for work that was done, to issue it again with another amount: without `issued_in_error` the API answers [`VOID_REQUIRES_ISSUED_IN_ERROR`](/errors/VOID_REQUIRES_ISSUED_IN_ERROR), and with it the issuer would be declaring something false; the fix is a corrective. **Correct:** Voiding a paid duplicate charged twice by mistake, confirming it. ```http POST /v1/companies/{company_id}/invoices/{invoice_id}/void { "reason": "Duplicate of invoice F-2026-0142, issued twice by mistake", "issued_in_error": true } ``` **Related:** [VOI-001 · Void only an invoice that should never have been issued](/rules/void#voi-001) · [VOI-005 · A corrected invoice, or a total corrective, is not voided](/rules/void#voi-005) · [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) **Explained in:** [Cancel vs amend › Void (anulación)](/verifactu/cancel-and-fix#anulación-void) ## VOI-005 · A corrected invoice, or a total corrective, is not voided `Required` · AEAT criterion · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. Do not void an invoice that has live corrective invoices (issued and not voided): it was corrected, so the operation took place, and further changes go on another corrective. The void is refused with `INVOICE_HAS_LIVE_CORRECTIVES`. A `TOTAL` corrective cannot be voided either (`TOTAL_CORRECTIVE_NOT_VOIDABLE`): the invoice it rectifies was voided by it and would stay voided with nothing to offset it; if what it rectified was wrong, issue a new invoice for what should have stayed invoiced. A `PARTIAL` corrective issued by mistake can still be voided. **Why:** Correcting and voiding are exclusive ways of fixing an invoice: once correctives were used, AEAT says a cancellation record does not apply. **Applies to:** invoice types `STANDARD`, `SIMPLIFIED`, `CORRECTIVE`; statuses `RECTIFIED`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/void`](/invoices/voidCompanyInvoice) **Error codes:** [`INVOICE_HAS_LIVE_CORRECTIVES`](/errors/INVOICE_HAS_LIVE_CORRECTIVES) (`422`), [`TOTAL_CORRECTIVE_NOT_VOIDABLE`](/errors/TOTAL_CORRECTIVE_NOT_VOIDABLE) (`422`) **Legal basis:** - AEAT, Aclaraciones a dudas de los desarrolladores (v1.3), 17. Forma de proceder ante errores cometidos al facturar, caso 2.d) — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/FAQs-Desarrolladores.pdf) > «Esta forma de actuar (cuando sea posible) no implica la expedición de nuevas facturas que "contrarresten o compensen" la factura expedida por error (que son mecanismos contemplados en los procedimientos admitidos de rectificación de facturas y que, si se utilizaran, no procedería hacer un RF de anulación de la factura expedida por error).» **Incorrect:** Voiding an invoice after a `PARTIAL` corrective reduced it: the API answers [`INVOICE_HAS_LIVE_CORRECTIVES`](/errors/INVOICE_HAS_LIVE_CORRECTIVES). **Correct:** Issuing a `TOTAL` corrective on it instead: it rectifies what is still invoiced, the partial included ([COR-023](/rules/corrective#cor-023)). **Related:** [VOI-001 · Void only an invoice that should never have been issued](/rules/void#voi-001) · [VOI-004 · A sent or paid invoice is voided only confirming it was issued by mistake](/rules/void#voi-004) · [COR-023 · A corrective never rectifies more than was invoiced](/rules/corrective#cor-023) · [COR-007 · A wrong corrective is fixed against the original, not corrected itself](/rules/corrective#cor-007) **Explained in:** [Cancel vs amend](/verifactu/cancel-and-fix) [← All rules](/rules#all-rules) ## Related - [Cancel vs amend](/verifactu/cancel-and-fix) — decide between cancelling an invoice (void) and issuing a corrective invoice, two operations with different fiscal weight - [Invoice lifecycle](/guides/invoice-lifecycle) — every invoice status, which operations each one allows, and the difference between the fiscal steps (issue, void, correct) and the commercial ones (sent, paid) --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # Corrective invoices When an issued invoice has to be rectified, with which reason code, how the correction is shown and within which deadline. [← All rules](/rules#all-rules) A corrective invoice (factura rectificativa) is a new invoice that corrects one already issued, which stays as it was. The law decides when one is due and which reason code it carries; these rules say what each case requires and what the API checks. 24 rules: 19 from the law, 3 AEAT criteria, 2 BeeL. rules. [How to read a rule](/rules#how-to-read-a-rule). ## COR-001 · Wrong data on an issued invoice is fixed with a corrective `Required` · Law · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. Issue a corrective invoice when an issued invoice lacks a required detail, charged the wrong tax, or its taxable base changes after the operation. The corrective is issued against the original, which must be `ISSUED`, `SENT`, `PAID` or `RECTIFIED`. **Why:** The law makes the corrective mandatory in these cases, and it is the only way to change what an issued invoice says: the original and its record stay as they were. **Applies to:** invoice types `STANDARD`, `SIMPLIFIED`; statuses `ISSUED`, `SENT`, `PAID`, `RECTIFIED`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Error codes:** [`INVOICE_NOT_CORRECTIBLE_IN_CURRENT_STATUS`](/errors/INVOICE_NOT_CORRECTIBLE_IN_CURRENT_STATUS) (`422`) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 15.1 y 15.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «Deberá expedirse una factura rectificativa en los casos en que la factura original no cumpla alguno de los requisitos que se establecen en los artículos 6 ó 7 [...] 2. Igualmente, será obligatoria la expedición de una factura rectificativa en los casos en que las cuotas impositivas repercutidas se hubiesen determinado incorrectamente o se hubieran producido las circunstancias que, según lo dispuesto en el artículo 80 de la Ley del Impuesto, dan lugar a la modificación de la base imponible.» **Incorrect:** Voiding an invoice for a sale that did happen because it was charged at 10 % instead of 21 %, and issuing a new one. **Correct:** Issuing an `R1` corrective against it: a `PARTIAL` one with the lines that settle the difference, or a `TOTAL` one followed by a new invoice at the right rate. **Related:** [COR-002 · Pick the reason code: R1–R4 for standard invoices, R5 for simplified](/rules/corrective#cor-002) · [COR-006 · Issue the corrective as soon as you know, within 4 years](/rules/corrective#cor-006) · [LIF-001 · An issued invoice is never edited or deleted](/rules/lifecycle#lif-001) · [VOI-001 · Void only an invoice that should never have been issued](/rules/void#voi-001) **Explained in:** [Cancel vs amend › Corrective invoice (rectificativa)](/verifactu/cancel-and-fix#rectificativa-corrective) · [Corrective invoices (R1–R5)](/verifactu/corrective-invoices) ## COR-002 · Pick the reason code: R1–R4 for standard invoices, R5 for simplified `Required` · Law · Impact: critical · Checked by the API: a request that breaks it is rejected with the error codes listed. Send the `rectification_code` that matches the cause: `R1` for an error founded in law or art. 80 Uno, Dos and Seis LIVA, `R2` for insolvency, `R3` for bad debt, `R4` for the rest. A simplified invoice is always corrected with `R5`, and `R5` corrects nothing else. **Why:** The code tells AEAT why the base or the tax changed. A standard invoice corrected with `R5`, or a simplified one with `R1`–`R4`, is a record of the wrong type. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Error codes:** [`RECTIFICATIVA_R5_ONLY_SIMPLIFICADA`](/errors/RECTIFICATIVA_R5_ONLY_SIMPLIFICADA) (`422`), [`RECTIFICATIVA_R1R4_NOT_SIMPLIFICADA`](/errors/RECTIFICATIVA_R1R4_NOT_SIMPLIFICADA) (`422`) **Legal basis:** - Orden HAC/1177/2024, anexo, lista L2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138) > «R1 Factura Rectificativa (Error fundado en derecho y art. 80 Uno Dos y Seis LIVA). R2 Factura Rectificativa (art. 80.3). R3 Factura Rectificativa (art. 80.4). R4 Factura Rectificativa (Resto). R5 Factura Rectificativa en facturas simplificadas.» - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Procedimientos de facturación: Tipo de facturas — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html) > «La rectificación de una factura simplificada se registrará con la clave R5 cualquiera que sea el motivo de la misma.» **Incorrect:** Correcting a simplified invoice with `R1`: the API answers [`RECTIFICATIVA_R1R4_NOT_SIMPLIFICADA`](/errors/RECTIFICATIVA_R1R4_NOT_SIMPLIFICADA). ```json { "rectification_type": "TOTAL", "rectification_code": "R1", "reason": "Ticket issued for the wrong table" } ``` **Correct:** Correcting the same simplified invoice with `R5`. ```json { "rectification_type": "TOTAL", "rectification_code": "R5", "reason": "Ticket issued for the wrong table" } ``` **Related:** [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [COR-008 · A bad-debt corrective (R3) needs the legal conditions first](/rules/corrective#cor-008) · [COR-009 · An insolvency corrective (R2) needs a declaration of insolvency](/rules/corrective#cor-009) · [COR-010 · A provisional price is rectified once the final one is known](/rules/corrective#cor-010) **Explained in:** [Corrective invoices (R1–R5) › Pick the reason (R1–R5)](/verifactu/corrective-invoices#pick-the-reason-r1r5) · [Corrective invoices (R1–R5) › Validation rules BeeL. applies](/verifactu/corrective-invoices#validation-rules-beel-applies) ## COR-003 · A corrective shows the difference or the amounts after the correction `Required` · Law · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. A corrective states the correction either as the difference, whatever its sign, or as the amounts after the correction together with the amount rectified. In the API, a `PARTIAL` corrective carries the difference as `lines`, and a `TOTAL` corrective takes no `lines`: it rectifies what is still invoiced on the original ([COR-023](/rules/corrective#cor-023)), line by line. **Why:** The corrective has to meet every requirement of an invoice and show what changed. A `PARTIAL` without lines states no correction, and a `TOTAL` with lines is refused. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Error codes:** [`RECTIFICATIVA_PARCIAL_SIN_LINEAS`](/errors/RECTIFICATIVA_PARCIAL_SIN_LINEAS) (`422`), [`RECTIFICATIVA_TOTAL_CON_LINEAS`](/errors/RECTIFICATIVA_TOTAL_CON_LINEAS) (`422`) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 15.5 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «La factura rectificativa deberá cumplir los requisitos que se establecen en los artículos 6 ó 7, según proceda. Cuando lo que se expida sea una factura rectificativa, los datos a los que se refiere el artículo 6.1.f), g) y h) expresarán la rectificación efectuada. En particular, los datos que se regulan en los párrafos f) y h) del citado artículo 6.1 se podrán consignar, bien indicando directamente el importe de la rectificación, con independencia de su signo, bien tal y como queden tras la rectificación efectuada, señalando igualmente en este caso el importe de dicha rectificación.» **Incorrect:** A `PARTIAL` corrective with no lines: the API answers [`RECTIFICATIVA_PARCIAL_SIN_LINEAS`](/errors/RECTIFICATIVA_PARCIAL_SIN_LINEAS). ```json { "rectification_type": "PARTIAL", "rectification_code": "R1", "reason": "Discount agreed after delivery" } ``` **Correct:** The same `PARTIAL` corrective with the difference as a negative line. ```json { "rectification_type": "PARTIAL", "rectification_code": "R1", "reason": "Discount agreed after delivery", "lines": [{ "description": "Discount", "quantity": -1, "unit_price": 50, "main_tax": { "type": "IVA", "percentage": 21 } }] } ``` **Related:** [COR-004 · The corrective record says whether it substitutes or adds a difference](/rules/corrective#cor-004) · [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) **Explained in:** [Corrective invoices (R1–R5) › The two axes](/verifactu/corrective-invoices#the-two-axes) · [Corrective invoices (R1–R5) › Validation rules BeeL. applies](/verifactu/corrective-invoices#validation-rules-beel-applies) ## COR-004 · The corrective record says whether it substitutes or adds a difference `Required` · AEAT criterion · Impact: low · Checked by the API: BeeL. applies it. Every corrective record declares whether it rectifies by substitution (`S`) or by differences (`I`). BeeL. records every corrective by differences, whatever its `rectification_type`: a `PARTIAL` corrective carries the difference as its lines, and a `TOTAL` one carries the original's lines with the opposite sign, which is the difference that cancels it. A record by differences carries no rectified base or rectified tax. **Why:** AEAT reads the corrective's amounts differently in each mode: by substitution the breakdown holds the amounts after the correction, by differences it holds the correction itself. Declaring a negated breakdown as a substitution would record twice the intended effect. **Applies to:** invoice types `CORRECTIVE`; VeriFactu enabled. **Legal basis:** - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Procedimientos de facturación: ¿Cómo registra el emisor una factura rectificativa? — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html) > «Asimismo, se deberá identificar el tipo de factura rectificativa con las claves “S- sustitución” o “I- por diferencias”.» - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Procedimientos de facturación: ¿Cómo registra el emisor una factura rectificativa por diferencias “I”? — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html) > «Para ello se deberá informar en un solo registro de la factura rectificativa con la clave “I”. En este caso no se deben rellenar los campos adicionales “Base rectificada” y “Cuota rectificada”.» **Incorrect:** Building your own corrective record and leaving out whether it substitutes or adds a difference. **Correct:** Choosing `rectification_type` on the request and letting BeeL. build the record by differences. **Related:** [COR-003 · A corrective shows the difference or the amounts after the correction](/rules/corrective#cor-003) · [REC-001 · Each issued invoice gets a billing record built from its data](/rules/records#rec-001) **Explained in:** [Corrective invoices (R1–R5) › The two axes](/verifactu/corrective-invoices#the-two-axes) ## COR-005 · A corrective identifies the invoice it rectifies `Required` · Law · Impact: medium · Checked by the API: BeeL. applies it. A corrective states the number and the issue date of the invoice it rectifies. In the API a corrective is always created against its original, the `{invoice_id}` of the request, and each corrective rectifies one invoice; BeeL. prints the original's number and issue date on the corrective's PDF and, under VeriFactu, sends them in its billing record. **Why:** Without an unambiguous reference to the original, neither the customer nor AEAT can tell what is being corrected. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 15.4 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «La rectificación se realizará mediante la emisión de una nueva factura en la que se haga constar los datos identificativos de la factura rectificada.» - RD 1619/2012 (Reglamento de facturación), art. 7.1.h) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a7) > «En caso de facturas rectificativas, la referencia expresa e inequívoca de la factura rectificada y de las especificaciones que se modifican.» **Incorrect:** Issuing a standard invoice with negative amounts and the original's number written in the notes. **Correct:** Creating the corrective on the original's own path, so it is linked to it. ```http POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective ``` **Related:** [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [COR-011 · Discounts and rebates granted after the sale go on a corrective](/rules/corrective#cor-011) **Explained in:** [Corrective invoices (R1–R5)](/verifactu/corrective-invoices) ## COR-006 · Issue the corrective as soon as you know, within 4 years `Required` · Law · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. Issue a corrective as soon as you learn of the cause, and never later than 4 years after the tax accrued or, for art. 80 LIVA causes, after the circumstance occurred. The API counts from the original's operation date (its `operation_date`, or its `issue_date` when it has none) unless you declare `circumstance_date` for an `R1`, `R2`, `R3` or `R5` corrective; the last day is the anniversary itself. Past it the corrective is refused with `CORRECTIVE_OUT_OF_TIME`. A refund from a payment integration is a circumstance of the day it is refunded. **Why:** Past that deadline the tax charged can no longer be rectified, and a late corrective does not change it. Counting from the operation when no circumstance is declared is the stricter reading of the two the law allows. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Error codes:** [`CORRECTIVE_OUT_OF_TIME`](/errors/CORRECTIVE_OUT_OF_TIME) (`422`), [`CORRECTIVE_CIRCUMSTANCE_DATE_NOT_APPLICABLE`](/errors/CORRECTIVE_CIRCUMSTANCE_DATE_NOT_APPLICABLE) (`422`), [`CORRECTIVE_CIRCUMSTANCE_DATE_OUT_OF_RANGE`](/errors/CORRECTIVE_CIRCUMSTANCE_DATE_OUT_OF_RANGE) (`422`) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 15.3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «La expedición de la factura rectificativa deberá efectuarse tan pronto como el obligado a expedirla tenga constancia de las circunstancias que, conforme a los apartados anteriores, obligan a su expedición, siempre que no hubiesen transcurrido cuatro años a partir del momento en que se devengó el Impuesto o, en su caso, se produjeron las circunstancias a que se refiere el artículo 80 de la Ley del Impuesto.» - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Procedimientos de facturación: tipo de facturas, R4 — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html) > «Cuando se haya producido una modificación de la base imponible del IVA por causas distintas a las previstas en el artículo 80 LIVA y no se deba a un error fundado de derecho deberá emitirse una factura rectificativa con serie específica cuya información se registrará con el tipo de factura R4.» **Incorrect:** Correcting in 2026, with `R4`, an invoice whose operation took place in 2021: the API answers [`CORRECTIVE_OUT_OF_TIME`](/errors/CORRECTIVE_OUT_OF_TIME). **Correct:** Correcting in 2026 an invoice of 2021 for a price change agreed in 2024, declaring when it was agreed. ```json { "rectification_type": "PARTIAL", "rectification_code": "R1", "reason": "Price reduction agreed with the customer on 2024-06-01", "circumstance_date": "2024-06-01", "lines": [{ "description": "Price reduction", "quantity": -1, "unit_price": 100, "main_tax": { "type": "IVA", "percentage": 21 } }] } ``` **Related:** [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [COR-008 · A bad-debt corrective (R3) needs the legal conditions first](/rules/corrective#cor-008) · [COR-014 · A corrective keeps the operation date of the original](/rules/corrective#cor-014) ## COR-007 · A wrong corrective is fixed against the original, not corrected itself `Required` · BeeL. rule · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. A corrective is never issued against another corrective. When a corrective is wrong, issue another corrective against the original invoice. **Why:** In BeeL. every corrective hangs from one original invoice, so the whole chain of corrections of an invoice stays readable from it. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Error codes:** [`CORRECTIVE_NOT_RECTIFIABLE`](/errors/CORRECTIVE_NOT_RECTIFIABLE) (`422`) **Incorrect:** Calling the corrective operation with the id of a corrective: the API answers [`CORRECTIVE_NOT_RECTIFIABLE`](/errors/CORRECTIVE_NOT_RECTIFIABLE). ```http POST /v1/companies/{company_id}/invoices/{corrective_id}/corrective ``` **Correct:** Calling it with the id of the original invoice, with the lines that settle the difference. ```http POST /v1/companies/{company_id}/invoices/{original_invoice_id}/corrective ``` **Related:** [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [COR-005 · A corrective identifies the invoice it rectifies](/rules/corrective#cor-005) **Explained in:** [Corrective invoices (R1–R5) › Validation rules BeeL. applies](/verifactu/corrective-invoices#validation-rules-beel-applies) ## COR-008 · A bad-debt corrective (R3) needs the legal conditions first `Required` · Law · Impact: medium · Responsibility: the issuing business. Issue an `R3` corrective only when the debt is uncollectable in the legal sense: 1 year since the tax accrued without payment (six months or one year for smaller businesses), the unpaid debt recorded in the VAT books, a court claim or notarial demand, and a recipient who is a business or a base above 50 €. Issue it within the following 6 months, send it to the customer and report it to AEAT; the cases the law excludes are in [COR-016](/rules/corrective#cor-016) and [COR-019](/rules/corrective#cor-019). The API checks the six months and the 50 € threshold ([COR-020](/rules/corrective#cor-020)); the rest is yours to meet. **Why:** Without these conditions the base cannot be reduced, and the tax the corrective gives back is still owed. **Applies to:** invoice types `CORRECTIVE`; `rectification_code` `R3`. **Legal basis:** - Ley 37/1992 del IVA, art. 80.Cuatro.A).1.ª, 3.ª y B) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «1.ª Que haya transcurrido un año desde el devengo del Impuesto repercutido sin que se haya obtenido el cobro de todo o parte del crédito derivado del mismo. [...] 3.ª Que el destinatario de la operación actúe en la condición de empresario o profesional, o, en otro caso, que la base imponible de aquella, Impuesto sobre el Valor Añadido excluido, sea superior a 50 euros. 4.ª Que el sujeto pasivo haya instado su cobro mediante reclamación judicial al deudor o por medio de requerimiento notarial al mismo» - Ley 37/1992 del IVA, art. 80.Cuatro.B) y 80.Cinco.2.ª — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «B) La modificación deberá realizarse en el plazo de los seis meses siguientes a la finalización del periodo de seis meses o un año a que se refiere la condición 1.ª anterior y comunicarse a la Agencia Estatal de Administración Tributaria en el plazo que se fije reglamentariamente. [...] Tampoco procederá la modificación de la base imponible cuando el destinatario de las operaciones no esté establecido en el territorio de aplicación del Impuesto, ni en Canarias, Ceuta o Melilla.» - Ley 37/1992 del IVA, art. 80.Cuatro.A).2.ª — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «2.ª Que esta circunstancia haya quedado reflejada en los Libros Registros exigidos para este Impuesto.» - RD 1624/1992 (Reglamento del IVA), art. 24.2.a).2.º — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28925#a24) > «El acreedor tendrá que comunicar por vía electrónica, a través del formulario disponible a tal efecto en la sede electrónica de la Agencia Estatal de Administración Tributaria, en el plazo de un mes contado desde la fecha de expedición de la factura rectificativa, la modificación de la base imponible practicada» **Incorrect:** Issuing an `R3` corrective two months after the due date because the customer stopped answering. **Correct:** Issuing it once the waiting period has passed and the debt has been claimed by notarial demand, and filing the communication with AEAT. **Related:** [COR-002 · Pick the reason code: R1–R4 for standard invoices, R5 for simplified](/rules/corrective#cor-002) · [COR-006 · Issue the corrective as soon as you know, within 4 years](/rules/corrective#cor-006) · [COR-009 · An insolvency corrective (R2) needs a declaration of insolvency](/rules/corrective#cor-009) · [COR-016 · Some unpaid debts never allow an R2 or R3 corrective](/rules/corrective#cor-016) · [COR-019 · Insolvency and bad-debt correctives need a recipient established in Spain](/rules/corrective#cor-019) · [COR-020 · A bad-debt corrective waits six months and needs a business recipient under 50 €](/rules/corrective#cor-020) **Explained in:** [Corrective invoices (R1–R5) › Scenario 3 — PARTIAL bad-debt write-off (R3)](/verifactu/corrective-invoices#scenario-3--partial-bad-debt-write-off-r3) ## COR-009 · An insolvency corrective (R2) needs a declaration of insolvency `Required` · Law · Impact: low · Responsibility: the issuing business. Issue an `R2` corrective only when the customer has not paid the tax charged and, after it accrued, a court has declared the customer insolvent (auto de declaración de concurso). Issue it within the two months that follow the end of the period the insolvency order gives creditors to report their claims, send a copy to the insolvency administrator, and report it to AEAT; the cases the law excludes are in [COR-016](/rules/corrective#cor-016). **Why:** The base can be reduced for insolvency only on that court decision and within that period; outside them the reduction has no legal footing. **Applies to:** invoice types `CORRECTIVE`; `rectification_code` `R2`. **Legal basis:** - Ley 37/1992 del IVA, art. 80.Tres — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «La base imponible podrá reducirse cuando el destinatario de las operaciones sujetas al Impuesto no haya hecho efectivo el pago de las cuotas repercutidas y siempre que, con posterioridad al devengo de la operación, se dicte auto de declaración de concurso.» - Ley 37/1992 del IVA, art. 80.Tres — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «La modificación, en su caso, no podrá efectuarse después de transcurrido el plazo de dos meses contados a partir del fin del plazo máximo fijado en el número 5.º del apartado 1 del artículo 21 de la Ley 22/2003, de 9 de julio, Concursal.» - RD 1624/1992 (Reglamento del IVA), art. 24.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28925#a24) > «En los supuestos del apartado tres del artículo 80 de la Ley del Impuesto, deberá expedirse y remitirse asimismo una copia de dicha factura a la administración concursal y en el mismo plazo.» - RD 1624/1992 (Reglamento del IVA), art. 24.2.a).2.º — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28925#a24) > «El acreedor tendrá que comunicar por vía electrónica, a través del formulario disponible a tal efecto en la sede electrónica de la Agencia Estatal de Administración Tributaria, en el plazo de un mes contado desde la fecha de expedición de la factura rectificativa, la modificación de la base imponible practicada» **Incorrect:** Issuing an `R2` corrective because the customer announced it is winding down. **Correct:** Issuing it after the court's declaration of insolvency, keeping a copy of the court order. **Related:** [COR-002 · Pick the reason code: R1–R4 for standard invoices, R5 for simplified](/rules/corrective#cor-002) · [COR-008 · A bad-debt corrective (R3) needs the legal conditions first](/rules/corrective#cor-008) · [COR-016 · Some unpaid debts never allow an R2 or R3 corrective](/rules/corrective#cor-016) **Explained in:** [Corrective invoices (R1–R5) › Scenario 2 — PARTIAL adjustment for bankruptcy (R2)](/verifactu/corrective-invoices#scenario-2--partial-adjustment-for-bankruptcy-r2) ## COR-010 · A provisional price is rectified once the final one is known `Required` · Law · Impact: low · Responsibility: the issuing business. When the price was not known when the tax accrued and you invoiced a provisional amount, issue an `R1` corrective once the final amount is known. **Why:** The provisional amount is only an estimate; the tax due is the one on the final price. **Applies to:** invoice types `CORRECTIVE`; `rectification_code` `R1`. **Legal basis:** - Ley 37/1992 del IVA, art. 80.Seis — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «Si el importe de la contraprestación no resultara conocido en el momento del devengo del impuesto, el sujeto pasivo deberá fijarlo provisionalmente aplicando criterios fundados, sin perjuicio de su rectificación cuando dicho importe fuera conocido.» **Incorrect:** Invoicing the balance of a job at a final price as a new standard invoice with no link to the provisional one. **Correct:** Issuing an `R1` `PARTIAL` corrective against the provisional invoice for the difference. **Related:** [COR-002 · Pick the reason code: R1–R4 for standard invoices, R5 for simplified](/rules/corrective#cor-002) · [COR-011 · Discounts and rebates granted after the sale go on a corrective](/rules/corrective#cor-011) **Explained in:** [Corrective invoices (R1–R5) › Pick the reason (R1–R5)](/verifactu/corrective-invoices#pick-the-reason-r1r5) ## COR-011 · Discounts and rebates granted after the sale go on a corrective `Required` · Law · Impact: medium · Responsibility: the issuing business. A discount, bonus or volume rebate granted after the operation reduces the base through a corrective invoice (`R1`), not through a negative standard invoice. **Why:** The reduction changes the taxable base of an invoice already issued, which only a corrective can do; a negative standard invoice is not a corrective. **Applies to:** invoice types `CORRECTIVE`; `rectification_code` `R1`. **Legal basis:** - Ley 37/1992 del IVA, art. 80.Uno.2.º — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «Los descuentos y bonificaciones otorgados con posterioridad al momento en que la operación se haya realizado siempre que sean debidamente justificados.» - AEAT, Aclaraciones a dudas de los desarrolladores (v1.3), 19. Rappels y rectificación — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/FAQs-Desarrolladores.pdf) > «Los rappels se documentan en facturas rectificativas.» **Incorrect:** Issuing a new standard invoice with a negative line for the rebate. **Correct:** Issuing a partial corrective against the invoice the rebate applies to. ```json { "rectification_type": "PARTIAL", "rectification_code": "R1", "reason": "Volume rebate for Q3", "lines": [{ "description": "Volume rebate Q3", "quantity": -1, "unit_price": 120, "main_tax": { "type": "IVA", "percentage": 21 } }] } ``` **Related:** [COR-002 · Pick the reason code: R1–R4 for standard invoices, R5 for simplified](/rules/corrective#cor-002) · [COR-012 · Returns can be netted only on a later supply to the same customer](/rules/corrective#cor-012) · [CNT-019 · Only a corrective invoice totals less than zero](/rules/contents#cnt-019) **Explained in:** [Corrective invoices (R1–R5) › Pick the reason (R1–R5)](/verifactu/corrective-invoices#pick-the-reason-r1r5) ## COR-012 · Returns can be netted only on a later supply to the same customer `Recommended` · Law · Impact: low · Responsibility: the issuing business. The API also answers the error codes listed. Document returned goods or packaging with a corrective. The law lets you net them on the invoice of a later supply instead only when it goes to the same customer and every operation carries the same VAT rate. The API accepts negative lines on a standard or simplified invoice for that netting, and for discounts not included in the unit price (art. 6.1.f), as long as the invoice total is not negative: a negative result is a correction and goes on a corrective ([CNT-019](/rules/contents#cnt-019)). **Why:** Outside that exception, a return changes the base of the invoice it came from and needs a corrective against it. An ordinary invoice with a negative total would be a credit note without the link to the invoice it corrects. **Applies to:** invoice types `STANDARD`, `CORRECTIVE` **Error codes:** [`NEGATIVE_TOTAL_REQUIRES_RECTIFICATIVE`](/errors/NEGATIVE_TOTAL_REQUIRES_RECTIFICATIVE) (`422`) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 15.2, párrafo segundo — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «cuando la modificación de la base imponible sea consecuencia de la devolución de mercancías o de envases y embalajes que se realicen con ocasión de un posterior suministro que tenga el mismo destinatario [...] no será necesaria la expedición de una factura rectificativa, sino que se podrá practicar la rectificación en la factura que se expida por dicho suministro [...] La rectificación se podrá realizar de este modo siempre que el tipo impositivo aplicable a todas las operaciones sea el mismo, con independencia de que su resultado sea positivo o negativo.» - RD 1619/2012 (Reglamento de facturación), art. 6.1.f) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «incluyendo el precio unitario sin Impuesto de dichas operaciones, así como cualquier descuento o rebaja que no esté incluido en dicho precio unitario.» **Incorrect:** Deducting returned crates from the next invoice to a different customer. **Correct:** A later supply of 500 € to the same customer at 21 % with a line of −60 € for returned crates at 21 %: total 440 € plus VAT. Or an `R1` `PARTIAL` corrective against the invoice the crates were delivered with. **Related:** [COR-011 · Discounts and rebates granted after the sale go on a corrective](/rules/corrective#cor-011) · [CNT-019 · Only a corrective invoice totals less than zero](/rules/contents#cnt-019) ## COR-013 · A corrective is only for the causes the law lists `Required` · Law · Impact: low · Responsibility: the issuing business. Do not issue a corrective for anything but a missing requirement, wrongly charged tax or an art. 80 LIVA change. An invoice issued for an operation that never took place is voided and, if needed, replaced by a new invoice; that replacement is never a corrective. Neither is an invoice issued in exchange for earlier simplified invoices, nor one that replaces an invoice only to remove a withholding ([COR-024](/rules/corrective#cor-024)). **Why:** Only those causes make an invoice a corrective; a corrective issued for anything else misreports what happened. An invoice for a sale that never took place does not fail a requirement: it should not exist, so it is voided. **Applies to:** invoice types `CORRECTIVE` **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 15.1 y 15.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «Deberá expedirse una factura rectificativa en los casos en que la factura original no cumpla alguno de los requisitos que se establecen en los artículos 6 ó 7 [...] 2. Igualmente, será obligatoria la expedición de una factura rectificativa en los casos en que las cuotas impositivas repercutidas se hubiesen determinado incorrectamente o se hubieran producido las circunstancias que, según lo dispuesto en el artículo 80 de la Ley del Impuesto, dan lugar a la modificación de la base imponible.» - RD 1619/2012 (Reglamento de facturación), art. 15.6 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «Únicamente tendrán la consideración de facturas rectificativas las que se expidan por alguna de las causas previstas en los apartados 1 y 2. No obstante, las facturas que se expidan en sustitución o canje de facturas simplificadas expedidas con anterioridad no tendrán la condición de rectificativas, siempre que las facturas simplificadas expedidas en su día cumpliesen los requisitos establecidos en el artículo 7.1.» **Incorrect:** Issuing a corrective to cancel an invoice for a sale that never happened. **Correct:** Voiding that invoice, because it should never have been issued. **Related:** [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [COR-024 · A corrective does not change only the withholding](/rules/corrective#cor-024) · [SIM-007 · Exchanging a simplified invoice for a full one](/rules/simplified#sim-007) · [VOI-001 · Void only an invoice that should never have been issued](/rules/void#voi-001) **Explained in:** [Cancel vs amend](/verifactu/cancel-and-fix) ## COR-014 · A corrective keeps the operation date of the original `Required` · AEAT criterion · Impact: low · Checked by the API: BeeL. applies it. The operation date of a corrective is the date the original supply or service took place. BeeL. sets it from the original invoice: its `operation_date`, or its `issue_date` when the original declared no other operation date. Every corrective carries it, whoever asks for it. **Why:** The corrective adjusts the tax of that operation, so AEAT expects it dated like the operation, not like the day it was issued. An original without `operation_date` documents an operation of its issue date; leaving the corrective without one would date it on the day of the corrective instead. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Legal basis:** - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Procedimientos de facturación: R1 — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html) > «Se incluirá como fecha de operación la fecha en que se realizó la entrega o prestó el servicio, indicada en la factura inicial. En el caso de rectificar varias facturas con una única factura rectificativa se indicará la fecha más reciente.» - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Procedimientos de facturación: fecha de operación de una rectificativa — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html) > «¿Qué fecha de operación debe hacerse constar en una factura rectificativa? La fecha de realización de la operación correspondiente a la factura original que se está rectificando.» - RD 1619/2012 (Reglamento de facturación), art. 6.1.i — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «i) La fecha en que se hayan efectuado las operaciones que se documentan o en la que, en su caso, se haya recibido el pago anticipado, siempre que se trate de una fecha distinta a la de expedición de la factura.» **Incorrect:** Recording the corrective of a March delivery as an operation of the day the corrective was issued. **Correct:** An invoice issued on 7 May for a service done that day, without `operation_date`, is corrected in October: the corrective carries 7 May as its operation date. **Related:** [DAT-004 · Send the operation date when it differs from the issue date](/rules/dates#dat-004) · [COR-005 · A corrective identifies the invoice it rectifies](/rules/corrective#cor-005) ## COR-015 · Do not raise the VAT charged to a consumer through a corrective `Required` · Law · Impact: low · Responsibility: the issuing business. Do not issue a corrective that increases the VAT charged to a recipient who is not a business, unless it follows an art. 80 LIVA cause or a legal rise of the tax rate. **Why:** The law does not let the issuer pass its own tax error on to a consumer after the sale. **Applies to:** invoice types `CORRECTIVE`; Recipient who is not a business. **Legal basis:** - Ley 37/1992 del IVA, art. 89.Tres.1.º — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a89) > «Cuando la rectificación no esté motivada por las causas previstas en el artículo 80 de esta Ley, implique un aumento de las cuotas repercutidas y los destinatarios de las operaciones no actúen como empresarios o profesionales, salvo en supuestos de elevación legal de los tipos impositivos» **Incorrect:** Charging a consumer, through an `R5` corrective, the VAT you forgot to add to a ticket. **Correct:** Absorbing the error, or correcting it only if the rise comes from a legal change of the rate. **Related:** [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [TAX-001 · Apply the VAT rate in force when the operation took place](/rules/taxes#tax-001) ## COR-016 · Some unpaid debts never allow an R2 or R3 corrective `Required` · Law · Impact: low · Responsibility: the issuing business. Do not reduce the base for insolvency (`R2`) or bad debt (`R3`) for the part of a debt secured by a real guarantee, guaranteed by a credit institution or covered by credit or surety insurance, or for debts between related parties. Debts owed or guaranteed by public entities are excluded from `R2`, and an `R3` is not issued for operations accrued before the customer was declared insolvent. A recipient not established in Spain is covered by [COR-019](/rules/corrective#cor-019). **Why:** The law excludes these debts from the reduction of the base; a corrective issued for them gives back a tax that is still owed. **Applies to:** invoice types `CORRECTIVE`; `rectification_code` `R2` or `R3`. **Legal basis:** - Ley 37/1992 del IVA, art. 80.Cinco.1.ª — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «1.ª No procederá la modificación de la base imponible en los casos siguientes: a) Créditos que disfruten de garantía real, en la parte garantizada. b) Créditos afianzados por entidades de crédito o sociedades de garantía recíproca o cubiertos por un contrato de seguro de crédito o de caución, en la parte afianzada o asegurada. c) Créditos entre personas o entidades vinculadas definidas en el artículo 79, apartado cinco, de esta Ley. d) Créditos adeudados o afianzados por Entes públicos.» - Ley 37/1992 del IVA, art. 80.Cinco.2.ª y 3.ª — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «2.ª Tampoco procederá la modificación de la base imponible cuando el destinatario de las operaciones no esté establecido en el territorio de aplicación del Impuesto, ni en Canarias, Ceuta o Melilla. [...] 3.ª Tampoco procederá la modificación de la base imponible de acuerdo con el apartado cuatro del artículo 80 de esta Ley con posterioridad al auto de declaración de concurso para los créditos correspondientes a cuotas repercutidas por operaciones cuyo devengo se produzca con anterioridad a dicho auto.» **Incorrect:** Issuing an `R3` corrective for an unpaid invoice to a subsidiary of the same group. **Correct:** Leaving the invoice to the related company as it is and pursuing the debt, without reducing the base. **Related:** [COR-008 · A bad-debt corrective (R3) needs the legal conditions first](/rules/corrective#cor-008) · [COR-009 · An insolvency corrective (R2) needs a declaration of insolvency](/rules/corrective#cor-009) · [COR-019 · Insolvency and bad-debt correctives need a recipient established in Spain](/rules/corrective#cor-019) ## COR-017 · A corrective keeps the recipient, except to correct the recipient's data `Required` · Law · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. A corrective goes to the recipient of the invoice it rectifies, with the data recorded on that invoice, and takes no `recipient`. The exception is correcting that recipient's own data when the invoice recorded them wrong (name, tax ID or address of the right recipient): send `recipient` with the corrected data, `rectification_type` `PARTIAL`, `rectification_code` `R4` and no `lines`. That corrective carries the corrected recipient, leaves the amounts unchanged (its lines negate what is still invoiced and repeat it, so each rate nets to zero) and leaves the original `RECTIFIED`. When the original went to a registered customer, the corrected recipient must be that same customer (`CORRECTIVE_RECIPIENT_IS_ANOTHER_PERSON` otherwise), and data identical to the recorded ones are refused with `CORRECTIVE_RECIPIENT_UNCHANGED`. Any other `recipient` is refused with `CORRECTIVE_RECIPIENT_NOT_ACCEPTED`. If the invoice was issued to another person altogether, correct it in full with a `TOTAL` corrective and issue a new invoice to the right customer. **Why:** An invoice with the recipient's data wrong does not meet the invoice requirements, and the law fixes that with a corrective; voiding it and issuing another leaves the defective invoice standing. Changing the person, instead, is not a correction of data: the operation with the first person did not happen, so that invoice is credited and the right one is issued. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Error codes:** [`CORRECTIVE_RECIPIENT_NOT_ACCEPTED`](/errors/CORRECTIVE_RECIPIENT_NOT_ACCEPTED) (`422`), [`CORRECTIVE_RECIPIENT_IS_ANOTHER_PERSON`](/errors/CORRECTIVE_RECIPIENT_IS_ANOTHER_PERSON) (`422`), [`CORRECTIVE_RECIPIENT_UNCHANGED`](/errors/CORRECTIVE_RECIPIENT_UNCHANGED) (`422`) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 15.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «1. Deberá expedirse una factura rectificativa en los casos en que la factura original no cumpla alguno de los requisitos que se establecen en los artículos 6 ó 7, sin perjuicio de lo establecido en el apartado 6 de este artículo.» - RD 1619/2012 (Reglamento de facturación), art. 6.1.c) y e) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «c) Nombre y apellidos, razón o denominación social completa, tanto del obligado a expedir factura como del destinatario de las operaciones. [...] e) Domicilio, tanto del obligado a expedir factura como del destinatario de las operaciones.» - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Procedimientos de facturación: tipo de facturas, R4 — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html) > «"R4": Factura Rectificativa (Resto). Se indicará tipo de factura R4 en estas situaciones: [...] Cuando se haya consignado erróneamente algún dato no monetario de la factura» **Incorrect:** Voiding an invoice whose customer's tax ID was mistyped and issuing it again: the defective invoice stays on file uncorrected. **Correct:** Correcting the mistyped tax ID with an `R4` corrective that carries the corrected recipient. ```json { "rectification_type": "PARTIAL", "rectification_code": "R4", "reason": "The customer's tax ID was mistyped", "recipient": { "customer_id": "8f1e…" } } ``` **Related:** [COR-005 · A corrective identifies the invoice it rectifies](/rules/corrective#cor-005) · [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [REC-009 · Check the data AEAT accepted with errors](/rules/records#rec-009) · [VOI-002 · Void an issued invoice through the void operation; delete a draft](/rules/void#voi-002) **Explained in:** [Corrective invoices (R1–R5)](/verifactu/corrective-invoices) ## COR-018 · A corrective can always correct what the original declared `Required` · Law · Impact: high · Checked by the API: BeeL. applies it. A corrective is judged against the treatment its original already had, not against the rules that BeeL. applies to new invoices. A regime key, exemption reason, withholding rate or surcharge rate that a new invoice can no longer use is accepted in the corrective only if the original carried it on one of its lines; the corrective is then registered as the original was. Anything the original did not carry is judged as on a new invoice. The checks AEAT itself makes on the record still apply, and a corrective, like any invoice, needs at least one NORMAL line. **Why:** The law makes the corrective mandatory whenever the original was wrong or its amounts change, so refusing it would leave the original with no way to be corrected. What a new invoice may no longer use is exactly what a corrective has to reverse. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 15.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «Deberá expedirse una factura rectificativa en los casos en que la factura original no cumpla alguno de los requisitos que se establecen en los artículos 6 ó 7, sin perjuicio de lo establecido en el apartado 6 de este artículo.» - RD 1619/2012 (Reglamento de facturación), art. 15.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «Igualmente, será obligatoria la expedición de una factura rectificativa en los casos en que las cuotas impositivas repercutidas se hubiesen determinado incorrectamente o se hubieran producido las circunstancias que, según lo dispuesto en el artículo 80 de la Ley del Impuesto, dan lugar a la modificación de la base imponible.» **Incorrect:** A partial corrective of an invoice issued under regime key `01` without withholding adds a line under key `03` with a 15 % withholding: it is judged as a new invoice and rejected. **Correct:** The full corrective of an old invoice carries the same regime key, exemption reason and withholding rate, negated, and is registered with the same breakdown the original had. **Related:** [COR-014 · A corrective keeps the operation date of the original](/rules/corrective#cor-014) · [TAX-016 · Regime keys 03, 06 and 14 are not accepted](/rules/taxes#tax-016) · [TAX-018 · An issued invoice does not use the intra-EU acquisition exemption](/rules/taxes#tax-018) · [TAX-019 · An issuer that is not an individual never bears the IRPF rates of individuals](/rules/taxes#tax-019) ## COR-019 · Insolvency and bad-debt correctives need a recipient established in Spain `Required` · Law · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. Do not issue an `R2` (insolvency) or `R3` (bad debt) corrective when the recipient is not established in Spain, the Canary Islands, Ceuta or Melilla. The exception is an insolvency declared by a court of another EU member state under Regulation (EU) 2015/848, which may reduce the base as an insolvency: an `R2` accepts a recipient of another member state, an `R3` does not. The API reads where the recipient is established from its address, or from the country of its identifier when there is no address (a Spanish NIF is Spain), and refuses the corrective with `CORRECTIVE_RECIPIENT_NOT_ESTABLISHED` when that is elsewhere or unknown. **Why:** The law does not allow the base to be reduced for these debts, so the VAT the corrective gives back is still owed. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice); `rectification_code` `R2` or `R3`. **Error codes:** [`CORRECTIVE_RECIPIENT_NOT_ESTABLISHED`](/errors/CORRECTIVE_RECIPIENT_NOT_ESTABLISHED) (`422`) **Legal basis:** - Ley 37/1992 del IVA, art. 80.Cinco.2.ª — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «Cinco. En relación con los supuestos de modificación de la base imponible comprendidos en los apartados tres y cuatro anteriores, se aplicarán las siguientes reglas: [...] 2.ª Tampoco procederá la modificación de la base imponible cuando el destinatario de las operaciones no esté establecido en el territorio de aplicación del Impuesto, ni en Canarias, Ceuta o Melilla. Quedan excluidos de lo dispuesto en el párrafo anterior los supuestos de créditos incobrables como consecuencia de un proceso de insolvencia declarado por un órgano jurisdiccional de otro Estado miembro cuando se trate de procedimientos de insolvencia a los que resulte de aplicación el Reglamento (UE) 2015/848 del Parlamento Europeo y del Consejo, de 20 de mayo de 2015, sobre procedimientos de insolvencia, que podrán dar lugar, en su caso, a la modificación de la base imponible del sujeto pasivo en los términos previstos en el artículo 80.tres de esta ley.» **Incorrect:** An `R3` corrective for an unpaid invoice to a customer based in France: the API answers [`CORRECTIVE_RECIPIENT_NOT_ESTABLISHED`](/errors/CORRECTIVE_RECIPIENT_NOT_ESTABLISHED). **Correct:** An `R2` corrective for a French customer declared insolvent by a French court, once the conditions of article 80.Tres are met. **Related:** [COR-009 · An insolvency corrective (R2) needs a declaration of insolvency](/rules/corrective#cor-009) · [COR-008 · A bad-debt corrective (R3) needs the legal conditions first](/rules/corrective#cor-008) · [COR-016 · Some unpaid debts never allow an R2 or R3 corrective](/rules/corrective#cor-016) **Explained in:** [Corrective invoices (R1–R5)](/verifactu/corrective-invoices) ## COR-020 · A bad-debt corrective waits six months and needs a business recipient under 50 € `Required` · Law · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. Do not issue an `R3` corrective before six months have passed since the tax accrued: the API counts them from the original's operation date and refuses an earlier one with `CORRECTIVE_BAD_DEBT_TOO_EARLY`, giving the first possible day. Six months is the period only for a business whose turnover the year before did not exceed 6,010,121.04 €; otherwise it is one year, and applying it is the issuer's responsibility. When the base of the operation is 50 € or less, the recipient must have acted as a business or professional: declare it with `recipient_is_business`, or the corrective is refused with `CORRECTIVE_BAD_DEBT_BASE_TOO_LOW`. **Why:** Before the waiting period, or for a consumer's debt of 50 € or less, the debt is not uncollectable in the legal sense and the base cannot be reduced. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice); `rectification_code` `R3`. **Error codes:** [`CORRECTIVE_BAD_DEBT_TOO_EARLY`](/errors/CORRECTIVE_BAD_DEBT_TOO_EARLY) (`422`), [`CORRECTIVE_BAD_DEBT_BASE_TOO_LOW`](/errors/CORRECTIVE_BAD_DEBT_BASE_TOO_LOW) (`422`) **Legal basis:** - Ley 37/1992 del IVA, art. 80.Cuatro.A).1.ª — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «1.ª Que haya transcurrido un año desde el devengo del Impuesto repercutido sin que se haya obtenido el cobro de todo o parte del crédito derivado del mismo. [...] Cuando el titular del derecho de crédito cuya base imponible se pretende reducir sea un empresario o profesional cuyo volumen de operaciones, calculado conforme a lo dispuesto en el artículo 121 de esta Ley, no hubiese excedido durante el año natural inmediato anterior de 6.010.121,04 euros, el plazo a que se refiere esta condición 1.ª podrá ser, de seis meses o un año.» - Ley 37/1992 del IVA, art. 80.Cuatro.A).3.ª — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «3.ª Que el destinatario de la operación actúe en la condición de empresario o profesional, o, en otro caso, que la base imponible de aquella, Impuesto sobre el Valor Añadido excluido, sea superior a 50 euros.» **Incorrect:** An `R3` corrective in March for a service invoiced in January: the API answers [`CORRECTIVE_BAD_DEBT_TOO_EARLY`](/errors/CORRECTIVE_BAD_DEBT_TOO_EARLY) with the first day it is possible. **Correct:** An `R3` corrective for an unpaid 40 € service to a self-employed customer, declaring that the customer acted as a business. ```json { "rectification_type": "TOTAL", "rectification_code": "R3", "reason": "Unpaid for more than six months; notarial demand sent on 2026-05-04", "recipient_is_business": true } ``` **Related:** [COR-008 · A bad-debt corrective (R3) needs the legal conditions first](/rules/corrective#cor-008) · [COR-019 · Insolvency and bad-debt correctives need a recipient established in Spain](/rules/corrective#cor-019) · [COR-006 · Issue the corrective as soon as you know, within 4 years](/rules/corrective#cor-006) **Explained in:** [Corrective invoices (R1–R5) › Scenario 3 — PARTIAL bad-debt write-off (R3)](/verifactu/corrective-invoices#scenario-3--partial-bad-debt-write-off-r3) ## COR-021 · An identical corrective a moment after another is taken as a double submission `Recommended` · BeeL. rule · Impact: low · Checked by the API: a request that breaks it is rejected with the error codes listed. A corrective identical to another live one of the same invoice (same type, reason code, reason, taxable base and amount payable, disbursements included) created less than two minutes earlier is refused with `CORRECTIVE_RECENT_DUPLICATE`: it is a double click or a retry. After that window an identical corrective is issued, since two refunds of the same amount are two correctives. To retry a request safely at any time, send an `Idempotency-Key`. Correctives that come from a payment integration carry their own identity and are not checked this way. **Why:** A double submission would issue a second fiscal document for the same correction. Blocking identical correctives for a whole day, instead, refused legitimate repeated refunds. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Error codes:** [`CORRECTIVE_RECENT_DUPLICATE`](/errors/CORRECTIVE_RECENT_DUPLICATE) (`422`) **Incorrect:** Retrying a corrective after a timeout without an `Idempotency-Key`, a few seconds later: the API answers [`CORRECTIVE_RECENT_DUPLICATE`](/errors/CORRECTIVE_RECENT_DUPLICATE) with the number of the one already issued. **Correct:** Retrying with the same `Idempotency-Key`: the API returns the corrective already issued instead of a new one. ```http POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective Idempotency-Key: 5f0c2d1e-refund-0042 ``` **Related:** [COR-023 · A corrective never rectifies more than was invoiced](/rules/corrective#cor-023) · [LIF-004 · Retry writes with the same Idempotency-Key](/rules/lifecycle#lif-004) ## COR-022 · An invoice whose record AEAT rejected is fixed before it is corrected `Required` · AEAT criterion · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. When AEAT rejected the record of the original invoice and it has not been resubmitted, fix it and resubmit it first; a corrective against it is refused with `CORRECTIVE_ORIGINAL_RECORD_REJECTED`. An original whose record is still being processed, or that was issued outside VeriFactu, can be corrected. **Why:** A rejected record never reaches AEAT's books. A corrective states the difference from the original, so issued first it would be recorded on its own, as a correction of an invoice AEAT does not have. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice); VeriFactu enabled for the original invoice. **Error codes:** [`CORRECTIVE_ORIGINAL_RECORD_REJECTED`](/errors/CORRECTIVE_ORIGINAL_RECORD_REJECTED) (`422`) **Legal basis:** - AEAT, Aclaraciones a dudas de los desarrolladores (v1.3), 17. Aclaraciones, caso 2.a) — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/FAQs-Desarrolladores.pdf) > «En el probable caso de que el RF generado de la “factura errónea” fuera rechazado por la AEAT (lo que podría servir para que el usuario se percatara del error cometido), ese RF rechazado no figuraría jamás en los sistemas de la AEAT (aunque constaría un rechazo).» - AEAT, Aclaraciones a dudas de los desarrolladores (v1.3), 17. Aclaraciones, caso 2.b) — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/FAQs-Desarrolladores.pdf) > «Si el RF generado de la “factura errónea” fuera rechazado por la AEAT (lo que podría servir para que el usuario se percatara del error cometido), habría que [...] corregir la factura original y generar un RF de alta de subsanación, sin registro previo en la AEAT (ya que el RF “original” fue rechazado y no existe en la AEAT).» **Incorrect:** Issuing a corrective for an invoice whose record AEAT rejected for a wrong recipient NIF: the API answers [`CORRECTIVE_ORIGINAL_RECORD_REJECTED`](/errors/CORRECTIVE_ORIGINAL_RECORD_REJECTED). **Correct:** Fixing the recipient's data, resubmitting the original's record and, once AEAT accepts it, issuing the corrective if one is still due. **Related:** [REC-008 · Follow submission_status and fix what AEAT rejects](/rules/records#rec-008) · [REC-009 · Check the data AEAT accepted with errors](/rules/records#rec-009) · [COR-005 · A corrective identifies the invoice it rectifies](/rules/corrective#cor-005) **Explained in:** [Handling AEAT rejections](/verifactu/handling-rejections) ## COR-023 · A corrective never rectifies more than was invoiced `Required` · Law · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. A corrective rectifies what is still invoiced: the original invoice plus the correctives already issued against it, voided ones excluded. A `TOTAL` corrective rectifies that remaining balance, negating every line of the original and of its live correctives, and is refused with `CORRECTIVE_NOTHING_LEFT_TO_RECTIFY` when previous correctives already left nothing. A `PARTIAL` corrective may raise any amount, but may not take the taxable base of any rate (tax, rate and equivalence surcharge) below zero: that is refused with `CORRECTIVE_EXCEEDS_INVOICED_AMOUNT`, which names the rate and how much of it is left. Disbursements (`SUPLIDO` lines) are capped by their own amount. **Why:** The taxable base of an operation changes by the amount that corresponds to what changed. After a partial credit of 300 on an invoice of 1,000, what is left invoiced is 700; a corrective that negated the 1,000 again would give back 1,300 and a tax that was never charged. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Error codes:** [`CORRECTIVE_EXCEEDS_INVOICED_AMOUNT`](/errors/CORRECTIVE_EXCEEDS_INVOICED_AMOUNT) (`422`), [`CORRECTIVE_NOTHING_LEFT_TO_RECTIFY`](/errors/CORRECTIVE_NOTHING_LEFT_TO_RECTIFY) (`422`) **Legal basis:** - Ley 37/1992 del IVA, art. 80.Dos — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a80) > «Dos. Cuando por resolución firme, judicial o administrativa o con arreglo a Derecho o a los usos de comercio queden sin efecto total o parcialmente las operaciones gravadas o se altere el precio después del momento en que la operación se haya efectuado, la base imponible se modificará en la cuantía correspondiente.» - RD 1619/2012 (Reglamento de facturación), art. 15.5 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «Cuando lo que se expida sea una factura rectificativa, los datos a los que se refiere el artículo 6.1.f), g) y h) expresarán la rectificación efectuada.» **Incorrect:** Rectifying an invoice of 1,000 that already has a −300 `PARTIAL` corrective with a `PARTIAL` of −800 at the same rate: it would take the base to −100, and the API answers [`CORRECTIVE_EXCEEDS_INVOICED_AMOUNT`](/errors/CORRECTIVE_EXCEEDS_INVOICED_AMOUNT). **Correct:** Issuing a `TOTAL` corrective on that invoice: it negates the 1,000 and the −300, rectifies 700 and leaves the invoice at zero. ```json { "rectification_type": "TOTAL", "rectification_code": "R1", "reason": "Order cancelled by agreement with the customer" } ``` **Related:** [COR-003 · A corrective shows the difference or the amounts after the correction](/rules/corrective#cor-003) · [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [COR-007 · A wrong corrective is fixed against the original, not corrected itself](/rules/corrective#cor-007) **Explained in:** [Corrective invoices (R1–R5)](/verifactu/corrective-invoices) ## COR-024 · A corrective does not change only the withholding `Required` · Law · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. A `PARTIAL` corrective whose lines negate operations of the invoice and repeat them unchanged (same description, amount and rate) except for the income tax withholding is refused with `CORRECTIVE_WITHHOLDING_ONLY`. The withholding is not one of the details an invoice must contain, nor a VAT amount, so correcting it alone is not a cause for a corrective. When an invoice carried a withholding it should not have, void it and issue a new invoice without it. Moving part of the price between a line with withholding and one without it corrects the operations themselves and is accepted. **Why:** Only an invoice that fails a legal requirement, charges the wrong VAT or needs an art. 80 LIVA change is a corrective. A document issued for any other reason and filed as a corrective misreports what happened, and its billing record carries no amount at all, because the record has no withholding. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Error codes:** [`CORRECTIVE_WITHHOLDING_ONLY`](/errors/CORRECTIVE_WITHHOLDING_ONLY) (`422`) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 15.1 y 15.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «Deberá expedirse una factura rectificativa en los casos en que la factura original no cumpla alguno de los requisitos que se establecen en los artículos 6 ó 7 [...] 2. Igualmente, será obligatoria la expedición de una factura rectificativa en los casos en que las cuotas impositivas repercutidas se hubiesen determinado incorrectamente o se hubieran producido las circunstancias que, según lo dispuesto en el artículo 80 de la Ley del Impuesto, dan lugar a la modificación de la base imponible.» - RD 1619/2012 (Reglamento de facturación), art. 15.6 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «Únicamente tendrán la consideración de facturas rectificativas las que se expidan por alguna de las causas previstas en los apartados 1 y 2.» **Incorrect:** A `PARTIAL` corrective that negates a line of 1,000 at 21% with 15% withholding and adds it again with no withholding: the API answers [`CORRECTIVE_WITHHOLDING_ONLY`](/errors/CORRECTIVE_WITHHOLDING_ONLY). **Correct:** Voiding the invoice, confirming it was issued in error, and issuing a new one without the withholding. **Related:** [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [COR-013 · A corrective is only for the causes the law lists](/rules/corrective#cor-013) · [VOI-001 · Void only an invoice that should never have been issued](/rules/void#voi-001) **Explained in:** [Cancel vs amend](/verifactu/cancel-and-fix) [← All rules](/rules#all-rules) ## Related - [Corrective invoices (R1–R5)](/verifactu/corrective-invoices) — pick the right rectification type and code, and see the canonical request shapes BeeL. accepts for each scenario - [Cancel vs amend](/verifactu/cancel-and-fix) — decide between cancelling an invoice (void) and issuing a corrective invoice, two operations with different fiscal weight - [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 --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # Numbering and series How invoice numbers are assigned, which documents need their own series, and why a number is never reused. [← All rules](/rules#all-rules) An invoice number is fiscal data: it is assigned once, at issue, and it identifies the invoice in AEAT's records for good. These rules cover who assigns it, which documents go in separate series, and what a number may look like. 9 rules: 5 from the law, 2 AEAT criteria, 2 BeeL. rules. [How to read a rule](/rules#how-to-read-a-rule). ## NUM-001 · The number is assigned when the invoice is issued `Required` · BeeL. rule · Impact: critical · Checked by the API: BeeL. applies it. Do not expect or send an invoice number: a draft has none, and BeeL. assigns the next number of the chosen series when the invoice is issued. Read `invoice_number` from the response of the issue call. **Why:** Numbering at issue is what keeps the series free of gaps: a draft deleted before issuing never consumed a number. **Applies to:** statuses `DRAFT`, `SCHEDULED`, `ISSUED`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice) **Incorrect:** Storing the draft's id as the invoice number in your system, or computing the next number yourself before issuing. **Correct:** Issuing the draft and saving the `invoice_number` the issue call returns. ```http POST /v1/companies/{company_id}/invoices/{invoice_id}/issue ``` **Related:** [NUM-003 · Numbers are correlative within each series](/rules/numbering#num-003) · [NUM-002 · An issued number is never reused, even when the invoice is voided](/rules/numbering#num-002) · [LIF-002 · Only a draft can be issued](/rules/lifecycle#lif-002) **Explained in:** [Series and numbering › The number is assigned when you issue](/guides/series-and-numbering#the-number-is-assigned-when-you-issue) ## NUM-002 · An issued number is never reused, even when the invoice is voided `Required` · AEAT criterion · Impact: critical · Checked by the API: a request that breaks it is rejected with the error codes listed. Treat every issued number as consumed for good. A voided invoice, or a test issued in production, keeps its number in the series; the invoice that replaces it gets a new one. BeeL. never gives two invoices of a company the same number: a series whose format could print the numbers of another series of the company is rejected with [`SERIES_FORMAT_OVERLAPS`](/errors/SERIES_FORMAT_OVERLAPS). If AEAT already holds a record with the same number and issue date that is not this invoice, for example one issued with the software you used before, the invoice is not registered: its `verifactu.submission_status` is `REJECTED`, and it has to be issued again with a different series or number. **Why:** The number identifies the invoice in AEAT's records. A second invoice with the same number would be a duplicate that AEAT does not accept. **Applies to:** statuses `ISSUED`, `SENT`, `PAID`, `RECTIFIED`, `VOIDED`; operations [`POST /v1/companies/{company_id}/series`](/invoice-series/createCompanySeries), [`PATCH /v1/companies/{company_id}/series/{series_id}`](/invoice-series/patchCompanySeries), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice) **Error codes:** [`SERIES_FORMAT_OVERLAPS`](/errors/SERIES_FORMAT_OVERLAPS) (`409`), [`SERIES_NUMBER_COLLISION`](/errors/SERIES_NUMBER_COLLISION) (`400`) **Legal basis:** - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Registros de facturación: anulación — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/registros-facturacion-anulacion.html) > «Desde el punto de vista sustantivo, si las facturas se han emitido, aunque sean erróneas deben mantenerse, con su correspondiente numeración, y sin perjuicio de que se anulen posteriormente y se sustituyan por nuevas facturas correctas.» - AEAT, Aclaraciones a dudas de los desarrolladores (v1.3), 6. Prohibición de numeración duplicada de un registro — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/FAQs-Desarrolladores.pdf) > «ya NO es posible reutilizar la numeración de ninguna factura expedida, aunque sean facturas expedidas "de prueba".» **Incorrect:** Creating a series with the fixed format `F-{YYYY}-{NUM:4}` next to series `F`, whose format is `{CODIGO}-{YYYY}-{NUM:4}`: both would print `F-2026-0042`, and the new series is rejected with [`SERIES_FORMAT_OVERLAPS`](/errors/SERIES_FORMAT_OVERLAPS). **Correct:** Voiding `F-2026-0042` and issuing the replacement as a new invoice, which takes the next number of the series. **Related:** [NUM-001 · The number is assigned when the invoice is issued](/rules/numbering#num-001) · [VOI-001 · Void only an invoice that should never have been issued](/rules/void#voi-001) · [LIF-003 · Test in the sandbox, never with real invoices](/rules/lifecycle#lif-003) **Explained in:** [Series and numbering › The number is assigned when you issue](/guides/series-and-numbering#the-number-is-assigned-when-you-issue) ## NUM-003 · Numbers are correlative within each series `Required` · Law · Impact: high · Checked by the API: BeeL. applies it. Within a series, invoice numbers follow one another without gaps or jumps. BeeL. takes the next number of the series at issue, gives it back if the issue fails, and applies the series' initial number only to the first period the series numbers in: later periods start at 1. Numbers are only correlative if every invoice of that series is issued through BeeL. **Why:** A gap or a jump in a series is what an inspection reads as a missing invoice. **Applies to:** invoice types `STANDARD`, `SIMPLIFIED`, `CORRECTIVE` **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «Número y, en su caso, serie. La numeración de las facturas dentro de cada serie será correlativa.» **Incorrect:** Issuing some invoices of series `A` from another system while BeeL. issues the rest of the same series. **Correct:** Giving each system its own series, or continuing an old sequence in BeeL. by setting the series' initial number before its first invoice. **Related:** [NUM-001 · The number is assigned when the invoice is issued](/rules/numbering#num-001) · [NUM-004 · Separate series may be used when there is a reason for them](/rules/numbering#num-004) · [NUM-007 · A series cannot be renumbered once it has issued](/rules/numbering#num-007) **Explained in:** [Series and numbering › How the counter works](/guides/series-and-numbering#how-the-counter-works) · [Series and numbering › Continuing a sequence from another system](/guides/series-and-numbering#continuing-a-sequence-from-another-system) ## NUM-004 · Separate series may be used when there is a reason for them `Recommended` · Law · Impact: low · Responsibility: the issuing business. You may number invoices in separate series when there is a reason, such as several establishments or operations of a different nature. Create one series per establishment or line of business and pick it when you create the invoice. **Why:** Mixing establishments in one series makes the sequence hard to follow; the law lets you keep them apart. **Applies to:** operations [`POST /v1/companies/{company_id}/series`](/invoice-series/createCompanySeries) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «Se podrán expedir facturas mediante series separadas cuando existan razones que lo justifiquen y, entre otros supuestos, cuando el obligado a su expedición cuente con varios establecimientos desde los que efectúe sus operaciones y cuando el obligado a su expedición realice operaciones de distinta naturaleza.» **Incorrect:** Creating a new series every month to restart the count, with no establishment or kind of operation behind it. **Correct:** Creating series `SHOP` and `ONLINE` for a business that sells in a shop and on the web, and sending each invoice's `series_id`. **Related:** [NUM-003 · Numbers are correlative within each series](/rules/numbering#num-003) · [NUM-005 · Simplified invoices are numbered in their own series](/rules/numbering#num-005) · [NUM-006 · Corrective invoices are numbered in their own series](/rules/numbering#num-006) **Explained in:** [Series and numbering › Default series per document type](/guides/series-and-numbering#default-series-per-document-type) ## NUM-005 · Simplified invoices are numbered in their own series `Required` · Law · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. A business that issues both full and simplified invoices in the same calendar year numbers them in separate series. A BeeL. series numbers only documents of its own type: a simplified invoice in a series of another type, or in an older `UNASSIGNED` series, is rejected with [`SERIES_INCOMPATIBLE_DOC_TYPE`](/errors/SERIES_INCOMPATIBLE_DOC_TYPE), when it is created, edited or issued. Without `series_id`, the company's default series for simplified invoices is used, and it is created on first use if the company has none. A series that has already numbered invoices cannot change its type ([`SERIES_DOCUMENT_TYPE_LOCKED_HAS_INVOICES`](/errors/SERIES_DOCUMENT_TYPE_LOCKED_HAS_INVOICES)), and a new series of type `UNASSIGNED` is rejected with [`SERIES_UNASSIGNED_TYPE_NOT_ALLOWED`](/errors/SERIES_UNASSIGNED_TYPE_NOT_ALLOWED). **Why:** Full and simplified invoices sharing a series would leave neither sequence correlative. **Applies to:** invoice types `SIMPLIFIED`, `STANDARD`; operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/companies/{company_id}/series`](/invoice-series/createCompanySeries), [`PATCH /v1/companies/{company_id}/series/{series_id}`](/invoice-series/patchCompanySeries) **Error codes:** [`SERIES_INCOMPATIBLE_DOC_TYPE`](/errors/SERIES_INCOMPATIBLE_DOC_TYPE) (`422`), [`SERIES_DOCUMENT_TYPE_LOCKED_HAS_INVOICES`](/errors/SERIES_DOCUMENT_TYPE_LOCKED_HAS_INVOICES) (`400`), [`SERIES_UNASSIGNED_TYPE_NOT_ALLOWED`](/errors/SERIES_UNASSIGNED_TYPE_NOT_ALLOWED) (`422`) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 7.1.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a7) > «Cuando el empresario o profesional expida facturas conforme a este artículo y al artículo 6 para la documentación de las operaciones efectuadas en un mismo año natural, será obligatoria la expedición mediante series separadas de unas y otras.» **Incorrect:** Creating a `SIMPLIFIED` invoice with the `series_id` of your standard-invoice series: it is rejected with [`SERIES_INCOMPATIBLE_DOC_TYPE`](/errors/SERIES_INCOMPATIBLE_DOC_TYPE), and so is issuing or updating an invoice in such a series. **Correct:** Omitting `series_id` on a simplified invoice: it is numbered in the company's simplified series, created with code `S` (or the next free code) the first time it is needed. **Related:** [NUM-004 · Separate series may be used when there is a reason for them](/rules/numbering#num-004) · [NUM-006 · Corrective invoices are numbered in their own series](/rules/numbering#num-006) · [SIM-001 · A simplified invoice never exceeds 3,000 €](/rules/simplified#sim-001) **Explained in:** [Series and numbering › Default series per document type](/guides/series-and-numbering#default-series-per-document-type) ## NUM-006 · Corrective invoices are numbered in their own series `Required` · Law · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. Corrective invoices go in a series specific to correctives, never in the series of the invoice they correct nor in an older `UNASSIGNED` series. Without a `series_id`, BeeL. numbers a corrective in the company's default corrective series, which is created on first use (code `R`, or the next free code whose numbers cannot repeat another series') if the company has none. An explicit series of another type is rejected with [`SERIES_INCOMPATIBLE_DOC_TYPE`](/errors/SERIES_INCOMPATIBLE_DOC_TYPE); a series that has already numbered invoices cannot change its type ([`SERIES_DOCUMENT_TYPE_LOCKED_HAS_INVOICES`](/errors/SERIES_DOCUMENT_TYPE_LOCKED_HAS_INVOICES)); a new series of type `UNASSIGNED` is rejected with [`SERIES_UNASSIGNED_TYPE_NOT_ALLOWED`](/errors/SERIES_UNASSIGNED_TYPE_NOT_ALLOWED). **Why:** The law requires correctives to be told apart from ordinary invoices by their series. **Applies to:** invoice types `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice), [`POST /v1/companies/{company_id}/series`](/invoice-series/createCompanySeries), [`PATCH /v1/companies/{company_id}/series/{series_id}`](/invoice-series/patchCompanySeries) **Error codes:** [`SERIES_INCOMPATIBLE_DOC_TYPE`](/errors/SERIES_INCOMPATIBLE_DOC_TYPE) (`422`), [`SERIES_DOCUMENT_TYPE_LOCKED_HAS_INVOICES`](/errors/SERIES_DOCUMENT_TYPE_LOCKED_HAS_INVOICES) (`400`), [`SERIES_UNASSIGNED_TYPE_NOT_ALLOWED`](/errors/SERIES_UNASSIGNED_TYPE_NOT_ALLOWED) (`422`) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «No obstante, será obligatoria, en todo caso, la expedición en series específicas de las facturas siguientes: [...] 2.º Las rectificativas.» **Incorrect:** Passing the `series_id` of your ordinary series when creating a corrective invoice. **Correct:** Omitting `series_id` on the corrective: it goes in the company's corrective series, created the first time it is needed. ```http POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective { "rectification_type": "TOTAL", "rectification_code": "R1", "reason": "Invoice issued with the wrong VAT rate" } ``` **Related:** [NUM-005 · Simplified invoices are numbered in their own series](/rules/numbering#num-005) · [COR-002 · Pick the reason code: R1–R4 for standard invoices, R5 for simplified](/rules/corrective#cor-002) **Explained in:** [Series and numbering › Correctives and proformas](/guides/series-and-numbering#correctives-and-proformas) ## NUM-007 · A series cannot be renumbered once it has issued `Required` · BeeL. rule · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. Once a series has issued an invoice, its code, format, reset policy, initial number and document type are fixed. Design the series before its first invoice; to number differently, or another type, create a new series. **Why:** Changing how an issued series is numbered would rewrite numbers already registered with AEAT or break the sequence. **Applies to:** operations [`PATCH /v1/companies/{company_id}/series/{series_id}`](/invoice-series/patchCompanySeries) **Error codes:** [`SERIES_CODE_LOCKED_HAS_INVOICES`](/errors/SERIES_CODE_LOCKED_HAS_INVOICES) (`400`), [`SERIES_FORMAT_LOCKED_HAS_INVOICES`](/errors/SERIES_FORMAT_LOCKED_HAS_INVOICES) (`400`), [`SERIES_RESET_LOCKED_HAS_INVOICES`](/errors/SERIES_RESET_LOCKED_HAS_INVOICES) (`400`), [`SERIES_INITIAL_NUMBER_LOCKED_HAS_INVOICES`](/errors/SERIES_INITIAL_NUMBER_LOCKED_HAS_INVOICES) (`400`), [`SERIES_DOCUMENT_TYPE_LOCKED_HAS_INVOICES`](/errors/SERIES_DOCUMENT_TYPE_LOCKED_HAS_INVOICES) (`400`), [`SERIES_NUMBERING_FROZEN`](/errors/SERIES_NUMBERING_FROZEN) (`400`) **Incorrect:** Changing the format of series `A` after it has issued invoices, to add the year: it is rejected with [`SERIES_FORMAT_LOCKED_HAS_INVOICES`](/errors/SERIES_FORMAT_LOCKED_HAS_INVOICES). **Correct:** Creating a new series with the new format and making it the default for new invoices. **Related:** [NUM-003 · Numbers are correlative within each series](/rules/numbering#num-003) · [NUM-004 · Separate series may be used when there is a reason for them](/rules/numbering#num-004) **Explained in:** [Series and numbering › A series locks once it has issued](/guides/series-and-numbering#a-series-locks-once-it-has-issued) ## NUM-008 · An invoice number fits AEAT's length and character set `Required` · AEAT criterion · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. The full invoice number, series prefix included, is at most 60 characters and uses only printable ASCII characters, without double quotes, single quotes, less-than, greater-than or equals signs. BeeL. checks the longest number a series can generate when you create it or change its code or format, counting the counter as at least nine digits ([`SERIES_FORMAT_NUMBER_TOO_LONG`](/errors/SERIES_FORMAT_NUMBER_TOO_LONG)), and checks the actual number again at issue: an invoice whose number AEAT would not accept is not issued, and the number is not consumed ([`INVOICE_NUMBER_TOO_LONG`](/errors/INVOICE_NUMBER_TOO_LONG)). **Why:** AEAT identifies the invoice by this number, in the record and in the QR, and does not accept a number outside these limits. **Applies to:** operations [`POST /v1/companies/{company_id}/series`](/invoice-series/createCompanySeries), [`PATCH /v1/companies/{company_id}/series/{series_id}`](/invoice-series/patchCompanySeries), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice) **Error codes:** [`SERIES_FORMAT_NUMBER_TOO_LONG`](/errors/SERIES_FORMAT_NUMBER_TOO_LONG) (`422`), [`SERIES_FORMAT_INVALID_CHARACTERS`](/errors/SERIES_FORMAT_INVALID_CHARACTERS) (`422`), [`INVOICE_NUMBER_TOO_LONG`](/errors/INVOICE_NUMBER_TOO_LONG) (`422`), [`INVOICE_NUMBER_INVALID_CHARACTERS`](/errors/INVOICE_NUMBER_INVALID_CHARACTERS) (`422`) **Legal basis:** - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.1 Agrupación IDFactura — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «NumSerieFactura solo puede contener caracteres ASCII del 32 a 126 (caracteres imprimibles), no permitiéndose la existencia de los siguientes caracteres:» - AEAT, Detalle de las especificaciones técnicas del código QR de la factura (v0.5.0), apartado 6, parámetro numserie — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/DetalleEspecificacTecnCodigoQRfactura.pdf) > «numserie Cadena de Máximo 60 Sí Nº Serie + Nº Factura» **Incorrect:** A series with a 50-character code and the format `{CODIGO}-{YYYY}-{NUM:4}`: its longest number reaches 65 characters, and the series is rejected with [`SERIES_FORMAT_NUMBER_TOO_LONG`](/errors/SERIES_FORMAT_NUMBER_TOO_LONG). **Correct:** A series format that produces short numbers such as `SHOP-2026-0001`. **Related:** [NUM-007 · A series cannot be renumbered once it has issued](/rules/numbering#num-007) · [QRC-005 · Use qr_url exactly as returned](/rules/qr#qrc-005) **Explained in:** [Series and numbering › The format](/guides/series-and-numbering#the-format) ## NUM-009 · Reverse-charge supplies of metals and electronics go in a special series `Required` · Law · Impact: low · Responsibility: the issuing business. Invoices for supplies of silver, platinum, palladium, mobile phones, game consoles, laptops or tablets in which the buyer is liable for the VAT are issued in a special series. Keep a dedicated series for these invoices. **Why:** The law requires these reverse-charge supplies to be documented in their own series; mixing them with other invoices breaks that requirement. **Applies to:** invoice types `STANDARD`; Supplies of silver, platinum, palladium, mobile phones, game consoles, laptops or tablets where the buyer is liable for VAT. **Legal basis:** - Ley 37/1992 del IVA, art. 84.Uno.2.º g) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «Las entregas de dichos bienes, en los casos en que sean sujetos pasivos del Impuesto sus destinatarios conforme a lo establecido en este número 2.°, deberán documentarse en una factura mediante serie especial.» - RD 1619/2012 (Reglamento de facturación), art. 6.1.a) 4.º — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «4.º Las que se expidan conforme a lo previsto en el artículo 84, apartado uno, número 2.º, letra g), de la Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido.» **Incorrect:** Invoicing a batch of laptops to a reseller in the same series as the rest of your sales. **Correct:** Creating a series such as `ISP-G` and issuing those invoices in it. **Related:** [NUM-004 · Separate series may be used when there is a reason for them](/rules/numbering#num-004) · [TAX-002 · Reverse-charge operations are invoiced without charging VAT](/rules/taxes#tax-002) · [CNT-012 · A reverse-charge invoice carries the mention «inversión del sujeto pasivo»](/rules/contents#cnt-012) [← All rules](/rules#all-rules) ## Related - [Series and numbering](/guides/series-and-numbering) — when an invoice gets its number, how the format and counter resets work, default series per document type, and why a series locks once it has issued --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # Invoice contents What every invoice has to say: when one is due, who the parties are, how operations and taxes are shown, and the mentions some operations require. [← All rules](/rules#all-rules) The content of an invoice is fixed by law, and much of it comes from data you send: the recipient, the lines and how each line is classified. BeeL. fills in the issuer's data and computes the taxes; these rules say what the rest must contain. 25 rules: 22 from the law, 2 AEAT criteria, 1 BeeL. rule. [How to read a rule](/rules#how-to-read-a-rule). ## CNT-001 · Every operation of the business is invoiced, exempt ones included `Required` · Law · Impact: medium · Responsibility: the issuing business. Issue an invoice, full or simplified, for every supply of goods or services the business makes, including operations that are not subject to VAT or are exempt, except where the invoicing regulation says one is not needed. **Why:** A missing invoice is a breach of the invoicing obligation in itself, whatever tax it would have carried. **Applies to:** Every supply of goods or services made in the course of business. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 2.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a2-2) > «los empresarios o profesionales están obligados a expedir factura y copia de esta por las entregas de bienes y prestaciones de servicios que realicen en el desarrollo de su actividad, incluidas las no sujetas y las sujetas pero exentas del Impuesto» **Incorrect:** Leaving a course taught to a customer out of the books because it is exempt from VAT. **Correct:** Invoicing the course with a line classified as exempt, so the invoice states the exemption. **Related:** [CNT-002 · A business customer always gets an invoice, identifying it when asked](/rules/contents#cnt-002) · [CNT-010 · An exempt operation states why it is exempt](/rules/contents#cnt-010) · [CNT-023 · Some operations are always invoiced, whoever the customer](/rules/contents#cnt-023) **Explained in:** [Tax classification per line › The four families](/verifactu/tax-classification#the-four-families) ## CNT-002 · A business customer always gets an invoice, identifying it when asked `Required` · Law · Impact: medium · Responsibility: the issuing business. When the recipient is a business or professional acting as such, or asks for an invoice to exercise a tax right, the operation is always invoiced. When that recipient asks for it, the invoice carries its NIF and address and shows the tax separately: a full invoice, or a simplified one completed with those details. In BeeL., that is a standard invoice ([SIM-006](/rules/simplified#sim-006)). **Why:** Without an invoice the issuer breaches its invoicing obligation, and without the recipient's details and the tax shown apart the customer cannot deduct the VAT. **Applies to:** invoice types `STANDARD`, `SIMPLIFIED`; The recipient is a business or professional acting as such, or asks for an invoice to exercise a tax right. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 2.2.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a2-2) > «Aquellas en las que el destinatario sea un empresario o profesional que actúe como tal, con independencia del régimen de tributación al que se encuentre acogido el empresario o profesional que realice la operación, así como cualesquiera otras en las que el destinatario así lo exija para el ejercicio de cualquier derecho de naturaleza tributaria.» - RD 1619/2012 (Reglamento de facturación), art. 7.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a7) > «cuando el destinatario de la operación sea un empresario o profesional y así lo exija, el expedidor de la factura simplificada deberá hacer constar, además, los siguientes datos: a) Número de Identificación Fiscal atribuido por la Administración tributaria española o, en su caso, por la de otro Estado miembro de la Unión Europea, así como el domicilio del destinatario de las operaciones. b) La cuota tributaria que, en su caso, se repercuta, que deberá consignarse por separado.» **Incorrect:** Selling to a company at the counter and refusing to put its NIF and address on the invoice when it asks for them. **Correct:** Issuing the invoice with the company's legal name, NIF and address; in BeeL., as a `STANDARD` invoice ([SIM-006](/rules/simplified#sim-006)). **Related:** [CNT-005 · A full invoice identifies the recipient by NIF](/rules/contents#cnt-005) · [SIM-006 · An identified customer gets a standard invoice (F1)](/rules/simplified#sim-006) · [SIM-009 · A customer who asks to be identified gets an invoice that identifies it](/rules/simplified#sim-009) **Explained in:** [Simplified vs standard (F1 vs F2) › On the F1 path](/verifactu/simplified-vs-standard#on-the-f1-path) ## CNT-003 · A full invoice names both parties by their legal name `Required` · Law · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. A full invoice shows the full name or legal name of the issuer and of the recipient. Send the recipient's `legal_name`, not a trade name; BeeL. takes the issuer's from the company's tax profile and, while that profile is incomplete, refuses to issue with [`EMISSION_NOT_READY`](/errors/EMISSION_NOT_READY), listing [`PROFILE_INCOMPLETE`](/errors/PROFILE_INCOMPLETE) among its blockers. **Why:** The legal name is what identifies each party for tax purposes; a trade name alone does not. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice) **Error codes:** [`RECIPIENT_FISCAL_NAME_REQUIRED`](/errors/RECIPIENT_FISCAL_NAME_REQUIRED) (`422`), [`EMISSION_NOT_READY`](/errors/EMISSION_NOT_READY) (`422`), [`PROFILE_INCOMPLETE`](/errors/PROFILE_INCOMPLETE) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.c) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «Nombre y apellidos, razón o denominación social completa, tanto del obligado a expedir factura como del destinatario de las operaciones.» **Incorrect:** Sending only the shop name the customer trades under. ```json { "recipient": { "trade_name": "Café Central", "nif": "B12345674", "address": { "street": "Calle Mayor 1", "postal_code": "28013", "city": "Madrid", "province": "Madrid" } } } ``` **Correct:** Sending the legal name as registered, with the trade name as an extra. ```json { "recipient": { "legal_name": "Cafeterías Centrales SL", "trade_name": "Café Central", "nif": "B12345674", "address": { "street": "Calle Mayor 1", "postal_code": "28013", "city": "Madrid", "province": "Madrid" } } } ``` **Related:** [CNT-004 · Every invoice shows the issuer's NIF](/rules/contents#cnt-004) · [CNT-005 · A full invoice identifies the recipient by NIF](/rules/contents#cnt-005) · [CNT-006 · A full invoice shows the address of both parties](/rules/contents#cnt-006) **Explained in:** [Simplified vs standard (F1 vs F2) › On the F1 path](/verifactu/simplified-vs-standard#on-the-f1-path) ## CNT-004 · Every invoice shows the issuer's NIF `Required` · Law · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. Every invoice carries the NIF the issuer operates with. BeeL. takes it from the issuing company's profile: without it no invoice is created or issued ([`COMPANY_NIF_MISSING`](/errors/COMPANY_NIF_MISSING)), whatever the path (API, dashboard, recurring invoice, payment integration), and VeriFactu cannot be enabled for the company. **Why:** The issuer's NIF is what AEAT files the invoice and its record under. **Applies to:** invoice types `STANDARD`, `SIMPLIFIED`, `CORRECTIVE`; operations [`PUT /v1/companies/{company_id}/verifactu-configuration`](/verifactu/updateCompanyVeriFactuConfiguration), [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice) **Error codes:** [`COMPANY_NIF_MISSING`](/errors/COMPANY_NIF_MISSING) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.d) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «Número de Identificación Fiscal atribuido por la Administración tributaria española o, en su caso, por la de otro Estado miembro de la Unión Europea, con el que ha realizado la operación el obligado a expedir la factura.» **Incorrect:** Enabling VeriFactu for a company whose NIF was never set in its profile: the API answers [`COMPANY_NIF_MISSING`](/errors/COMPANY_NIF_MISSING). **Correct:** Completing the company's NIF before its first invoice; each NIF issues through its own company. **Related:** [CNT-003 · A full invoice names both parties by their legal name](/rules/contents#cnt-003) · [REC-005 · One chain per NIF, one company per NIF](/rules/records#rec-005) **Explained in:** [Compliance and responsibilities › The issuing business](/verifactu/compliance-and-responsibilities#the-issuing-business) ## CNT-005 · A full invoice identifies the recipient by NIF `Required` · Law · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. Send the recipient's NIF, or an alternative identifier for a customer without a Spanish NIF, on every standard invoice. The NIF is mandatory by law for exempt intra-EU supplies of goods, reverse-charge operations and operations located in Spain by an issuer established here. **Why:** Without the recipient's identification the invoice does not meet the legal content, and the customer cannot deduct its VAT. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice) **Error codes:** [`RECIPIENT_ID_REQUIRED`](/errors/RECIPIENT_ID_REQUIRED) (`422`), [`EXEMPTION_REQUIRES_RECIPIENT_ID_TYPE`](/errors/EXEMPTION_REQUIRES_RECIPIENT_ID_TYPE) (`400`) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.d) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «Asimismo, será obligatoria la consignación del Número de Identificación Fiscal del destinatario en los siguientes casos: 1.º Que se trate de una entrega de bienes destinados a otro Estado miembro que se encuentre exenta conforme al artículo 25 de la Ley del Impuesto. 2.º Que se trate de una operación cuyo destinatario sea el sujeto pasivo del Impuesto correspondiente a aquélla. 3.º Que se trate de operaciones que se entiendan realizadas en el territorio de aplicación del Impuesto y el empresario o profesional obligado a la expedición de la factura haya de considerarse establecido en dicho territorio.» **Incorrect:** Creating a standard invoice for a Spanish company with only its name and address: it is rejected with [`RECIPIENT_ID_REQUIRED`](/errors/RECIPIENT_ID_REQUIRED). **Correct:** Sending the company's NIF with its legal name and address. ```json { "type": "STANDARD", "recipient": { "legal_name": "Cafeterías Centrales SL", "nif": "B12345674", "address": { "street": "Calle Mayor 1", "postal_code": "28013", "city": "Madrid", "province": "Madrid" } } } ``` **Related:** [CNT-020 · A Spanish recipient's NIF is in the AEAT census](/rules/contents#cnt-020) · [CNT-021 · A recipient without a Spanish NIF is identified by an alternative id](/rules/contents#cnt-021) · [TAX-004 · Intra-EU supplies of goods are exempt only with the buyer's EU VAT number](/rules/taxes#tax-004) **Explained in:** [Simplified vs standard (F1 vs F2) › On the F1 path](/verifactu/simplified-vs-standard#on-the-f1-path) · [International customers › Identifying foreign customers](/verifactu/international-customers#identifying-foreign-customers) ## CNT-006 · A full invoice shows the address of both parties `Required` · Law · Impact: medium · Responsibility: your integration. The API also answers the error codes listed. A full invoice shows the address of the issuer and of the recipient. Send the recipient's fiscal address, on a recipient sent inline and on the customers you store. **Why:** The address is part of the legal content of a full invoice; an invoice without the recipient's address is incomplete and has to be corrected. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`POST /v1/companies/{company_id}/customers`](/customers/createCompanyCustomer) **Error codes:** [`RECIPIENT_ADDRESS_REQUIRED`](/errors/RECIPIENT_ADDRESS_REQUIRED) (`422`), [`EMISSION_NOT_READY`](/errors/EMISSION_NOT_READY) (`422`), [`PROFILE_INCOMPLETE`](/errors/PROFILE_INCOMPLETE) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.e) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «Domicilio, tanto del obligado a expedir factura como del destinatario de las operaciones.» **Incorrect:** Invoicing a customer stored without an address. **Correct:** Completing the customer's address before invoicing it, or sending the recipient inline with its `address`. **Related:** [CNT-003 · A full invoice names both parties by their legal name](/rules/contents#cnt-003) · [CNT-005 · A full invoice identifies the recipient by NIF](/rules/contents#cnt-005) **Explained in:** [Simplified vs standard (F1 vs F2) › On the F1 path](/verifactu/simplified-vs-standard#on-the-f1-path) ## CNT-007 · Each line describes the operation, its unit price and any discount `Required` · Law · Impact: medium · Responsibility: your integration. The API also answers the error codes listed. Describe each operation with the data needed to work out its taxable base: a meaningful description, the unit price without tax, and any discount not already included in that price. Send the discount as `discount_percentage` rather than folding it into the price. **Why:** A line that does not say what was supplied or at what price does not let anyone check the taxable base. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice) **Error codes:** [`LINE_NORMAL_DESCRIPTION_REQUIRED`](/errors/LINE_NORMAL_DESCRIPTION_REQUIRED), [`LINE_INVALID_DISCOUNT`](/errors/LINE_INVALID_DISCOUNT) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.f) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «Descripción de las operaciones, consignándose todos los datos necesarios para la determinación de la base imponible del Impuesto, tal y como ésta se define por los artículos 78 y 79 de la Ley del Impuesto, correspondiente a aquéllas y su importe, incluyendo el precio unitario sin Impuesto de dichas operaciones, así como cualquier descuento o rebaja que no esté incluido en dicho precio unitario.» **Incorrect:** A single line described as `Services` with the discount already subtracted from the price. **Correct:** A line that says what was supplied, with its net unit price and the discount apart. ```json { "description": "Website maintenance, September 2026", "quantity": 1, "unit_price": 500, "discount_percentage": 10, "main_tax": { "type": "IVA", "percentage": 21 } } ``` **Related:** [CNT-008 · The tax rate and the tax amount are shown apart from the base](/rules/contents#cnt-008) · [CNT-009 · The base is broken down by rate and by kind of operation](/rules/contents#cnt-009) **Explained in:** [Amounts and rounding › Three ways to price a line](/guides/amounts-and-rounding#three-ways-to-price-a-line) ## CNT-008 · The tax rate and the tax amount are shown apart from the base `Required` · Law · Impact: medium · Checked by the API: BeeL. applies it. A full invoice states the tax rate applied and the tax amount charged, separately from the taxable base. You choose the rate of each line; BeeL. computes the tax amount of each rate and shows it apart from the base. **Why:** The VAT charged is what the customer deducts; it has to be readable on its own, next to the rate it comes from. **Applies to:** invoice types `STANDARD`, `CORRECTIVE` **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.g) y h) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «El tipo impositivo o tipos impositivos, en su caso, aplicados a las operaciones. h) La cuota tributaria que, en su caso, se repercuta, que deberá consignarse por separado.» - Ley 37/1992 del IVA, art. 88.Dos — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a88) > «A estos efectos, la cuota repercutida se consignará separadamente de la base imponible, incluso en el caso de precios fijados administrativamente, indicando el tipo impositivo aplicado.» **Incorrect:** Sending a line with a price that already includes VAT as if it were the net price, so the base and the tax amount on the invoice are wrong. **Correct:** Sending the net price with its `main_tax`, or pricing the line with `total_including_tax` so BeeL. works the base and the tax out of the total. **Related:** [CNT-009 · The base is broken down by rate and by kind of operation](/rules/contents#cnt-009) · [TAX-001 · Apply the VAT rate in force when the operation took place](/rules/taxes#tax-001) · [REC-012 · Tax amounts are base times rate](/rules/records#rec-012) **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) ## CNT-009 · The base is broken down by rate and by kind of operation `Required` · Law · Impact: low · Checked by the API: BeeL. applies it. When one invoice mixes exempt and taxed operations, reverse-charge and ordinary operations, or different VAT rates, the taxable base is shown separately for each. Classify every line on its own; BeeL. groups the breakdown from those classifications. **Why:** Each part of the base is taxed differently; lumped together, the invoice does not say how much is exempt or at which rate. **Applies to:** invoice types `STANDARD`, `SIMPLIFIED`, `CORRECTIVE` **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «Deberá especificarse por separado la parte de base imponible correspondiente a cada una de las operaciones que se documenten en una misma factura en los siguientes casos:» **Incorrect:** Putting an exempt training course and taxed materials on one line at 21 %. **Correct:** Two lines: the course classified as exempt and the materials at 21 %, each with its own `main_tax`. **Related:** [CNT-008 · The tax rate and the tax amount are shown apart from the base](/rules/contents#cnt-008) · [CNT-010 · An exempt operation states why it is exempt](/rules/contents#cnt-010) **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) ## CNT-010 · An exempt operation states why it is exempt `Required` · Law · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. An invoice for an exempt operation refers to the article of the VAT law or of Directive 2006/112/CE that exempts it, or states that it is exempt. Give every 0 % line its `exemption_reason`, and an `exemption_reason_text` when the reason is `OTRO`. **Why:** Without the reference, a 0 % line reads as a missing tax, not as an exemption. **Applies to:** invoice types `STANDARD`, `SIMPLIFIED`, `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice) **Error codes:** [`EXEMPT_ZERO_RATE_REQUIRES_REASON`](/errors/EXEMPT_ZERO_RATE_REQUIRES_REASON) (`422`), [`LINE_EXEMPTION_TEXT_REQUIRED`](/errors/LINE_EXEMPTION_TEXT_REQUIRED) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.j) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «En el supuesto de que la operación que se documenta en una factura esté exenta del Impuesto, una referencia a las disposiciones correspondientes de la Directiva 2006/112/CE, de 28 de noviembre, relativa al sistema común del Impuesto sobre el Valor Añadido, o a los preceptos correspondientes de la Ley del Impuesto o indicación de que la operación está exenta.» **Incorrect:** A line at 0 % with no exemption reason: it is rejected with [`EXEMPT_ZERO_RATE_REQUIRES_REASON`](/errors/EXEMPT_ZERO_RATE_REQUIRES_REASON). **Correct:** An educational service exempt under article 20 of the VAT law. ```json { "description": "English course, level B2", "quantity": 1, "unit_price": 300, "main_tax": { "type": "IVA", "percentage": 0 }, "exemption_reason": "EXENTA_ART_20" } ``` **Related:** [CNT-001 · Every operation of the business is invoiced, exempt ones included](/rules/contents#cnt-001) · [CNT-009 · The base is broken down by rate and by kind of operation](/rules/contents#cnt-009) · [TAX-005 · Exempt and non-subject lines carry no VAT rate](/rules/taxes#tax-005) **Explained in:** [Tax classification per line › Mapping table: BeeL. API value ↔ AEAT code](/verifactu/tax-classification#mapping-table-beel-api-value--aeat-code) · [Tax classification per line › Exempt educational service (E1)](/verifactu/tax-classification#exempt-educational-service-e1) ## CNT-011 · Only one original of each invoice exists `Required` · Law · Impact: medium · Responsibility: the issuing business. Issue a single original of each invoice. A duplicate is allowed only when the same operation has several recipients or the original was lost, and every duplicate carries the word «duplicado». **Why:** Two originals of one invoice look like two operations to the customer and to an inspection. **Applies to:** Copies handed over after issue. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 14.1, 14.2 y 14.4 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a14) > «1. Los empresarios y profesionales o sujetos pasivos sólo podrán expedir un original de cada factura. [...] 4. En cada uno de los ejemplares duplicados deberá hacerse constar la expresión «duplicado».» **Incorrect:** Issuing the same sale again as a new invoice because the customer lost the first one. **Correct:** Sending the customer the PDF of the original again, marked «duplicado» if you hand it over as a duplicate. **Related:** [LIF-005 · Duplicating an invoice creates a new one, not a copy](/rules/lifecycle#lif-005) · [NUM-002 · An issued number is never reused, even when the invoice is voided](/rules/numbering#num-002) · [CNT-024 · A duplicate for several recipients shows each one's share](/rules/contents#cnt-024) **Explained in:** [Invoice lifecycle › Duplicating an invoice](/guides/invoice-lifecycle#duplicating-an-invoice) ## CNT-012 · A reverse-charge invoice carries the mention «inversión del sujeto pasivo» `Required` · Law · Impact: high · Checked by the API: BeeL. applies it. When the recipient is the one liable for the VAT, the invoice carries the mention «inversión del sujeto pasivo», on any document of it, one you render included. Classify those lines as reverse charge: BeeL. then prints the mention on the invoice's PDF, in a block of its own apart from the exemptions. **Why:** The mention is what tells the recipient that it has to self-assess the VAT; without it the invoice reads as if VAT had been left out by mistake. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; Operations in which the recipient is liable for the VAT (reverse charge). **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.m) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «En el caso de que el sujeto pasivo del Impuesto sea el adquirente o el destinatario de la operación, la mención «inversión del sujeto pasivo».» **Incorrect:** Invoicing construction work for a developer at 0 % VAT with no mention of who pays the tax. **Correct:** Classifying the line as reverse charge, so the invoice states «inversión del sujeto pasivo». ```json { "description": "Building work, phase 2", "quantity": 1, "unit_price": 12000, "main_tax": { "type": "IVA", "percentage": 0 }, "exemption_reason": "ISP_ART_84_2_F" } ``` **Related:** [TAX-002 · Reverse-charge operations are invoiced without charging VAT](/rules/taxes#tax-002) · [TAX-003 · Reverse-charge lines carry no tax and never go on a simplified invoice](/rules/taxes#tax-003) · [NUM-009 · Reverse-charge supplies of metals and electronics go in a special series](/rules/numbering#num-009) **Explained in:** [Tax classification per line › Reverse charge (inversión del sujeto pasivo, S2)](/verifactu/tax-classification#inversión-del-sujeto-pasivo-s2) ## CNT-013 · A cash-basis invoice carries the mention «régimen especial del criterio de caja» `Required` · Law · Impact: medium · Checked by the API: BeeL. applies it. Invoices for operations under the special cash-basis regime carry the mention «régimen especial del criterio de caja», on any document of the invoice. BeeL. prints it on the invoice's PDF, once, after the exemptions, when a line carries regime key `07`; a document you render yourself has to carry it too. **Why:** The mention tells the recipient that the VAT accrues on payment, which changes when it can deduct it. **Applies to:** invoice types `STANDARD`, `SIMPLIFIED`, `CORRECTIVE`; IVA lines with regime key `07` (cash basis). **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.p) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «En el caso de aplicación del régimen especial del criterio de caja la mención «régimen especial del criterio de caja.» **Incorrect:** An invoice under the cash-basis regime whose document says nothing about the regime. **Correct:** An invoice under the cash-basis regime (regime key `07`) that carries the mention «régimen especial del criterio de caja». **Related:** [TAX-016 · Regime keys 03, 06 and 14 are not accepted](/rules/taxes#tax-016) · [CNT-014 · A used-goods, art or antiques invoice carries its regime mention](/rules/contents#cnt-014) · [CNT-015 · A travel-agency invoice carries the mention «régimen especial de las agencias de viajes»](/rules/contents#cnt-015) **Explained in:** [Regime keys › "07" — Cash-basis IVA (criterio de caja)](/verifactu/regime-keys#07--cash-basis-iva-criterio-de-caja) ## CNT-014 · A used-goods, art or antiques invoice carries its regime mention `Required` · Law · Impact: medium · Responsibility: the issuing business. Invoices under the special regime for used goods, works of art, antiques and collectors' items carry the corresponding regime mention, and do not show the VAT separately: it is included in the price. **Why:** Under this regime the VAT is charged on the margin; showing it apart, or omitting the mention, misstates the tax to the buyer. **Applies to:** Operations under the special regime for used goods, works of art, antiques and collectors' items (regime key 03). **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.o) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «En caso de aplicación del régimen especial de los bienes usados, objetos de arte, antigüedades y objetos de colección, la mención «régimen especial de los bienes usados», «régimen especial de los objetos de arte» o «régimen especial de las antigüedades y objetos de colección».» - Ley 37/1992 del IVA, art. 138 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a138) > «En las facturas que documenten las operaciones a que resulte aplicable este régimen especial, los sujetos pasivos no podrán consignar separadamente la cuota repercutida, debiendo entenderse ésta comprendida en el precio total de la operación.» **Incorrect:** Selling a second-hand car under the margin regime with the VAT broken out on the invoice. **Correct:** Invoicing it under regime key 03 with the mention «régimen especial de los bienes usados» and the VAT included in the price. **Related:** [CNT-013 · A cash-basis invoice carries the mention «régimen especial del criterio de caja»](/rules/contents#cnt-013) · [CNT-015 · A travel-agency invoice carries the mention «régimen especial de las agencias de viajes»](/rules/contents#cnt-015) **Explained in:** [Regime keys › "03" — REBU (used goods, art, antiques)](/verifactu/regime-keys#03--rebu-used-goods-art-antiques) ## CNT-015 · A travel-agency invoice carries the mention «régimen especial de las agencias de viajes» `Required` · Law · Impact: low · Checked by the API: BeeL. applies it. Invoices for operations under the special regime for travel agencies carry the mention «régimen especial de las agencias de viajes», on any document of the invoice. BeeL. prints it on the invoice's PDF, once, after the exemptions, when a line carries regime key `05`; a document you render yourself has to carry it too. **Why:** The mention tells the customer that the VAT is charged on the agency's margin, not on the full price. **Applies to:** invoice types `STANDARD`, `SIMPLIFIED`, `CORRECTIVE`; IVA lines with regime key `05` (travel agencies). **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.n) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «En caso de aplicación del régimen especial de las agencias de viajes, la mención «régimen especial de las agencias de viajes».» **Incorrect:** Invoicing a package holiday under the travel-agency regime with no mention of the regime. **Correct:** Invoicing it with the mention «régimen especial de las agencias de viajes» on the invoice. **Related:** [CNT-013 · A cash-basis invoice carries the mention «régimen especial del criterio de caja»](/rules/contents#cnt-013) · [CNT-014 · A used-goods, art or antiques invoice carries its regime mention](/rules/contents#cnt-014) **Explained in:** [Regime keys › The catalogue](/verifactu/regime-keys#the-catalogue) ## CNT-016 · An intra-EU supply of a new means of transport describes the vehicle `Required` · Law · Impact: low · Responsibility: the issuing business. An invoice for the intra-EU supply of a new means of transport states its characteristics, the date it first entered service, and the distance or hours travelled until delivery. Put these in the line description. **Why:** These data are what make the vehicle count as new, which decides where its VAT is paid. **Applies to:** Supplies of new means of transport to another EU Member State. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.k) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «En las entregas de medios de transporte nuevos a que se refiere el artículo 25 de la Ley del Impuesto, sus características, la fecha de su primera puesta en servicio y las distancias recorridas u horas de navegación o vuelo realizadas hasta su entrega.» **Incorrect:** A line that says only `Motorbike`. **Correct:** A line that says `Motorbike, 125 cc, first registered 2026-08-01, 150 km at delivery`. **Related:** [TAX-004 · Intra-EU supplies of goods are exempt only with the buyer's EU VAT number](/rules/taxes#tax-004) ## CNT-017 · An invoice may be in any language `Recommended` · Law · Impact: low · Responsibility: the issuing business. You may issue an invoice in any language. Keep the means to produce a Spanish version, because AEAT may ask for a translation of an invoice in a language that is not official in Spain. **Why:** In a tax inspection AEAT may require a translation into Spanish, or into another official language in Spain, of an invoice issued in a language that is not official here. **Applies to:** The language of the invoice document. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 12.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a12) > «Las facturas podrán expedirse en cualquier lengua. No obstante, la Administración tributaria, cuando lo considere necesario [...] podrá exigir una traducción al castellano, o a otra lengua oficial en España, de las facturas expedidas en una lengua no oficial» **Incorrect:** Assuming an English-only invoice can never be asked for in Spanish. **Correct:** Issuing in English for a foreign customer, knowing the PDF can also be produced in Spanish. **Explained in:** [Branding and PDFs › Choose template, colour and languages](/guides/branding-and-pdf#choose-template-colour-and-languages) ## CNT-018 · Invoices go by email only with the recipient's consent `Required` · Law · Impact: low · Responsibility: the issuing business. Send invoices electronically only to recipients who have agreed to receive them that way, except where electronic invoicing is mandatory. Record that consent in your own system before emailing invoices. **Why:** An electronic invoice sent without consent does not count as delivered in the form the law allows. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/send`](/invoices/sendCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/deliveries`](/invoices/createCompanyInvoiceDelivery); Electronic delivery of invoices. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 9.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a9) > «La expedición, transmisión y recepción de la factura electrónica estará condicionada a que su destinatario haya dado su consentimiento, excepto en los supuestos de factura electrónica obligatoria establecidos en el artículo 8 bis.» **Incorrect:** Emailing invoices to every customer on file without having asked them. **Correct:** Asking at sign-up whether the customer accepts invoices by email, and emailing only those who do. **Related:** [DAT-008 · Deliver the invoice to the customer in time](/rules/dates#dat-008) **Explained in:** [Sending email › Recipients](/guides/sending-email#recipients) ## CNT-019 · Only a corrective invoice totals less than zero `Required` · BeeL. rule · Impact: critical · Checked by the API: a request that breaks it is rejected with the error codes listed. Do not use a standard or simplified invoice with a negative total as a credit note. A refund or a reduction is a corrective invoice against the original. An invoice that totals zero is valid. **Why:** A negative ordinary invoice is a correction without the link to the invoice it corrects. **Applies to:** invoice types `STANDARD`, `SIMPLIFIED`; operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice) **Error codes:** [`NEGATIVE_TOTAL_REQUIRES_RECTIFICATIVE`](/errors/NEGATIVE_TOTAL_REQUIRES_RECTIFICATIVE) (`422`) **Incorrect:** Creating a `STANDARD` invoice whose only line has `quantity: -1`, to refund a customer: it is rejected with [`NEGATIVE_TOTAL_REQUIRES_RECTIFICATIVE`](/errors/NEGATIVE_TOTAL_REQUIRES_RECTIFICATIVE). ```json { "type": "STANDARD", "lines": [{ "description": "Refund", "quantity": -1, "unit_price": 100, "main_tax": { "type": "IVA", "percentage": 21 } }] } ``` **Correct:** Issuing a partial corrective against the invoice being refunded. ```http POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective { "rectification_type": "PARTIAL", "rectification_code": "R1", "reason": "Refund of one unit returned by the customer", "lines": [{ "description": "Returned unit", "quantity": -1, "unit_price": 100, "main_tax": { "type": "IVA", "percentage": 21 } }] } ``` **Related:** [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [COR-012 · Returns can be netted only on a later supply to the same customer](/rules/corrective#cor-012) **Explained in:** [Amounts and rounding › Amounts that are rejected](/guides/amounts-and-rounding#amounts-that-are-rejected) ## CNT-020 · A Spanish recipient's NIF is in the AEAT census `Recommended` · AEAT criterion · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. Check a Spanish customer's NIF against the AEAT census before invoicing it. With VeriFactu enabled, BeeL. checks it with AEAT when you issue and refuses a NIF that AEAT reports as not in the census or revoked, before any number is spent; that check depends on AEAT's census service answering, so validate the NIF when the customer signs up. **Why:** AEAT accepts a record whose recipient is not in the census only as an error that has to be fixed later; a revoked NIF cannot operate at all. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/nif/validate`](/nif-validation/validateNif); VeriFactu enabled. **Error codes:** [`NIF_NOT_IN_CENSUS`](/errors/NIF_NOT_IN_CENSUS) (`422`), [`NIF_REVOCADO`](/errors/NIF_REVOCADO) (`422`) **Legal basis:** - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 4.3.1 Tratamiento de los errores en remisión voluntaria VERI*FACTU — [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. [...] Los NIF informados en la agrupación Destinatario que sean correctos, pero no figuren censados en la AEAT, indicando el tipo de identificación “07” (“No censado”) en el campo “IDType” dentro del bloque “IDOtro”.» **Incorrect:** Issuing to a customer whose NIF and legal name do not match the census: it is rejected with [`NIF_NOT_IN_CENSUS`](/errors/NIF_NOT_IN_CENSUS). **Correct:** Validating the NIF when the customer signs up, and correcting the legal name or NIF before the first invoice. ```http POST /v1/nif/validate ``` **Related:** [CNT-005 · A full invoice identifies the recipient by NIF](/rules/contents#cnt-005) · [CNT-021 · A recipient without a Spanish NIF is identified by an alternative id](/rules/contents#cnt-021) · [REC-009 · Check the data AEAT accepted with errors](/rules/records#rec-009) **Explained in:** [Handling AEAT rejections › Recipient data — fix the invoice](/verifactu/handling-rejections#recipient-data--fix-the-invoice) ## CNT-021 · A recipient without a Spanish NIF is identified by an alternative id `Required` · AEAT criterion · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. Identify a recipient without a Spanish NIF with an `alternative_id` of the type that fits (EU VAT number, passport, official ID, residence certificate, other document or not registered) and its country, never together with a `nif`. The country can be omitted only for a passport or the not-registered type, which then take `ES`. With country `ES`, only a passport or the not-registered type is accepted. An EU VAT number (`NIF_IVA`) is accepted only with the country of another EU Member State and in that State's VAT number format: its country prefix (`EL` for Greece) followed by the national number, in capital letters and without spaces, as in `FR40303265045`. A Spanish NIF is never sent as an EU VAT number; a customer from outside the EU is identified with another type. A corrective invoice other than `R5` carries the recipient of the invoice it corrects and is held to the same rule: if that recipient does not meet it, first correct its data with an `R4` corrective that carries the corrected recipient. **Why:** AEAT identifies each recipient either by NIF or by this identifier, never both, and rejects combinations its validations do not allow, including an EU VAT number that is not from a Member State or does not have that State's structure. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice), [`POST /v1/companies/{company_id}/customers`](/customers/createCompanyCustomer), [`PATCH /v1/companies/{company_id}/customers/{customer_id}`](/customers/patchCompanyCustomer), [`POST /v1/companies/{company_id}/recurring-invoices`](/recurring-invoices/createCompanyRecurringInvoice) **Error codes:** [`RECIPIENT_NIF_AND_ID_OTHER_EXCLUSIVE`](/errors/RECIPIENT_NIF_AND_ID_OTHER_EXCLUSIVE), [`ALTERNATIVE_ID_SPAIN_INVALID_TYPE`](/errors/ALTERNATIVE_ID_SPAIN_INVALID_TYPE) (`422`), [`RECIPIENT_UNREGISTERED_ID_MUST_BE_DNI_OR_NIE`](/errors/RECIPIENT_UNREGISTERED_ID_MUST_BE_DNI_OR_NIE), [`ALTERNATIVE_ID_VAT_REQUIRES_EU_COUNTRY`](/errors/ALTERNATIVE_ID_VAT_REQUIRES_EU_COUNTRY) (`422`), [`ALTERNATIVE_ID_VAT_INVALID_FORMAT`](/errors/ALTERNATIVE_ID_VAT_INVALID_FORMAT) (`422`), [`ALTERNATIVE_ID_COUNTRY_REQUIRED`](/errors/ALTERNATIVE_ID_COUNTRY_REQUIRED) (`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 se cumplimenta NIF, no deberá existir la agrupación IDOtro y viceversa, pero es obligatorio que se cumplimente uno de los dos.» - 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) > «Cuando uno o varios destinatarios se identifiquen a través de la agrupación IDOtro y CodigoPais sea "ES", se validará que el campo IDType sea “03” o “07”.» - 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) > «Cuando uno o varios destinatarios se identifiquen a través de la agrupación IDOtro e IDType sea “02”, se validará que el campo identificador se ajuste a la estructura de NIF-IVA de alguno de los Estados Miembros y debe estar identificado. Ver nota (1).» - Orden HAC/1177/2024, anexo, lista L7 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138) > «02 NIF-IVA. 03 Pasaporte. 04 Documento oficial de identificación expedido por el país o territorio de residencia. 05 Certificado de residencia. 06 Otro documento probatorio. 07 No censado.» **Incorrect:** Sending a Spanish NIF in `nif` together with an `alternative_id`: it is rejected with [`RECIPIENT_NIF_AND_ID_OTHER_EXCLUSIVE`](/errors/RECIPIENT_NIF_AND_ID_OTHER_EXCLUSIVE). ```json { "recipient": { "legal_name": "Dupont SARL", "nif": "B12345674", "alternative_id": { "type": "NIF_IVA", "number": "FR40303265045", "country_code": "FR" } } } ``` **Correct:** Sending only the alternative identifier, with its type and country. ```json { "recipient": { "legal_name": "Dupont SARL", "alternative_id": { "type": "NIF_IVA", "number": "FR40303265045", "country_code": "FR" }, "address": { "street": "12 rue de Rivoli", "postal_code": "75001", "city": "Paris", "province": "Paris", "country_code": "FR" } } } ``` **Related:** [CNT-005 · A full invoice identifies the recipient by NIF](/rules/contents#cnt-005) · [COR-017 · A corrective keeps the recipient, except to correct the recipient's data](/rules/corrective#cor-017) · [TAX-004 · Intra-EU supplies of goods are exempt only with the buyer's EU VAT number](/rules/taxes#tax-004) · [TAX-006 · Services to a business abroad are not subject to Spanish VAT](/rules/taxes#tax-006) **Explained in:** [International customers › Identifying foreign customers](/verifactu/international-customers#identifying-foreign-customers) · [Glossary › Alternative ID types (foreign customers)](/guides/glossary#alternative-id-types-foreign-customers) ## CNT-022 · Invoices to Spanish public administrations are electronic `Required` · Law · Impact: medium · Responsibility: the issuing business. A public limited company, a limited liability company or another entity listed in art. 4.1 of Ley 25/2013 that invoices a Spanish public administration issues an electronic invoice and files it through the general entry point that corresponds to that administration (FACe, for the State). Any other supplier may do the same. **Why:** For these suppliers the electronic invoice filed through the entry point is how the administration receives the invoice; a PDF by email does not meet the obligation. **Applies to:** Invoices to Spanish public administrations, issued by the entities listed in art. 4.1 of Ley 25/2013 (among them SA and SL companies). **Legal basis:** - Ley 25/2013 (factura electrónica en el Sector Público), art. 4.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2013-13722#a4) > «Todos los proveedores que hayan entregado bienes o prestado servicios a la Administración Pública podrán expedir y remitir factura electrónica. En todo caso, estarán obligadas al uso de la factura electrónica y a su presentación a través del punto general de entrada que corresponda, las entidades siguientes: a) Sociedades anónimas; b) Sociedades de responsabilidad limitada;» **Incorrect:** A limited company emailing a PDF invoice to a town council. **Correct:** The same company issuing an electronic invoice and filing it through the council's entry point. **Related:** [CNT-018 · Invoices go by email only with the recipient's consent](/rules/contents#cnt-018) · [DAT-012 · Plan for mandatory B2B electronic invoices](/rules/dates#dat-012) ## CNT-023 · Some operations are always invoiced, whoever the customer `Required` · Law · Impact: medium · Responsibility: the issuing business. Issue an invoice in every case for intra-EU supplies of goods exempt under art. 25 LIVA, distance sales of goods located in Spain under art. 68.Tres.a) and Cinco LIVA, exports of goods (except in duty-free shops), goods installed or assembled before delivery under art. 68.Dos.2.º LIVA, and any operation for a legal person not acting as a business or for a public administration. **Why:** For these operations the regulation removes every exception to the duty to invoice, even when the customer is not a business. **Applies to:** The operations listed in art. 2.2 b) to f) of the RD 1619/2012. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 2.2 b) a f) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a2-2) > «Deberá expedirse factura y copia de esta en todo caso en las siguientes operaciones: [...] b) Las entregas de bienes destinados a otro Estado miembro a que se refiere el artículo 25 de la Ley del Impuesto. [...] d) Las entregas de bienes expedidos o transportados fuera de la Comunidad Europea a que se refiere el artículo 21.1.º y 2.º de la Ley del Impuesto, excepto las efectuadas en las tiendas libres de impuestos [...] f) Aquellas de las que sean destinatarias personas jurídicas que no actúen como empresarios o profesionales» **Incorrect:** Exporting goods to a private buyer outside the EU and handing over only a delivery note. **Correct:** Invoicing the export, with the exemption stated on the invoice. **Related:** [CNT-001 · Every operation of the business is invoiced, exempt ones included](/rules/contents#cnt-001) · [CNT-002 · A business customer always gets an invoice, identifying it when asked](/rules/contents#cnt-002) · [TAX-004 · Intra-EU supplies of goods are exempt only with the buyer's EU VAT number](/rules/taxes#tax-004) ## CNT-024 · A duplicate for several recipients shows each one's share `Required` · Law · Impact: low · Responsibility: the issuing business. When one supply or service has several recipients and you hand each a copy of the invoice, the original and every duplicate state the share of the taxable base and of the tax that corresponds to each recipient, and every duplicate carries the word «duplicado». **Why:** Each recipient deducts only its own share; without it, the same tax could be deducted more than once. **Applies to:** One supply or service with several recipients, documented with an original and duplicates. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 14.2.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a14) > «a) Cuando en una misma entrega de bienes o prestación de servicios concurriesen varios destinatarios. En este caso, deberá consignarse en el original y en cada uno de los duplicados la porción de base imponible y de cuota repercutida a cada uno de ellos.» **Incorrect:** Handing two co-owners of a flat the same invoice for a renovation, each as an original, with the whole amount on both. **Correct:** One original and one duplicate, each stating the base and the VAT that falls to each co-owner. **Related:** [CNT-011 · Only one original of each invoice exists](/rules/contents#cnt-011) ## CNT-025 · State the establishment when it decides how the operation is taxed `Required` · Law · Impact: low · Responsibility: the issuing business. When the issuer or the recipient has several fixed places of business, the invoice states the location of the head office or establishment the operation relates to whenever that matters for how the operation is taxed. **Why:** Where a service is located can depend on which establishment receives it; the invoice has to show the one that decides the tax. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; Issuers or recipients with several fixed places of business. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.e), párrafo segundo — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «Cuando el obligado a expedir factura o el destinatario de las operaciones dispongan de varios lugares fijos de negocio, deberá indicarse la ubicación de la sede de actividad o establecimiento al que se refieran aquéllas en los casos en que dicha referencia sea relevante para la determinación del régimen de tributación correspondiente a las citadas operaciones.» **Incorrect:** Invoicing a service to a group's Spanish branch with only the address of its head office abroad. **Correct:** Invoicing it with the address of the Spanish branch that receives the service. **Related:** [CNT-006 · A full invoice shows the address of both parties](/rules/contents#cnt-006) · [TAX-006 · Services to a business abroad are not subject to Spanish VAT](/rules/taxes#tax-006) [← All rules](/rules#all-rules) ## Related - [Amounts and rounding](/guides/amounts-and-rounding) — how BeeL. turns quantities, prices and rates into bases, taxes and totals: precision, the three ways to price a line, per-group tax rounding, IRPF, and the amounts that are rejected - [Simplified vs standard (F1 vs F2)](/verifactu/simplified-vs-standard) — when BeeL. issues a simplified invoice (F2) or a standard invoice (F1), the rules of the RD 1619/2012 behind them, and what BeeL. enforces at the API boundary - [Tax classification per line](/verifactu/tax-classification) — set `exemption_reason` on each line correctly, with the full mapping from BeeL. API values to AEAT codes (S1/S2/N1/N2/E1–E6) - [Regime keys](/verifactu/regime-keys) — the catalogue of VeriFactu regime codes BeeL. supports, when each one is required, and how it pairs with `exemption_reason` --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # Simplified invoices When a simplified invoice (F2) may replace a full one, what it must carry and what it can never document. [← All rules](/rules#all-rules) A simplified invoice (factura simplificada, F2) is the ticket of a sale to an unidentified customer. The law caps its amount and excludes some operations; once the customer is identified on it, AEAT registers it as F1. 10 rules: 7 from the law, 2 AEAT criteria, 1 BeeL. rule. [How to read a rule](/rules#how-to-read-a-rule). ## SIM-001 · A simplified invoice never exceeds 3,000 € `Required` · AEAT criterion · Impact: critical · Checked by the API: a request that breaks it is rejected with the error codes listed. Do not issue a simplified invoice whose total, VAT included, is above 3,000 €. Above it, issue a standard invoice (F1) with the customer identified. **Why:** The law allows a simplified invoice up to that amount only for the operations of art. 4.2, or in other cases AEAT authorises (art. 4.3), and AEAT's validations reject an F2 record above it unless it carries a billing agreement. **Applies to:** invoice types `SIMPLIFIED`; operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice) **Error codes:** [`SIMPLIFIED_INVOICE_EXCEEDS_LEGAL_LIMIT`](/errors/SIMPLIFIED_INVOICE_EXCEEDS_LEGAL_LIMIT) (`400`) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 4.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a4) > «los empresarios o profesionales podrán igualmente expedir factura simplificada y copia de ésta cuando su importe no exceda de 3.000 euros, Impuesto sobre el Valor Añadido incluido, en las operaciones que se describen a continuación: a) Ventas al por menor» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.8 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Cuando TipoFactura sea “F2”, se validará que Ʃ (BaseImponibleOimporteNoSujeto + CuotaRepercutida) de todas las líneas de detalle no sea superior a 3.000,00 euros. [...] Esta validación no se aplicará cuando exista acuerdo de facturación» - RD 1619/2012 (Reglamento de facturación), art. 4.3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a4) > «El Departamento de Gestión Tributaria de la Agencia Estatal de Administración Tributaria podrá autorizar la expedición de facturas simplificadas, en supuestos distintos de los señalados en los apartados anteriores» **Incorrect:** A simplified invoice with one line of 2,600 € at 21 % VAT: it totals 3,146 € and the API answers [`SIMPLIFIED_INVOICE_EXCEEDS_LEGAL_LIMIT`](/errors/SIMPLIFIED_INVOICE_EXCEEDS_LEGAL_LIMIT). **Correct:** The same sale as a standard invoice, with the customer's NIF or `alternative_id`. **Related:** [SIM-002 · Above 400 €, a simplified invoice needs an art. 4.2 activity](/rules/simplified#sim-002) · [SIM-006 · An identified customer gets a standard invoice (F1)](/rules/simplified#sim-006) **Explained in:** [Simplified vs standard (F1 vs F2) › The decision in one table](/verifactu/simplified-vs-standard#the-decision-in-one-table) · [Simplified vs standard (F1 vs F2) › On the F2 path](/verifactu/simplified-vs-standard#on-the-f2-path) ## SIM-002 · Above 400 €, a simplified invoice needs an art. 4.2 activity `Required` · Law · Impact: high · Responsibility: the issuing business. Do not issue a simplified invoice above 400 €, VAT included, unless the operation is one of those listed in art. 4.2 (retail sales, hospitality, passenger transport and the rest of the list) or the invoice is a corrective. **Why:** Outside art. 4.2 the law only allows a simplified invoice up to that amount; above it the operation needed a full invoice. **Applies to:** invoice types `SIMPLIFIED` **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 4.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a4) > «La obligación de expedir factura podrá ser cumplida mediante la expedición de factura simplificada y copia de esta en cualquiera de los siguientes supuestos: a) Cuando su importe no exceda de 400 euros, Impuesto sobre el Valor Añadido incluido, o b) cuando deba expedirse una factura rectificativa.» **Incorrect:** A consultancy issuing a 900 € simplified invoice to a private client. **Correct:** A restaurant issuing a 900 € simplified invoice for a group dinner: hospitality is in the art. 4.2 list. **Related:** [SIM-001 · A simplified invoice never exceeds 3,000 €](/rules/simplified#sim-001) · [SIM-009 · A customer who asks to be identified gets an invoice that identifies it](/rules/simplified#sim-009) **Explained in:** [Simplified vs standard (F1 vs F2) › The decision in one table](/verifactu/simplified-vs-standard#the-decision-in-one-table) ## SIM-003 · Some operations can never go on a simplified invoice `Required` · Law · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. Do not document on a simplified invoice the operations of art. 4.4: intra-EU supplies of goods exempt under art. 25 LIVA and operations not located in Spain (`NO_SUJETA_LOCALIZACION`), whether the customer is a business in another Member State or anyone outside the EU. The API checks it when the invoice is created, when a draft is edited (also when only its type changes) and when it is issued. A corrective of a simplified invoice (`R5`), checked when it is created and issued, may correct such an operation that the simplified invoice already carried, but cannot add a new one. AEAT's validations also keep reverse-charge lines off simplified invoices, and, as BeeL.'s own rule, the API refuses equivalence surcharge and IRPF withholding on them. The corrective of a simplified invoice (`R5`) follows the same rules: no reverse charge, no equivalence surcharge and no IRPF withholding. **Why:** These operations are excluded from the simplified invoice by the law, and they need an identified recipient, whether to exempt, to shift the tax to the customer or to withhold. **Applies to:** invoice types `SIMPLIFIED`, `CORRECTIVE`; operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice) **Error codes:** [`SIMPLIFICADA_FORBIDS_CROSS_BORDER`](/errors/SIMPLIFICADA_FORBIDS_CROSS_BORDER) (`400`), [`SIMPLIFICADA_FORBIDS_ISP`](/errors/SIMPLIFICADA_FORBIDS_ISP) (`400`), [`SIMPLIFICADA_FORBIDS_SURCHARGE`](/errors/SIMPLIFICADA_FORBIDS_SURCHARGE) (`400`), [`SIMPLIFICADA_FORBIDS_IRPF`](/errors/SIMPLIFICADA_FORBIDS_IRPF) (`422`) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 4.4.a) y d) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a4) > «No podrá expedirse factura simplificada por las siguientes operaciones: a) Las entregas de bienes destinados a otro Estado miembro a que se refiere el artículo 25 de la Ley del Impuesto. [...] d) Las entregas de bienes o prestaciones de servicios a que se refiere el artículo 2.3.b) b').» - RD 1619/2012 (Reglamento de facturación), art. 2.3.b) b') — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a2) > «El proveedor o prestador esté establecido en el territorio de aplicación del Impuesto [...] y dicha entrega o prestación, conforme a las reglas de localización aplicables a las mismas, no se entienda realizada en el territorio de aplicación del Impuesto, en los siguientes supuestos: a'') Cuando la operación esté sujeta en otro Estado miembro, el sujeto pasivo del Impuesto sea el destinatario para quien se realice la operación [...] b'') Cuando la operación se entienda realizada fuera de la Comunidad.» - 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, Preguntas frecuentes SIF y VERI*FACTU, R5 — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html) > «La rectificación de una factura simplificada se registrará con la clave R5 cualquiera que sea el motivo de la misma.» **Incorrect:** A simplified invoice for a service to a consumer in the United States, with its line `NO_SUJETA_LOCALIZACION`: the API answers [`SIMPLIFICADA_FORBIDS_CROSS_BORDER`](/errors/SIMPLIFICADA_FORBIDS_CROSS_BORDER), also if a standard draft with that line is switched to `SIMPLIFIED` and issued. **Correct:** A standard invoice identifying the customer, with the line `NO_SUJETA_LOCALIZACION`. **Related:** [SIM-006 · An identified customer gets a standard invoice (F1)](/rules/simplified#sim-006) · [TAX-004 · Intra-EU supplies of goods are exempt only with the buyer's EU VAT number](/rules/taxes#tax-004) · [TAX-003 · Reverse-charge lines carry no tax and never go on a simplified invoice](/rules/taxes#tax-003) · [SUR-001 · The surcharge rate matches the VAT rate of its line](/rules/surcharge#sur-001) · [TAX-006 · Services to a business abroad are not subject to Spanish VAT](/rules/taxes#tax-006) **Explained in:** [Simplified vs standard (F1 vs F2) › Operations where F2 is not allowed](/verifactu/simplified-vs-standard#operations-where-f2-is-not-allowed) · [Simplified vs standard (F1 vs F2) › Why no IRPF on F2](/verifactu/simplified-vs-standard#why-no-irpf-on-f2) ## SIM-004 · A simplified invoice still carries its minimum contents `Required` · Law · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. A simplified invoice carries its number and series, issue date, the operation date when different, the issuer's NIF and name, what was sold, the tax rate and the total. BeeL. fills in the issuer's data from the company profile; each line needs a description and its main tax. **Why:** Simplified does not mean empty: without these details the ticket is not a valid invoice. **Applies to:** invoice types `SIMPLIFIED`; operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice) **Error codes:** [`LINE_NORMAL_DESCRIPTION_REQUIRED`](/errors/LINE_NORMAL_DESCRIPTION_REQUIRED), [`LINE_MAIN_TAX_REQUIRED`](/errors/LINE_MAIN_TAX_REQUIRED), [`EMISSION_NOT_READY`](/errors/EMISSION_NOT_READY) (`422`), [`PROFILE_INCOMPLETE`](/errors/PROFILE_INCOMPLETE) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 7.1.d)–g) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a7) > «d) Número de Identificación Fiscal, así como el nombre y apellidos, razón o denominación social completa del obligado a su expedición. e) La identificación del tipo de bienes entregados o de servicios prestados. f) Tipo impositivo aplicado y, opcionalmente, también la expresión «IVA incluido». [...] g) Contraprestación total.» **Incorrect:** A simplified invoice whose only line has no description: the API answers [`LINE_NORMAL_DESCRIPTION_REQUIRED`](/errors/LINE_NORMAL_DESCRIPTION_REQUIRED). **Correct:** The same line with a description of what was sold and its VAT rate. **Related:** [SIM-008 · A simplified invoice carries the same legal mentions as a full one](/rules/simplified#sim-008) · [NUM-005 · Simplified invoices are numbered in their own series](/rules/numbering#num-005) · [SIM-010 · A simplified invoice with several VAT rates shows the base of each](/rules/simplified#sim-010) **Explained in:** [Simplified vs standard (F1 vs F2) › On the F2 path](/verifactu/simplified-vs-standard#on-the-f2-path) ## SIM-005 · The record of a simplified invoice carries no recipient `Required` · AEAT criterion · Impact: low · Checked by the API: BeeL. applies it. The billing record of a simplified invoice (F2) or of its corrective (R5) carries no recipient, while F1 and R1–R4 records carry at least one. BeeL. never sends recipient data in an F2 or R5 record. **Why:** AEAT rejects an F2 or R5 record with recipients, and an F1 without them. **Applies to:** invoice types `SIMPLIFIED`, `CORRECTIVE`; VeriFactu enabled; F2 and R5 records. **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 “F1”, “F3”, “R1”, “R2”, “R3” o “R4”, la agrupación Destinatarios tiene que estar cumplimentada, con al menos un destinatario. - Si TipoFactura es “F2” o “R5”, la agrupación Destinatarios no puede estar cumplimentada.» **Incorrect:** Expecting the customer's name on a simplified invoice to reach AEAT. **Correct:** Issuing a standard invoice when the customer has to be identified to AEAT. **Related:** [SIM-006 · An identified customer gets a standard invoice (F1)](/rules/simplified#sim-006) · [REC-001 · Each issued invoice gets a billing record built from its data](/rules/records#rec-001) **Explained in:** [Simplified vs standard (F1 vs F2) › On the F2 path](/verifactu/simplified-vs-standard#on-the-f2-path) · [What AEAT receives from your invoice](/verifactu/what-aeat-receives) ## SIM-006 · An identified customer gets a standard invoice (F1) `Required` · BeeL. rule · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. Issue an invoice that identifies its recipient as a standard invoice (F1). BeeL. requires it: a `SIMPLIFIED` invoice whose `recipient` carries an `nif` or `alternative_id` is rejected with `SIMPLIFIED_INVOICE_FORBIDS_IDENTIFIED_RECIPIENT` when it is created, when an edit changes its type or recipient, and when it is issued. A simplified invoice BeeL. generates from a payment never carries the payer's tax id. **Why:** The law would allow a simplified invoice completed with the recipient's details ([SIM-009](/rules/simplified#sim-009)), but the billing record of a simplified invoice (F2) carries no recipient ([SIM-005](/rules/simplified#sim-005)): the NIF would be on the invoice and never reach AEAT. BeeL. issues that case as a standard invoice, so the invoice type and the record agree. **Applies to:** invoice types `SIMPLIFIED`, `STANDARD`; operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`PATCH /v1/companies/{company_id}/recurring-invoices/{recurring_invoice_id}`](/recurring-invoices/patchCompanyRecurringInvoice) **Error codes:** [`SIMPLIFIED_INVOICE_FORBIDS_IDENTIFIED_RECIPIENT`](/errors/SIMPLIFIED_INVOICE_FORBIDS_IDENTIFIED_RECIPIENT) (`422`) **Incorrect:** A simplified invoice whose `recipient` carries the customer's `nif`: the API answers `422` `SIMPLIFIED_INVOICE_FORBIDS_IDENTIFIED_RECIPIENT`. **Correct:** A standard invoice with the customer's NIF, name and address, whatever the amount. **Related:** [SIM-005 · The record of a simplified invoice carries no recipient](/rules/simplified#sim-005) · [SIM-009 · A customer who asks to be identified gets an invoice that identifies it](/rules/simplified#sim-009) · [CNT-005 · A full invoice identifies the recipient by NIF](/rules/contents#cnt-005) **Explained in:** [Simplified vs standard (F1 vs F2) › On the F2 path](/verifactu/simplified-vs-standard#on-the-f2-path) · [Simplified vs standard (F1 vs F2) › On the F1 path](/verifactu/simplified-vs-standard#on-the-f1-path) ## SIM-007 · Exchanging a simplified invoice for a full one `Required` · Law · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. An invoice issued in exchange for earlier simplified invoices is not a corrective. Issue it with the exchange operation: it issues a standard invoice with the lines of the simplified invoices and the identified recipient, lists them in `replaced_invoice_ids`, and leaves each simplified invoice `VOIDED` with `void_cause` `EXCHANGED`, in the same act. Under VERI*FACTU it is recorded as F3 identifying each replaced simplified invoice by number and issue date; the simplified invoices keep their record and are not cancelled. Only issued simplified invoices that were not voided, exchanged or corrected can be exchanged (`EXCHANGE_REQUIRES_SIMPLIFIED`, `SIMPLIFIED_NOT_EXCHANGEABLE`), each listed once (`EXCHANGE_DUPLICATED_SIMPLIFIED`), and under VERI*FACTU only once AEAT has accepted each one's record: one issued without VERI*FACTU fails with `SIMPLIFIED_EXCHANGE_NOT_RECORDABLE`, one whose record is still pending with `EXCHANGE_SIMPLIFIED_NOT_YET_ACCEPTED` (wait and retry), and one whose record was rejected with `EXCHANGE_SIMPLIFIED_RECORD_REJECTED` until it is fixed or resubmitted. The exchange invoice is not voided (`EXCHANGE_INVOICE_NOT_VOIDABLE`) and, while how to correct it is decided, not corrected either (`EXCHANGE_INVOICE_NOT_CORRECTABLE`). Do not cancel the simplified invoice with an `R5` corrective to issue a new invoice: nothing is being rectified, so it is not a corrective. **Why:** The exchange documents the same sale again with the customer identified. It replaces the simplified invoice instead of crediting it, so the sale counts once; a corrective would state a rectification that did not happen. AEAT's F3 key is for invoices replacing simplified invoices already issued and recorded, so an F3 cannot point at a simplified invoice AEAT does not have. **Applies to:** invoice types `SIMPLIFIED`, `STANDARD`; operations [`POST /v1/companies/{company_id}/invoices/simplified-exchanges`](/invoices/createCompanySimplifiedExchange) **Error codes:** [`EXCHANGE_REQUIRES_SIMPLIFIED`](/errors/EXCHANGE_REQUIRES_SIMPLIFIED) (`422`), [`SIMPLIFIED_NOT_EXCHANGEABLE`](/errors/SIMPLIFIED_NOT_EXCHANGEABLE) (`422`), [`EXCHANGE_DUPLICATED_SIMPLIFIED`](/errors/EXCHANGE_DUPLICATED_SIMPLIFIED) (`422`), [`EXCHANGE_INVOICE_NOT_VOIDABLE`](/errors/EXCHANGE_INVOICE_NOT_VOIDABLE) (`422`), [`SIMPLIFIED_EXCHANGE_NOT_RECORDABLE`](/errors/SIMPLIFIED_EXCHANGE_NOT_RECORDABLE) (`422`), [`EXCHANGE_SIMPLIFIED_RECORD_REJECTED`](/errors/EXCHANGE_SIMPLIFIED_RECORD_REJECTED) (`422`), [`EXCHANGE_SIMPLIFIED_NOT_YET_ACCEPTED`](/errors/EXCHANGE_SIMPLIFIED_NOT_YET_ACCEPTED) (`422`), [`EXCHANGE_INVOICE_NOT_CORRECTABLE`](/errors/EXCHANGE_INVOICE_NOT_CORRECTABLE) (`422`) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 15.6 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a15) > «No obstante, las facturas que se expidan en sustitución o canje de facturas simplificadas expedidas con anterioridad no tendrán la condición de rectificativas, siempre que las facturas simplificadas expedidas en su día cumpliesen los requisitos establecidos en el artículo 7.1.» - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Procedimientos de facturación: factura en sustitución de simplificadas — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html) > «Se deberá informar en el bloque “Tipo Factura” con la clave “F3: factura emitida en sustitución de facturas simplificadas facturadas y declaradas” y en el bloque de “Datos sustituidas” se identificarán las facturas simplificadas sustituidas con el número, serie y fecha de expedición.» **Incorrect:** Cancelling the simplified invoice with an `R5` `TOTAL` corrective and issuing a new standard invoice: it states a rectification that did not happen. **Correct:** Exchanging the simplified invoice for a standard invoice to the customer. ```http POST /v1/companies/{company_id}/invoices/simplified-exchanges { "simplified_invoice_ids": ["550e8400-e29b-41d4-a716-446655440010"], "recipient": { "customer_id": "8f1e2a3b-4c5d-6e7f-8091-a2b3c4d5e6f7" } } ``` **Related:** [SIM-009 · A customer who asks to be identified gets an invoice that identifies it](/rules/simplified#sim-009) · [COR-002 · Pick the reason code: R1–R4 for standard invoices, R5 for simplified](/rules/corrective#cor-002) · [COR-013 · A corrective is only for the causes the law lists](/rules/corrective#cor-013) **Explained in:** [Simplified vs standard (F1 vs F2) › Exchanging simplified invoices for a full invoice](/verifactu/simplified-vs-standard#upgrading-an-f2-to-f1-the-canje-case) · [Corrective invoices (R1–R5) › Scenario 5 — R5: correcting a simplified invoice](/verifactu/corrective-invoices#scenario-5--r5-cancelling-an-f2-to-issue-a-proper-f1) ## SIM-008 · A simplified invoice carries the same legal mentions as a full one `Required` · Law · Impact: low · Responsibility: the issuing business. When they apply, a simplified invoice carries the same mentions as a full invoice: the exemption, the special regime or the other mentions of art. 6.1 j) to p). **Why:** The mention is what tells the reader why the invoice charges no tax or follows a special regime; a ticket is not exempt from it. **Applies to:** invoice types `SIMPLIFIED` **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 7.1.i) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a7) > «En los supuestos a que se refieren las letras j) a p) del artículo 6.1 de este Reglamento, deberá hacerse constar las menciones referidas en las mismas.» **Incorrect:** A ticket for an exempt service that states neither the exemption nor its legal basis. **Correct:** The same ticket stating that the service is exempt and the article that exempts it. **Related:** [SIM-004 · A simplified invoice still carries its minimum contents](/rules/simplified#sim-004) · [CNT-010 · An exempt operation states why it is exempt](/rules/contents#cnt-010) ## SIM-009 · A customer who asks to be identified gets an invoice that identifies it `Required` · Law · Impact: medium · Responsibility: the issuing business. When the recipient is a business acting as such and asks for it, or needs it to exercise a tax right, the invoice shows the recipient's NIF and address and the tax separately, even if you would otherwise hand out a simplified invoice without those details. A simplified invoice completed with them is valid, and AEAT registers it as F1. **Why:** Without the recipient's details and the tax shown apart, the recipient cannot deduct the VAT. **Applies to:** invoice types `STANDARD`, `SIMPLIFIED` **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 2.2.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a2-2) > «Aquellas en las que el destinatario sea un empresario o profesional que actúe como tal, con independencia del régimen de tributación al que se encuentre acogido el empresario o profesional que realice la operación, así como cualesquiera otras en las que el destinatario así lo exija para el ejercicio de cualquier derecho de naturaleza tributaria.» - RD 1619/2012 (Reglamento de facturación), art. 7.2 y 7.3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a7) > «cuando el destinatario de la operación sea un empresario o profesional y así lo exija, el expedidor de la factura simplificada deberá hacer constar, además, los siguientes datos: [...] 3. También deberán hacerse constar los datos referidos en el apartado anterior, cuando el destinatario de la operación no sea un empresario o profesional y así lo exija para el ejercicio de cualquier derecho de naturaleza tributaria.» - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Procedimientos de facturación: Tipo de facturas — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html) > «Se registran con la clave F1: [...] Las facturas simplificadas cualificadas reguladas en los artículos 7.2 y 7.3 del Reglamento por el que se regulan las obligaciones de facturación» **Incorrect:** Refusing a company its NIF and address on the invoice because the till only prints tickets. **Correct:** Issuing an invoice with the company's NIF and address (in BeeL., a standard invoice), or exchanging the ticket for one. **Related:** [SIM-006 · An identified customer gets a standard invoice (F1)](/rules/simplified#sim-006) · [SIM-007 · Exchanging a simplified invoice for a full one](/rules/simplified#sim-007) · [CNT-002 · A business customer always gets an invoice, identifying it when asked](/rules/contents#cnt-002) **Explained in:** [Simplified vs standard (F1 vs F2) › Exchanging simplified invoices for a full invoice](/verifactu/simplified-vs-standard#upgrading-an-f2-to-f1-the-canje-case) ## SIM-010 · A simplified invoice with several VAT rates shows the base of each `Required` · Law · Impact: low · Responsibility: your integration. When a simplified invoice covers operations at different VAT rates, it shows the taxable base of each rate separately, besides the rate applied. Give each line its own `main_tax`. **Why:** With several rates, the total alone does not say how much was taxed at each one. **Applies to:** invoice types `SIMPLIFIED`; Simplified invoices with lines at different VAT rates. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 7.1.f) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a7) > «Asimismo, cuando una misma factura comprenda operaciones sujetas a diferentes tipos impositivos del Impuesto sobre el Valor Añadido deberá especificarse por separado, además, la parte de base imponible correspondiente a cada una de las operaciones.» **Incorrect:** A ticket for food at 10 % and drinks at 21 % sent as one line at a blended rate. **Correct:** The same ticket as two lines, each with its own rate, so the base of each rate is shown. **Related:** [SIM-004 · A simplified invoice still carries its minimum contents](/rules/simplified#sim-004) · [CNT-009 · The base is broken down by rate and by kind of operation](/rules/contents#cnt-009) [← All rules](/rules#all-rules) ## Related - [Simplified vs standard (F1 vs F2)](/verifactu/simplified-vs-standard) — when BeeL. issues a simplified invoice (F2) or a standard invoice (F1), the rules of the RD 1619/2012 behind them, and what BeeL. enforces at the API boundary - [Corrective invoices (R1–R5)](/verifactu/corrective-invoices) — pick the right rectification type and code, and see the canonical request shapes BeeL. accepts for each scenario - [What AEAT receives from your invoice](/verifactu/what-aeat-receives) — how BeeL. turns your invoice into the record AEAT registers — the description, the total, the number, the recipient and the late-submission flag — and why some of them differ from what you see on the invoice --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # Taxes and exemptions How each line is taxed: VAT rates, reverse charge, exempt and non-subject operations, OSS, disbursements, IRPF and the currency amounts are expressed in. [← All rules](/rules#all-rules) Every line carries its own tax treatment, and AEAT receives it line by line. These rules say which rate or classification a line needs and which ones BeeL. rejects before the invoice is issued. 19 rules: 8 from the law, 9 AEAT criteria, 2 BeeL. rules. [How to read a rule](/rules#how-to-read-a-rule). ## TAX-001 · Apply the VAT rate in force when the operation took place `Required` · Law · Impact: high · Responsibility: the issuing business. Each taxed line carries the VAT rate that applied on the date the operation accrued, not the one in force on the day you issue. **Why:** A rate that was not in force at accrual charges the wrong tax, and the invoice then has to be corrected. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice); Lines taxed with IVA (`main_tax.type: IVA`). **Legal basis:** - Ley 37/1992 del IVA, art. 90.Dos — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a90) > «Dos. El tipo impositivo aplicable a cada operación será el vigente en el momento del devengo.» **Incorrect:** Invoicing in October a supply that accrued in June at the rate that applies in October, because it is the one in force on the issue date. **Correct:** Sending `operation_date` with the June date and the rate that applied in June on each line. ```json { "operation_date": "2026-06-18", "lines": [{ "description": "Supply", "quantity": 1, "unit_price": 100, "main_tax": { "type": "IVA", "percentage": 21 } }] } ``` **Related:** [DAT-004 · Send the operation date when it differs from the issue date](/rules/dates#dat-004) · [TAX-014 · Only the VAT rates AEAT accepts on the operation date](/rules/taxes#tax-014) · [TAX-005 · Exempt and non-subject lines carry no VAT rate](/rules/taxes#tax-005) **Explained in:** [Tax classification per line › Allowed main_tax.percentage values](/verifactu/tax-classification#allowed-main_taxpercentage-values) ## TAX-002 · Reverse-charge operations are invoiced without charging VAT `Required` · Law · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. When the recipient is the one liable for the VAT, the line does not charge VAT: classify it as reverse charge with the `exemption_reason` of its case of art. 84.Uno.2.º LIVA, `ISP_ART_84_2_A` to `ISP_ART_84_2_F`. The invoice carries the mention «inversión del sujeto pasivo». Case g) (silver, platinum and palladium, mobile phones, consoles, laptops and tablets) must be documented in a special series and is rejected with [`REVERSE_CHARGE_CASE_NOT_SUPPORTED`](/errors/REVERSE_CHARGE_CASE_NOT_SUPPORTED). Deciding that an operation falls under reverse charge is the issuer's call. **Why:** Charging VAT on a reverse-charge operation makes both parties declare it: the issuer collects a tax it does not owe and the recipient self-assesses it again. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; Operations where the recipient is the taxpayer (inversión del sujeto pasivo). **Error codes:** [`REVERSE_CHARGE_CASE_NOT_SUPPORTED`](/errors/REVERSE_CHARGE_CASE_NOT_SUPPORTED) (`422`) **Legal basis:** - Ley 37/1992 del IVA, art. 84.Uno.2.º a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «Los empresarios o profesionales para quienes se realicen las operaciones sujetas al Impuesto en los supuestos que se indican a continuación: a) Cuando las mismas se efectúen por personas o entidades no establecidas en el territorio de aplicación del Impuesto.» - Ley 37/1992 del IVA, art. 84.Uno.2.º b) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «b) Cuando se trate de entregas de oro sin elaborar o de productos semielaborados de oro, de ley igual o superior a 325 milésimas.» - Ley 37/1992 del IVA, art. 84.Uno.2.º c) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «c) Cuando se trate de:» - Ley 37/1992 del IVA, art. 84.Uno.2.º c) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «– Entregas de desechos nuevos de la industria, desperdicios y desechos de fundición, residuos y demás materiales de recuperación constituidos por metales férricos y no férricos, sus aleaciones, escorias, cenizas y residuos de la industria que contengan metales o sus aleaciones.» - Ley 37/1992 del IVA, art. 84.Uno.2.º c) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «– Las operaciones de selección, corte, fragmentación y prensado que se efectúen sobre los productos citados en el guion anterior.» - Ley 37/1992 del IVA, art. 84.Uno.2.º c) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «– Entregas de desechos, desperdicios o recortes de plástico.» - Ley 37/1992 del IVA, art. 84.Uno.2.º c) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «– Entregas de desperdicios o desechos de papel, cartón o vidrio.» - Ley 37/1992 del IVA, art. 84.Uno.2.º c) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «– Entregas de desperdicios o artículos inservibles de trapos, cordeles, cuerdas o cordajes.» - Ley 37/1992 del IVA, art. 84.Uno.2.º c) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «– Entregas de productos semielaborados resultantes de la transformación, elaboración o fundición de los metales no férricos referidos en el primer guion, con excepción de los compuestos por níquel. En particular, se considerarán productos semielaborados los lingotes, bloques, placas, barras, grano, granalla y alambrón.» - Ley 37/1992 del IVA, art. 84.Uno.2.º c) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «En todo caso, se considerarán comprendidas en los párrafos anteriores las entregas de los materiales definidos en el anexo de esta ley.» - Ley 37/1992 del IVA, art. 84.Uno.2.º d) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «d) Cuando se trate de prestaciones de servicios que tengan por objeto derechos de emisión, reducciones certificadas de emisiones y unidades de reducción de emisiones de gases de efecto invernadero» - Ley 37/1992 del IVA, art. 84.Uno.2.º e) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «e) Cuando se trate de las siguientes entregas de bienes inmuebles:» - Ley 37/1992 del IVA, art. 84.Uno.2.º f) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «Cuando se trate de ejecuciones de obra, con o sin aportación de materiales, así como las cesiones de personal para su realización, consecuencia de contratos directamente formalizados entre el promotor y el contratista que tengan por objeto la urbanización de terrenos o la construcción o rehabilitación de edificaciones.» - Ley 37/1992 del IVA, art. 84.Uno.2.º g) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a84) > «Las entregas de dichos bienes, en los casos en que sean sujetos pasivos del Impuesto sus destinatarios conforme a lo establecido en este número 2.°, deberán documentarse en una factura mediante serie especial.» - Real Decreto 1619/2012, Reglamento de facturación, art. 6.1 m) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «m) En el caso de que el sujeto pasivo del Impuesto sea el adquirente o el destinatario de la operación, la mención «inversión del sujeto pasivo».» **Incorrect:** A contractor invoicing construction work to the developer charges 21 % VAT on the line. **Correct:** The line goes at 0 % with the reverse-charge reason of its case. ```json { "description": "Construction work, phase 2", "quantity": 1, "unit_price": 25000, "main_tax": { "type": "IVA", "percentage": 0 }, "exemption_reason": "ISP_ART_84_2_F" } ``` **Related:** [TAX-003 · Reverse-charge lines carry no tax and never go on a simplified invoice](/rules/taxes#tax-003) · [CNT-012 · A reverse-charge invoice carries the mention «inversión del sujeto pasivo»](/rules/contents#cnt-012) · [CNT-005 · A full invoice identifies the recipient by NIF](/rules/contents#cnt-005) **Explained in:** [Tax classification per line › Reverse charge (inversión del sujeto pasivo, S2)](/verifactu/tax-classification#inversión-del-sujeto-pasivo-s2) ## TAX-003 · Reverse-charge lines carry no tax and never go on a simplified invoice `Required` · AEAT criterion · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. A reverse-charge line goes at 0 % with no tax amount, and only on a full invoice or its correctives, never on a simplified one. It cannot carry an equivalence surcharge nor use the OSS regime. **Why:** AEAT registers a reverse-charge line only with rate and tax amount at zero, and only on invoice types that identify the recipient, who is the one who self-assesses. **Applies to:** invoice types `STANDARD`, `SIMPLIFIED`, `CORRECTIVE`; Lines classified as reverse charge (`exemption_reason` `ISP_ART_84_2_*`). **Error codes:** [`LINE_EXEMPTION_WITH_TAX`](/errors/LINE_EXEMPTION_WITH_TAX), [`SIMPLIFICADA_FORBIDS_ISP`](/errors/SIMPLIFICADA_FORBIDS_ISP) (`400`), [`ISP_INCOMPATIBLE_WITH_SURCHARGE`](/errors/ISP_INCOMPATIBLE_WITH_SURCHARGE) (`400`), [`OSS_REGIME_INCOMPATIBLE_WITH_ISP`](/errors/OSS_REGIME_INCOMPATIBLE_WITH_ISP) **Legal basis:** - 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”. - Cuando CalificacionOperacion sea “S2”: ✓ TipoImpositivo = 0. [...] ✓ CuotaRepercutida = 0.» **Incorrect:** A simplified invoice with a reverse-charge line: the API answers [`SIMPLIFICADA_FORBIDS_ISP`](/errors/SIMPLIFICADA_FORBIDS_ISP). **Correct:** A standard invoice to the identified business recipient, with the line at 0 % and its reverse-charge reason. **Related:** [TAX-002 · Reverse-charge operations are invoiced without charging VAT](/rules/taxes#tax-002) · [SIM-003 · Some operations can never go on a simplified invoice](/rules/simplified#sim-003) · [SUR-001 · The surcharge rate matches the VAT rate of its line](/rules/surcharge#sur-001) **Explained in:** [Tax classification per line › Rules BeeL. enforces](/verifactu/tax-classification#rules-beel-enforces) ## TAX-004 · Intra-EU supplies of goods are exempt only with the buyer's EU VAT number `Required` · Law · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. An intra-EU supply of goods is exempt only when the buyer has a VAT number from another Member State and has given it to you. The recipient goes on the invoice with that number as an alternative identifier of type NIF-IVA, and the operation is also declared in the recapitulative statement (modelo 349). **Why:** Without a valid EU VAT number the exemption does not apply and Spanish VAT was due; AEAT also rejects an E5 record that does not identify the recipient that way. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; Goods shipped to a business in another EU Member State (`exemption_reason: EXENTA_ART_25`). **Error codes:** [`EXEMPTION_REQUIRES_RECIPIENT_ID_TYPE`](/errors/EXEMPTION_REQUIRES_RECIPIENT_ID_TYPE) (`400`) **Legal basis:** - Ley 37/1992 del IVA, art. 25.Uno — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a25) > «siempre que el adquirente sea un empresario o profesional o una persona jurídica que no actúe como tal, que disponga de un número de identificación a efectos del Impuesto sobre el Valor Añadido asignado por un Estado miembro distinto del Reino de España, que haya comunicado dicho número de identificación fiscal al vendedor.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.5.1 OperacionExenta E5 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «si OperacionExenta es igual a “E5”, sólo deberá existir la agrupación IDOtro cuando se cumplimente el bloque “Destinatario”.» **Incorrect:** Invoicing goods to a French company as exempt with the recipient identified only by name: the API answers [`EXEMPTION_REQUIRES_RECIPIENT_ID_TYPE`](/errors/EXEMPTION_REQUIRES_RECIPIENT_ID_TYPE). **Correct:** Identifying the customer with its EU VAT number as `alternative_id` of type NIF-IVA, after checking that the number is valid. **Related:** [CNT-005 · A full invoice identifies the recipient by NIF](/rules/contents#cnt-005) · [CNT-021 · A recipient without a Spanish NIF is identified by an alternative id](/rules/contents#cnt-021) · [TAX-005 · Exempt and non-subject lines carry no VAT rate](/rules/taxes#tax-005) **Explained in:** [International customers › B2B intra-EU — goods (E5)](/verifactu/international-customers#b2b-intra-eu--goods-e5) ## TAX-005 · Exempt and non-subject lines carry no VAT rate `Required` · AEAT criterion · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. A line with an `exemption_reason` goes at 0 %: it carries neither a VAT rate nor a tax amount, and no equivalence surcharge. **Why:** AEAT does not accept a rate or a tax amount on an exempt or non-subject line; the invoice would say the operation is exempt and charge VAT at the same time. **Applies to:** Lines with an `exemption_reason` (exempt, non-subject or reverse charge). **Error codes:** [`LINE_EXEMPTION_WITH_TAX`](/errors/LINE_EXEMPTION_WITH_TAX), [`INVALID_IVA_SURCHARGE_PAIR`](/errors/INVALID_IVA_SURCHARGE_PAIR) (`422`) **Legal basis:** - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.4 y 3.1.3.15.5 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Si el campo OperacionExenta está cumplimentado no se pueden informar ninguno de estos campos: TipoImpositivo, CuotaRepercutida, TipoRecargoEquivalencia y CuotaRecargoEquivalencia.» **Incorrect:** A training course marked `EXENTA_ART_20` sent at 21 %: the API answers [`LINE_EXEMPTION_WITH_TAX`](/errors/LINE_EXEMPTION_WITH_TAX). **Correct:** The same line at 0 % with its exemption reason. ```json { "description": "Vocational training course", "quantity": 1, "unit_price": 400, "main_tax": { "type": "IVA", "percentage": 0 }, "exemption_reason": "EXENTA_ART_20" } ``` **Related:** [CNT-010 · An exempt operation states why it is exempt](/rules/contents#cnt-010) · [TAX-003 · Reverse-charge lines carry no tax and never go on a simplified invoice](/rules/taxes#tax-003) **Explained in:** [Tax classification per line › Rules BeeL. enforces](/verifactu/tax-classification#rules-beel-enforces) ## TAX-006 · Services to a business abroad are not subject to Spanish VAT `Required` · Law · Impact: medium · Responsibility: the issuing business. A service to a business established in another country is, as a general rule, located where the customer is established: invoice it without Spanish VAT, as not subject by location rules (`NO_SUJETA_LOCALIZACION`), and identify the customer. When the customer is liable for the VAT in another Member State, the invoice carries the mention «inversión del sujeto pasivo» and is never a simplified invoice. The exceptions of art. 70 LIVA (real estate, events, transport and others) need their own analysis. **Why:** Charging Spanish VAT on a service located abroad collects a tax Spain is not owed, and the customer cannot deduct it. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; Services to a business customer established outside Spain, general rule. **Legal basis:** - Ley 37/1992 del IVA, art. 69.Uno.1.º — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a69) > «Cuando el destinatario sea un empresario o profesional que actúe como tal y radique en el citado territorio la sede de su actividad económica, o tenga en el mismo un establecimiento permanente o, en su defecto, el lugar de su domicilio o residencia habitual» - RD 1619/2012 (Reglamento de facturación), art. 6.1.m) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «En el caso de que el sujeto pasivo del Impuesto sea el adquirente o el destinatario de la operación, la mención «inversión del sujeto pasivo».» - RD 1619/2012 (Reglamento de facturación), art. 4.4.d) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a4) > «d) Las entregas de bienes o prestaciones de servicios a que se refiere el artículo 2.3.b) b').» **Incorrect:** A software consultancy invoices a German company at 21 % Spanish VAT. **Correct:** The line goes at 0 % with `exemption_reason: NO_SUJETA_LOCALIZACION` and the customer is identified with its EU VAT number. **Related:** [TAX-004 · Intra-EU supplies of goods are exempt only with the buyer's EU VAT number](/rules/taxes#tax-004) · [TAX-007 · Sales declared through OSS use regime key 17](/rules/taxes#tax-007) · [CNT-021 · A recipient without a Spanish NIF is identified by an alternative id](/rules/contents#cnt-021) · [CNT-012 · A reverse-charge invoice carries the mention «inversión del sujeto pasivo»](/rules/contents#cnt-012) **Explained in:** [International customers › B2B intra-EU — services (N2)](/verifactu/international-customers#b2b-intra-eu--services-n2) · [International customers › Services to non-EU customers](/verifactu/international-customers#services-to-non-eu-customers) ## TAX-007 · Sales declared through OSS use regime key 17 `Required` · AEAT criterion · Impact: medium · Responsibility: the issuing business. The API also answers the error codes listed. Above 10,000 € a year of intra-EU distance sales of goods and B2C services, counting the previous year and the current one, the VAT of those sales is due in the customer's country. Declaring it through the OSS or IOSS one-stop shop is an option; an operation you declare there goes with regime key `17`. In BeeL., send such a line with regime key `17` and the destination country's VAT rate, without `exemption_reason`. **Why:** AEAT identifies one-stop-shop sales by the regime key; under another key the record says Spanish VAT was charged on a sale taxed in another country. **Applies to:** Distance sales and B2C services to other EU countries declared in the OSS or IOSS one-stop shop. **Error codes:** [`OSS_REGIME_INCOMPATIBLE_WITH_ISP`](/errors/OSS_REGIME_INCOMPATIBLE_WITH_ISP) **Legal basis:** - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Registros de facturación: alta (OSS) — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/registros-facturacion-alta.html) > «En las operaciones de los regímenes de ventanilla única (OSS, one stop shop) [...] el código de régimen a indicar de la lista L8 es el "17": Operación acogida a alguno de los regímenes previstos en el Capítulo XI del Título IX (OSS e IOSS).» - Ley 37/1992 del IVA, art. 73.Uno — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a73) > «el límite referido será de 10.000 euros para el importe total, excluido el impuesto, de dichas entregas de bienes y/o prestaciones de servicios realizadas en la Comunidad, durante el año natural precedente, o su equivalente en su moneda nacional. Cuando las operaciones efectuadas durante el año en curso superen el límite indicado en el párrafo anterior» **Incorrect:** An online shop above the OSS threshold invoices a consumer in Italy at 21 % under the general regime `01`. **Correct:** The line goes with regime key `17` and the Italian VAT rate, without `exemption_reason`. **Related:** [TAX-006 · Services to a business abroad are not subject to Spanish VAT](/rules/taxes#tax-006) · [TAX-003 · Reverse-charge lines carry no tax and never go on a simplified invoice](/rules/taxes#tax-003) **Explained in:** [Regime keys › "17" — OSS / IOSS](/verifactu/regime-keys#17--oss--ioss) · [International customers › B2C intra-EU — above the OSS threshold](/verifactu/international-customers#b2c-intra-eu--above-the-oss-threshold) ## TAX-008 · Disbursements go as SUPLIDO lines, without tax `Required` · AEAT criterion · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. An amount you paid in the customer's name and on their behalf is not part of your taxable base: send it as a `SUPLIDO` line, which carries no VAT, surcharge or IRPF. It is not part of the billing record either. An invoice with nothing but `SUPLIDO` lines is not an invoice and is rejected with [`INVOICE_REQUIRES_AT_LEAST_ONE_NORMAL_LINE`](/errors/INVOICE_REQUIRES_AT_LEAST_ONE_NORMAL_LINE): put the disbursement on the invoice of the operation it belongs to. **Why:** Taxing a disbursement charges VAT on money that was never your income; AEAT only accepts it in the total as a non-subject or zero-rated amount. **Applies to:** Amounts paid on behalf of the customer (disbursements, *suplidos*). **Error codes:** [`LINE_SUPLIDO_MUST_HAVE_NO_TAX`](/errors/LINE_SUPLIDO_MUST_HAVE_NO_TAX), [`LINE_SUPLIDO_MUST_HAVE_NO_RECARGO`](/errors/LINE_SUPLIDO_MUST_HAVE_NO_RECARGO), [`LINE_SUPLIDO_MUST_HAVE_NO_IRPF`](/errors/LINE_SUPLIDO_MUST_HAVE_NO_IRPF), [`INVOICE_REQUIRES_AT_LEAST_ONE_NORMAL_LINE`](/errors/INVOICE_REQUIRES_AT_LEAST_ONE_NORMAL_LINE) (`422`) **Legal basis:** - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Registros de facturación: alta (suplidos) — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/registros-facturacion-alta.html) > «los importes suplidos al igual que ocurre con el recargo financiero, no son importes "propios" del registro de facturación, y no tienen que incluirse entre las menciones del “registro de facturación de alta”. No obstante, en el caso de que se incluyeran como mayor importe en el concepto “Importe total factura” (lo cual, no es obligatorio), deberán consignarse como importe no sujeto al IVA o cantidades a tipo cero (0%).» - AEAT, Aclaraciones a dudas de los desarrolladores (v1.3), 22 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/FAQs-Desarrolladores.pdf) > «NO procede hacer una factura que solo contenga gastos suplidos, porque eso NO sería una factura, así que nunca debería existir como tal.» - Ley 37/1992 del IVA, art. 78.Tres.3.º — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a78) > «Las sumas pagadas en nombre y por cuenta del cliente en virtud de mandato expreso del mismo. El sujeto pasivo vendrá obligado a justificar la cuantía efectiva de tales gastos y no podrá proceder a la deducción del impuesto que eventualmente los hubiera gravado.» **Incorrect:** An accounting firm (*gestoría*) adds the registry fee it paid for the client as a normal line at 21 %. **Correct:** The fee goes as a `SUPLIDO` line. ```json { "line_type": "SUPLIDO", "description": "Registry fee paid on your behalf", "quantity": 1, "unit_price": 35.20 } ``` **Related:** [TAX-009 · IRPF withholding is not part of the total AEAT receives](/rules/taxes#tax-009) **Explained in:** [Disbursements (suplidos)](/verifactu/suplidos) ## TAX-009 · IRPF withholding is not part of the total AEAT receives `Required` · AEAT criterion · Impact: medium · Checked by the API: BeeL. applies it. The IRPF withheld on an invoice is not part of its billing record: the total AEAT receives is the total before the withholding, so it can differ from the amount payable. BeeL. leaves the withholding out of the record for you. **Why:** Comparing the QR amount or the registered total with the amount payable and reading the difference as an error leads to correcting an invoice that is right. **Applies to:** Invoices with IRPF withholding, under VeriFactu. **Legal basis:** - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Registros de facturación: alta (retenciones) — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/registros-facturacion-alta.html) > «Por lo que se refiere a las retenciones, estas no forman parte formalmente del registro de facturación (no es uno de los elementos constitutivos de la factura de acuerdo con la Directiva UE).» **Incorrect:** Flagging as a mismatch an invoice whose QR says 121.00 while the customer pays 106.00 after a 15 % withholding. **Correct:** Reconciling payments against the amount payable, and the AEAT record against the total before withholding. **Related:** [TAX-010 · Set the IRPF withholding when the customer must withhold](/rules/taxes#tax-010) · [TAX-008 · Disbursements go as SUPLIDO lines, without tax](/rules/taxes#tax-008) **Explained in:** [What AEAT receives from your invoice › The total](/verifactu/what-aeat-receives#the-total) · [Amounts and rounding › IRPF](/guides/amounts-and-rounding#irpf) ## TAX-010 · Set the IRPF withholding when the customer must withhold `Recommended` · BeeL. rule · Impact: medium · Responsibility: your integration. The API also answers the error codes listed. When your customer has to withhold IRPF from your invoice, set `irpf_rate` on each line, one of 0, 1, 2, 2.8, 6, 7, 7.6, 9.5, 15, 19 or 24. A line without it takes the company's `default_irpf_rate`, if one is set. BeeL. shows the withholding and takes it off the amount payable; a simplified invoice never carries it. **Why:** Without the withholding on the invoice the customer pays the full amount, and one of you ends up correcting it with the tax authority. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; Professionals invoicing a business or professional that has to withhold IRPF. **Error codes:** [`INVALID_IRPF`](/errors/INVALID_IRPF) (`422`), [`SIMPLIFICADA_FORBIDS_IRPF`](/errors/SIMPLIFICADA_FORBIDS_IRPF) (`422`) **Incorrect:** A freelance consultant invoices a company without `irpf_rate` and without a default withholding rate, and the company has to ask for a corrected invoice. **Correct:** The line carries the withholding. ```json { "description": "Consulting, September", "quantity": 1, "unit_price": 1000, "main_tax": { "type": "IVA", "percentage": 21 }, "irpf_rate": 15 } ``` **Related:** [TAX-009 · IRPF withholding is not part of the total AEAT receives](/rules/taxes#tax-009) · [SIM-003 · Some operations can never go on a simplified invoice](/rules/simplified#sim-003) **Explained in:** [Amounts and rounding › IRPF](/guides/amounts-and-rounding#irpf) ## TAX-012 · The tax and the billing record are expressed in euros `Required` · Law · Impact: medium · Checked by the API: BeeL. applies it. An invoice may state its amounts in another currency, but the VAT charged is expressed in euros, and every amount in the billing record is in euros. BeeL. invoices only in euros, so both hold for every invoice it issues. **Why:** AEAT only takes tax and record amounts in euros; a foreign-currency amount would have to be converted at the exchange rate the law sets. **Applies to:** Every invoice. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 12.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a12) > «Los importes que figuran en las facturas podrán expresarse en cualquier moneda, a condición de que el importe del Impuesto que, en su caso, se repercuta se exprese en euros, utilizando a tal efecto el tipo de cambio a que se refiere el artículo 79.Once de la Ley del Impuesto.» - RD 1007/2023 (RRSIF), art. 10.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#a1-2) > «Todos los importes monetarios que consten en el registro de facturación de alta deberán expresarse en euros. Cuando la factura se hubiese expedido en una unidad de cuenta o divisa distinta del euro tendrá que efectuarse en el registro la correspondiente conversión.» **Incorrect:** Expecting BeeL. to register a dollar invoice and convert it for AEAT. **Correct:** Converting the price to euros before sending it, as [TAX-013](/rules/taxes#tax-013) says. **Related:** [TAX-013 · Send every amount in euros](/rules/taxes#tax-013) **Explained in:** [Amounts and rounding › Precision](/guides/amounts-and-rounding#precision) ## TAX-013 · Send every amount in euros `Required` · BeeL. rule · Impact: critical · Responsibility: your integration. The API has no currency field: every amount you send is read as euros. Convert foreign-currency prices to euros before sending them; you may mention the original currency in the notes. **Why:** A price sent in dollars or pounds is invoiced, taxed and registered with AEAT as that many euros, and only a corrective fixes it. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice) **Incorrect:** Passing through a Stripe charge of 100 USD as `unit_price: 100`. **Correct:** Converting it first and sending the euro amount, with the original amount in `notes`. ```json { "notes": "Original charge: 100.00 USD", "lines": [{ "description": "Subscription, September", "quantity": 1, "unit_price": 92.40, "main_tax": { "type": "IVA", "percentage": 21 } }] } ``` **Related:** [TAX-012 · The tax and the billing record are expressed in euros](/rules/taxes#tax-012) **Explained in:** [Amounts and rounding › Precision](/guides/amounts-and-rounding#precision) ## TAX-014 · Only the VAT rates AEAT accepts on the operation date `Required` · AEAT criterion · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. A subject, non-exempt IVA line uses one of the VAT rates AEAT's validations accept on the operation date, or on the issue date when the invoice has no `operation_date`. The temporary rates are only accepted on operations of their period: 5 % from 1 July 2022 to 30 September 2024, and 2 % and 7.5 % from 1 October to 31 December 2024. `GET /v1/tax-types` publishes each rate with its period. The API rejects any other rate, and a rate outside its period, before the invoice is numbered. **Why:** AEAT rejects a record whose rate is not one of its accepted values for that date, after the invoice already has its number. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective`](/invoices/createCompanyCorrectiveInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice); Subject, non-exempt lines taxed with IVA. **Error codes:** [`INVALID_PERCENTAGE`](/errors/INVALID_PERCENTAGE), [`VAT_RATE_NOT_ACCEPTED_ON_DATE`](/errors/VAT_RATE_NOT_ACCEPTED_ON_DATE) (`422`) **Legal basis:** - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.1 TipoImpositivo — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Solo se permiten TipoImpositivo = 0; 2; 4; 5; 7,5; 10 y 21 (valores que indican el tanto por ciento).» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.1 TipoImpositivo — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Si FechaOperacion (FechaExpedicionFactura de la agrupación IDFactura si no se informa FechaOperacion) ≥ 1 de julio de 2022 y ≤ 30 de septiembre de 2024 se admitirá TipoImpositivo = 5.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.1 TipoImpositivo — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Si FechaOperacion (FechaExpedicionFactura de la agrupación IDFactura si no se informa FechaOperacion) ≥ 1 de octubre de 2024 y ≤ 31 de diciembre de 2024 se admitirá el TipoImpositivo = 7,5.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.1 TipoImpositivo — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Si FechaOperacion (FechaExpedicionFactura de la agrupación IDFactura si no se informa FechaOperacion) ≥ 1 de octubre de 2024 y ≤ 31 de diciembre de 2024 se admitirá el TipoImpositivo = 2» **Incorrect:** A line at 5 % issued today without `operation_date`: the API answers [`VAT_RATE_NOT_ACCEPTED_ON_DATE`](/errors/VAT_RATE_NOT_ACCEPTED_ON_DATE). A line at 16 % answers [`INVALID_PERCENTAGE`](/errors/INVALID_PERCENTAGE). **Correct:** A line at 5 % for a supply of March 2024, with its `operation_date`. ```json { "operation_date": "2024-03-12", "lines": [{ "description": "Electricity, February 2024", "quantity": 1, "unit_price": 100, "main_tax": { "type": "IVA", "percentage": 5 } }] } ``` **Related:** [TAX-001 · Apply the VAT rate in force when the operation took place](/rules/taxes#tax-001) · [TAX-005 · Exempt and non-subject lines carry no VAT rate](/rules/taxes#tax-005) **Explained in:** [Tax classification per line › Allowed main_tax.percentage values](/verifactu/tax-classification#allowed-main_taxpercentage-values) ## TAX-015 · Regime key 08 means not subject to the line's tax `Required` · AEAT criterion · Impact: high · Checked by the API: a request that breaks it is rejected with the error codes listed. Regime key `08` is for an operation subject to another indirect tax: IPSI or IGIC on an IVA line, IPSI or IVA on an IGIC line. For the line's own tax it is not subject, so the line goes at 0 % with `exemption_reason: NO_SUJETA_LOCALIZACION`. It is not the general regime of IGIC: an ordinary IGIC sale uses regime key `01`. **Why:** AEAT only accepts regime key `08` with the non-subject classification N2 and rejects the record otherwise, after the invoice already has its number. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/companies/{company_id}/recurring-invoices`](/recurring-invoices/createCompanyRecurringInvoice); IVA and IGIC lines with regime key `08`. **Error codes:** [`REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`](/errors/REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED) (`422`) **Legal basis:** - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.6.6 ClaveRegimen 08 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Si ClaveRegimen = “08”, CalificacionOperacion tiene que ser “N2” y siempre debe ir relleno.» - Orden HAC/1177/2024, anexo, lista L8B — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138) > «Operaciones sujetas al IPSI/ IVA (Impuesto sobre la Producción, los Servicios y la Importación/ Impuesto sobre el Valor Añadido).» **Incorrect:** An IGIC line at 7 % with regime key `08` for an ordinary sale in the Canary Islands: the API answers [`REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`](/errors/REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED). ```json { "description": "Sale", "quantity": 1, "unit_price": 100, "main_tax": { "type": "IGIC", "percentage": 7, "regime_key": "08" } } ``` **Correct:** The same sale under regime key `01`. An IVA business invoicing a service located in the Canary Islands uses `08` with the non-subject reason. ```json { "description": "Service located in the Canary Islands", "quantity": 1, "unit_price": 100, "main_tax": { "type": "IVA", "percentage": 0, "regime_key": "08" }, "exemption_reason": "NO_SUJETA_LOCALIZACION" } ``` **Related:** [TAX-006 · Services to a business abroad are not subject to Spanish VAT](/rules/taxes#tax-006) · [TAX-017 · Special regime keys carry the classification AEAT requires](/rules/taxes#tax-017) **Explained in:** [Regime keys](/verifactu/regime-keys) ## TAX-016 · Regime keys 03, 06 and 14 are not accepted `Required` · AEAT criterion · Impact: low · Checked by the API: a request that breaks it is rejected with the error codes listed. Regime keys `03` (used goods, art and antiques), `06` (group of entities, advanced level) and `14` (VAT pending accrual in public-works certifications) are rejected on a new invoice. An invoice under `03` must not show the VAT amount separately, while the invoice always states it; AEAT requires with `06` the cost-based taxable base, and with `14` an operation date after the issue date and a public-administration recipient, data the invoice does not carry. `GET /v1/tax-types` does not offer them, and the tax configuration does not accept them as the default regime key. Keys `05` (travel agencies) and `07` (cash basis) are accepted: the invoice PDF carries the mention of their regime ([CNT-015](/rules/contents#cnt-015), [CNT-013](/rules/contents#cnt-013)). The corrective of an invoice that already carried `03` keeps it. **Why:** An invoice under the used-goods regime with the VAT amount shown separately does not meet the invoicing regulation; a record under `06` or `14` without its data is rejected by AEAT after the invoice already has its number. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/companies/{company_id}/recurring-invoices`](/recurring-invoices/createCompanyRecurringInvoice), [`PUT /v1/configuration/taxes`](/tax-configuration/updateTaxConfiguration), [`PUT /v1/companies/{company_id}/tax-configuration`](/tax-configuration/updateCompanyTaxConfiguration); IVA and IGIC lines with regime key `03`, `06` or `14`. **Error codes:** [`REGIME_KEY_NOT_SUPPORTED`](/errors/REGIME_KEY_NOT_SUPPORTED) (`422`) **Legal basis:** - Real Decreto 1619/2012, Reglamento de facturación, art. 6.1 o) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «o) En caso de aplicación del régimen especial de los bienes usados, objetos de arte, antigüedades y objetos de colección, la mención «régimen especial de los bienes usados», «régimen especial de los objetos de arte» o «régimen especial de las antigüedades y objetos de colección».» - Real Decreto 1619/2012, Reglamento de facturación, art. 16.2 c) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a16) > «c) En las facturas que expidan los sujetos pasivos revendedores por las entregas sometidas al régimen especial no podrán consignar separadamente la cuota del Impuesto sobre el Valor Añadido repercutida, y esta deberá entenderse comprendida en el precio total de la operación.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.6.4 ClaveRegimen 06 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Si ClaveRegimen es igual a “06”: ✓ Se validará que TipoFactura sea distinto de “F2”, “F3”, “R5”. ✓ Campo BaseImponibleACoste deberá estar cumplimentado.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.6.9 ClaveRegimen 14 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «FechaOperacion, campo de cumplimentación obligatoria y posterior a fecha de expedición.» **Incorrect:** A line with regime key `03` or `14`: the API answers [`REGIME_KEY_NOT_SUPPORTED`](/errors/REGIME_KEY_NOT_SUPPORTED). **Correct:** Invoice the operation under the key that fits it, such as `01`. **Related:** [DAT-003 · The operation date is never after the issue date nor over twenty years old](/rules/dates#dat-003) · [TAX-017 · Special regime keys carry the classification AEAT requires](/rules/taxes#tax-017) · [COR-018 · A corrective can always correct what the original declared](/rules/corrective#cor-018) · [CNT-013 · A cash-basis invoice carries the mention «régimen especial del criterio de caja»](/rules/contents#cnt-013) · [CNT-015 · A travel-agency invoice carries the mention «régimen especial de las agencias de viajes»](/rules/contents#cnt-015) **Explained in:** [Regime keys](/verifactu/regime-keys) ## TAX-017 · Special regime keys carry the classification AEAT requires `Required` · AEAT criterion · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. Under regime key `04` (investment gold) it is reverse charge or exempt. Under `10` (collections on behalf of third parties) it is non-subject with `NO_SUJETA_ART_7_9`, on a standard invoice whose recipient is identified by NIF. Under `11` (business premises rental) an IVA line is subject at 21 %. **Why:** AEAT rejects a record whose classification, rate, invoice type or recipient does not match what its regime key allows, after the invoice already has its number. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/companies/{company_id}/recurring-invoices`](/recurring-invoices/createCompanyRecurringInvoice); IVA and IGIC lines with regime key `04`, `10` or `11`. **Error codes:** [`REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED`](/errors/REGIME_KEY_CLASSIFICATION_NOT_ACCEPTED) (`422`), [`REGIME_KEY_REQUIRES_VAT_RATE`](/errors/REGIME_KEY_REQUIRES_VAT_RATE) (`422`), [`REGIME_KEY_REQUIRES_STANDARD_INVOICE`](/errors/REGIME_KEY_REQUIRES_STANDARD_INVOICE) (`422`), [`REGIME_KEY_REQUIRES_RECIPIENT_NIF`](/errors/REGIME_KEY_REQUIRES_RECIPIENT_NIF) (`422`) **Legal basis:** - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.6.3 ClaveRegimen 04 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «si clave de ClaveRegimen es igual a “04”, CalificacionOperacion solo puede ser “S2”, o bien OperacionExenta.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.6.7 ClaveRegimen 10 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «✓ CalificacionOperacion tiene que ser “N1” y siempre debe ir relleno. ✓ TipoFactura tiene que ser “F1”. ✓ Todos los destinatarios tienen que estar identificado mediante NIF.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.6.8 ClaveRegimen 11 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «cuando ClaveRegimen sea “11”, únicamente se admitirá el TipoImpositivo = 21.» **Incorrect:** A business premises rental at 10 % under regime key `11`: the API answers [`REGIME_KEY_REQUIRES_VAT_RATE`](/errors/REGIME_KEY_REQUIRES_VAT_RATE). **Correct:** The rental at 21 % under regime key `11`. ```json { "description": "Office rent, October", "quantity": 1, "unit_price": 900, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "11" } } ``` **Related:** [TAX-015 · Regime key 08 means not subject to the line's tax](/rules/taxes#tax-015) · [CNT-014 · A used-goods, art or antiques invoice carries its regime mention](/rules/contents#cnt-014) · [TAX-016 · Regime keys 03, 06 and 14 are not accepted](/rules/taxes#tax-016) **Explained in:** [Regime keys](/verifactu/regime-keys) ## TAX-018 · An issued invoice does not use the intra-EU acquisition exemption `Required` · Law · Impact: low · Checked by the API: a request that breaks it is rejected with the error codes listed. Article 26 LIVA exempts intra-EU acquisitions of goods: an operation of the buyer, which the seller's invoice does not document. A line of an issued invoice with `EXENTA_ART_26` is rejected with [`EXEMPTION_NOT_FOR_ISSUED_INVOICE`](/errors/EXEMPTION_NOT_FOR_ISSUED_INVOICE). A supply of goods to another member state goes with `EXENTA_ART_25`. **Why:** Declaring on a sale the exemption of a purchase gives AEAT an exemption cause that does not match the operation invoiced. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/companies/{company_id}/recurring-invoices`](/recurring-invoices/createCompanyRecurringInvoice); Lines with `exemption_reason` `EXENTA_ART_26`. **Error codes:** [`EXEMPTION_NOT_FOR_ISSUED_INVOICE`](/errors/EXEMPTION_NOT_FOR_ISSUED_INVOICE) (`422`) **Legal basis:** - Ley 37/1992 del IVA, art. 26 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a26) > «Artículo 26. Exenciones en las adquisiciones intracomunitarias de bienes.» **Incorrect:** A supply of goods to a French company marked `EXENTA_ART_26`: the API answers [`EXEMPTION_NOT_FOR_ISSUED_INVOICE`](/errors/EXEMPTION_NOT_FOR_ISSUED_INVOICE). **Correct:** The intra-EU supply goes with the exemption of article 25. ```json { "description": "Machine parts", "quantity": 10, "unit_price": 120, "main_tax": { "type": "IVA", "percentage": 0 }, "exemption_reason": "EXENTA_ART_25" } ``` **Related:** [TAX-005 · Exempt and non-subject lines carry no VAT rate](/rules/taxes#tax-005) **Explained in:** [Tax classification per line](/verifactu/tax-classification) ## TAX-019 · An issuer that is not an individual never bears the IRPF rates of individuals `Required` · Law · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. Only individuals pay IRPF, so no entity bears its rates for individuals (1, 2, 7 and 15 %, and 6, 2.8 and 7.6 % in Ceuta and Melilla). Public (`A`) and private (`B`) limited companies, general (`C`) and limited (`D`) partnerships, cooperatives (`F`), associations (`G`), public bodies (`Q`), religious institutions (`R`) and temporary business associations (`U`) are legal persons and pay Corporate Income Tax; the permanent establishment of a non-resident entity (`W`) bears the Corporate Income Tax withholding regime. Their income bears withholding only when it is one of those the Corporate Income Tax regulation lists (rent of urban property, image rights, director fees, capital income…), at 19 %, or 24 % on image rights; any other income, such as a provision of services, bears none, and an exempt entity bears none on its exempt income. So their invoice lines, products, recurring templates and default configuration accept `irpf_rate` 0, 19 or 24 (and 9.5, see below), and a line created without `irpf_rate` never inherits a default they cannot bear: it gets 0. A non-resident entity (`N`) bears the Non-Residents Income Tax withholding: 24 %, or 19 % if it resides in the European Union or the European Economic Area, or 0 when the income is exempt or a tax treaty says so; it accepts 0, 19 or 24, and which one depends on facts the NIF does not show, so none is suggested. The State, the Autonomous Communities and the local entities (`S` and `P`) are fully exempt and their income bears no withholding: only 0. Any other rate is rejected with [`IRPF_RATE_NOT_FOR_CORPORATE_ISSUER`](/errors/IRPF_RATE_NOT_FOR_CORPORATE_ISSUER). Other issuers are not restricted: whether an individual's income bears 15 %, 7 %, 2 % or 1 % depends on the activity and its years, and `E`, `H`, `J` and `V` depend on facts the NIF does not show. Corrective invoices are not checked either: they correct by differences what the original carried. In Ceuta and Melilla the 19 % on rents of urban property there is halved, so a company or a permanent establishment can also use 9.5 (see [TAX-022](/rules/taxes#tax-022)). **Why:** The customer withholds and pays the Treasury what the invoice says; an entity's invoice at 15 % makes it withhold at a rate that does not exist for that income, or withhold where nothing had to be withheld. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/companies/{company_id}/recurring-invoices`](/recurring-invoices/createCompanyRecurringInvoice), [`POST /v1/companies/{company_id}/recurring-invoices/derivations`](/recurring-invoices/createCompanyRecurringInvoiceDerivation), [`PATCH /v1/companies/{company_id}/recurring-invoices/{recurring_invoice_id}`](/recurring-invoices/patchCompanyRecurringInvoice), [`PUT /v1/configuration/taxes`](/tax-configuration/updateTaxConfiguration), [`PUT /v1/companies/{company_id}/tax-configuration`](/tax-configuration/updateCompanyTaxConfiguration), [`POST /v1/products`](/products/createProduct), [`PUT /v1/products/{product_id}`](/products/updateProduct), [`PATCH /v1/products/{product_id}`](/products/patchProduct), [`POST /v1/products/bulk`](/products/createProductsBulk), [`POST /v1/companies/{company_id}/products`](/products/createCompanyProduct), [`PATCH /v1/companies/{company_id}/products/{product_id}`](/products/patchCompanyProduct), [`POST /v1/companies/{company_id}/products/bulk`](/products/createCompanyProductsBulk); Invoices other than corrective ones, recurring templates, products and the default tax configuration of an issuer whose NIF starts with `A`, `B`, `C`, `D`, `F`, `G`, `N`, `P`, `Q`, `R`, `S`, `U` or `W`. **Error codes:** [`IRPF_RATE_NOT_FOR_CORPORATE_ISSUER`](/errors/IRPF_RATE_NOT_FOR_CORPORATE_ISSUER) (`422`) **Legal basis:** - Ley 35/2006 del IRPF, art. 8.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2006-20764#a8) > «1. Son contribuyentes por este impuesto:» - Ley 35/2006 del IRPF, art. 8.1 a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2006-20764#a8) > «a) Las personas físicas que tengan su residencia habitual en territorio español.» - Orden EHA/451/2008, art. 3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a3) > «F. Sociedades cooperativas.» - Orden EHA/451/2008, art. 3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a3) > «G. Asociaciones.» - Orden EHA/451/2008, art. 3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a3) > «P. Corporaciones Locales.» - Orden EHA/451/2008, art. 3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a3) > «Q. Organismos públicos.» - Orden EHA/451/2008, art. 3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a3) > «R. Congregaciones e instituciones religiosas.» - Orden EHA/451/2008, art. 3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a3) > «S. Órganos de la Administración del Estado y de las Comunidades Autónomas.» - Orden EHA/451/2008, art. 4 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a4) > «Para las personas jurídicas y entidades sin personalidad jurídica que carezcan de la nacionalidad española, el número de identificación fiscal comenzará con la letra N, que indicará su carácter de entidad extranjera.» - Orden EHA/451/2008, art. 5.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a5) > «2. Para los establecimientos permanentes de entidades no residentes en territorio español, el número de identificación fiscal comenzará con la letra W, que indicará su carácter de establecimiento permanente de entidad no residente en territorio español.» - Ley 27/2014 del Impuesto sobre Sociedades, art. 9.1 a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2014-12328#a9) > «1. Estarán totalmente exentos del Impuesto:» - Ley 27/2014 del Impuesto sobre Sociedades, art. 9.1 a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2014-12328#a9) > «a) El Estado, las Comunidades Autónomas y las entidades locales.» - Real Decreto 634/2015, Reglamento del Impuesto sobre Sociedades, art. 61 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2015-7771#a61) > «No existirá obligación de retener ni de ingresar a cuenta respecto de:» - Real Decreto 634/2015, Reglamento del Impuesto sobre Sociedades, art. 61 o) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2015-7771#a61) > «o) Las rentas obtenidas por las entidades exentas a que se refiere el apartado 1 del artículo 9 de la Ley del Impuesto.» - Real Decreto Legislativo 5/2004, texto refundido de la Ley del Impuesto sobre la Renta de no Residentes, art. 23.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2004-4527#a23) > «1. Los establecimientos permanentes estarán sometidos al régimen de retenciones del Impuesto sobre Sociedades por las rentas que perciban» - Real Decreto Legislativo 5/2004, texto refundido de la Ley del Impuesto sobre la Renta de no Residentes, art. 5 a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2004-4527#a5) > «a) Las personas físicas y entidades no residentes en territorio español conforme al artículo 6 que obtengan rentas en él, salvo que sean contribuyentes por el Impuesto sobre la Renta de las Personas Físicas.» - Real Decreto Legislativo 5/2004, texto refundido de la Ley del Impuesto sobre la Renta de no Residentes, art. 31.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2004-4527#a31) > «2. Los sujetos obligados a retener deberán retener o ingresar a cuenta una cantidad equivalente a la que resulte de aplicar las disposiciones previstas en esta Ley para determinar la deuda tributaria correspondiente a los contribuyentes por este impuesto sin establecimiento permanente» - Real Decreto Legislativo 5/2004, texto refundido de la Ley del Impuesto sobre la Renta de no Residentes, art. 25.1 a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2004-4527#a25) > «a) Con carácter general el 24 por 100. No obstante, el tipo de gravamen será el 19 por ciento cuando se trate de contribuyentes residentes en otro Estado miembro de la Unión Europea o del Espacio Económico Europeo» - Real Decreto Legislativo 5/2004, texto refundido de la Ley del Impuesto sobre la Renta de no Residentes, art. 31.4 a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2004-4527#a31) > «a) Las rentas que estén exentas en virtud de lo dispuesto en el artículo 14 o en un convenio para evitar la doble imposición que resulte aplicable» - Ley 27/2014 del Impuesto sobre Sociedades, art. 7.1 a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2014-12328#a7) > «a) Las personas jurídicas, excluidas las sociedades civiles que no tengan objeto mercantil.» - Ley 27/2014 del Impuesto sobre Sociedades, art. 7.1 d) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2014-12328#a7) > «d) Las uniones temporales de empresas, reguladas en la Ley 18/1982, de 26 de mayo, sobre régimen fiscal de las agrupaciones y uniones temporales de Empresas y de las Sociedades de desarrollo industrial regional.» - Orden EHA/451/2008, art. 3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a3) > «A. Sociedades anónimas.» - Orden EHA/451/2008, art. 3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a3) > «B. Sociedades de responsabilidad limitada.» - Orden EHA/451/2008, art. 3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a3) > «C. Sociedades colectivas.» - Orden EHA/451/2008, art. 3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a3) > «D. Sociedades comanditarias.» - Orden EHA/451/2008, art. 3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2008-3580#a3) > «U. Uniones Temporales de Empresas.» - Real Decreto 634/2015, Reglamento del Impuesto sobre Sociedades, art. 60.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2015-7771#a60) > «1. Deberá practicarse retención, en concepto de pago a cuenta del Impuesto sobre Sociedades correspondiente al perceptor, respecto de:» - Real Decreto 634/2015, Reglamento del Impuesto sobre Sociedades, art. 60.1 c) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2015-7771#a60) > «c) Las contraprestaciones obtenidas como consecuencia de la atribución de cargos de administrador o consejero en otras sociedades.» - Real Decreto 634/2015, Reglamento del Impuesto sobre Sociedades, art. 60.1 d) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2015-7771#a60) > «d) Las rentas procedentes de la cesión del derecho a la explotación de la imagen o del consentimiento o autorización para su utilización, aun cuando constituyan ingresos derivados de explotaciones económicas.» - Real Decreto 634/2015, Reglamento del Impuesto sobre Sociedades, art. 60.1 e) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2015-7771#a60) > «e) Las rentas procedentes del arrendamiento o subarrendamiento de inmuebles urbanos, aun cuando constituyan ingresos derivados de explotaciones económicas.» - Real Decreto 634/2015, Reglamento del Impuesto sobre Sociedades, art. 66 a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2015-7771#a66) > «a) Con carácter general, el 19 por ciento. Cuando se trate de rentas procedentes del arrendamiento o subarrendamiento de inmuebles urbanos situados en Ceuta, Melilla o sus dependencias, obtenidas por entidades domiciliadas en dichos territorios o que operen en ellos mediante establecimiento o sucursal, dicho porcentaje se dividirá por dos.» - Real Decreto 634/2015, Reglamento del Impuesto sobre Sociedades, art. 66 b) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2015-7771#a66) > «b) En el caso de rentas procedentes de la cesión del derecho a la explotación de la imagen o del consentimiento o autorización para su utilización, el 24 por ciento.» - Ley 27/2014 del Impuesto sobre Sociedades, art. 128.6 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2014-12328#a128) > «a) Con carácter general, el 19 por ciento.» - Real Decreto 439/2007, Reglamento del IRPF, art. 95.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2007-6820#a95) > «1. Cuando los rendimientos sean contraprestación de una actividad profesional, se aplicará el tipo de retención del 15 por ciento sobre los ingresos íntegros satisfechos.» - Real Decreto 439/2007, Reglamento del IRPF, art. 101.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2007-6820#a101) > «No obstante, el porcentaje de retención e ingreso a cuenta sobre los rendimientos procedentes de la propiedad intelectual, cualquiera que sea su calificación, será del 15 por ciento» - Real Decreto 1065/2007, Reglamento General de gestión e inspección tributaria, art. 19.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2007-15984#a19) > «1. Para las personas físicas de nacionalidad española, el número de identificación fiscal será el número de su documento nacional de identidad seguido del correspondiente código o carácter de verificación» **Incorrect:** An SL (NIF `B…`) or an association (NIF `G…`) invoices a consultancy service with `irpf_rate: 15`: the API answers [`IRPF_RATE_NOT_FOR_CORPORATE_ISSUER`](/errors/IRPF_RATE_NOT_FOR_CORPORATE_ISSUER). **Correct:** The same SL invoices the rent of an office in Madrid: rent of urban property bears withholding, at 19 %. ```json { "description": "Office rent, October", "quantity": 1, "unit_price": 900, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "11" }, "irpf_rate": 19 } ``` **Related:** [TAX-017 · Special regime keys carry the classification AEAT requires](/rules/taxes#tax-017) · [TAX-022 · Reduced withholding rates of Ceuta and Melilla derive from their base rate](/rules/taxes#tax-022) ## TAX-022 · Reduced withholding rates of Ceuta and Melilla derive from their base rate `Required` · Law · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. Income with the Ceuta and Melilla deduction bears a reduced withholding, and the law gives the reduction, not the figure: under IRPF, the professional rates of 15 % and 7 % and the 19 % on rents of urban property located there are reduced by 60 %, giving 6 %, 2.8 % and 7.6 %; under Corporate Income Tax, the 19 % on those rents is halved, giving 9.5 %. Each reduced rate is accepted wherever its base rate is, with the reduction of the tax the issuer pays: an individual or an entity whose income is attributed to its members can use 6, 2.8 and 7.6; a company that pays Corporate Income Tax, or a permanent establishment of a non-resident entity, can use 9.5, and an individual sending 9.5 gets [`IRPF_RATE_ONLY_FOR_CORPORATE_ISSUER`](/errors/IRPF_RATE_ONLY_FOR_CORPORATE_ISSUER). Whether the issuer has the right to the reduction depends on where the income is obtained, which the NIF does not show: the issuer chooses it. The agricultural rates (1 % and 2 %) and the image-rights rate (24 %) have no reduction in the law, so no reduced rate derives from them. **Why:** Without the reduced rates an issuer entitled to the Ceuta and Melilla reduction cannot invoice the withholding the law sets, and its customer would withhold more than it must. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`POST /v1/companies/{company_id}/recurring-invoices`](/recurring-invoices/createCompanyRecurringInvoice), [`POST /v1/companies/{company_id}/recurring-invoices/derivations`](/recurring-invoices/createCompanyRecurringInvoiceDerivation), [`PATCH /v1/companies/{company_id}/recurring-invoices/{recurring_invoice_id}`](/recurring-invoices/patchCompanyRecurringInvoice), [`PUT /v1/configuration/taxes`](/tax-configuration/updateTaxConfiguration), [`PUT /v1/companies/{company_id}/tax-configuration`](/tax-configuration/updateCompanyTaxConfiguration); Lines, recurring templates and default tax configuration with an `irpf_rate` of 6, 2.8, 7.6 or 9.5. **Error codes:** [`IRPF_RATE_ONLY_FOR_CORPORATE_ISSUER`](/errors/IRPF_RATE_ONLY_FOR_CORPORATE_ISSUER) (`422`) **Legal basis:** - Ley 35/2006 del IRPF, art. 101.5 a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2006-20764#a101) > «Estos porcentajes se reducirán en un 60 por ciento cuando los rendimientos tengan derecho a la deducción en la cuota prevista en el artículo 68.4 de esta Ley.» - Ley 35/2006 del IRPF, art. 101.8 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2006-20764#a101) > «Este porcentaje se reducirá en un 60 por ciento cuando el inmueble esté situado en Ceuta o Melilla en los términos previstos en el artículo 68.4 de esta Ley.» - Real Decreto 439/2007, Reglamento del IRPF, art. 95.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2007-6820#a95) > «Estos porcentajes se reducirán en un 60 por ciento cuando los rendimientos tengan derecho a la deducción en la cuota prevista en el artículo 68.4 de la Ley del Impuesto.» - Real Decreto 439/2007, Reglamento del IRPF, art. 100 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2007-6820#a100) > «Este porcentaje se reducirá en el 60 por ciento cuando el inmueble urbano esté situado en Ceuta o Melilla, en los términos previstos en el artículo 68.4 de la Ley del Impuesto.» - Real Decreto 634/2015, Reglamento del Impuesto sobre Sociedades, art. 66 a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2015-7771#a66) > «Cuando se trate de rentas procedentes del arrendamiento o subarrendamiento de inmuebles urbanos situados en Ceuta, Melilla o sus dependencias, obtenidas por entidades domiciliadas en dichos territorios o que operen en ellos mediante establecimiento o sucursal, dicho porcentaje se dividirá por dos.» **Incorrect:** An individual rents an office in Melilla and invoices it with `irpf_rate: 9.5`: that is the Corporate Income Tax rate, and the API answers [`IRPF_RATE_ONLY_FOR_CORPORATE_ISSUER`](/errors/IRPF_RATE_ONLY_FOR_CORPORATE_ISSUER). **Correct:** The same individual invoices the rent with 7.6 % withholding: 19 % reduced by 60 %. ```json { "description": "Office rent in Melilla, October", "quantity": 1, "unit_price": 900, "main_tax": { "type": "IPSI", "percentage": 4, "regime_key": "01" }, "irpf_rate": 7.6 } ``` **Related:** [TAX-019 · An issuer that is not an individual never bears the IRPF rates of individuals](/rules/taxes#tax-019) [← All rules](/rules#all-rules) ## Related - [Tax classification per line](/verifactu/tax-classification) — set `exemption_reason` on each line correctly, with the full mapping from BeeL. API values to AEAT codes (S1/S2/N1/N2/E1–E6) - [Amounts and rounding](/guides/amounts-and-rounding) — how BeeL. turns quantities, prices and rates into bases, taxes and totals: precision, the three ways to price a line, per-group tax rounding, IRPF, and the amounts that are rejected - [International customers](/verifactu/international-customers) — every cross-border scenario — intra-EU B2B, B2C with OSS, exports, services to non-EU — with the exact request shape BeeL. accepts - [Regime keys](/verifactu/regime-keys) — the catalogue of VeriFactu regime codes BeeL. supports, when each one is required, and how it pairs with `exemption_reason` --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # Equivalence surcharge When a supply to a retailer carries the equivalence surcharge (*recargo de equivalencia*), at which rate, and on which invoice. [← All rules](/rules#all-rules) Retailers under the equivalence surcharge regime do not file VAT returns for those sales: their supplier charges the surcharge on top of VAT. These rules cover the rate on each line and how those supplies are invoiced. 2 rules: 2 from the law. [How to read a rule](/rules#how-to-read-a-rule). ## SUR-001 · The surcharge rate matches the VAT rate of its line `Required` · Law · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. A line sold to a retailer under the surcharge regime carries the surcharge rate the law pairs with that line's VAT rate, under regime key `18`: 5.2 or 1.75 (tobacco products) with 21 %, 1.4 with 10 %, 0.5 with 4 %, and the temporary pairs only on operations of their period: 0.5 with 5 % up to 31 December 2022, 0.62 with 5 % from 1 January 2023 to 30 September 2024, and 1 with 7.5 % and 0.26 with 2 % from 1 October to 31 December 2024. `GET /v1/tax-types` publishes every pair with its period. The former 0.625 is no longer accepted; an invoice issued with it is declared at 0.62. A draft saved with 0.625 is not issued as it stands: the API answers [`SURCHARGE_RATE_REQUIRES_RECALCULATION`](/errors/SURCHARGE_RATE_REQUIRES_RECALCULATION), and updating the draft recalculates the line at 0.62. BeeL. sets regime `18` on an IVA line that carries a surcharge and the general regime `01` on an IVA line under `18` that carries none. Add the surcharge only when the buyer has told you they are under the regime. **Why:** A surcharge that does not match the VAT rate charges the wrong tax, and AEAT does not accept the pair in the record. A surcharge under any other regime key is rejected. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; Supplies of goods to a retailer under the equivalence surcharge regime (regime key `18`). **Error codes:** [`INVALID_IVA_SURCHARGE_PAIR`](/errors/INVALID_IVA_SURCHARGE_PAIR) (`422`), [`SURCHARGE_REQUIRES_REGIME`](/errors/SURCHARGE_REQUIRES_REGIME) (`422`), [`REGIME_REQUIRES_SURCHARGE`](/errors/REGIME_REQUIRES_SURCHARGE) (`422`), [`SURCHARGE_RATE_NOT_ACCEPTED_ON_DATE`](/errors/SURCHARGE_RATE_NOT_ACCEPTED_ON_DATE) (`422`), [`SURCHARGE_RATE_REQUIRES_RECALCULATION`](/errors/SURCHARGE_RATE_REQUIRES_RECALCULATION) (`422`) **Legal basis:** - Ley 37/1992 del IVA, art. 161 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a161) > «Los tipos del recargo de equivalencia serán los siguientes: 1.º Con carácter general, el 5,2 por ciento. 2.º Para las entregas de bienes a las que resulte aplicable el tipo impositivo establecido en el artículo 91, apartado uno de esta Ley, el 1,4 por ciento. 3.º Para las entregas de bienes a las que sea aplicable el tipo impositivo previsto en el artículo 91, apartado dos de esta Ley, el 0,50 por ciento. 4.º Para las entregas de bienes objeto del Impuesto Especial sobre las Labores del Tabaco, el 1,75 por ciento.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.3 TipoRecargoEquivalencia — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Si TipoImpositivo es 21 sólo se admitirán TipoRecargoEquivalencia = 5,2 ó 1,75. - Si TipoImpositivo es 10 sólo se admitirá TipoRecargoEquivalencia = 1,4.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.3 TipoRecargoEquivalencia — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Si FechaOperacion (FechaExpedicionFactura de la agrupación IDFactura si no se informa FechaOperacion) es mayor o igual que 1 de enero de 2023 y menor o igual que 30 de septiembre de 2024, solo se admitirá TipoRecargoEquivalencia = 0,62.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.3 TipoRecargoEquivalencia — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Si FechaOperacion (FechaExpedicionFactura de la agrupación IDFactura si no se informa FechaOperacion) es igual o inferior al 31 de diciembre de 2022, solo se admitirá TipoRecargoEquivalencia = 0,5.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.3 TipoRecargoEquivalencia — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Si TipoImpositivo es 7,5 sólo se admitirá TipoRecargoEquivalencia = 1.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.15.3 TipoRecargoEquivalencia — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «Si TipoImpositivo es 2 sólo se admitirá TipoRecargoEquivalencia = 0,26.» - Real Decreto-ley 1/2023, disposición adicional decimosexta — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-625#da-16) > «Con efectos desde el 1 de enero de 2023, el tipo del recargo de equivalencia aplicable en el Impuesto sobre el Valor Añadido a las operaciones a que se refieren el apartado 2 del artículo 1 y el párrafo cuarto del apartado 1 del artículo 72 del Real Decreto-ley 20/2022, de 27 de diciembre, de medidas de respuesta a las consecuencias económicas y sociales de la Guerra de Ucrania y de apoyo a la reconstrucción de la isla de La Palma y a otras situaciones de vulnerabilidad, será del 0,62 por ciento» - AEAT, Nota informativa sobre los nuevos tipos de recargo de equivalencia en el IVA, Suministro inmediato de información — [source](https://sede.agenciatributaria.gob.es/Sede/iva/novedades-iva/novedades-normativa-2023/nota-informativa-nuevos-tipos-recargo-iva.html) > «En el caso de que se haya emitido una factura con recargo del 0,625%, independientemente de la factura rectificativa que proceda (emitida por sustitución o por diferencias), se podrá remitir un único registro de facturación con el tipo de recargo del 0,62%.» **Incorrect:** A 10 % line with the 5.2 surcharge: the API answers [`INVALID_IVA_SURCHARGE_PAIR`](/errors/INVALID_IVA_SURCHARGE_PAIR). **Correct:** A 21 % line with its 5.2 surcharge under regime `18`. ```json { "description": "Kitchen utensils (resale)", "quantity": 10, "unit_price": 12, "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "18" }, "equivalence_surcharge_rate": 5.2 } ``` **Related:** [SUR-002 · Supplies with the surcharge go on separate invoices](/rules/surcharge#sur-002) · [TAX-003 · Reverse-charge lines carry no tax and never go on a simplified invoice](/rules/taxes#tax-003) **Explained in:** [Equivalence surcharge (recargo de equivalencia) › Accepted surcharge values](/verifactu/equivalence-surcharge#accepted-surcharge-values) · [Equivalence surcharge (recargo de equivalencia) › When you add the surcharge](/verifactu/equivalence-surcharge#when-you-add-the-surcharge) ## SUR-002 · Supplies with the surcharge go on separate invoices `Required` · Law · Impact: low · Responsibility: the issuing business. Document the supplies that carry the equivalence surcharge on their own invoices, stating the surcharge rate and amount. **Why:** The law requires separate invoices for these supplies; an invoice that mixes them does not meet the invoicing obligations. **Applies to:** invoice types `STANDARD`, `CORRECTIVE`; Supplies of goods on which the equivalence surcharge is charged. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 16.4 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a16) > «Los empresarios o profesionales que efectúen entregas de bienes en las que deba repercutirse el recargo de equivalencia deberán, en todo caso, expedir facturas separadas para documentar dichas entregas, consignando en ellas el tipo del recargo que se haya aplicado y su importe.» **Incorrect:** One invoice to a retailer with goods for resale under the surcharge and a repair service without it. **Correct:** Two invoices: one for the goods with the surcharge, one for the service. **Related:** [SUR-001 · The surcharge rate matches the VAT rate of its line](/rules/surcharge#sur-001) **Explained in:** [Equivalence surcharge (recargo de equivalencia) › The surcharge is per-line, not per-invoice](/verifactu/equivalence-surcharge#the-surcharge-is-per-line-not-per-invoice) [← All rules](/rules#all-rules) ## Related - [Equivalence surcharge (recargo de equivalencia)](/verifactu/equivalence-surcharge) — when to add `equivalence_surcharge_rate` on B2B lines, the surcharge values BeeL. accepts and their periods, and how the line is sent to AEAT --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # Dates and deadlines The dates an invoice carries and the deadlines for issuing it, sending it and charging its VAT. [← All rules](/rules#all-rules) An invoice has two dates: the issue date, which BeeL. sets when you issue, and the operation date, which you send when the sale happened on another day. The law also sets when an invoice has to be issued and delivered; those deadlines are the issuer's to keep. 14 rules: 11 from the law, 2 AEAT criteria, 1 BeeL. rule. [How to read a rule](/rules#how-to-read-a-rule). ## DAT-001 · Do not send an issue date `Required` · BeeL. rule · Impact: critical · Checked by the API: BeeL. applies it. The API has no writable issue date: an invoice is dated the day it is issued, and a scheduled one the day it is scheduled for. To record when the sale happened, send `operation_date`. **Why:** Backdating or postdating an invoice is not possible: the issue date is the day its billing record is generated. An integration that tries to set it ends up with invoices dated differently from what it expects. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice) **Incorrect:** Trying to send an issue date set to the last day of the previous month to close the month's invoicing. **Correct:** Issuing today, with the date the service was provided as `operation_date`. ```json { "operation_date": "2026-08-31", "lines": [{ "description": "August maintenance", "quantity": 1, "unit_price": 300, "main_tax": { "type": "IVA", "percentage": 21 } }] } ``` **Related:** [DAT-002 · The issue date is the day the billing record is generated](/rules/dates#dat-002) · [DAT-004 · Send the operation date when it differs from the issue date](/rules/dates#dat-004) · [LIF-002 · Only a draft can be issued](/rules/lifecycle#lif-002) **Explained in:** [Invoice lifecycle › Dates](/guides/invoice-lifecycle#dates) ## DAT-002 · The issue date is the day the billing record is generated `Required` · AEAT criterion · Impact: high · Checked by the API: BeeL. applies it. An invoice's issue date is the date its billing record is generated, which is also, as a rule, the day the record is sent: it cannot be later than today nor set to an earlier day. BeeL. dates the invoice when you issue it. **Why:** An issue date that does not match the record's makes the record inconsistent; AEAT rejects an issue date in the future. **Applies to:** statuses `ISSUED`; Invoices under VeriFactu. **Legal basis:** - 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 fecha de expedición de la factura debe coincidir con la de generación del registro de facturación. Ambas fechas, generalmente deben corresponderse con la fecha en que se remite el Registro de facturación.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.1 Agrupación IDFactura — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «La FechaExpedicionFactura no podrá ser superior a la fecha actual.» - 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.» **Incorrect:** Keeping a month of invoices as drafts and expecting them to carry the dates of each sale when you issue them at month end. **Correct:** Issuing each invoice when the sale happens, or issuing later with each sale's date as `operation_date` and within the deadlines. **Related:** [DAT-001 · Do not send an issue date](/rules/dates#dat-001) · [DAT-006 · Invoice businesses before day 16 of the following month](/rules/dates#dat-006) · [REC-002 · The record goes to AEAT as soon as the invoice is issued](/rules/records#rec-002) **Explained in:** [What AEAT receives from your invoice › Dates and late submission](/verifactu/what-aeat-receives#dates-and-late-submission) · [Invoice lifecycle › Dates](/guides/invoice-lifecycle#dates) ## DAT-003 · The operation date is never after the issue date nor over twenty years old `Required` · AEAT criterion · Impact: medium · Checked by the API: a request that breaks it is rejected with the error codes listed. `operation_date` is the day the operation took place or the advance payment was received, so it cannot be later than the issue date. It cannot be more than twenty years before the issue date either. To bill before delivering, invoice the advance payment with the day you received it. **Why:** AEAT does not accept an operation dated in the future except in two special regimes, nor one dated more than twenty years back; an invoice dated before the operation it documents is not consistent. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice) **Error codes:** [`OPERATION_DATE_AFTER_ISSUE_DATE`](/errors/OPERATION_DATE_AFTER_ISSUE_DATE) (`422`), [`OPERATION_DATE_TOO_OLD`](/errors/OPERATION_DATE_TOO_OLD) **Legal basis:** - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.7 FechaOperacion — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «el campo FechaOperacion solo podrá ser superior a la fecha actual, si ClaveRegimen= "14" o "15”.» - AEAT, Validaciones y errores VERI*FACTU (v1.2.2), 3.1.3.7 FechaOperacion — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validaciones_Errores_Veri-Factu.pdf) > «La FechaOperacion no debe ser inferior a la fecha actual menos veinte años y no debe ser superior al año siguiente de la fecha actual.» **Incorrect:** Issuing today an invoice for next week's delivery with that date as `operation_date`: the API answers [`OPERATION_DATE_AFTER_ISSUE_DATE`](/errors/OPERATION_DATE_AFTER_ISSUE_DATE). **Correct:** Issuing the invoice on the delivery day, or invoicing now the advance payment you already received. **Related:** [DAT-004 · Send the operation date when it differs from the issue date](/rules/dates#dat-004) · [DAT-010 · Invoice advance payments when you receive them](/rules/dates#dat-010) **Explained in:** [Invoice lifecycle › Dates](/guides/invoice-lifecycle#dates) ## DAT-004 · Send the operation date when it differs from the issue date `Required` · Law · Impact: high · Responsibility: your integration. When the goods were delivered, the service provided or the advance received on a day other than the issue date, send that day as `operation_date`. Omitted, the invoice takes the issue date as the operation date. **Why:** The operation date decides the VAT rate and the tax period. Without it, an invoice issued in October for a September sale says the sale happened in October. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices`](/invoices/createCompanyInvoice), [`PATCH /v1/companies/{company_id}/invoices/{invoice_id}`](/invoices/patchCompanyInvoice) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.1.i) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «La fecha en que se hayan efectuado las operaciones que se documentan o en la que, en su caso, se haya recibido el pago anticipado, siempre que se trate de una fecha distinta a la de expedición de la factura.» **Incorrect:** Issuing on 2 October the invoice for work finished on 30 September without `operation_date`. **Correct:** Sending the day the work was finished. ```json { "operation_date": "2026-09-30", "lines": [{ "description": "Website redesign", "quantity": 1, "unit_price": 2400, "main_tax": { "type": "IVA", "percentage": 21 } }] } ``` **Related:** [DAT-001 · Do not send an issue date](/rules/dates#dat-001) · [DAT-003 · The operation date is never after the issue date nor over twenty years old](/rules/dates#dat-003) · [TAX-001 · Apply the VAT rate in force when the operation took place](/rules/taxes#tax-001) **Explained in:** [Invoice lifecycle › Dates](/guides/invoice-lifecycle#dates) ## DAT-005 · Invoice consumers when the operation takes place `Required` · Law · Impact: medium · Responsibility: the issuing business. When the customer is a consumer, issue the invoice at the moment the operation is performed. **Why:** An invoice to a consumer issued days later breaks the issuing deadline, and under VeriFactu its record reaches AEAT late too. **Applies to:** Operations with a recipient that is not a business or professional acting as such. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 11.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a11) > «Las facturas deberán ser expedidas en el momento de realizarse la operación.» **Incorrect:** An online shop collects the day's orders and issues their invoices the following week. **Correct:** The shop issues each invoice when the order is completed. **Related:** [DAT-006 · Invoice businesses before day 16 of the following month](/rules/dates#dat-006) · [DAT-002 · The issue date is the day the billing record is generated](/rules/dates#dat-002) ## DAT-006 · Invoice businesses before day 16 of the following month `Required` · Law · Impact: medium · Responsibility: the issuing business. When the customer is a business or professional, issue the invoice before day 16 of the month after the one in which the VAT accrued. **Why:** An invoice issued after the deadline breaches the invoicing obligations and can be sanctioned, even though the sale was declared. **Applies to:** Operations with a business or professional acting as such. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 11.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a11) > «No obstante, cuando el destinatario de la operación sea un empresario o profesional que actúe como tal, las facturas deberán expedirse antes del día 16 del mes siguiente a aquél en que se haya producido el devengo del Impuesto correspondiente a la citada operación.» **Incorrect:** Invoicing on 20 October a service to a company that was completed on 25 September. **Correct:** Issuing that invoice by 15 October, with `operation_date` set to 25 September. **Related:** [DAT-005 · Invoice consumers when the operation takes place](/rules/dates#dat-005) · [DAT-007 · One invoice for a month of operations, issued in time](/rules/dates#dat-007) · [DAT-008 · Deliver the invoice to the customer in time](/rules/dates#dat-008) · [DAT-013 · Intra-EU supplies of goods are invoiced by the month after transport starts](/rules/dates#dat-013) · [DAT-014 · Under the cash-basis regime, the deadline runs from the operation, not the payment](/rules/dates#dat-014) ## DAT-007 · One invoice for a month of operations, issued in time `Required` · Law · Impact: low · Responsibility: the issuing business. You may put several operations for the same customer in one invoice only if they all took place in the same calendar month. Issue it by the last day of that month or, when the customer is a business, before day 16 of the next one. **Why:** Grouping operations from different months in one invoice, or issuing it late, breaches the invoicing rules even when every operation is on it. **Applies to:** Recapitulative invoices: several operations for the same customer in one invoice. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 13.1 y 13.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a13) > «Podrán incluirse en una sola factura distintas operaciones realizadas en distintas fechas para un mismo destinatario, siempre que las mismas se hayan efectuado dentro de un mismo mes natural. 2. Estas facturas deberán ser expedidas como máximo el último día del mes natural en el que se hayan efectuado las operaciones que se documenten en ellas.» **Incorrect:** One invoice to a company for deliveries made between 20 August and 10 September. **Correct:** One invoice for the August deliveries and another for the September ones, each issued in time. **Related:** [DAT-006 · Invoice businesses before day 16 of the following month](/rules/dates#dat-006) · [DAT-004 · Send the operation date when it differs from the issue date](/rules/dates#dat-004) ## DAT-008 · Deliver the invoice to the customer in time `Required` · Law · Impact: low · Responsibility: the issuing business. Send the original invoice to the customer when you issue it or, when the customer is a business, before day 16 of the month after the accrual. BeeL. can email it for you. **Why:** An invoice the customer never receives cannot be deducted by them, and delivering it is an obligation of the issuer. **Applies to:** statuses `ISSUED`; operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/send`](/invoices/sendCompanyInvoice), [`POST /v1/companies/{company_id}/invoices/deliveries`](/invoices/createCompanyInvoiceDelivery) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 18 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a18) > «La obligación de remisión de las facturas que se establece en el artículo 17 deberá cumplirse en el mismo momento de su expedición o bien, cuando el destinatario sea un empresario o profesional que actúe como tal, antes del día 16 del mes siguiente a aquél en que se haya producido el devengo del Impuesto» **Incorrect:** Issuing invoices through the API and never delivering them, assuming AEAT's record reaches the customer. **Correct:** Emailing the PDF from BeeL. once it is ready, or delivering it through your own channel. **Related:** [DAT-006 · Invoice businesses before day 16 of the following month](/rules/dates#dat-006) · [CNT-018 · Invoices go by email only with the recipient's consent](/rules/contents#cnt-018) **Explained in:** [Sending email](/guides/sending-email) ## DAT-009 · VAT is charged by invoice within 1 year of accrual `Required` · Law · Impact: low · Responsibility: the issuing business. VAT is passed on to the customer through an invoice, and the right to charge it is lost 1 year after the VAT accrued. The duty to invoice the operation remains after that. **Why:** Invoicing or correcting upwards after that window leaves the issuer paying a VAT it can no longer charge to the customer. **Applies to:** Every operation that accrues VAT. **Legal basis:** - Ley 37/1992 del IVA, art. 88.Cuatro — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a88) > «Se perderá el derecho a la repercusión cuando haya transcurrido un año desde la fecha del devengo.» **Incorrect:** Leaving an operation uninvoiced for more than a year, so the VAT on it can no longer be charged to the customer. **Correct:** Reconciling unbilled operations every month, so each is invoiced within the deadlines. **Related:** [DAT-006 · Invoice businesses before day 16 of the following month](/rules/dates#dat-006) · [COR-006 · Issue the corrective as soon as you know, within 4 years](/rules/corrective#cor-006) ## DAT-010 · Invoice advance payments when you receive them `Required` · Law · Impact: low · Responsibility: the issuing business. A payment received before the operation is invoiced too, with the day you received it as `operation_date`; the final invoice then covers the rest. Exempt intra-EU supplies of goods are the exception. **Why:** VAT accrues when an advance is received, so an advance without its invoice leaves VAT accrued and never charged. **Applies to:** Payments received before the goods are delivered or the service is provided. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 2.1, párrafo segundo — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a2-2) > «También deberá expedirse factura y copia de esta por los pagos recibidos con anterioridad a la realización de las entregas de bienes o prestaciones de servicios por las que deba asimismo cumplirse esta obligación conforme al párrafo anterior, a excepción de las entregas de bienes exentas del Impuesto sobre el Valor Añadido por aplicación de lo dispuesto en el artículo 25 de la Ley del Impuesto.» **Incorrect:** Collecting a 30 % deposit on a kitchen installation and invoicing everything only when the work is finished. **Correct:** Invoicing the deposit the day it is received, and the remaining 70 % when the installation is completed. **Related:** [DAT-003 · The operation date is never after the issue date nor over twenty years old](/rules/dates#dat-003) · [DAT-004 · Send the operation date when it differs from the issue date](/rules/dates#dat-004) ## DAT-011 · Adapted billing systems are mandatory from 1 January 2027 or 1 July 2027 `Required` · Law · Impact: medium · Responsibility: the issuing business. Corporate-tax payers must invoice with a billing system adapted to the regulation before 1 January 2027, and the other taxpayers of its art. 3.1 before 1 July 2027. **Why:** These dates were set by the RD-ley 15/2025, which amended the RD 1007/2023; from them on, these taxpayers invoice through an adapted billing system. **Applies to:** Taxpayers under the billing-systems regulation; those keeping their VAT books through the SII are outside it. **Legal basis:** - RD 1007/2023 (RRSIF), disposición final cuarta — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2023-24840#df-4) > «los obligados tributarios a que se refiere el artículo 3.1.a) deberán tener adaptados los sistemas informáticos a las características y requisitos establecidos en este reglamento y en su normativa de desarrollo antes del 1 de enero de 2027. El resto de obligados tributarios mencionados en el artículo 3.1 deberán tener operativos los citados sistemas informáticos antes del 1 de julio de 2027.» - Real Decreto-ley 15/2025, disposición final primera — [source](https://www.boe.es/diario_boe/txt.php?id=BOE-A-2025-24446) > «Disposición final primera. Modificación del Real Decreto 1007/2023, de 5 de diciembre. La disposición final cuarta queda redactada en los siguientes términos:» **Incorrect:** A company subject to corporate tax plans its switch to an adapted billing system for spring 2027. **Correct:** The company enables VeriFactu and tests its integration in the sandbox during 2026. **Related:** [REC-001 · Each issued invoice gets a billing record built from its data](/rules/records#rec-001) · [LIF-003 · Test in the sandbox, never with real invoices](/rules/lifecycle#lif-003) **Explained in:** [Overview › At a glance](/verifactu#at-a-glance) ## DAT-012 · Plan for mandatory B2B electronic invoices `Recommended` · Law · Impact: low · Responsibility: the issuing business. Once the ministerial order that RD 238/2026 depends on is in force, businesses will have to issue structured electronic invoices to other Spanish businesses, first the largest ones and later the rest. Until that order is published the obligation does not apply; watch for it. **Why:** The deadline starts counting from an order that has not been published yet, and adapting invoicing to structured formats takes time. **Applies to:** Invoices to businesses and professionals established in Spain, once RD 238/2026 applies. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 8 bis.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a8-2) > «Será obligatoria la factura electrónica en las condiciones establecidas en la Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la sociedad de la Información, y en su normativa de desarrollo cuando el destinatario de la operación sea un empresario o profesional que tenga en España la sede de su actividad económica» - RD 238/2026, disposición final cuarta — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2026-7295#df-4) > «la aplicación efectiva de este real decreto quedará diferida en los siguientes términos, contados desde la entrada en vigor de la orden ministerial prevista en el apartado 1 de la disposición final tercera» **Incorrect:** Assuming a PDF sent by email will keep being enough for every business customer indefinitely. **Correct:** Tracking the publication of the ministerial order and planning a structured format for invoices to Spanish businesses. **Related:** [CNT-018 · Invoices go by email only with the recipient's consent](/rules/contents#cnt-018) · [QRC-010 · A structured e-invoice carries the QR URL as a field](/rules/qr#qrc-010) ## DAT-013 · Intra-EU supplies of goods are invoiced by the month after transport starts `Required` · Law · Impact: low · Responsibility: the issuing business. Invoice an intra-EU supply of goods before day 16 of the month after the one in which the goods start to be shipped or transported to the buyer, also when several supplies go on one recapitulative invoice. **Why:** For these supplies the deadline runs from the start of the transport, not from the general rule of the month after accrual. **Applies to:** Intra-EU supplies of goods exempt under art. 25 LIVA. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 11.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a11) > «En las entregas de bienes comprendidas en el artículo 75.Uno.8.º de la Ley del Impuesto, las facturas deberán expedirse antes del día 16 del mes siguiente a aquél en que se inicie la expedición o el transporte de los bienes con destino al adquirente.» - RD 1619/2012 (Reglamento de facturación), art. 13.3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a13) > «En las entregas de bienes comprendidas en el artículo 75.Uno.8.º de la Ley del Impuesto, las facturas deberán expedirse antes del día 16 del mes siguiente a aquél en que se inicie la expedición o el transporte de los bienes con destino al adquirente.» **Incorrect:** Goods leave for a buyer in Germany on 28 September and the invoice is issued on 20 October. **Correct:** The same invoice issued by 15 October. **Related:** [DAT-006 · Invoice businesses before day 16 of the following month](/rules/dates#dat-006) · [DAT-007 · One invoice for a month of operations, issued in time](/rules/dates#dat-007) · [TAX-004 · Intra-EU supplies of goods are exempt only with the buyer's EU VAT number](/rules/taxes#tax-004) ## DAT-014 · Under the cash-basis regime, the deadline runs from the operation, not the payment `Required` · Law · Impact: low · Responsibility: the issuing business. Under the special cash-basis regime, issue the invoice when the operation takes place or, when the customer is a business or professional acting as such, before day 16 of the month after the one in which the operation took place, even though the VAT accrues on payment. **Why:** Under this regime the VAT accrues later, but the invoicing deadline does not move with it. **Applies to:** Operations under the special cash-basis regime (regime key `07`). **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 11.3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a11) > «En las operaciones acogidas al régimen especial del criterio de caja regulado en el Capítulo X del Título IX de la Ley del Impuesto, la expedición de la factura deberá realizarse en el momento de la realización de tales operaciones, salvo cuando el destinatario de la operación sea un empresario o profesional que actúe como tal, en cuyo caso deberán expedirse antes del día 16 del mes siguiente a aquel en que se haya realizado la operación.» **Incorrect:** A cash-basis business waits for a client's payment in November to invoice a service delivered in August. **Correct:** It invoices the service by 15 September, with regime key `07`. **Related:** [DAT-006 · Invoice businesses before day 16 of the following month](/rules/dates#dat-006) · [CNT-013 · A cash-basis invoice carries the mention «régimen especial del criterio de caja»](/rules/contents#cnt-013) · [TAX-016 · Regime keys 03, 06 and 14 are not accepted](/rules/taxes#tax-016) [← All rules](/rules#all-rules) ## Related - [Invoice lifecycle](/guides/invoice-lifecycle) — every invoice status, which operations each one allows, and the difference between the fiscal steps (issue, void, correct) and the commercial ones (sent, paid) - [Sending email](/guides/sending-email) — how BeeL. delivers invoice emails — the sandbox recipient restriction, per-account send quotas, queued delivery, and bulk limits - [Overview](/verifactu) — how BeeL. handles VeriFactu compliance — what BeeL. does for you, what you control, and where to learn each scenario - [What AEAT receives from your invoice](/verifactu/what-aeat-receives) — how BeeL. turns your invoice into the record AEAT registers — the description, the total, the number, the recipient and the late-submission flag — and why some of them differ from what you see on the invoice --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # QR code and PDF The tax QR code on every invoice: when it exists, what it encodes, and how any document that carries it presents it. [← All rules](/rules#all-rules) Every invoice issued with a billing system carries a QR code that lets its recipient check it with AEAT. The API returns the QR data with the invoice; these rules apply to any document that carries it. 10 rules: 6 from the law, 3 AEAT criteria, 1 BeeL. rule. [How to read a rule](/rules#how-to-read-a-rule). ## QRC-001 · Every invoice carries the tax QR code `Required` · Law · Impact: high · Responsibility: your integration. An invoice issued with a billing system carries the tax QR code, whether it is a full or a simplified invoice, on any document of the invoice. The invoice's `verifactu` block returns the QR data: `qr_url` and `qr_base64`. **Why:** The QR is how the recipient checks the invoice with AEAT. A document without it is not the invoice the regulation describes. **Applies to:** Invoices of a company under VeriFactu, full or simplified. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.5.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «La representación gráfica del contenido parcial de la factura mediante un código “QR”.» - RD 1619/2012 (Reglamento de facturación), art. 7.5 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a7) > «deberá incluirse, además, lo contenido en el apartado 5 del artículo 6 de este Reglamento.» **Incorrect:** Sending the customer a document of your own with the invoice data and no QR. **Correct:** Printing the invoice's QR (`qr_base64`, or `qr_url` encoded) on every document of the invoice you hand over. **Related:** [QRC-002 · Wait for the QR before you distribute the PDF](/rules/qr#qrc-002) · [QRC-005 · Use qr_url exactly as returned](/rules/qr#qrc-005) · [QRC-003 · The QR measures between 30 mm and 40 mm](/rules/qr#qrc-003) **Explained in:** [QR code and the invoice PDF](/verifactu/qr-and-pdf) · [QR code and the invoice PDF › Rendering your own PDF](/verifactu/qr-and-pdf#rendering-your-own-pdf) ## QRC-002 · Wait for the QR before you distribute the PDF `Required` · BeeL. rule · Impact: critical · Responsibility: your integration. The API also answers the error codes listed. Do not render or send a document of an invoice under VeriFactu before its QR data exists. Wait for the `invoice.pdf.generated` webhook, or read the invoice until `verifactu.qr_url` is present. The API applies the same rule to its own PDF: it is painted once, with the QR, and never modified afterwards — voiding or correcting the invoice does not change it. Asking for the PDF of an invoice whose record ended without QR data answers `INVOICE_NOT_REGISTERED_NO_PDF`; an email requested before the PDF exists is accepted with `202` and sent when the PDF is stored, or recorded as failed if the record ends without QR data. **Why:** A document rendered without the QR data cannot carry the QR the invoice needs. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices/{invoice_id}/issue`](/invoices/issueCompanyInvoice), [`GET /v1/companies/{company_id}/invoices/{invoice_id}/pdf`](/invoices/getCompanyInvoicePdf), [`POST /v1/companies/{company_id}/invoices/{invoice_id}/send`](/invoices/sendCompanyInvoice); Invoices of a company under VeriFactu. **Error codes:** [`INVOICE_NOT_REGISTERED_NO_PDF`](/errors/INVOICE_NOT_REGISTERED_NO_PDF) (`400`) **Incorrect:** Rendering your own PDF before the invoice carries `qr_url`. **Correct:** Waiting for the `invoice.pdf.generated` webhook, or reading the invoice again until `verifactu.qr_url` is present. **Related:** [QRC-001 · Every invoice carries the tax QR code](/rules/qr#qrc-001) · [REC-008 · Follow submission_status and fix what AEAT rejects](/rules/records#rec-008) **Explained in:** [QR code and the invoice PDF › The PDF and the QR](/verifactu/qr-and-pdf#the-pdf-and-the-qr) · [QR code and the invoice PDF › The QR exists from PENDING](/verifactu/qr-and-pdf#the-qr-exists-from-pending) ## QRC-003 · The QR measures between 30 mm and 40 mm `Required` · Law · Impact: medium · Responsibility: your integration. The QR code printed on an invoice measures at least 30 mm × 30 mm and at most 40 mm × 40 mm. **Why:** A smaller QR may not scan, and the Orden fixes the range: neither smaller nor larger. **Applies to:** Any document that carries the QR, including one you render. **Legal basis:** - Orden HAC/1177/2024, art. 21.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138#a2-3) > «El código «QR» deberá tener un tamaño entre 30x30 y 40x40 milímetros y seguir las especificaciones de la norma ISO/IEC 18004.» - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Remisión de información por el receptor / QR — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/posibilidad-remision-informacion-factura-parte-receptor.html) > «no puede ser menor de 30x30 mm no puede ser mayor de 40x40 mm.» **Incorrect:** Scaling the `qr_base64` image down to fit a narrow header. **Correct:** Placing the image at a fixed physical size inside the range, whatever the page layout. **Related:** [QRC-004 · The QR follows ISO/IEC 18004 with error correction M](/rules/qr#qrc-004) · [QRC-009 · Keep a blank margin around the QR](/rules/qr#qrc-009) · [QRC-008 · The QR goes once, at the start of the first page](/rules/qr#qrc-008) **Explained in:** [QR code and the invoice PDF › Rendering your own PDF](/verifactu/qr-and-pdf#rendering-your-own-pdf) ## QRC-004 · The QR follows ISO/IEC 18004 with error correction M `Required` · Law · Impact: low · Responsibility: your integration. A QR code generated for an invoice follows ISO/IEC 18004 and uses error-correction level M. Set it when you encode `qr_url` with your own library. **Why:** Other levels change the density of the code, and the Orden fixes this one. **Applies to:** A QR you generate yourself from `qr_url`. **Legal basis:** - Orden HAC/1177/2024, art. 21.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138#a2-3) > «Para la generación del código «QR» se empleará el nivel M (medio) de corrección de errores.» **Incorrect:** Encoding `qr_url` with a library that defaults to error-correction level L. **Correct:** Encoding it with level M, or printing `qr_base64` unchanged. **Related:** [QRC-003 · The QR measures between 30 mm and 40 mm](/rules/qr#qrc-003) · [QRC-005 · Use qr_url exactly as returned](/rules/qr#qrc-005) **Explained in:** [QR code and the invoice PDF › Rendering your own PDF](/verifactu/qr-and-pdf#rendering-your-own-pdf) ## QRC-005 · Use qr_url exactly as returned `Required` · Law · Impact: high · Checked by the API: BeeL. applies it. Do not build or change the URL the QR encodes: use `qr_url` as BeeL. returns it. It carries only the four parameters AEAT requires, the issuer NIF, the number, the issue date and the amount AEAT registered. **Why:** The URL has to match the registered record. A URL built from your own invoice total, or with extra parameters, points AEAT at an invoice that does not exist. **Applies to:** Invoices of a company under VeriFactu. **Legal basis:** - Orden HAC/1177/2024, art. 21.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138#a2-3) > «b) Información de la factura que formará parte de la «URL»: 1.º NIF del obligado a expedir la factura. 2.º Número de serie y número de la factura expedida. 3.º Fecha de expedición de la factura. 4.º Importe total de la factura.» - AEAT, Detalle de las especificaciones técnicas del código QR de la factura (v0.5.0), apartado 6 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/DetalleEspecificacTecnCodigoQRfactura.pdf) > «IMPORTANTE: este parámetro nunca podrá incorporarse en la «URL» que va en el código «QR» de la factura» **Incorrect:** Rebuilding the URL from your own data, with the invoice total including IRPF, or adding `formato=json`. **Correct:** Encoding the `qr_url` string from the invoice, unchanged. ```json { "verifactu": { "qr_url": "https://www2.agenciatributaria.gob.es/wlpl/TIKE-CONT/ValidarQR?nif=B27534239&numserie=S-2026-0001&fecha=19-09-2026&importe=121.00" } } ``` **Related:** [QRC-001 · Every invoice carries the tax QR code](/rules/qr#qrc-001) · [QRC-004 · The QR follows ISO/IEC 18004 with error correction M](/rules/qr#qrc-004) **Explained in:** [QR code and the invoice PDF › Rendering your own PDF](/verifactu/qr-and-pdf#rendering-your-own-pdf) · [What AEAT receives from your invoice › The total](/verifactu/what-aeat-receives#the-total) ## QRC-006 · The VeriFactu legend goes just below the QR `Required` · Law · Impact: medium · Responsibility: your integration. Just below the QR, print «Factura verificable en la sede electrónica de la AEAT» or «VERI*FACTU», preferably centred on it. The Orden asks for a type and size clearly visible and similar to the rest of the invoice data; AEAT's specification, for one equal to or larger than it. Print it only on invoices whose record goes to AEAT. **Why:** The legend tells the recipient the invoice was sent to AEAT and can be checked there; on an invoice that was not, it would say something false. **Applies to:** Any document that carries the QR of an invoice registered under VeriFactu. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 6.5.b) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a6) > «Estas facturas, sean electrónicas o no, incorporarán además la frase “Factura verificable en la sede electrónica de la AEAT” o “VERI*FACTU” únicamente en aquellos casos en los que el sistema informático realice la remisión de todos los registros de facturación a la Agencia Estatal de Administración Tributaria» - Orden HAC/1177/2024, art. 20.1.b) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138#a2-2) > «la frase «Factura verificable en la sede electrónica de la AEAT» o «VERI*FACTU», que deberá tener un tipo de letra y tamaño bien visibles, similares a los del resto de datos de la factura.» - AEAT, Detalle de las especificaciones técnicas del código QR de la factura (v0.5.0), apartado 3 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/DetalleEspecificacTecnCodigoQRfactura.pdf) > «justo debajo del código «QR» deberá aparecer la frase «Factura verificable en la sede electrónica de la AEAT» o «VERI*FACTU», preferiblemente centrada con respecto al código «QR».» - AEAT, Detalle de las especificaciones técnicas del código QR de la factura (v0.5.0), apartado 3 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/DetalleEspecificacTecnCodigoQRfactura.pdf) > «deberán tener un tipo de letra y tamaño legibles, siempre iguales o superiores a los del resto de datos de la factura.» **Incorrect:** Printing the legend in small print in the footer, away from the QR. **Correct:** Printing «Factura verificable en la sede electrónica de la AEAT» centred just below the QR, as large as the invoice lines. **Related:** [QRC-007 · «QR tributario:» goes just above the QR](/rules/qr#qrc-007) · [QRC-003 · The QR measures between 30 mm and 40 mm](/rules/qr#qrc-003) **Explained in:** [QR code and the invoice PDF › The legend next to the QR](/verifactu/qr-and-pdf#the-legend-next-to-the-qr) ## QRC-007 · «QR tributario:» goes just above the QR `Required` · AEAT criterion · Impact: medium · Responsibility: your integration. Above the QR, print the text «QR tributario:», preferably centred on it, in a legible type size equal to or larger than the rest of the invoice data. **Why:** AEAT's specification presents the QR with this label, so that the recipient knows which code to scan. **Applies to:** Any document that carries the QR, including one you render. **Legal basis:** - AEAT, Detalle de las especificaciones técnicas del código QR de la factura (v0.5.0), apartado 3 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/DetalleEspecificacTecnCodigoQRfactura.pdf) > «La presentación del código «QR» incluirá también un texto que siempre deberá ir precediéndolo: «QR tributario:», y que se situará encima del propio código «QR» (preferiblemente centrado con respecto a este)» - AEAT, Detalle de las especificaciones técnicas del código QR de la factura (v0.5.0), apartado 3 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/DetalleEspecificacTecnCodigoQRfactura.pdf) > «Tanto el texto que siempre debe preceder al código «QR», como, en su caso, la frase que habrán de incluir los sistemas «VERI*FACTU» deberán tener un tipo de letra y tamaño legibles, siempre iguales o superiores a los del resto de datos de la factura.» **Incorrect:** Printing the QR on its own, or with a label in a smaller font than the invoice lines. **Correct:** Printing «QR tributario:» centred above the QR, at the same size as the invoice data. **Related:** [QRC-006 · The VeriFactu legend goes just below the QR](/rules/qr#qrc-006) · [QRC-008 · The QR goes once, at the start of the first page](/rules/qr#qrc-008) **Explained in:** [QR code and the invoice PDF › Rendering your own PDF](/verifactu/qr-and-pdf#rendering-your-own-pdf) ## QRC-008 · The QR goes once, at the start of the first page `Required` · AEAT criterion · Impact: medium · Responsibility: your integration. Place the QR at the beginning of the invoice, before its content. On a portrait page it goes near the top margin, preferably centred (otherwise top left); on a landscape page, on the left, preferably near the top-left corner (otherwise centred between the top and bottom margins). On an invoice of several pages it appears once, on the first page. **Why:** AEAT's specification fixes where the recipient finds the code; a QR repeated or buried in the footer departs from it. **Applies to:** Any document that carries the QR, including one you render. **Legal basis:** - AEAT, Detalle de las especificaciones técnicas del código QR de la factura (v0.5.0), apartado 3 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/DetalleEspecificacTecnCodigoQRfactura.pdf) > «Si la factura ocupara varias páginas, el código «QR» aparecería una única vez, en la primera página.» - AEAT, Preguntas frecuentes SIF y VERI*FACTU, Remisión de información por el receptor / QR — [source](https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/posibilidad-remision-informacion-factura-parte-receptor.html) > «El QR tributario solo debe aparecer una vez, al principio de la factura y antes del contenido de esta.» - AEAT, Detalle de las especificaciones técnicas del código QR de la factura (v0.5.0), apartado 3 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/DetalleEspecificacTecnCodigoQRfactura.pdf) > «En el caso de utilizar un formato de orientación horizontal (apaisado) para la factura, el código «QR» se situará a la izquierda de esta, preferiblemente cercana al margen superior-izquierdo (o, si no, centrada respecto a los márgenes superior e inferior de la factura).» **Incorrect:** Repeating the QR in the footer of every page. **Correct:** Printing it once, at the top of page one, centred between the margins. **Related:** [QRC-007 · «QR tributario:» goes just above the QR](/rules/qr#qrc-007) · [QRC-009 · Keep a blank margin around the QR](/rules/qr#qrc-009) **Explained in:** [QR code and the invoice PDF › Rendering your own PDF](/verifactu/qr-and-pdf#rendering-your-own-pdf) ## QRC-009 · Keep a blank margin around the QR `Required` · AEAT criterion · Impact: low · Responsibility: your integration. Leave at least 2 mm of blank space on all four sides of the QR (6 mm recommended), with enough contrast against the background. **Why:** Without a quiet zone, text or lines next to the code stop it from scanning. **Applies to:** Any document that carries the QR, including one you render. **Legal basis:** - AEAT, Detalle de las especificaciones técnicas del código QR de la factura (v0.5.0), apartado 3 — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/DetalleEspecificacTecnCodigoQRfactura.pdf) > «se deben mantener como mínimo 2 milímetros de espacio vacío (en blanco) alrededor de los cuatro lados del código «QR», recomendándose que sean 6 milímetros.» **Incorrect:** Placing the QR flush against a table border. **Correct:** Keeping a white margin around it on every side. **Related:** [QRC-003 · The QR measures between 30 mm and 40 mm](/rules/qr#qrc-003) · [QRC-008 · The QR goes once, at the start of the first page](/rules/qr#qrc-008) **Explained in:** [QR code and the invoice PDF › Rendering your own PDF](/verifactu/qr-and-pdf#rendering-your-own-pdf) ## QRC-010 · A structured e-invoice carries the QR URL as a field `Required` · Law · Impact: low · Responsibility: your integration. When you send an invoice as a structured electronic invoice, include the `qr_url` as a separate field; the QR image itself is then not needed. A PDF still shows the QR image. **Why:** In a structured file there is no image to scan: the URL is how the recipient reaches AEAT's check. **Applies to:** Invoices you send as structured e-invoices (Facturae, UBL and similar). **Legal basis:** - Orden HAC/1177/2024, art. 20.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138#a2-2) > «En caso de tratarse de una factura electrónica, destinada al intercambio de su información de forma estructurada» - Orden HAC/1177/2024, art. 20.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138#a2-2) > «se deberá incluir como un campo independiente la «URL» contenida en el código «QR», no siendo necesario incluir el propio código «QR».» **Incorrect:** Converting the invoice to a structured format and dropping the QR data. **Correct:** Mapping `verifactu.qr_url` to its own field of the structured invoice. **Related:** [QRC-005 · Use qr_url exactly as returned](/rules/qr#qrc-005) · [QRC-001 · Every invoice carries the tax QR code](/rules/qr#qrc-001) **Explained in:** [QR code and the invoice PDF › Rendering your own PDF](/verifactu/qr-and-pdf#rendering-your-own-pdf) [← All rules](/rules#all-rules) ## Related - [QR code and the invoice PDF](/verifactu/qr-and-pdf) — when the VeriFactu QR code data is available, how the PDF relates to it, and what applies to any document that carries the QR - [What AEAT receives from your invoice](/verifactu/what-aeat-receives) — how BeeL. turns your invoice into the record AEAT registers — the description, the total, the number, the recipient and the late-submission flag — and why some of them differ from what you see on the invoice --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # 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 - [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 --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # Conservation How long issued invoices and their records are kept, by whom, and what to export before changing systems. [← All rules](/rules#all-rules) Keeping invoices is the issuing business's duty. Under VERI*FACTU AEAT keeps the billing records, but not the invoices themselves. 4 rules: 3 from the law, 1 AEAT criterion. [How to read a rule](/rules#how-to-read-a-rule). ## CON-001 · Keep copies of issued invoices for the limitation period `Required` · Law · Impact: high · Responsibility: the issuing business. The issuing business keeps copies of the invoices it issues, with their original content and in order, for the limitation period of the General Tax Law, four years, and for the six years the Commercial Code sets for a business's documents. **Why:** AEAT can ask for any invoice within that period. Keeping copies is the issuer's duty even when someone else keeps them materially. **Applies to:** Every issued invoice. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 19.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a19) > «Los documentos deben conservarse con su contenido original, ordenadamente y en los plazos y con las condiciones fijados por este Reglamento.» - Ley 37/1992 del IVA, art. 165.Uno — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1992-28740#a165) > «las copias de las facturas expedidas, deberán conservarse, incluso por medios electrónicos, durante el plazo de prescripción del Impuesto.» - Ley 58/2003 General Tributaria, art. 66 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2003-23186#a66) > «Prescribirán a los cuatro años los siguientes derechos:» - Código de Comercio, art. 30.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-1885-6627#art30) > «Los empresarios conservarán los libros, correspondencia, documentación y justificantes concernientes a su negocio, debidamente ordenados, durante seis años» **Incorrect:** Assuming invoices can be discarded once the quarter is filed. **Correct:** Keeping every issued invoice, PDF and data, for the whole period, in order. **Related:** [CON-002 · AEAT keeps the records, not your invoices](/rules/conservation#con-002) · [CON-003 · Export your invoices before leaving](/rules/conservation#con-003) · [CON-004 · Invoices kept electronically are reachable on request](/rules/conservation#con-004) **Explained in:** [Compliance and responsibilities › What BeeL. keeps for each invoice](/verifactu/compliance-and-responsibilities#what-beel-keeps-for-each-invoice) ## CON-002 · AEAT keeps the records, not your invoices `Required` · AEAT criterion · Impact: medium · Responsibility: the issuing business. Under VERI*FACTU AEAT keeps the billing records, but a record does not contain the whole invoice: its lines, for one, are not in it. Keep the full invoices yourself. **Why:** Relying on AEAT's copy leaves you without the detail of each invoice when you are asked for it. **Applies to:** Invoices of a company under VeriFactu. **Legal basis:** - AEAT, Aclaraciones a dudas de los desarrolladores (v1.3), 13. Conservación de registros en VERI*FACTU y libros registros — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/FAQs-Desarrolladores.pdf) > «Por lo que se refiere a las Facturas Completas, estas deben conservarse en la [...] medida en que el Registro no contiene la totalidad del detalle de las facturas (por ejemplo las líneas de facturación).» **Incorrect:** Keeping only the AEAT registration numbers and discarding the invoices. **Correct:** Keeping each invoice's PDF and data, lines included. **Related:** [CON-001 · Keep copies of issued invoices for the limitation period](/rules/conservation#con-001) · [CON-003 · Export your invoices before leaving](/rules/conservation#con-003) **Explained in:** [Compliance and responsibilities › What BeeL. keeps for each invoice](/verifactu/compliance-and-responsibilities#what-beel-keeps-for-each-invoice) ## CON-003 · Export your invoices before leaving `Required` · Law · Impact: medium · Responsibility: the issuing business. The issuing business keeps its invoices for the whole conservation period, also after it stops using a billing system. Export the invoices and their PDFs before closing the account; keeping their billing records as well is advisable. **Why:** The duty to keep the invoices does not end with the use of a system. Under VERI*FACTU the regulation sets no duty to keep the records, which AEAT keeps, but having them makes each invoice easier to trace. **Applies to:** operations [`POST /v1/companies/{company_id}/invoices/exports`](/invoices/createCompanyInvoiceExport), [`POST /v1/companies/{company_id}/invoices/pdf-archive`](/invoices/createCompanyInvoicePdfArchive) **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 19.1 y 19.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a19) > «Los empresarios o profesionales deberán conservar, durante el plazo previsto en la Ley 58/2003, de 17 de diciembre, General Tributaria, los siguientes documentos: [...] 2. Los documentos deben conservarse con su contenido original, ordenadamente y en los plazos y con las condiciones fijados por este Reglamento.» - AEAT, Aclaraciones a dudas de los desarrolladores (v1.3), 13. Conservación de registros en VERI*FACTU y libros registros — [source](https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/FAQs-Desarrolladores.pdf) > «Cuando se utilicen sistemas VERI*FACTU, las obligaciones de conservación de los registros NO aparecen reguladas en la normativa [...] No obstante, por razones de funcionalidad del sistema (no por obligación reglamentaria), parece lógico que dichos sistemas también conserven esos mismos registros.» **Incorrect:** Closing the account at the end of the year with no copy of that year's invoices. **Correct:** Exporting the invoices and downloading their PDFs first. ```bash curl -X POST "https://app.beel.es/api/v1/companies/{company_id}/invoices/exports" \ -H "Authorization: Bearer $BEEL_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "format": "ITEMS", "filters": { "date_from": "2026-01-01", "date_to": "2026-12-31" } }' \ -o invoices-2026.xlsx ``` **Related:** [CON-001 · Keep copies of issued invoices for the limitation period](/rules/conservation#con-001) · [CON-004 · Invoices kept electronically are reachable on request](/rules/conservation#con-004) **Explained in:** [Bulk operations and exports › Exports](/guides/bulk-operations-and-exports#exports) ## CON-004 · Invoices kept electronically are reachable on request `Required` · Law · Impact: low · Responsibility: the issuing business. Invoices kept electronically must be available online, so that AEAT can view, download and use them on request without undue delay. **Why:** Copies you cannot produce when AEAT asks count as copies you do not have. **Applies to:** Invoices kept by electronic means. **Legal basis:** - RD 1619/2012 (Reglamento de facturación), art. 21.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696#a21) > «Los documentos conservados por medios electrónicos deberán ser gestionados y conservados por medios que garanticen un acceso en línea a los datos así como su carga remota y utilización por parte de la Administración tributaria ante cualquier solicitud de esta y sin demora injustificada.» **Incorrect:** Archiving the invoices on a disk nobody can reach remotely. **Correct:** Keeping them where they can be searched and downloaded when AEAT asks. **Related:** [CON-001 · Keep copies of issued invoices for the limitation period](/rules/conservation#con-001) · [CON-003 · Export your invoices before leaving](/rules/conservation#con-003) **Explained in:** [Bulk operations and exports › Exports](/guides/bulk-operations-and-exports#exports) [← All rules](/rules#all-rules) ## Related - [Bulk operations and exports](/guides/bulk-operations-and-exports) — issue, mark, download, email and export many invoices at once, and create or delete customers and products in batches — and how to read what came back - [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 --- Full OpenAPI spec: https://docs.beel.es/api/openapi --- # Sanctions The fines the General Tax Law sets for invoicing breaches and for billing software that does not comply. [← All rules](/rules#all-rules) These rules restate what the General Tax Law fines, so that an integration knows what is at stake. They are not legal advice. 3 rules: 3 from the law. [How to read a rule](/rules#how-to-read-a-rule). ## SAN-001 · Do not hold non-compliant or altered billing software `Required` · Law · Impact: medium · Responsibility: the issuing business. Holding billing software that does not meet art. 29.2.j) of the General Tax Law, when it is not certified although the regulation requires it or when certified devices have been altered, is an infringement of its own, fined 50,000 € per financial year. **Why:** The fine applies to holding such software, whatever it was used for. **Applies to:** Every business subject to the billing-system regulation. **Legal basis:** - Ley 58/2003 General Tributaria, art. 201 bis.2 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2003-23186#a2-2) > «Constituye infracción tributaria la tenencia de los sistemas o programas informáticos o electrónicos que no se ajusten a lo establecido en el artículo 29.2.j) de esta Ley, cuando los mismos no estén debidamente certificados teniendo que estarlo por disposición reglamentaria o cuando se hayan alterado o modificado los dispositivos certificados.» - Ley 58/2003 General Tributaria, art. 201 bis.4 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2003-23186#a2-2) > «La infracción señalada en el apartado 2 anterior, se sancionará con multa pecuniaria fija de 50.000 euros por cada ejercicio» **Incorrect:** Keeping a tool that edits or deletes issued invoices next to the invoicing flow. **Correct:** Issuing, correcting and voiding only through documents the system records. **Related:** [LIF-001 · An issued invoice is never edited or deleted](/rules/lifecycle#lif-001) · [SAN-002 · Invoicing breaches are fined in proportion to the operations](/rules/sanctions#san-002) ## SAN-002 · Invoicing breaches are fined in proportion to the operations `Required` · Law · Impact: medium · Responsibility: the issuing business. Breaching the invoicing obligations (issuing, delivering, correcting and keeping invoices) is fined at 1 % of the operations involved; at 2 % when invoices were not issued or not kept, or 300 € per operation when their amount cannot be known; and at 75 % when invoices carry false or falsified data. **Why:** A flow that skips invoices, or corrects them by issuing new ones with altered data, turns into a fine proportional to the amounts involved. **Applies to:** Every business with invoicing obligations. **Legal basis:** - Ley 58/2003 General Tributaria, art. 201.1 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2003-23186#a201) > «Constituye infracción tributaria el incumplimiento de las obligaciones de facturación, entre otras, la de expedición, remisión, rectificación y conservación de facturas, justificantes o documentos sustitutivos.» - Ley 58/2003 General Tributaria, art. 201.2.a) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2003-23186#a201) > «La sanción consistirá en multa pecuniaria proporcional del uno por ciento del importe del conjunto de las operaciones que hayan originado la infracción.» - Ley 58/2003 General Tributaria, art. 201.2.b) — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2003-23186#a201) > «b) Cuando el incumplimiento consista en la falta de expedición o en la falta de conservación de facturas, justificantes o documentos sustitutivos. La sanción consistirá en multa pecuniaria proporcional del dos por ciento del importe del conjunto de las operaciones que hayan originado la infracción. Cuando no sea posible conocer el importe de las operaciones a que se refiere la infracción, la sanción será de 300 euros por cada operación respecto de la que no se haya emitido o conservado la correspondiente factura o documento.» - Ley 58/2003 General Tributaria, art. 201.3 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2003-23186#a201) > «La infracción prevista en el apartado 1 de este artículo será muy grave cuando el incumplimiento consista en la expedición de facturas o documentos sustitutivos con datos falsos o falseados. La sanción consistirá en multa pecuniaria proporcional del 75 por ciento del importe del conjunto de las operaciones que hayan originado la infracción.» **Incorrect:** Leaving sales without an invoice, or fixing a mistake by issuing a second invoice for the same sale. **Correct:** Invoicing every operation and fixing mistakes with a corrective invoice. **Related:** [SAN-001 · Do not hold non-compliant or altered billing software](/rules/sanctions#san-001) · [CNT-001 · Every operation of the business is invoiced, exempt ones included](/rules/contents#cnt-001) · [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [SAN-003 · A substantial breach doubles the invoicing fine](/rules/sanctions#san-003) ## SAN-003 · A substantial breach doubles the invoicing fine `Required` · Law · Impact: low · Responsibility: the issuing business. The fines for invoicing breaches are increased by 100 % when the breach of the invoicing obligations is substantial. **Why:** A breach that runs through the invoicing as a whole, rather than an isolated one, is fined at twice the proportional amount. **Applies to:** Every business with invoicing obligations. **Legal basis:** - Ley 58/2003 General Tributaria, art. 201.5 — [source](https://www.boe.es/buscar/act.php?id=BOE-A-2003-23186#a201) > «Las sanciones impuestas de acuerdo con lo dispuesto en este artículo se graduarán incrementando la cuantía resultante en un 100 por ciento si se produce el incumplimiento sustancial de las obligaciones anteriores.» **Incorrect:** Leaving most of a year's sales uninvoiced and treating the fine as the proportional one alone. **Correct:** Invoicing every operation within its deadline, so no breach builds up. **Related:** [SAN-002 · Invoicing breaches are fined in proportion to the operations](/rules/sanctions#san-002) [← All rules](/rules#all-rules) --- Full OpenAPI spec: https://docs.beel.es/api/openapi ---