Compliance of the integrator's component

When a kiosk, a point of sale or an ERP issues invoices through the Factuarea API, two pieces of software take part in every sale: Factuarea, which generates, numbers, chains and remits the billing record, and your component, which asks for it and prints or shows the invoice and its QR. Each one has its own responsible declaration.

This page is Factuarea's reading of the AEAT developers' FAQ of 4 December 2025 (section 5) and of Order HAC/1177/2024, written to help you prepare your integration. It is orientative: the producer of the component is the one who signs, and is responsible for, its declaration. It does not replace legal advice.

When this applies

Your software is a component when, on every operation, it calls the Factuarea API to obtain the invoice and its billing record and does not generate, number, chain, sign or remit billing records of its own. The flow of the unattended checkout is the typical case.

If your software does generate its own records, it is itself an invoicing system with its own obligations and this page does not apply.

Who does what

Task	Factuarea	Your component
Generate the billing record of every invoice and annulment	Yes	No
Number the invoice and chain the record to the previous one	Yes	No
Sign the record (NO VERI*FACTU mode)	Yes	No
Remit the records to the AEAT, in batches and in order, with retries	Yes	No
Warn of the records still pending	Yes (`GET /v1/verifactu/stats`)	No
Call the API on every operation	No	Yes
Show or print the invoice and its QR as received	No	Yes
Declare that it calls the Factuarea API, and which version	No	Yes

What your component must do

Never hand over an invoice without its record. An operation is invoiced when the API has answered with the invoice and verifactu.status: "registered". If the answer is failed, it is not yet: treat the sale as pending and repeat the call with the same external_id (see when verifactu.status is failed).
Do not alter the record or the QR you received. Print qr_png_base64 and huella as they come. Do not recompute them, and do not change amounts, number or date after the response. If a figure is wrong, the way to fix it is a corrective invoice or an annulment, never an edit on the terminal.
Keep the connection indefectible. Call the API on every operation, with no local numbering and no fallback that issues without an answer. With no connection the terminal does not issue: Factuarea has no offline mode (see no connection, no invoice).
Handle errors and retries. Resend the same request, with the same external_id, until you get a definitive answer. Treat 409 resource_locked as "try again in a few seconds", 409 idempotency_key_reused as a bug in your identifiers, and a 422 as something to fix before repeating. Keep the request_id of every failure for support. See Errors the terminal must handle.
Show or print the QR as the specification requires. Between 30 × 30 mm and 40 × 40 mm, error correction level M, at least 2 mm of white margin, the label QR tributario: above and the legend of the response below, in a font no smaller than the rest of the data, at the beginning of the document. See Showing the QR. The ticket PDF (GET /v1/invoices/{invoice}/pdf?format=ticket_80) already lays it out.
Declare what it is. Your producer issues a responsible declaration for the component that states, among its content, that it calls the Factuarea API and in which version.

Your own responsible declaration

The declaration follows the content of article 15 of the Order, in this order. The last column tells you what applies to a component:

Item	Content	In a component
a)	Name of the system	The name of your component.
b)	Identifier code	The code you assign to it.
c)	Complete version	The version of your component.
d)	Hardware and software components, and a short description	The terminal and its software, and that it calls the Factuarea API on every operation.
e)	Whether it can only work as VERI*FACTU	State it; the component generates no records.
f)	Whether several taxpayers can use it	State it.
g)	Signature types for non VERI*FACTU records	Not applicable: the component signs nothing.
h), i), j)	Name or business name, tax ID and full postal address of the producer	Yours.
k)	The literal declaration of compliance	The literal wording of article 15.1.k) of the Order.
l)	Full date and place of signature	Yours.

Add an annex that says how the component integrates with Factuarea: which API it calls, in which version, and that it generates, numbers, chains, signs and remits nothing. The version of Factuarea is in its own declaration, which you read with GET /v1/verifactu/declaracion-responsable (system_name, system_id, version); pin the API version with the Factuarea-Version header (see Versioning).

The model below is orientative: complete the fields between brackets under your responsibility and use the literal wording of the Order for item k). It is in Spanish, the language of the declaration that Factuarea itself issues and that the Spanish tax authority reads.

DECLARACIÓN RESPONSABLE DEL SISTEMA INFORMÁTICO DE FACTURACIÓN

a) Nombre del sistema informático: [nombre del componente]
b) Código identificador del sistema informático: [código de dos caracteres]
c) Identificador completo de la versión: [versión del componente]
d) Componentes hardware y software, y breve descripción: [terminal, sistema
   operativo y aplicación]. El componente atiende el cobro en terminales
   desatendidos e invoca de forma indefectible, en cada operación, la API pública
   del sistema informático de facturación Factuarea para obtener la factura, su
   registro de facturación y su código QR, que muestra o imprime tal como los recibe.
e) Solo puede funcionar como VERI*FACTU: [sí / no]. El componente no genera
   registros de facturación.
f) Permite su uso por varios obligados tributarios: [sí / no]
g) Tipos de firma de los registros no VERI*FACTU: no aplica. El componente no
   genera ni firma registros de facturación.
h) Nombre o razón social del productor: [nombre o razón social]
i) NIF del productor: [NIF]
j) Dirección postal completa del productor: [dirección]
k) [Declaración literal de cumplimiento que recoge el artículo 15.1.k) de la
   Orden HAC/1177/2024.]
l) [Localidad y país], [día] de [mes] de [año]

ANEXO. Integración con el sistema informático de facturación Factuarea

1. El componente invoca la API pública de Factuarea (https://api.factuarea.com/v1)
   mediante POST /v1/invoices en cada operación. Versión del sistema informático
   de Factuarea: [versión de su declaración responsable vigente]. Versión de la
   API: [valor de Factuarea-Version].
2. El componente no genera, numera, encadena, firma ni remite registros de
   facturación: lo hace en exclusiva el sistema informático de Factuarea.
3. El componente no entrega ninguna factura sin el registro de facturación que
   devuelve la API, y no altera ni el registro ni el código QR recibidos.
4. Sin conexión con la API, el componente no emite facturas.
5. Ante un fallo o una respuesta dudosa, el componente repite la misma petición con
   el mismo identificador externo hasta recibir una respuesta definitiva.

Checklist before going live

The component calls the API on every operation and has no local numbering.
It sends a stable external_id per sale and stores it before the first call.
It treats verifactu.status: "failed" as a pending sale and repeats the call.
It prints qr_png_base64 and huella as received, with the label and the legend, at the size and margin required.
It does not issue with no connection.
It handles 409, 422, 429 and 5xx as described in Errors the terminal must handle.
Its producer has signed its own responsible declaration, which states that it calls the Factuarea API and in which version.
You tested the whole flow with a fact_test_ key (see Test mode & sandbox).

Unattended checkout invoicing

The one-call flow, the QR, retries and errors.

VeriFactu auto-submission

How Factuarea remits the records of the company.