# What AEAT receives from your invoice

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.

AEAT does not receive your invoice as you sent it: it receives a billing record (*registro de facturación*) built from it, with AEAT's own fields and rules. Most of it is a straight copy. A few fields are derived, and those are the ones that surprise integrators reconciling against AEAT.

## The description

AEAT requires a description of the operation for the whole invoice. BeeL. takes it from, in order:

1. the invoice's `notes`, if set;
2. otherwise, the description of the **first line** that has one — skipping disbursements (*suplidos*), which AEAT never receives;
3. otherwise, a fixed generic description.

Long text is cut to AEAT's maximum length (500 characters), counted as AEAT counts it: in UTF-16 code units, so an emoji or any other character outside the Basic Multilingual Plane takes two. If the text AEAT shows for an invoice matters to you, put it in `notes`.

The recipient's name is not cut: AEAT takes at most 120 of those units, and a longer `legal_name` is rejected when the invoice is issued, before it is numbered ([`FIELD_TOO_LONG`](/errors/FIELD_TOO_LONG)).

## The total

The total AEAT receives is **not** your invoice's `totals.invoice_total`, nor its `totals.total_to_pay`. It is the sum, over the lines AEAT receives, of each line's **base + VAT + equivalence surcharge**:

- **IRPF is not included.** Withholding is declared separately; it is not part of the operation AEAT registers.
- **Disbursements are not included.** They are not part of the taxable operation, so AEAT never receives them.
- **OSS lines (`regime_key: "17"`) contribute their base only.** The destination country's VAT is settled through the OSS return, not in Spain.

A worked example:

```text
Line 1   base 1 000.00   VAT 21 % 210.00                    → 1 210.00
Line 2   base   200.00   VAT 21 %  42.00   surcharge 5.2 % 10.40  →   252.40
Disbursement (court fee paid for the client)      50.00     →  not sent
IRPF 15 % on line 1                                -150.00   →  not sent

totals.invoice_total:   1 210.00 + 252.40 − 150.00         = 1 312.40
totals.total_to_pay:    1 312.40 + 50.00                   = 1 362.40
Total AEAT receives:    1 210.00 + 252.40                  = 1 462.40
```

So when you compare an invoice with its AEAT record — or with the `importe` in its QR URL — expect them to differ whenever the invoice has IRPF, disbursement or OSS lines. Both are correct for what they measure.

> **Rules that apply here:** [TAX-009 · IRPF withholding is not part of the total AEAT receives](/rules/taxes#tax-009) · [QRC-005 · Use qr_url exactly as returned](/rules/qr#qrc-005)

## The invoice number

The number is sent **whole**, exactly as it appears on the invoice (for example `F-2026/00042`), including the series prefix. AEAT identifies the record by that number, the issuing NIF and the issue date — which is why a used number can never be reused, even after a void.

## The recipient

| Invoice | Recipient sent to AEAT |
|---|---|
| Standard (F1), exchange invoice (F3) and correctives R1–R4 | Name plus NIF, or plus `alternative_id` for a foreign customer |
| Simplified (F2) and its corrective R5 | **None** |

BeeL. sends no recipient data on these types. On top of that, BeeL. does not accept an identified recipient on a simplified invoice you create: it issues that invoice as a standard one — see [Simplified vs standard](/verifactu/simplified-vs-standard). For standard invoices, AEAT checks the recipient's NIF and name against its census; a mismatch is what usually produces an [accepted-with-errors](/verifactu/handling-rejections#accepted-with-errors) result.

## Dates and late submission

The record carries the invoice's issue date and, when you set one, its `operation_date` — always the **original** dates. BeeL. never re-dates an invoice to make a submission fit.

Normally the registration goes out the same day the invoice is issued. When it goes out on a **different day**, BeeL. flags the record as a late submission automatically, in the field AEAT's record format provides for it. Article 16.4 of the Orden HAC/1177/2024 requires a system that could not submit because of a technical incident to submit «en cuanto sea posible», in order, and to indicate it in that field. You cannot set the flag; BeeL. sets it from the dates.

> **Rules that apply here:** [DAT-002 · The issue date is the day the billing record is generated](/rules/dates#dat-002) · [REC-007 · Keep invoicing when AEAT is unreachable](/rules/records#rec-007) · [SIM-005 · The record of a simplified invoice carries no recipient](/rules/simplified#sim-005) · [REC-001 · Each issued invoice gets a billing record built from its data](/rules/records#rec-001)

## Related

<Related>

- [Tax classification](/verifactu/tax-classification) — how each line's `exemption_reason` becomes an AEAT code
- [Invoice types](/verifactu/invoice-types) — how `type` and `rectification_code` become F1, F2, F3, R1–R5
- [Disbursements](/verifactu/suplidos) — why they stay off the record
- [QR code and the invoice PDF](/verifactu/qr-and-pdf) — the other thing built from the record

</Related>

---

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