What AEAT receives from your 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).

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:

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.

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

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. For standard invoices, AEAT checks the recipient's NIF and name against its census; a mismatch is what usually produces an 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.

Related