When you issue an invoice under Spain’s VERI*FACTU regime, FiscalRail generates the corresponding registration record and submits it to the Spanish Tax Agency, the AEAT.
To submit these records on behalf of our clients, we evaluated three practical approaches:
- Ask each client to upload a digital certificate that FiscalRail could use to authenticate requests to the AEAT.
- Register FiscalRail as a social collaborator with the AEAT and retain the required representation documents from each client.
- Ask each client to grant FiscalRail a procedure-specific power through the AEAT’s Registry of Powers.
We chose the third approach.
Why we do not ask for your digital certificate
Using the client’s certificate is technically straightforward, but it creates the wrong security boundary.
A digital certificate and its private key may be usable for many purposes beyond VERI*FACTU. Accepting one would make FiscalRail responsible for storing, protecting, rotating and eventually deleting an unusually sensitive credential.
Dedicated certificates (certificados de sello) can reduce that exposure, but they are expensive and add certificate-management work for every client. In fact, we might introduce this as a supported option in the future, which we think could be especially useful for platforms which already have agreements with their merchants.
Why we did not choose social collaboration
Social collaboration is a valid AEAT-supported route, but the requirements don't end on FiscalRail's registration with AEAT.
Each client must still complete the prescribed representation form, and the collaborator must retain that document and produce it if the AEAT requests it. The form must be signed electronically, or alternatively, FiscalRail would need to ask for supporting identity documentation and manually verify it, creating unnecessary delay.
That is workable, but it creates a private document-verification and record-retention workflow between FiscalRail and every client. We preferred the authorization to be registered directly with the AEAT instead.
A procedure-specific AEAT power
FiscalRail clients grant us the specific power IZ860: Remisión y consulta de registros de facturación por servicio web.
The client authenticates on the AEAT website using one of the many supported identification methods, enters FiscalRail’s NIF, selects IZ860, reviews the validity period and signs the grant.
The AEAT then provides a receipt containing a Código Seguro de Verificación, or CSV. FiscalRail uses that code to retrieve and validate the grant and then confirms the authorization directly with the AEAT. The process is automatic, allowing clients to begin issuing invoices within minutes without waiting for manual review by FiscalRail.
Additionally, this power is more limited than broad social collaboration. Our clients grant us specific access to AEAT's endpoints for submitting VERI*FACTU issuance records, nothing more.
A test environment for VERI*FACTU
FiscalRail Test accounts reproduce the same invoice, registration-status and webhook workflow exposed by Live accounts, but they do not contact the AEAT and do not require an IZ860 power.
Deterministic test scenarios let you exercise accepted records, records accepted with errors, rejected records and temporary failures followed by retries. You can therefore build and test the unhappy paths (which will inevitably appear) before going live.
See our VERI*FACTU guide for authorization instructions and our Spain testing guide for the available test scenarios.