Scope and limitations

BeeL implements the AEAT VeriFactu surface that 99 % of self-employed and small-business issuers need. A handful of scenarios from the broader AEAT specification are not exposed today. This page is the canonical list so you don't discover gaps by trial and error.

Quick reference

Why each gap exists

Autofactura and factura por terceros

These flows let the buyer (autofactura, D) or a contracted third party (T) issue the registro on behalf of the seller, with the AEAT emitida_por_tercero_o_destinatario field carrying the role. Support is in development and will land in upcoming releases — they need their own delegation model on top of the API key, plus a signing-certificate flow distinct from the standard self-issuance path, which we're building out.

Today the issuer is always derived from the API key: every invoice carries the NIF tied to the key and VeriFactu submits under that NIF. If you need either flow right now, the operational workaround is that each issuing party holds their own BeeL account and emits from there — fiscally equivalent, just one extra account per relationship.

When the native flow ships, you'll be able to set emitida_por_tercero_o_destinatario and the matching nombre_tercero / nif_tercero directly on the invoice payload; the rest of the API surface won't change.

F3 factura sustitutiva

F3 collapses the two-step "annul the F2 then issue an F1" into one record. BeeL exposes the two-step path explicitly through R5 + new F1, because:

• The running fiscal total reconciles cleanly (F2 + R5 cancellation + F1 net = F1).
• Auditors find the chain easier to follow.
• The same operation works without changing your client code when you upgrade from a simplified to a standard invoice in any scenario.

See the F2 → F1 (canje) section in Simplified vs standard for the exact request shapes.

Abono standalone vs corrective

Some accounting systems model a "credit note" as an independent document with a negative total, distinct from a rectification. BeeL doesn't — every abono is a rectification (POST /v1/invoices/{id}/corrective) and gets an R1–R5 code. The AEAT cares about the motive of the correction, and R1 ("error fundado en derecho", which covers Art. 80 Uno/Dos/Seis LIVA — returns of goods, post-issuance discounts, contract resolution) is the right vehicle for what most ERPs call a standalone credit.

Public subsanación endpoint

AEAT's rechazo_previo workflow (N, X, S) lets the issuer manually subsana a registro de facturación in a small set of non-fiscal cases (e.g. fixing a typo on the description after the registro was accepted). BeeL doesn't expose this because:

• Most "subsanaciones" are actually rectificaciones in disguise — and BeeL already routes those through the rectificativa endpoint.
• For the genuinely non-fiscal cases (typo on description, etc.), BeeL retries automatically on rejection and reports the result via the invoice's verifactu.submission_status.
• The audit trail of a public subsanación endpoint is famously confusing; keeping it internal removes a footgun.

If you hit a case where you truly need to subsana and the auto-retry doesn't help, email it@beel.es with the invoice ID.

Rectification chains

Each POST /v1/invoices/{original_id}/corrective targets exactly one original. AEAT does allow a single rectificativa to reference multiple originals (the facturas_rectificadas array), but in practice this is rare and prone to mismatches. BeeL forces a 1:1 relationship — if you need to correct three originals, issue three rectificativas.

What this page does NOT cover

Things BeeL does support that you might second-guess:

• All five rectificativa codes R1–R5 with both PARTIAL (delta) and TOTAL (substitution) flows — see Corrective invoices.
• Both descriptive enums (EXENTA_ART_25, NO_SUJETA_LOCALIZACION, etc.) and AEAT translation (E5, N2, S2) for exemption_reason — see Tax classification.
• All twenty regime keys 01–20 — see Regime keys.
• All five equivalence surcharge pairs including the RD-ley 11/2022 0.625 % — see Equivalence surcharge.
• IGIC and IPSI for territorial taxation — see Territorial taxes.
• OSS (regime_key: "17"), exports (02), REBU (03), criterio de caja, and the rest of the regime_key catalogue.
• VeriFactu auto-submission gated by the global config + per-account toggle — see Auto-submit policy.

Roadmap

If your integration is blocked by one of the gaps above, write to it@beel.es with:

• The AEAT operation you need (citing the LIVA article if applicable).
• A concrete example of the invoice you'd want to emit.
• Volume estimate — how many of these you'd issue per month.

We prioritise additions to this list based on aggregate demand, regulatory deadlines, and audit risk.