Frequently Asked Questions

Verifacti is a solution designed for software developers who need to adapt their invoicing systems to Veri*Factu (Spain's Tax Agency system), Ticketbai in the Basque Country, and soon NaTicket in Navarra. Verifacti currently offers three differentiated APIs and an intuitive, easy-to-use web platform.👉 Watch Verifacti Online DemoVeri*Factu APIThe Veri*Factu API enables compliance with the Veri*Factu system regulations of the Spanish Tax Agency (AEAT). It is a cloud-based REST API that operates in three fundamental steps:

1. Receiving a request with invoice data in JSON format.
2. Immediately returning a response with the corresponding QR code for the invoice.
3. Immediately generating the invoicing record (XML) and submitting it to the tax authority's API, ensuring compliance with all regulatory requirements.

Ticketbai APIThe Ticketbai API enables adaptation to the Ticketbai system required by the Basque Provincial Tax Authorities. Currently, there are three different Ticketbai systems, one for each province of the Basque Country. With the Verifacti Ticketbai API, compliance with any of these three tax authorities is achieved through a single integration.NIF Management APIThe NIF Management API simplifies the creation, activation, and deactivation of NIFs (Tax Identification Numbers) within Verifacti, webhook configuration, and management of automated representation models. This API is especially beneficial for software with hundreds or thousands of taxpayers.Coming Soon: Electronic Invoice and NaTicket

Verifacti will continue evolving with key improvements in the future:

• Electronic invoice: Will comply with electronic invoicing requirements once the necessary regulatory framework is established.
• Navarra Tax Authority: Verifacti will develop a specific API for the Navarra NaTicket system when the necessary regulatory framework is established.

We explain the essential requirements of the Veri*Factu regulation and how Verifacti helps you meet them (within Veri*Factu mode):

• QR Code Generation - Invoices issued by your software must include the Veri*Factu QR code => When you make a call to communicate the issuance of an invoice, our API instantly returns the QR code so you can attach it to the invoice.

• Generation and submission of the invoicing record - When you issue an invoice, an XML file must be generated (at that same moment) according to AEAT requirements (the so-called "invoicing record") and must be submitted to the AEAT without delay => When you make a call to communicate the issuance of an invoice, we generate the XML synchronously and instantly, and submit it to the AEAT with our own digital certificate.

• Checking the AEAT response - Once the invoice has been sent to the AEAT (a process that may take a few minutes), it is important to check the AEAT response to rule out / fix errors => Verifacti provides webhooks and specific endpoints to monitor and manage AEAT responses.

• Responsible declaration (Declaración responsable) - You must have a responsible declaration accessible in a visible place for your users / clients. => Verifacti provides a template and materials to complete this document.

• Representation models (Modelos de representación) - Before sending the first invoice of a taxpayer who uses your software to the AEAT, you must manage the signing by the taxpayer of a very simple form that the AEAT published in the BOE (Official State Gazette) in December => Verifacti provides pre-filled forms with clear signing instructions, as well as simple mechanisms for you to send us the form (manually or via endpoint).

👉 https://www.youtube.com/watch?v=45bMYOmRT4w&list=PLf7jmt87ZrAOKXjwwXmk-39T599EAd7NL&index=4

Verifacti is a solution designed for developers and technical teams who need to adapt their software to the tax requirements established by the Spanish Tax Agency (Veri*Factu) and/or the Basque Provincial Tax Authorities (Ticketbai). Verifacti is the ideal solution for:1. Invoicing software vendors and distributorsAny software provider that includes invoicing functionality will need to ensure compliance with Veri*Factu and Ticketbai requirements. Software subject to compliance includes ERPs, CRMs, invoicing software, SaaS platforms, and in general any software that includes invoice issuance among its features.2. Companies or freelancers with their own invoicing systems.Veri*Factu will also be mandatory for taxpayers who use their own software for invoice issuance.👉 Watch short video: what is Verifacti, who is it for and what does it do

In most cases, the integration is completed by a single developer in one to three full-time days, plus a few additional part-time days afterwards.

In the eyes of the AEAT, an architecture that relies on an API like Verifacti's is a mixed architecture with 2 components:

• CPF (Main Invoicing Component): your SIF (Invoicing Information System) from which invoices are issued.
• CEF (External Invoicing Component): our API.

There are aspects of Veri*Factu compliance and responsibilities that are unavoidable for the CPF (your software), and that a solution like ours helps you fulfill but that ultimately depend on you. Here are some examples:

• Real-time submission of invoices with correct data - We don't know when your users interact with your software; it is your responsibility to ensure correct real-time submission.
• Publication of the responsible declaration (declaración responsable) - While we provide a template and guide you, it is you who must complete and ensure the correct publication of this document in your software.
• Inclusion of the QR on the invoice - While we provide the QR, it is you who must ensure it is placed on the invoice.

The main reason for using an API like Verifacti's is to save countless development hours during integration and maintenance phases.By using the Verifacti API, you avoid the main challenges of direct integration with the tax authority, such as:

• Confusing and insufficient documentation.
• Mandatory use of XML as the communication format.
• Time and frequency restrictions on calls to the tax authority's API.
• Mandatory certificate-based signing.
• Mandatory chaining of invoicing records.
• Hash generation and verification.

Verifacti stands out as an unbeatable solution for the Veri*Factu challenge that will minimize the number of development hours and queries needed to solve this challenge:

• Dedicated and personalized support to ensure an easy and correct integration
• API Documentation that is simple and clear
• Section with call and request examples
• Hyper-detailed FAQ section
• Also works for Ticketbai and soon Navarra

* NIF Management API for programmatic registration and deregistration of your users

• Automated representation management system via API
• Webhooks to receive AEAT responses
• Intelligent error validation system to prevent AEAT errors
• Invoice recipient verification to avoid AEAT errors
• Serverless architecture based on containers, enabling automatic scaling based on load

Although Verifacti does not have a full English version, Verifacti is easily used by non-Spanish-speaking developers as follows:

• For everything available under the verifacti.com domain, simply activate your browser's translation feature.
• For the YouTube channel, English subtitles are available.

Yes. Verifacti also helps you comply with Ticketbai. With very little additional integration effort, you can meet the requirements of any of the Basque Country's provincial tax authorities. Ticketbai API here.

You can see client logos and testimonials on our Home page.

We distinguish ourselves by actively helping our clients and users adapt their software to Veri*Factu, both during the integration phases and subsequent maintenance.For any questions, please follow these steps:

1. Check our 🛟 FAQ section—90% of questions are already answered there.
2. For commercial inquiries, write to ventas@verifacti.com
3. For any other type of question, write to soporte@verifacti.com. Your email is read by several people and you will receive a prompt response.
4. We will schedule a call if necessary.

We provide a pre-recorded online demo available for you to watch at any time. It lasts about 30 minutes and covers the most important aspects of how Verifacti helps any software adapt to Veri*Factu, including the most common questions about certificates, representation, responsible declaration, deadlines, and more.If you prefer a personalized demo, request a demo here.

To assess the need for a call, we ask our users and clients to first contact us by email with their specific and concrete questions.

• If we can resolve your questions by email, we will do so.
• If necessary, we will send you a link to schedule a video call.

This approach has an important advantage: greater speed. Generally, we take less time to answer an email than to schedule a call, since 95% of questions from users and clients are very repetitive, and we already have optimized explanatory resources in written or video format that we will send you.

You have access to a series of key resources to speed up your software adaptation and minimize errors that we encourage you to review:

• Quick Start Guide: we explain step by step how to adapt your software.
• Simple and clear API documentation for the 3 APIs that make up Verifacti: Veri*Factu, Ticketbai, and NIF Management.
• Call examples: we show you how to structure your calls for all types of invoices.
• Hyper-detailed FAQ section, with a search bar at the top.
• Online demo where we explain how Verifacti works and answer the most common questions.
• Veri*Factu Tutorial with a series of short videos covering all key compliance aspects.

These resources can be consumed in their entirety in about two to three hours, and we recommend that our users review them carefully as they will prevent unnecessary blocks and questions.

We have a section with call and request examples for all types of invoices:

• Simplified invoice
• Standard invoice
• Multiple VAT rates invoice
• Invoice to a foreign individual
• Invoice to an intra-EU company
• VAT-exempt invoice
• Non-subject operation invoice
• Invoice with IGIC (Canary Islands tax)
• Invoice with IPSI (Ceuta and Melilla tax)
• Invoice with disbursements and withholding
• Credit note
• Exchange invoice
• Corrective invoices
• Corrective invoices by substitution
• Corrective invoices by differences
• Equivalence surcharge invoice
• Invoice issued by third parties
• Invoice issued by recipient
• Cancellation invoice
• Amendment invoice

On December 2, 2025, these deadlines were extended. We outline the new deadlines below, which the AEAT explains here.

1. Deadlines for own-use softwareIf your invoicing software is for your own use (for issuing your own invoices), then your deadline would be:

• January 1, 2027 if you are subject to corporate tax.
• July 1, 2027 for others (mainly freelancers/self-employed)

2. Deadlines for software producers or vendors

If you are a software producer or vendor, your software must have been adapted to Veri*Factu since July 29, 2025. The AEAT has insisted that all software sold today must be adapted. This deadline has not changed and can be confirmed in the AEAT's own FAQ here.Exception: software already sold with a multi-year maintenance contract—the deadline is extended to the 2027 deadlines (see above)

The AEAT's expectation is that invoices are submitted in real time; it is not possible to send invoices at the end of the day or of any time period.

Incentives for software manufacturers, vendors, and distributors

• Legal obligation - Since July 29, 2025, only invoicing software adapted to Veri*Factu can be sold in Spain. Selling non-adapted software exposes the SIF to very significant penalties. This legal obligation has not changed following the Veri*Factu postponement of December 2, 2025, which only affects individual taxpayers with their own software.
• Competitive advantage - Successive AEAT announcements and their media coverage have had the effect of ensuring awareness of the regulation among taxpayers. Software customers will likely place greater value during 2026 and 2027 on software solutions that solve the Veri*Factu challenge. Any software offering from now on that does not incorporate Veri*Factu will be at a competitive disadvantage compared to those that can ensure regulatory compliance.
• Tax incentives - In the Basque Country, with the Ticketbai system, tax incentives were offered that encouraged early voluntary adoption, and the same has happened in other countries with similar systems. Announcements in this direction are foreseeable, which will accelerate adoption and favor providers that offer Veri*Factu with guarantees.

Incentives for individual companies

The main argument for individual taxpayers to join Veri*Factu early is tax incentives. In the Basque Country, with the Ticketbai system, tax incentives were offered that encouraged early voluntary adoption, and the same has happened in other countries with similar systems. Announcements in this direction are foreseeable, which will accelerate adoption and favor providers that offer Veri*Factu with guarantees.

An invoicing record and an invoice are not the same thing.

Invoicing records are the XMLs generated by Verifacti from the calls made to the API. For each call made to the Tax Agency, there is one XML (invoicing record).An invoice can have one or more invoicing records.

• Initially, when a new invoice is created, there would be a single record for that invoice.
• If subsequent calls related to the same invoice are made later (for example, a call to the amendment endpoint), there would be more than one record for the same invoice.

In the eyes of the Tax Authority, a purchase ticket is equivalent to a simplified invoice, and simplified invoices must be reported through the Veri*Factu system. In other words, all tickets must be reported through the Veri*Factu system as simplified invoices.

When using Verifacti, all invoices from different series are consolidated into a single chain, so effectively there is always a single SIF. This architecture is described in the developer FAQ here (page 10).

The tax authority offers two paths to comply with the Veri*Factu system: Veri*Factu mode and Non-Veri*Factu mode.

• Veri*Factu mode consists of sending invoicing records to the tax authority in real time.
• In Non-Veri*Factu mode, records must still be generated in real time, but they are not sent to the AEAT—they are retained by the invoicing software.

Non-Veri*Factu mode is not covered by the API due to the zero demand we have received for this way of complying with the regulation. Here are some of the drawbacks of Non-Veri*Factu mode:

1. Storage obligation: In Non-Veri*Factu mode, the taxpayer does not send invoices to the tax authority in real time, which creates an obligation to store the invoicing records. This means that the invoicing software must be prepared to send all the taxpayer's tax information upon request by the Tax Agency.
2. Additional requirements: choosing this path implies additional technical requirements such as the need for an event log.
3. Tax inspections: The tax authority has indicated that taxpayers who opt for Non-Veri*Factu mode will have a higher probability of being subject to tax inspections.
4. Temporary option: The tax authority has expressed that Non-Veri*Factu mode is a temporary option intended to disappear in the future.

In Veri*Factu mode, there is no obligation to store the invoicing records sent to the Tax Agency, neither for the invoicing software nor for the taxpayer, since those records have already been previously submitted. The tax authority is clear on this point: the obligation to store invoicing records only exists in Non-Veri*Factu mode.👉 Watch short video: Veri*Factu vs Non-Veri*Factu, and the obligation to store the XML invoicing records

No, companies enrolled in the Immediate Information Supply (SII - Suministro Inmediato de Información) system are not required to adapt to the VERI*FACTU system. For an official and specific confirmation for your case, we recommend consulting directly with the Tax Agency (AEAT) via email at verifactu@correo.aeat.es.

The Verifacti API for Veri*Factu is designed to facilitate the submission of tax information to the Tax Agency, providing an accessible solution for invoicing software developers. Instead of integrating directly with the tax authority's API, developers can make their requests to the Verifacti API, thus avoiding technological complexities and technical barriers.👉 Watch short video: how our API works (Part 1) - Explanation and first stepsEase and speedThe Verifacti API is designed to offer a simple and quick integration thanks to:

• Clear and concise documentation, with examples and Postman collections.
• Use of JSON as the communication format.
• No time or number limits on API calls.
• Elimination of the need for your own certificates, using Verifacti's representation certificates.
• Dedicated technical support, especially during the integration phase.

The Verifacti API workflow follows this scheme:

1. When a new invoice is issued in the invoicing software, a request is sent to the Verifacti API using a specific API key for the issuing company (taxpayer NIF). The invoice data is sent in JSON format.
2. The Verifacti API responds immediately with a QR code in Base64 format, ready to be included in the invoice and delivered to the recipient.
3. The Verifacti API immediately generates the invoicing record (XML file) complying with all requirements (immediacy, chaining, format, unalterability, integrity, traceability, etc.).
4. In the following seconds/minutes, Verifacti sends the information to the tax authority's API, which issues a response XML.
5. The AEAT response must be confirmed to verify whether the invoice was accepted or requires corrections: this can be done via webhook or by making a subsequent call to the record status endpoint.

Verifacti API as a faithful reflection of Veri*Factu

Verifacti has designed its API to be a faithful reflection of the tax authority's API, replicating:

• The endpoints.
• The structure of the calls.
• The error messages returned by the tax authority.

This means that any error returned by the Verifacti API comes, with few exceptions, directly from the tax authority. This allows developers to identify problems with original Tax Agency messages and correct them without intermediaries.By not acting as an interpreter of the Tax Authority's requirements, Verifacti ensures a transparent integration aligned with official criteria, allowing developers to focus on implementation without uncertainties.

We have an essential resource that is a must-read for the steps needed for a successful integration: quick start guide.

The Verifacti API is responsible for generating the Invoicing Record (XML) and everything included in and dependent on it: hash and chaining.The software integrating with Verifacti only needs to ensure that requests are made with the issuer's unique API Key and the JSON with the invoicing operation data to our API.From your call onward, we take care of the rest:

• We generate the XML.
• We return the QR code so you can attach it to the invoice.
• We submit the XML to the AEAT with our own digital certificate.
• We provide you the AEAT response via webhooks or through the record status endpoint.

The traceability requirement demanded by Veri*Factu refers to the mandatory chaining of invoicing records (XML). Each new XML generated must reference the previous XML, thus creating a chain that allows you to jump from one XML to another until reaching the first in the chain.The record chain therefore constitutes a chaining of all invoicing records (XMLs) generated and sent by an invoicing information system in chronological order of creation, regardless of whether the records refer to invoice creation or other operations (such as cancellation or amendment), and regardless also of the numbers and series of the invoices issued.When working with the Verifacti API, traceability is ensured by the API itself, which generates the XML files from user calls. Thus, when a call is made to the Create Invoice endpoint and a 200 status code is received, it can be assumed that Verifacti has generated the XML file from the call data and that it is correctly chained to the previous one.Traceability should not be confused with the invoicing regulation requirement that establishes the mandatory sequential numbering of invoices within the same series. This sequentiality requirement is a requirement that Veri*Factu does not enforce (it does not return an error when sequentiality is not met) and has nothing to do with traceability.

In the case of Veri*Factu, the tax authority has imposed limits on the quantity and timing of requests that can be made to the AEAT, and it is common for a request made to our API to take up to 100 or 200 seconds to be submitted to the tax authority. For this reason, our API returns the QR immediately and subsequently takes one or two minutes to deliver the invoicing record to the tax authority. This is correct and is the way the AEAT has chosen to manage requests to its API.In the case of Ticketbai, the response is immediate and includes both the QR and the hash.

These are some capabilities and features of the API:

• QR code generation
• XML generation (including chaining and hash)
• Certificate management
• Retry logic if the AEAT API is down
• Batch transmission
• Ticketbai API compliance included in the price
• Intelligent validation to prevent sending XMLs that would generate errors, avoiding the need for subsequent correction requests
• Invoice recipient verification to avoid AEAT errors
• NIF management API for programmatic registration and deregistration of users
• Webhooks to receive AEAT responses
• Automated representation management system via API
• Serverless architecture based on containers, enabling automatic scaling based on load
• Simple and clear API documentation

Verifacti can be integrated with any tech stack. The only technical requirement is that your stack is capable of making calls to a cloud REST API. This is very common and widely supported in any modern language or framework (and also in older ones).If you don't know how to do it, you'll easily find resources on the web, ChatGPT, or YouTube with tutorials explaining how to make calls to a REST API from practically any technology. It is a standard, completely safe, and common procedure in software integration.Additionally, we have clients who have successfully integrated Verifacti from a multitude of languages, frameworks, and ERPs. Among them, notable examples include:

• Programming languages: Python, Java, C#, Visual Basic .NET, PHP, Ruby on Rails, Go, Rust, Kotlin, Swift, Objective-C, C++, Perl.
• JavaScript environments and frameworks: Node.js, Express, NestJS, React, Angular, Vue.js, Next.js, Nuxt.js, Svelte.
• Backend frameworks and stacks: Django, Flask, Spring Boot, Laravel, Symfony, CodeIgniter, ASP.NET Core, Grails.
• Enterprise integration environments / ERPs: Odoo (custom modules), Dolibarr, SAP, Microsoft Dynamics, Sage, Zoho, Oracle NetSuite.
• Invoicing and accounting systems: Holded, A3 Software, Factusol, ContaPlus.
• Automation and integrations: Zapier, Integromat (Make), n8n.
• Databases and connectors: MySQL, PostgreSQL, SQL Server, MongoDB, Firebase, Redis.
• Other common environments: WordPress (with plugins), Magento, Shopify, WooCommerce, Prestashop.

In summary, it doesn't matter if you work with classic or modern technologies: Verifacti is compatible with any tech stack.

For companies with multiple stores or POS terminals and different invoice series, if they use an external component like Verifacti to chain all their invoices, all these locations are considered a single Independent Invoicing Software (SIF).The AEAT argues that the SIF definition refers to the smallest independent invoicing software. Given the architecture of our solution, the invoicing from different stores is not independent of each other, so they form a single SIF and a single chain.This method is fully valid and compliant with the regulation, offering an alternative to other models that, while also correct, are not the only way to operate.

Verifacti does not offer a direct plugin for Excel or Google Sheets. However, from Google Sheets it is possible to make calls to external APIs, which would be necessary to interact with the Verifacti API and send invoices to the AEAT.

Verifacti will soon launch plugins that will not require code integration for some of the following ecosystems:

• Woocommerce
• Prestashop
• Stripe
• Shopify
• Odoo

We will notify interested parties when these plugins are available.

Yes. In the API documentation you will find the Postman collections to download.

• Veri*Factu API
• Ticketbai API
• NIF Management API

For effective tracking of invoices sent through the API, we recommend storing the following fields in your database:

• From the Create Invoice response: the uuid, the Base64 string of the QR, and the hash.
• From the Invoice Status response: fecha_expedicion (issue date) and the current status of the invoice. Additionally, for error tracking and debugging, it is very useful to store the estado (status) and mensaje_error (error message) obtained from this query.
• From the Download XML response: xlm_req (request XML) and xlm_res (response XML) for auditing and reference purposes.

The endpoint URLs do not change—they are the same for both test and production environments. What determines which environment is used is the API key being used.Each API key has an associated environment: test or production.

• In the test environment, the company API key starts with vf_test_
• In the production environment, the company API key starts with vf_prod_

You should not include the SIF identifier in your calls to Verifacti because:

1. XML generation: Verifacti is responsible for generating the XML required for communication with the AEAT.
2. SIF inclusion: It is in this XML where the SIF identifier is included, ensuring that the information is sent correctly to the AEAT.

By letting Verifacti handle this process, errors are minimized and compliance with Veri*Factu and Ticketbai regulations is guaranteed.

The Verifacti API supports TLS 1.2 and above. It is not compatible with SSLv3.

Verifacti works with a subscription model with recurring monthly or annual payments depending on your plan.The cost (monthly or annual) of the Verifacti API depends primarily on the number of active NIFs in the production environment (number of actual taxpayers).For a low number of NIFs, prices are public:

1. Browse the pricing page.

1. Choose your number of NIFs (taxpayers who will issue invoices with your software)

For a high number of NIFs, we can provide you with a proposal tailored to your needs (use the contact form for this). To send you relevant information and a tailored proposal and to resolve your questions, we need to know the following:

1. Is the software you are going to integrate for your own company's use or is it software you sell/distribute to third parties?
2. What is the approximate number of NIFs issuing invoices with your software? (number of taxpayers who issue invoices with your software)
3. What is the approximate number of invoices issued with your software? (for example, approximate range of invoices issued per month or per year per NIF)

You have a free account to complete all or most of the integration. You will only start paying when you begin sending invoices to the real AEAT production environment.

In Verifacti, we use the terms NIF, company, taxpayer, or obligated taxpayer interchangeably. Each NIF within Verifacti represents a taxpayer whose tax information (invoices) needs to be sent to the tax authority.When we talk about the number of NIFs, we refer to the number of taxpayer users of your invoicing software:

• If you sell software or deploy it, it refers to the users of your invoicing software, i.e., those users who issue invoices using your software (number of individual taxpayers who issue invoices with your software).
• If it is about adapting your own internal software, with which you issue your own invoices, then it would be a single NIF (your own), or several NIFs if you are a group of companies.

A special case is the issuance of invoices on behalf of the recipient (self-invoice) or third parties. In these cases, the number of NIFs corresponds to the taxpayers subject to VAT, i.e., those who sell a product or service.

All Verifacti plans include a very high safety limit of invoices per NIF per month.

• This is a safety limit, designed so that it is never or almost never exceeded.
• For the plans advertised on the pricing page, the current limit is 3,000 invoices per NIF per month. For custom plans, the limit may differ.
• If this figure is exceeded, operations are not interrupted—simply an additional variable amount is added to the Verifacti invoice for the extra invoices not covered by the plan. This cost for plans advertised on the pricing page is 2 Euros per 1,000 additional invoices.
• If this limit is not sufficient for you, contact us and we will make you a personalized offer.

The first NIF in Verifacti is the most expensive. This especially affects own-use software that only needs one NIF, paying a per-NIF price that is higher than users with multiple NIFs.The reason for structuring prices this way is that Verifacti has a significant cost associated with each client regardless of the number of contracted NIFs. We strive to monitor and help each client regardless of size, and this commitment to good support and assistance requires us to reflect this in a price that has a minimum regardless of the number of NIFs.This pricing structure ensures that we can resolve integration and maintenance queries with any client, even those who only have one NIF.

The payment dynamics as NIFs are created/activated or deactivated are as follows.For MONTHLY plans

- First, you must create a paid subscription by choosing the "Month" option. At that time, you are charged for a single NIF. Let's say it is September 15.

• From then on, every 15th of each month, the same amount equivalent to 1 NIF will be charged.
• When you create your first NIF in production, you are not charged anything, because you are already paying for it.
• When you create your second NIF in production, nothing is charged at that moment, but on the next 15th you will be charged the time consumed by that second NIF in the previous month (retroactive payment for the prorated consumption of that NIF) and a full month in advance (prepayment of one full month).
• From then on, you would be charged for 2 NIFs each month (prepayment).
• Same dynamic with each NIF increase.
• If at any time you deactivate a NIF, simply when the next billing arrives, that NIF will not be charged. There is no refund for the paid and unused amount for that NIF.

For ANNUAL plans

• First, you must create a paid subscription by choosing the "Year" option. At that time, you are charged for a single NIF for the entire year. Let's say it is September 15.
• When additional NIFs are registered, the total annual amount prorated for the remaining time until the next September 15 is charged at the time of registration. That is, if a NIF is registered on March 15, there would be 6 months left to complete the one-year cycle, and 6 months would be charged in advance for the right to use that NIF for the next 6 months.
• The following September 15, the total annual amount for all active NIFs in production at that time will be charged.

If you pay for a year of use in advance, there are 10% discounts. This requires advance prepayment of 12 months for each NIF you add. The year counts from the date you created your annual subscription (the date you became a paying customer), or from the last renewal date of your annual plan.

No. You will only pay for what you use and for the time you use it. You will not have to pay any installation fees and you can stop using the service whenever you want.

No. Verifacti prices are per taxpayer (NIF) and independent of the number of POS terminals and/or locations from which invoices are issued. We are a cloud API that does not require local installation of any software.

Yes. We have an API for managing NIF activation and deactivation, webhooks, and automated representation model management. All of this is included in the price.

Yes. When you pay for a NIF in production, you can choose whether that NIF uses the Ticketbai or Veri*Factu path without affecting the cost.

Verifacti offers a sandbox or free account with a test NIF so you can try the API and perform the integration.1. Create a free Verifacti accountRegister in seconds on Verifacti. Simply go to Verifacti, click Create Account, enter your email and password. After this step, you'll be ready to explore the platform.2. Access the test NIF

Your free account includes a test NIF, which allows you to make calls to the tax authority's test environment. To access it:

• Go to the Companies section.
• Click on the test NIF to enter its control panel.
• This test NIF is included in the free plan and is sufficient for most Verifacti integration cases.

3. Make your first calls from the terminal

Within your test NIF's panel:

• Click on Terminal in the sidebar menu.
• From here, you can make calls to the various tax authority endpoints through Verifacti.
• Select a call type from the dropdown.
• Send the test call to the tax authority by clicking Send.
• If you test the Create Invoice endpoint, you will receive an immediate response with the QR ready to attach to the invoice.

4. Explore the records section

After making a call to the Create Invoice endpoint, go to the Records section to review the request information:

• QR image and its associated link.
• JSON generated in the request.
• XML sent to the tax authority by Verifacti.
• XML response from the tax authority.

5. Use the API KeyIn the Settings section, you will find the API Key for your test account. Use it to make API calls directly from your own code.

Not necessarily. The free plan includes a pre-created NIF in the test environment from which the integration can be done at no cost.However, there are some very useful features (especially for clients with high NIF volumes) that require a paid subscription:

• NIF Management API
• Webhooks
• Automated representation model management
• Creation of multiple NIFs in the test environment

It is possible to access all these features by creating a paid subscription at the symbolic price equivalent to one NIF in production. Once the paid subscription is created, all that functionality becomes available.

Yes. The AEAT test environment is intended solely for integration and validation, and its use must be limited in both volume and time. The AEAT sets limits on the number of invoices sent and monitors that there is no continuous and permanent use of the test environment.If you are not actively integrating, you need to stop submissions until you resume the integration process. For this reason, at Verifacti we have alert systems that notify when an integration is approaching these limits.

The free test NIF has this limitation: since it is a NIF shared by many of our users, we have restricted access to that endpoint to prevent data sharing between users.

To work with Ticketbai, you need to create a paid subscription and create a new NIF by selecting the Ticketbai option.

Invoicing records in the test environment, just like in production, cannot be deleted. This makes sense: the test mode works exactly the same as the production mode, in which invoicing records cannot be deleted.It would be possible to cancel all invoices with the cancellation endpoint, but that would not delete the records, and those invoice numbers could not be reused.

The following features require a paid subscription equivalent to the cost of a single NIF in production:

• NIF Management API
• Webhooks
• Automated representation model management
• Creation of multiple NIFs in the test environment

It is possible to access all these features by creating a paid subscription at the symbolic price equivalent to one NIF in production. Once the paid subscription is created, all that functionality becomes available.To be able to create NIFs in the production environment, a paid subscription is also required. As the number of production NIFs increases, the invoice will increase accordingly.

The AEAT does not allow testing with fictitious CIFs, which requires using real CIFs for testing, although these submissions are marked as tests and have no tax validity.

The prefix is added to the invoice number only when using the test NIF provided by Verifacti. This is done to avoid potential numbering collisions between different users who are testing the platform simultaneously.This prefix will not be present in invoices generated with NIFs registered for test or production environments.

It is not possible to delete registered NIFs, even in the test environment. The reason is that doing so would delete the associated invoicing records, which is contrary to Veri*Factu's purpose of preserving records.If you still wish to proceed with the deletion of registered NIFs, write to soporte@verifacti.com with the specific NIFs you want to delete. Once provided, our team will perform the deletion from our system.

For software with multiple taxpayers, in most cases Verifacti is contracted as a provider by the invoicing software developer. This developer registers the taxpayers in Verifacti, so normally the taxpayers do not interact with Verifacti at all.Regarding how to pass the cost on to the taxpayers, this is an exclusive decision of the invoicing software. In this regard, we have seen all kinds of approaches from our clients:

• Absorbing the cost
• Passing the cost on
• Including a margin

Very exceptionally, we have invoicing software companies that choose to ask their taxpayers to contract with us directly. In these cases:

• It is recommended that the software provide an easy path for the taxpayer to enter their unique API Key.
• Prices might be higher, since there would be no volume discount for a high number of NIFs.

If you have received an offer by email, contact the person who sent you the proposal by email.If you have not received an offer by email, then the steps to follow are:

1. Log in to the platform with your username and password
2. Navigate to this page
3. Click on "Buy first NIF" and follow the steps.

• Make sure to check the "Company" checkbox and enter company details (name, NIF, etc.).
• Enter payment details: you will be charged the cost of one NIF in production at that time

From that moment on, you are a paying customer:

• You will continue to be charged the equivalent cost of the first NIF per month from that point on
• If you activate the first NIF in production, you will not be charged anything extra
• If you activate more NIFs in production, your invoice will increase based on the number of activated NIFs
• As you add NIFs, the unit cost per NIF decreases (the first is the most expensive, then costs drop rapidly)

Verifacti, like most cloud-based SaaS services, has terms of use to which clients are bound when subscribing to a paid plan. These terms detail the legal rights and obligations of the parties, as well as the SLA, DPA, and other legal elements.We also have our public "responsible declaration (declaración responsable)", which establishes our responsibilities within the mixed architecture we form together with our clients.

Verifacti's system is designed so that the initial purchase is for one license. As you add production NIFs to your account, the invoice will automatically adjust to reflect the actual number of licenses in use.

Common reasons why a subscription may appear as inactive are:

1. Payment status issues (expired card, insufficient funds, or a transaction error).
2. End of subscription period without automatic renewal.
3. Pending manual activation after registration or initial payment.

To identify the exact cause and resolve it, check the following in your Verifacti account:

• Access your control panel and check the Subscriptions or Billing section. There you should be able to see the current status of your plan and the expiration date.
• Check if there is any pending notification or message related to payments in your account.

If after reviewing these points you still cannot find the cause or need additional assistance, contact the support team (soporte@verifacti.com).

Yes, any person or entity can subscribe to Verifacti, whether an individual or a legal entity.

You can consult our DPA in our terms of use.

Verifacti has an SLA that is published in the terms of use.

If your company is located in the Canary Islands and IGIC or a tax exemption must be applied to the Verifacti subscription, you should contact our team at soporte@verifacti.com. We will adjust your account to be tax-exempt, allowing you to proceed with subscription activation without applying any tax.

Following the postponement of the mandatory entry into force of Veri*Factu until 2027, the management of the paid subscription in Verifacti depends on the type of user.1. Taxpayers who issue their own invoices

If you use your own invoicing software, you have these options:

• Keep the subscription in production: you can continue sending invoices to the AEAT, to the production or test environment. During the transitional period, there are no repercussions and it serves to validate that the integration works correctly. The AEAT has confirmed that it is possible to leave Veri*Factu and return to non-adapted software at any time.
• Cancel the subscription: you can cancel your subscription, go to zero cost, and reactivate it later when you need it. Check the cancellation FAQ to learn about the procedure and its effects.

2. Software manufacturers, vendors, and distributorsFor this group, the obligation remains in force since July 29, 2025, that all invoicing software sold in Spain must be adapted software, an obligation confirmed by the AEAT after the postponement. We explain this in the FAQ about deadlines. At a minimum, adapted software must include a Veri*Factu activation option, whether voluntary or deferred before 2027.If you are a software manufacturer, vendor, or distributor, you have the following options:

• You may consider deactivating production NIFs so you don't pay for them.
• You can easily reactivate those NIFs later when you need them.

Our recommendation is not to cancel the paid subscription, since you have the obligation to have adapted software. You will continue paying the equivalent cost of one NIF in production.

How to request cancellation of my paid subscriptionTo request cancellation of your Verifacti paid subscription, follow these steps:

1. Navigate to the billing section.
2. Click on "Cancel".
3. Follow the steps until you confirm the cancellation.

What are the consequences of cancelling my paid subscription

Important considerations in case of cancelling the paid subscription in Verifacti:

• Once you have requested cancellation of your subscription, you can continue using Verifacti until the end of your billing cycle (monthly or annual). Once the period ends, the cancellation of your subscription will take effect automatically.
• Deactivating NIFs is not the same as cancelling the subscription. Even if all the NIFs you have created are deactivated, you will continue to be charged the price equivalent to 1 NIF in production, which gives you the right to use functionality such as the ability to create NIFs in the test environment, webhooks, and the NIF Management API. To stop paying, it is necessary to cancel the paid subscription.
• Once you cancel your subscription, the NIFs and webhooks you have created will be automatically deactivated.
• If you try to make submissions with API Keys from NIFs you created that have been deactivated as a result of subscription cancellation, these submissions will fail and cannot be made.
• Remember that once your subscription is cancelled, any invoicing record (XML) generated by Verifacti will be deleted after 30 days, except for the very last one (needed to continue your XML chain in case you resume submissions to the AEAT).
• If you want to keep the XMLs, remember to use the export XMLs endpoint to obtain the XMLs before cancelling the subscription to avoid losing them.

The invoices that Verifacti issues to your company for contracted services or subscriptions are available in the Billing section.

When bank direct debit is chosen as the payment method, the invoice is generated when the payment reaches the destination bank account, and this usually takes a few days to materialize from the time of the charge (typically between 3 and 5 business days from the moment the charge is made).This is the standard way the payment platform we use (Stripe) works, and it is not something Verifacti can modify.

We automatically send invoices to the email address indicated in the Billing section. This email can be edited and can be different from the email used to log in.

Here is how to make sure your tax details appear on the invoice that Verifacti issues to you. You can enter your billing details in two different ways.From the Billing area

1. Log in to Verifacti with your account and navigate to Billing
2. Click on Access your billing portal
3. In the Billing Details section, click on Update details

This change will only affect invoices issued after the change. Previously issued invoices will not reflect the billing details.

When purchasing your subscription

During the purchase process, after choosing the payment method, you should see a checkbox that says "I am a company". Click there and you can enter your billing details.

To change your payment method (from card to bank direct debit or vice versa), follow these steps:

1. Navigate to the billing panel
2. Click on "Access your billing portal"
3. Find the payment methods section and change your payment method—you have two options: bank card and SEPA bank direct debit.

It is not possible to change the billing frequency (from monthly to annual) directly from the Verifacti dashboard. To make this change, please contact our team at soporte@verifacti.com so they can manage it for you.

Verifacti issues a single invoice per registered account. If your account has multiple associated NIFs, all services will be grouped into that single invoice. To receive separate invoices for each NIF or company, it is necessary to create an independent Verifacti account for each one.

Verifacti offers its users a web platform that allows you to:

• Explore Verifacti and integrate your software using a free account.
• Create, activate, and deactivate companies (NIFs).
• Make calls from the terminal.
• Access documentation, FAQ, and integration resources.
• View invoices and invoicing records.

On the home screen, you can see all created NIFs, plus the test NIF that came included with the free account, separated into tabs: test vs. production.Clicking on a NIF takes you to its individual control panel:

• Home: Visualization of charts with invoicing information for the NIF.
• Invoices: View of all invoices issued for the NIF, in a table filterable by date and other criteria.
• Records: Access to all invoicing records sent to the Tax Agency, including any request made to the tax authority through Verifacti.
• Terminal: Make calls to the tax authority for this NIF, with request examples on the left side and the API response on the right side.
• Settings: Enter company data and access the API Key, needed to make requests for this NIF.

With these features, the Verifacti platform facilitates the management and automation of invoicing processes with the tax authority.

Verifacti does not offer functionality to invite team members to an account. There is only one set of credentials per Verifacti account.

In the case of software vendors and distributors, Verifacti is not designed for sharing access with taxpayers, since with one login, private information of other taxpayers could be viewed.However, it would be very easy to replicate the screens for records or invoices in your own software using information from your own database and/or endpoints that provide access to the available information:

• List invoices
• Export XMLs

Verifacti is a platform and API that allows users to send and manage their invoices in an automated manner.We do not provide manual invoicing services from documents such as receipts or images.

Verifacti's solution is based on a REST API that can be integrated with platforms like OpenCart and PrestaShop.However, we currently do not have specific solutions or pre-built plugins for these platforms.

In Verifacti, there are two types of API Keys that are obtained differently.NIF API KeyEach taxpayer for whom invoices are to be submitted to the AEAT must be registered in Verifacti and will have a unique API Key per environment. Ideally, there will be two API Keys per NIF: one for the test environment and one for the production environment.This API Key is essential for API calls. This API Key allows:

• Identifying the taxpayer (VAT payer) who appears on the invoice as the seller of a product or service.
• Determining the tax authority environment to which the tax information should be sent (test vs. production).
• Determining the tax authority (AEAT vs. Basque Provincial Tax Authorities) to which the taxpayer belongs.

In Verifacti, there are two environments: test and production. When adding a company (a NIF) within Verifacti, you must specify the environment (test or production). That company's environment variable in Verifacti will define which tax authority environment the requests related to that company are sent to.

• In the test environment, the company API Key starts with vf_test_
• In the production environment, the company API Key starts with vf_prod_

Depending on each use case, more or fewer API Keys of this type will be required:

• Software distributors and vendors will require multiple NIFs, one per user or taxpayer.
• Independent companies will only need to create API Keys in test and production for their own NIF (or several NIFs if they are a group of companies).

NIF API Keys can be generated in two ways:

1. Manually from the home screen. Click on "Add company" and follow the steps.
2. Through the NIF Management API. See documentation.

API Keys can be viewed in two ways:

• From the settings section within each NIF.
• They can also be obtained with the NIF Management API, NIF API Key endpoint.

To create new NIFs, a paid subscription is required.

• A paid subscription at the cost equivalent to 1 NIF in production gives you the ability to have multiple NIFs in the test environment without the cost increasing.
• With the paid subscription created, it is possible to create NIFs in the production environment, and the invoice will adjust upward.

API Key for the NIF Management APIFor using the NIF Management API (NIF registration and deregistration, webhooks, representation models), a specific API Key is needed, which can be obtained here.To access this API Key, a paid subscription is required. Any paid subscription, regardless of the cost or number of production NIFs, provides an API Key for the NIF Management API and the ability to have multiple NIFs in the test environment.👉 Watch short video: How our API works (Part 2) - How to create NIFs and obtain API Keys in Verifacti

API Keys do not expire.

Verifacti has a specific API for managing NIFs. If you have many taxpayers using your software, this API is essential for a successful integration.

In Verifacti, NIFs cannot be deleted. NIFs are deactivated.How to deactivate a NIF

To deactivate a NIF, there are two paths:

1. Manually, from the companies panel, by clicking the "Deactivate" button
2. Via endpoint, with the NIF deactivation endpoint.

Consequences of deactivating a NIF

When a NIF is deactivated:

• It is no longer possible to submit invoices to the AEAT with that NIF.
• The NIF can be reactivated at any time (manually or via the Activate NIFs endpoint).
• If it is a production NIF and not the only production NIF (i.e., if you have several production NIFs and deactivate one of them), that NIF will no longer be charged on the next invoice.
• If it is the only production NIF, then even if it is deactivated, you will continue to be charged the amount equivalent to the first production NIF as long as the paid subscription is active.

In that case, you simply need to create a new NIF on our platform and deactivate the previous one.

Invoicing regulations require that invoices be issued with consecutive numbering within the same series.Number assignment

The correct practice is to assign the invoice number only after it has been successfully sent to our API and a 200 (OK) status code has been received in response. The 200 status confirms that the invoicing record has been created, and regardless of whether the AEAT accepts or rejects the invoice for any reason, the number has been correctly assigned.That said, if invoices are issued slightly out of order with a difference of a few minutes, this is not usually considered a serious problem.Handling AEAT invoice rejection

Once a 200 response has been obtained from the Verifacti API, if the AEAT subsequently rejects the invoice, the number would still be correctly used and should not be "released" for another invoice. In this context, the invoicing record has been created and submitted to the AEAT, and therefore the number is used by the invoice with errors. The AEAT rejection must be resolved through a corrective invoice that references precisely that erroneously issued invoice.Incidents

In incident situations such as an internet outage, invoice generation may be interrupted even while sales continue to occur (see incidents section). Ideally, when the connection is restored, invoices should be sent in the order of the original transactions.Do not confuse sequentiality with traceability

This requirement for sequential invoice numbering within the same series established by invoicing regulations (which Veri*Factu ignores) should not be confused with the chaining or traceability requirement that Veri*Factu does establish, which affects the invoicing records (XMLs) that the Verifacti API is responsible for generating. It is therefore Verifacti that guarantees this XML traceability requirement.Veri*Factu accepts non-sequential invoicesIt is important to clarify that Veri*Factu accepts submissions of invoices with non-consecutive numbering without errors. Therefore, it should not be assumed that because invoices were accepted without errors, the sequentiality requirement has been properly met. Complying with Veri*Factu does not exempt you from the sequential numbering obligation of invoicing regulations.

There are two date fields in the Verifacti API:

• fecha_expedicion (issue date): mandatory field, this is the invoice issue date which must be the current date.
• fecha_operacion (operation date): optional field, in case you want to issue an invoice for a transaction that occurred on a past date, this field should be used.

Key points to keep in mind:

• The fecha_operacion field does not directly affect the sequential numbering of invoices.
• Sequentiality is governed by the issue date.
• Numbering must be consecutive and uninterrupted based on this issue/registration date.
• The fecha_operacion field simply indicates when the delivery of goods or provision of services took place. It can be earlier than the issue date.
• The operation date determines which settlement period (month or quarter) the VAT should be attributed to, even if the invoice is issued later (always within the regulatory deadlines).

There is a field in the invoicing record (XML) that specifies the exact time of the invoicing record generation (FechaHoraHusoGenRegistro). This field is completed by the Verifacti API and does not require any data in the user's API call.This is the time the system uses for time control: the call to the Tax Agency (or delegated software) must be made within a maximum of 240 seconds (4 minutes) after this record generation time, according to the regulation.

The combination of the series and invoice number must not exceed 60 characters.

One of the Veri*Factu system requirements when creating a new invoice is to include a breakdown by VAT type, which in the Veri*Factu API is called lines.It is important to clarify that the tax authority does not use this breakdown to obtain information about the products or services sold. Its purpose is exclusively to reflect different VAT types in cases where the same invoice includes multiple VAT types.Therefore, in situations where the entire invoice has a single VAT type, only a single line will be necessary.

The breakdown lines in the invoice summary must be grouped by both tax rate and tax regime key.

If there are different combinations of these two criteria, a separate breakdown line must be generated for each one, even if the tax rate is the same but the tax regime key differs.

The sum of an invoice's breakdown may not exactly match the invoice total. This difference can be up to a maximum of several tens of euros. The tax authority will not consider this an error.

Veri*Factu does contemplate invoices issued by third parties or by the recipient (self-invoices). In the API, this is done using the emitida_por_tercero_o_destinatario field. These invoices can and must be sent just like all others.Some important clarifications regarding this type of invoice:

• For calculating Verifacti API costs, in this type of invoice, the taxpayer (VAT payer) must be registered as a NIF, even if they are not a user of the invoicing software.
• In the JSON, the taxpayer's data will not appear, because that data is communicated through the NIF API Key.
• In the case of an invoice issued by a third party, it is necessary to indicate who the third party is in the specific fields nombre_tercero and nif_tercero.

Invoices that include IRPF (income tax) withholding, such as payments to freelancers, must exclude the IRPF component when reported to the Tax Agency through Veri*Factu. This means that the total invoice amount in the hands of the final recipient will be different from the total invoice amount in Veri*Factu. When viewing an invoice on the AEAT website (through the QR), the AEAT itself explains that the data shown there does not include withholdings.

In Veri*Factu, there is no specific "discount" field: you must reflect it by adjusting the invoice amounts. You can do this by subtracting the discount directly from the taxable base of the line(s) (sending the already net base) or by adding an additional line with a negative amount (same VAT key as the affected line), so that the total amount is correct; if the discount is after issuance, then a corrective invoice/credit note is appropriate.

The tax authority establishes that disbursements (suplidos) do not have to be mandatorily included in invoices sent through the Veri*Factu system. However, they can be voluntarily included through an additional line with 0% VAT.

Yes, the Verifacti API supports the Special Travel Agency Regime (REAV - Régimen Especial de las Agencias de Viajes). To register invoices under the Special Travel Agency Regime (REAV), use the clave_regimen parameter with the value 05.You can find more information in the API documentation.

Yes, the Verifacti API supports the Special Used Goods Regime (REBU - Régimen Especial de Bienes Usados). To register invoices under the Special Used Goods Regime (REBU), you should use the clave_regimen with the value 03.You can find more information in the API documentation.

The Equivalence Surcharge (Recargo de Equivalencia), if applicable, must be indicated in the invoice lines, specifying both the percentage and the corresponding amount. This aligns with the tax breakdown structure in the invoice lines.

All invoices must be reported in EUR.

You can use as many series as you want within the same NIF.

No, it is not necessary to verify that the previous invoice has been accepted by the Tax Agency.

In fact, in many contexts, it is not desirable to wait, since the AEAT response could take minutes.

The only requirement is that the invoicing record associated with the previous invoice has been correctly generated, which in practice means that the previous Verifacti API call returned a 200 status code.

When issuing an F1-type invoice, it is necessary to identify the recipient. Two cases are distinguished here:When the recipient is a Spanish individual (freelancer or not), a Spanish entity with a valid NIF, or a foreigner with a NIE.

* In this case, the "nif" and "nombre" (name) fields must be provided, where "nombre" corresponds to the first and last names for individuals and the company name for entities.

• For individuals, the name must be sufficiently similar to the one appearing on the DNI (national ID).

When the recipient is not a Spanish individual, a Spanish entity with a valid NIF, nor holds a NIE.

* In this case, the "nombre" (name) and "id_otro" (other ID) fields must be used to identify the recipient.

• A specific case within this general case is that of EU companies with a valid VIES VAT number.
• To identify foreign or non-resident clients, the passport or, in general, the field 06 (other supporting document) in the API can be used. In these cases, the AEAT does not validate said document.

If an invoice is issued with a recipient error, it will be necessary to issue a corrective invoice by substitution.

Verifacti provides several resources to help validate invoice recipient data, thus minimizing errors.1. Default invoice recipient validation

In the Create New Invoice call, there is a validar_destinatario field that is set to true by default.

• If the nif field is included, we validate by default that it is registered with the AEAT, since if it is not, the AEAT will reject the submission. This requires an additional call on our side, so if you are sure that the recipients' NIFs are registered, you can disable this validation by setting this field to false. This will make the call faster.
• Similarly, if the id_otro field is included with id_type equal to 02, we validate by default that the VAT is in the VIES registry. You can disable this validation by setting this field to false.

2. Specific validation endpoints

There are also specific endpoints for selective use outside the invoice creation process. These endpoints require an activated paid subscription.

• The Validate NIF at the AEAT endpoint allows performing the above validation through an endpoint.
• The Validate VAT in VIES endpoint allows validating that an intra-EU VAT number is in the VIES registry. Note that this endpoint uses an EU API that fails quite often.

If the client's DNI/NIE data is incorrect or missing, and the legal conditions allow it, you can convert the invoice into a simplified invoice.

To do this, resend the invoice marking the tipo_factura as F2 and omitting the NIF and client name. If you want to issue a full invoice (type F1), it is mandatory to include the correct recipient data.

If the name associated with a client's DNI is found to be incorrect, it is essential to obtain and record the exact name.

The Tax Agency (AEAT) requires that the recipient's name be correct. It is not permitted to mark a person as NOT registered if they are actually in the registry, as the problem lies in the inaccuracy of the data (the name) and not in the lack of DNI registration.

The QR code in the Veri*Factu system is an encoded URL, unique for each invoice, located on the Tax Agency website. This URL allows verifying whether the invoice has been received by the tax authority through the Veri*Factu system. The tax authority expects all invoices issued by taxpayers subject to the Veri*Factu system to include this QR. Thus, any recipient of an invoice with a QR can easily access the URL from their mobile device and verify that the invoice has been reported to the Tax Agency.The QR is generated from the following 5 invoice fields:

1. Issuer NIF
2. Series
3. Number
4. Date
5. Amount

When a new invoice call is made to the Verifacti API, the synchronous immediate response includes the QR in Base64 image format.👉 Watch short video: QR code in Veri*Factu, what it is and how it is generated

If you didn't save the QR in your database, you can make an additional call to the record status endpoint to recover it. To do this, you need to have saved the UUID of the request with which you created the invoice. Remember that with Veri*Factu, it is only necessary to include the QR on the invoice; it is not necessary to include or store the hash, unless you offer non-Veri*Factu services.

With Veri*Factu, it is not necessary to include the hash on the invoice—the QR is sufficient. The hash must be included in the XML sent to the tax authority. The generation of that XML (with the hash) and its submission to the tax authority are Verifacti's responsibility.With Ticketbai, yes, it is necessary to include the hash, and it is part of the API response.

There are libraries and functions in all tech stacks to convert the Base64 encoded QR image returned by the API into an image that can be attached to the invoice.

For the specific case of SaaS companies that use Stripe for subscriptions, the flow can be:

1. The invoice.payment_succeeded event arrives, which contains the invoice object.
2. Make a call to our API and collect the QR.
3. The invoice object contains the Stripe PDF at invoice.invoice_pdf. Download it, attach the QR, and upload it to an S3.
4. Show the client your own PDF, not the Stripe one.

Regarding the PDF, you can do two things:

1. Use a library, but it is still costly to handle all cases correctly.
2. Use the Stripe PDF itself and simply modify it. This is really easy and fast.

QR generation is straightforward. Although the Verifacti API provides the QR immediately when generating a new invoice, many users prefer to generate it themselves and add it to the invoice, since QR generation libraries exist in almost every programming language.

QR codes are returned as a Base64-encoded image, resulting in a considerably long character string (exceeding 3,000 characters), not a short URL as one might expect.

Yes, it is mandatory to include descriptive text next to the QR code on the invoice PDF. Phrases such as VERI*FACTU or Factura verificable en la sede electrónica de la AEAT (Invoice verifiable at the AEAT electronic office) can be used.

The QR code size must follow the ISO/IEC 18004 standard. This standard establishes a minimum of 4 module margins. The QR codes generated by Verifacti have 6 module margins, thus complying with the specification.

Yes, it is recommended to save the QR for the following reasons:

1. Ease of reprinting: Having the QR saved allows you to quickly and easily reprint the document in case of loss or damage of the original.
2. Authenticity verification: The QR can be used to verify the document's authenticity at any time.
3. Regulatory compliance: Keeping the QR ensures that Veri*Factu and Ticketbai regulations are met, as these systems may require QR presentation during audits or reviews.

Additionally, it is suggested to store the QR in a safe and accessible place, such as a digital cloud file, to prevent its loss.

Yes, it is possible to modify and cancel invoices in Veri*Factu and with the Verifacti API.

To modify or cancel an already generated invoice, it is necessary to make additional calls to the AEAT through additional invoicing records.The possible paths to follow include:

• Corrective invoices with the Create Invoice endpoint (for most cases)
• Credit notes with the Create Invoice endpoint (for full returns)
• Cancel invoice endpoint (for very restricted cases where the invoice was issued in error)
• Amend invoice endpoint (for very restricted cases where the change does not include fields with fiscal impact)

Confusion with the unalterability requirement

It is common to hear that under the Veri*Factu system, invoices cannot be modified. This perception is incorrect. The unalterability required by Veri*Factu refers to the invoicing records (XMLs generated by Verifacti), not the invoices themselves. Invoicing records are the XMLs that Verifacti generates from the calls made to the API. For each call made to the Tax Agency, there is one XML (invoicing record) and these cannot be modified after creation.

Corrective invoices

• Whenever you want to modify any aspect of an invoice (accepted, partially accepted, or rejected) that involves a change in fiscally relevant data (such as recipient, amount, tax rate, etc.), you must always use a corrective invoice.
• Corrective invoices are types R1, R2, R3, R4, or R5.
• Corrective invoices are new invoices with a different series from the original, and with their own QR.
• These additional invoices must be delivered to the recipient.
• When you issue a corrective invoice (including F3), you reference the original invoice. However, the AEAT does not appear to verify whether the original invoice was previously sent or anything of the sort.

You can perfectly issue a corrective invoice referencing an invoice that was never sent through the Veri*Factu system and it will not cause any issue with the AEAT API.Credit note

• The only exception is when you issue an invoice for goods that are subsequently returned in full. In that case, it is sufficient to issue a normal "negative" invoice. This is an ordinary invoice with a negative total amount that can go in the same series.
• It would be a standard F1 invoice.
• The fact that a negative F1 can be issued is made very clear in the AEAT examples, which can be found at the following link.
• These additional invoices must be delivered to the recipient.
• Credit notes do not require their own series; they can go in the same series as the original invoice.

These endpoints exist in the Verifacti API because they also exist in the AEAT's own API. While the naming invites their use for all types of operations, the AEAT establishes very restricted use.Cancellation endpoint

* Only for invoices that should never have been issued (issued in error).

• Important: if an invoice is cancelled, that number cannot be reused—you must skip to the next one, otherwise Veri*Factu will report a duplicate invoice error.

Amendment endpoint

* When the corrected field has no fiscal implications, such as the description field.

Verifacti does not provide detailed tax advice for complex invoicing cases (such as simplified invoice returns, corrective invoices with disbursements, or the use of R1 and R5). Our documentation and examples cover the most common scenarios.For specific or unclear situations, we recommend consulting a tax advisor or the AEAT directly through verifactu@correo.aeat.es, who usually provide a quick response.

Below is a high-level overview of the types of errors that can prevent your invoice from being considered valid and correct by the Tax Agency (AEAT).Something very important to understand regarding error handling is that under the Veri*Factu regulation, an invoice cannot be created (nor delivered to its recipient) if the Invoicing Record (XML) has not been previously generated, which requires a successful call to the Verifacti API. This is a red line for the AEAT, which accepts late XML submission but does not accept the non-creation of the XML.1. Status code 500 response from the Verifacti API and Incidents

• A 500 status code response from the Verifacti API implies that some kind of incident is preventing correct API calls. An example would be the Verifacti API being down.
• The way to handle this situation would be similar to handling incidents such as internet or power outages, situations in which it becomes impossible to contact the Verifacti API.
• In any of these situations, even if transactions and sales continue to occur, no invoice should be delivered to the buyer of the goods or services, since the AEAT makes clear that it is not possible to issue invoices without generating an invoicing record (XML), i.e., without having previously called the Verifacti API correctly.

2. Status code 429 response from the Verifacti API

• This status indicates that too many requests per minute are being made for the same API key.
• You should retry later at a lower rate.

3. Status code 400 response from the Verifacti API

• The 400 response status code indicates instant validation errors from the Verifacti API that generally occur due to format, syntax, or authentication failures in the request.
• If a 400 status code is received, the invoice cannot be considered generated, as the invoicing record has not been generated and the QR for attaching to the invoice has not been returned.
• If a 400 status code response is received, the submission must be corrected by reviewing and fixing the request structure and data format (e.g., ensuring dates follow the DD-MM-YYYY format).

4. Rejected or Accepted with Errors status of the invoicing record by the AEAT

• When a 200 status code response is received, which comes with the QR for attaching to the invoice, the invoicing record (XML) has already been correctly generated by the Verifacti API for submission to the AEAT and the invoice can be considered generated.
• At this point, the process of submitting the invoicing record to the AEAT begins, and the record status will be "Pending".
• Once the submission is complete, a process that can take a few minutes, the AEAT issues a response XML indicating whether they accepted the invoicing record.
• The record status should be checked through two possible paths: webhooks (recommended) or the record status endpoint.
• The record status can also be viewed on the verifacti.com web interface, within each NIF's panel, in the "Records" menu.
• AEAT errors occur due to failures in the fiscal content of the record (e.g., incorrect NIF/CIF).
• When the record does not have the "Correct" status, then the invoice has been created but is not fiscally valid despite having received Verifacti's initial OK.
• In this case, the invoice must be rectified. This involves issuing a Corrective Invoice to correct the invoice through an additional invoicing record. In exceptional cases, an amendment record can be issued.

5. Errors due to regulatory non-compliance outside Veri*Factu

Complying with Veri*Factu does not guarantee compliance with all invoicing regulations or accounting or tax rules. It is common to encounter situations where the Veri*Factu system accepts invoices with elements that are incorrect from the perspective of invoicing regulations. Therefore, it should not be assumed that a "correct" AEAT response to a call to its API through Verifacti equates to full regulatory approval.Some examples of invoice errors that are nevertheless accepted by Veri*Factu (and by the Verifacti API) include:

• Veri*Factu accepts without errors invoices that violate the sequential invoice numbering requirement within the same series established by invoicing regulations. Veri*Factu will not return an error if we send invoices in non-sequential order, despite this being incorrect and subject to penalties.
• Veri*Factu accepts without errors invoices where the issue date is earlier than the date of the 200 status code response from the Verifacti API, which is the exact moment the invoicing record was created. This is incorrect, as the AEAT establishes that the issue date must coincide with the moment of the invoicing record (XML) creation.

Regarding the errors that Verifacti detects and prevents, we must distinguish between two different types of errors:Detection of errors in the invoicing record

* The Verifacti API has a validation system that prevents some of the most typical errors in invoicing records. When detected, the creation of the invoicing record is prevented, the submission to the AEAT is avoided, and the need for a subsequent corrective invoice is eliminated.

• While the Verifacti API detects many errors, it is not possible to detect all of them, and therefore records may encounter AEAT errors once submitted to the tax authority.

Detection of errors according to invoicing or tax regulations

* Veri*Factu accepts without errors invoices that have errors according to various current regulations, such as invoices with non-sequential numbering or invoices with an issue date earlier than the invoicing record creation date.

• The Verifacti API does not perform any validation in these situations. The reason is that it would be risky to add validations that the tax authority itself does not enforce, as the tolerance for certain errors may have reasons unknown to us, and therefore that tolerance must be preserved in the Verifacti API as well.

Below we explain how to deal with different types of incidents.AEAT outage: we handle itIn the event of a tax authority API outage (something that has already happened in the test environment in the past), Verifacti will take care of retrying submissions until the AEAT API is operational again. Verifacti users therefore do not need to worry about this eventuality, which is covered by our API.Other incidents: retry calls and provisional sale receipt or delayed invoice issuance (B2B only)

Any of the following 3 situations make it impossible to call the Verifacti API:

• Power outage
• Internet outage
• Verifacti API outage

The AEAT addresses this topic in a FAQ on their website, with a response that can be misleading. There, the AEAT says that late submission of the Invoicing Record (the XML with the invoice data) is accepted and that you can "continue invoicing." However, that AEAT FAQ assumes the ability to generate the XML on-premise, which is very uncommon. Therefore, the AEAT approves delaying the XML submission, but does not approve delaying the XML creation to a moment after the invoice issuance.In inquiries we have made to the AEAT, they have confirmed that it is not possible under any circumstances to issue an invoice without prior XML generation. For those software that use our API, this means that creating invoices without being able to call our API is not a possibility.The AEAT has communicated to us in inquiries that given this situation, the issuance of a provisional sale receipt would be acceptable. That is, you can continue selling (and collecting payment, for example with the POS terminal if necessary), you just need to ensure that you do not deliver an invoice to the client. Instead, you should deliver an alternative document that includes the data that would be on the invoice, but that clarifies it is not the invoice, and indicates a channel for obtaining the invoice later for those who wish to do so.Once the incident is resolved and the ability to make calls to the Verifacti API is restored, all pending invoice generation calls must be made:

• Calls should be made in the same order as the transactions took place, although not achieving this would not be a serious problem.
• The incident field must be set to TRUE.
• Consider marking the operation date field with the transaction date if more than one day has elapsed.

It is also worth clarifying that in the case of a B2B transaction, it is possible to delay the invoice issuance. In this case, the invoice can be issued subsequently, up to the 16th of the month following the transaction. This is another admissible solution.

Below we show some typical errors detected by the Verifacti API that generate an immediate 400 status code response. We show you the errors and give you information to fix them:

• Authorization Header: Make sure the authorization token is preceded by the word Bearer. Correct format: Authorization: Bearer [your_token].
• Date Format (fecha_expedicion): Verify that the date is in the DD-MM-YYYY format (day and month with two digits). For example, 22-02-2025.
• id_otro field: This field must be a JSON object directly, not a text string containing a JSON.
• Decimal Separator in Amounts: Use the period ( . ) as the decimal separator for all amounts (e.g., 320.00) with a maximum of 2 decimal places.
• Boolean Values (true/false): Make sure boolean values are true or false (lowercase and without quotes), not text strings like "True".
• Handling serie and numero: If series and number information is combined in the numero field, the serie field must be explicitly sent as an empty string ("").
• Misplaced line fields: Fields like impuesto, clave_regimen, and calificacion_operacion are line-level fields and must be included within the invoice items, not at the header level.

We strongly recommend reviewing our official documentation and detailed examples to ensure a correct implementation.

Below we delve into the errors the AEAT can find in the invoicing records (XML) received from the Verifacti API and how to handle them:Possible errors

* There are many possible errors the AEAT can find in an invoicing record, the most typical being format errors or the erroneous combination (contrary to documentation) of values from different fields.

• The following AEAT document contains a list of possible errors.

Error handling

* If the invoice has been delivered to the client, even if the AEAT has rejected the invoicing record, the invoice is considered generated, and therefore its numbering is "occupied" and another invoice with that numbering should not be issued again.

• The path recommended by the AEAT for resolving these situations is issuing corrective invoices, which require a different series from the originals. More information about corrective invoices in the examples section.
• The situation would therefore be resolved through additional invoicing record(s), without modifying the original invoicing record, thus respecting the integrity and unalterability requirement of invoicing records.
• Only in cases where the invoice was not delivered to the end client and the invoice should never have been issued or was issued in error could the invoice cancellation endpoint be used.

A successful integration must include a mechanism to listen for the AEAT response to submitted requests to confirm there are no errors.This will allow you to:

• Confirm that the request was processed correctly.
• Detect and correct Tax Agency errors in time.

This can be done:

• Through webhooks (preferred)
• Through the record status endpoint (requires an extra call per request)

The hash is applied to invoicing records, not to individual invoices.

Verifacti is responsible for chaining these records sequentially at the time of their generation, regardless of whether the associated invoice is subsequently accepted or rejected by the system.The final status of an invoice is determined after its submission, so the chaining sequence is not affected by resending corrected or previously rejected invoices.

If the invoicing record has been sent to the AEAT, even if the AEAT has rejected the invoicing record, the invoice is considered generated, its numbering is "occupied" and another invoice with that numbering should not be issued again.

The Duplicate status and its associated details are responses that come directly from the Tax Agency (AEAT), they are not generated by the Verifacti API. This means that the AEAT has already previously received and processed a record with the same data.

For a duplicate invoice, it is not necessary to issue a corrective invoice. The AEAT will simply ignore it.

Yes, it is possible to use the same series and invoice number in different fiscal years.Veri*Factu and the AEAT API only consider an invoice as a duplicate if the series, number, and issue date match.

When creating invoices in batches, responses are returned in the same order in which the invoices were sent. If any invoice is rejected due to a validation error, an error message will be returned specifying the index of the invoice within the batch that failed. To test batch invoice submissions, an active subscription is required.

Currently, it is not possible to view the status or history of webhook deliveries in the Verifacti graphical interface. The webhook will attempt to send the message to your configured endpoint immediately after the invoice is sent to the AEAT, which usually occurs approximately one minute after your request.

According to AEAT specifications, invoicing records must be packaged and sent in groups, not individually.

Verifacti groups multiple records into a single submission to the AEAT. Each time such a submission is made, your webhook is notified with the information of all records included in that package.Therefore, the number of webhook calls corresponds to the number of packaged submissions made to the AEAT, not to the individual number of processed invoices.

No, Verifacti webhooks do not retry the notification delivery if your endpoint is down or not responding.To ensure data consistency and avoid outdated records, you should implement a process in your system that periodically reviews (for example, every hour) whether you have invoice records in Pending status that are older than a certain threshold.In those cases, you can use the record status query endpoint to obtain the updated document information.

The Verifacti API invoice listing endpoint queries the AEAT API directly. Currently, the AEAT API does not allow getting a list of invoices for a single day. To perform the query, it is necessary to specify a date range.

Yes, to get invoices for a full year, you must make 12 calls to the invoice listing endpoint, setting the periodo parameter for each month (from 1 to 12). This is an AEAT API restriction.

There is no way to query the Tax Agency for the last issued invoice. The last issued invoice must be obtained from the software's own database. It is possible to list invoices through the list invoices endpoint, which forwards the request directly to the AEAT, but you cannot make a call that returns only the last one.

It is not necessary to include previous old invoices from the same tax period or from the same series.

The Veri*Factu production environment has been enabled since April 2025. It is already possible to send real invoices to the AEAT.

To run tests, you must create the company in test mode. The same company can exist in test and production mode simultaneously, each with its own different API Key.

The responsible declaration (declaración responsable) is a self-certification in which the SIF confirms that it complies with the regulation. The "certification" requirement established by the Anti-Fraud Law (from which Veri*Factu originates) is satisfied with this "self-certification" that each invoicing software must publish, and that the AEAT can require in case of an inspection.To comply with Veri*Factu, there are no external certification or AEAT verification requirements. Simply, each invoicing software must incorporate this document, regulated in Chapter IV of the Ministerial Order (Orden Ministerial).In a mixed architecture case such as using an API like Verifacti, both the invoicing software and Verifacti itself must have their responsible declaration. Ours is available:

• Through a link
• Via endpoint

There is a complete section in the AEAT FAQ about this document and its requirements. Here we only highlight two very important aspects of this document:

1. Placement of the responsible declaration - It must be visible to the software users and, in the case of commercialization, also to buyers. It is suggested that it be accessible in the help section of web-based software.

1. Software numbering - The responsible declaration must refer to the corresponding software number. Each provider must have a declaration for each software numbering created after the entry into force of Veri*Factu. Only the current declaration, corresponding to the software numbering in use, should be available, although in case of an inspection, the AEAT could request all previous ones.

👉 Watch short video: Responsible declaration part 1, certification, where to include it, versions and other questions

The AEAT has published an example of a responsible declaration in PDF.We have adapted this example for our users. You can download it here:

• We provide an editable Word document.
• We include informational notes for the more complex sections.
• We add a section to explain the role of the Verifacti API.

Key information for filling out the document:

1. Section titles are in bold and larger font.
2. Replace the example responses with your own data.
3. Delete the informational notes when completing the document.

It is mandatory to mention Verifacti as an external component. We have included a specific section for mixed architectures with an external component. You must indicate our current software version number, which may change. You have a specific endpoint to obtain our declaration and the current version number.👉 Watch short video: Responsible declaration part 2: guide to easily completing the responsible declaration

There is no list of AEAT-approved software for Veri*Factu. The certification obligation established by the anti-fraud law is resolved through self-certification, i.e., a responsible declaration (see related FAQ). Although some providers and invoicing software claim to be approved by the AEAT, such approval does not exist. It is a commercial strategy based on an inaccurate and even misleading claim.In Ticketbai, the Basque Provincial Tax Authorities' system, the concept of administration-approved software does exist as "software garante" (guarantor software). We also cover Ticketbai and we are "software garante", meaning software approved by the Tax Authority in all three Basque Country provinces. We include the list of guarantor software in Vizcaya as an example.

There is no list of AEAT-approved software for Veri*Factu. The certification obligation established by the anti-fraud law is resolved through self-certification, i.e., a responsible declaration (see related FAQ). Although some providers and invoicing software claim to be approved by the AEAT, such approval does not exist. It is a commercial strategy based on an inaccurate and even misleading claim.Verifacti has signed a specific social collaboration agreement with the AEAT (agreement 017) that allows us to use our own certificate to submit tax information to the AEAT on behalf of our clients. See list of entities with agreement here (we appear as Bilbabit SL).In Ticketbai, the Basque Provincial Tax Authorities' system, the concept of administration-approved software does exist as "software garante" (guarantor software). We also cover Ticketbai and we are "software garante", meaning software approved by the Tax Authority in all three Basque Country provinces. We include the list of guarantor software in Vizcaya as an example.

See the specific AEAT FAQ on this topic.

We refer you to the instructions available in the document template.

Verifacti uses its own digital certificate to submit information to the AEAT on behalf of third parties. The AEAT requires the signing of a representation model by the taxpayers.Verifacti's certificate as a social collaboratorVerifacti uses its own representation digital certificate to send tax information to the tax authority on behalf of the taxpayers. This avoids the need to request certificates and passwords from Verifacti users, reducing security risks and avoiding user refusal to share sensitive credentials. To this end, Verifacti operates within the social collaboration framework, a figure predating Veri*Factu that is widely used for many tax advisory purposes. Specifically, Verifacti has signed agreement 017 with the AEAT, created specifically to provide coverage for the social collaboration figure in the scope of Veri*Factu. Verifacti appears listed (Bilbabit SL) in the official list of entities with agreement of the AEAT.

👉 Watch short video: Certificates and representation (Part 1) - Verifacti's Social Collaborator Certificate

Representation models (Modelos de representación)Whenever it is not the taxpayer themselves who submits their information to the AEAT, the regulation requires that taxpayers sign a representation model authorizing Verifacti to send tax information on their behalf. These representation models were published in the BOE (Official State Gazette) in December 2024 (see Annexes I, II, and III).Verifacti offers its clients two different paths to expedite the signing of these representation models:

1. From the Verifacti web interface, following the steps indicated in the Settings → Representation section for each NIF.
2. Programmatically, through the NIF Management API.

It is very important to note that the representation model only needs to be managed once per NIF. That is, if you want to have the same NIF registered twice in test and in production, it would be sufficient to do this management once in test for it to also be valid for the production NIF, even if it has not yet been created. Therefore, the appropriate chronology for representation management could be:

1. Create NIF in test

2. Manage representation for that NIF

1. Create NIF in production (representation will already be managed without needing to do it again).

👉 Watch short video: Certificates and representation (Part 2) - Help for Signing Representation Models

The AEAT has been clear that the correct way to sign the models is either in person or through a digital certificate. We are aware that this flow is not the most user-friendly since some taxpayers do not have a digital certificate. If changes occur that allow a simpler path, we will notify all our clients accordingly.

Verifacti operates within the social collaboration framework, a figure predating Veri*Factu that is widely used for many tax advisory purposes. Specifically, Verifacti has signed agreement 017 with the AEAT, created specifically to provide coverage for the social collaboration figure in the scope of Veri*Factu. Verifacti appears listed (Bilbabit SL) in the official list of entities with agreement of the AEAT.

The Verifacti endpoint only accepts files in PDF format for the signed Representation Model.

In Spain, to interact with the Tax Agency (Hacienda) and platforms like Verifacti, digital certificates issued by any recognized Certification Entity are accepted, not limited exclusively to the FNMT (Fábrica Nacional de Moneda y Timbre - Spain's national mint).For managing and applying these digital signatures, AutoFirma software (developed by the Spanish Government) is an excellent option.Additionally, programs like Adobe Acrobat also allow you to digitally sign documents using the valid certificates installed on your system.

Make sure that the NIF appearing in the digital certificate is exactly the same as the NIF registered in our systems and in any associated documents, such as setup or registration PDF files.A common error is a one-digit or one-letter discrepancy between the certificate NIF and the NIF in other documents.

To fix it, regenerate the representation document PDF with the correct NIF, sign it, and submit it.If you believe your model is valid, please contact soporte@verifacti.com so they can review and approve it manually.

This error (Codigo[4112]), in the AEAT test environment, is due to internal tests carried out by the AEAT itself and not a problem with Verifacti. It generally occurs on Saturday mornings.The Verifacti production environment is not affected and works correctly with the same certificate.

In Veri*Factu mode, there is no obligation to store the invoicing records sent to the Tax Agency, neither for the invoicing software nor for the taxpayer, since those records have already been previously submitted. The tax authority is clear on this point: the obligation to store invoicing records only exists in Non-Veri*Factu mode.By invoicing record, the tax authority means the XML files that Verifacti generates from the calls received, and which are submitted to the AEAT. These are, therefore, the XML request files to the tax authority and the tax authority's response files. In Veri*Factu mode, there is no obligation to store these files.That said, Verifacti provides endpoints to download the invoicing records for those users who wish to keep them.Export XMLs endpointDownload XML endpointAdditionally, Verifacti will store this information for all active production NIFs and for a short time after (see terms of use).The above should not be confused with the obligation to store invoices derived from the Invoicing Regulation (Reglamento de Facturación) or other tax or accounting regulations. Any obligation that the software or its users (the taxpayers) had before the appearance of the Veri*Factu system remains in force. There are therefore storage obligations regarding invoices, as was already the case before the Veri*Factu regulation.👉 Watch short video: Veri*Factu vs Non-Veri*Factu, and the obligation to store the XML invoicing records

You can access the data of a NIF in two different ways:

1. Via endpoint - Verifacti provides endpoints to download the invoicing records for those users who wish to keep them.

Export XMLs endpointDownload XML endpoint

1. Web interface - You can view the latest records through the web interface, from the records screen of each NIF.

Remember that Verifacti only stores the XMLs generated 30 calendar days after a NIF is deactivated. It is the responsibility of each Verifacti API user to export the XMLs if they wish to keep them.

All information related to a NIF (taxpayer) is stored while it is active in the production environment. Once it is no longer active, after a short time (see terms of use), we do not guarantee the custody of that data.Verifacti provides endpoints to download the invoicing records for those users who wish to keep them.Export XMLs endpointDownload XML endpoint

Yes. At Verifacti, we intend to address the needs that arise around electronic invoicing once the regulation has been developed. For now, it is not possible as the necessary regulatory framework does not yet exist.

Yes. Verifacti intends to provide coverage for the Navarra NaTicket system to cover the entire Spanish territory.

Why are there two different APIs to integrate with Veri*Factu and TicketBAI?

We decided to design two differentiated APIs, one for Veri*Factu and another for TicketBAI, largely following the structure of the official tax authority APIs.This provides several advantages:

• Consistency: the endpoints, fields, and error messages we present to our users are practically the same as those in the tax authority APIs.
• Easier tax consultations: this similarity eliminates interpretations or biases stemming from an intermediary API, which streamlines communication with advisors and with the tax authorities themselves.

What does this mean for integration?

It is necessary to integrate with two different APIs.However, in practice, after integrating with Veri*Factu, the subsequent TicketBAI integration usually requires only 10%-20% additional effort. This is because several calls coincide, and when they don't, they maintain a very similar structure.For example, when creating an invoice, you will need two different JSONs, using one or the other depending on the target API.

Signing and submission in compliance with TicketBAI

To comply with TicketBAI regulations, the invoicing system must generate an XML file for each transaction, digitally sign it, and submit it to the corresponding Provincial Tax Authority (Hacienda Foral). Our API takes care of generating the XML using the data provided in the API call and signing it in compliance with the regulation.Each invoice is cryptographically linked to the previous one, and the digital signature guarantees its integrity, preventing tampering. For this, a digital certificate issued by a qualified trust service provider is required.Current legislation allows the use of several types of digital certificates for signing TicketBAI invoices:

• Device certificate: created explicitly for use in TicketBAI.
• Entity representative certificate: identifies the individual responsible for the legal entity.
• Entity seal certificate: no personal data of the representative appears, only the company is identified.
• Freelancer certificate: created explicitly for use in TicketBAI.

In general, the decision of which certificate to use depends on various factors: legal nature, software to be used, invoicing scenario, and certificate characteristics.Why choose the device certificate with Verifacti?

At Verifacti, we chose to implement the use of device certificates, as they offer numerous advantages over other options:

• Exclusive use for TicketBAI: It does not allow performing other procedures with the Provincial Tax Authority.
• Privacy ensured: The taxpayer does not need to provide their own personal certificate.
• Operational simplicity: The same certificate can be used both for signing and sending the XML files.
• The Verifacti API integrates a device certificate issued by a QTSP (Izenpe). This must be previously registered and associated with the taxpayer's NIF at the Provincial Tax Authority. Although Verifacti offers a managed option to minimize technical effort, it also allows the integrator to use their own device certificate if preferred.

Device certificate registration

For the device certificate to be used in sending TicketBAI files, it must be linked to the NIF of the invoice issuer. The process varies slightly by province:For Álava and Vizcaya, registration is done before sending the first invoicing record. If not done, the Tax Authority will reject the submission and the error message will indicate that the certificate is not registered.For Guipúzcoa, registration is done after sending the first invoicing record.In both cases, the registration process is very simple and done online. The steps are as follows:

1. The taxpayer accesses the Provincial Tax Authority's web portal with their personal digital certificate.
2. They provide the serial number of Verifacti's device certificate (1f3647f642e9fae56807d91d6865a22a).

You can find links to each Provincial Tax Authority's portal here:Device certificate registration in Araba

Device certificate registration in GuipúzcoaDevice certificate registration in VizcayaIMPORTANT: If registration is not completed, TicketBAI files will be rejected by the Provincial Tax Authority.

To comply with TicketBAI, the software that sends the invoicing records must be registered in the official Guarantor Software (Software Garante) list. That is, if a software uses Verifacti to integrate with the Provincial Tax Authorities, Verifacti must be a guarantor software (and it is), but the software that uses Verifacti does not need to be a guarantor software.Although the law itself does not explicitly require the use of registered software, in practice it is essential. The generated XML files must include identifying data of the software according to its registration: name, version, developer entity, and TicketBAI license number. The latter is obtained upon completing the registration process.Verifacti has already gone through this process and is a guarantor software. The registration process in the Basque Country requires the company that will send the records (Verifacti) to submit a technical report demonstrating compliance with TicketBAI requirements. Additionally, a responsible declaration must be submitted confirming regulatory compliance and assuming commitments in case of legal modifications affecting the system.You can consult the official lists at the following links, where Verifacti appears as guarantor software (Bilbabit SL):

• TicketBAI Software List in Álava
• TicketBAI Software List in Guipúzcoa
• Guarantor Software List in Vizcaya