Sending XML Files
TicketBAI compliance contemplates the creation of two types of XML Files:
Registration Files: XML file created when a new invoice is issued.
Cancellation Files: XML file created when an invoice is cancelled, such as for transactions not carried out.
TicketBAI requires that these files be sent to the corresponding Tax Authority, depending on where the legal address of the taxpayer issuing the invoices is declared.
Araba and Gipuzkoa
SIGN ES performs the sending automatically in Araba and Gipuzkoa. The invoices sent by SIGN ES is used as the “Issued invoices book” of the SII System (Immediate Information Supply) for taxpayers who must comply with it. However, if additional information is required as contemplated by the SII -such as external reference, real estate transfers subject to VAT, amongst other- this will have to be sent through an additional service called OSATU, not contemplated within TicketBAI specifications (See requirements of OSATU service available in Spanish).
The sending process of TicketBAI files is carried out in the SIGN ES API Signing component. The Signing component synchronizes the state of TicketBAI files from the SIGN ES server to the Spanish Tax Authority's server. This synchronization is implemented over the request/response model provided by the Spanish Tax Authority.
Response
When a file is submitted, the systems of the Tax Authorities automatically perform various validations, and the results of these checks are included in the response.
The ideal registration status is REGISTERED. SIGN ES helps to reduce rejections by ensuring that XML files are correctly structured and the data is formatted accurately through its validation processes.
However, if the invoice's registration status appears as REQUIRES_CORRECTION, it may be necessary to re-submit the file, provided that the Spanish invoicing regulations do not require issuing a correcting invoice.
Re-sending of the invoices
SIGN ES enables the re-sending of invoices in the REGISTERED, REQUIRES_CORRECTION, and REQUIRES_INSPECTION registration state via REMEDY invoices to Zuzendu in the following cases:
- registration files have been rejected
- registration files have been accepted with errors but do NOT require a correction by law
- files accepted by TicketBAI, where the taxpayer needs to modify information that does not require a correction by law
If an error is received because the taxpayer has either failed to register the device certificate in Araba or exceeded the 30-day acceptance period in Gipuzkoa, the taxpayer must promptly register or accept the device certificate, depending on the relevant territory.
The re-sending of invoices with a registration status of PENDING or STORED is not permitted. These invoices are either waiting for submission by SIGN ES or are stored because transmission to the tax authority is not necessary.
Bizkaia
Sending of invoices with SIGN ES
Sending is performed using a device certificate that must be registered with DFB/BFA by the obligated taxpayer. This must be done before the device starts generating invoices on behalf of the taxpayer.
By sending the invoices in real time we ensure that the deadlines imposed by BATUZ are met.
COMPANIES: SIGN ES carries out the automatic sending of TicketBAI invoices within the LROE subsection 1.1 - Issued invoices using guarantor software (Model 240). This submission is in real-time.
INDIVIDUALS: once the activity code is provided SIGN ES carries out the sending of TicketBAI invoices within the LORE subsection 1.1 - Income with issued invoices using guarantor software (Model 140).
Ideally, the activity_code should be provided at the moment of creating the invoice. This allows the real-time transmission of the invoice to the tax authorities. Otherwise, the invoice will remain in a STORED state and will be forwarded to the tax authorities only after the invoice has been updated with the activity code.
Please check that the activity code is valid in Bizkaia, otherwise the invoice will get rejected by the tax authority.
For individuals, there are two additional optional fields: the income_tax_amount and pay_collect which along with the activity_code form a grouped set of data. If these fields are left empty while the activity code is provided, they will automatically be marked as 'No' by default.
If the VAT base is different from the IRPF income the taxpayer will need to fill in the income_tax_amount field. For guidance on calculating this, you can refer to our article How to calculate the IRPF Income Amount on an invoice?
The pay_collect field indicates if the taxpayer has chosen to be part of the collection and payment criteria.
The activity code can only be introduced once, either during the creation of the invoice or when updating it, and it cannot be modified afterward. This also applies to the income_tax_amount and pay_collection fields, once you submit them with the activity code. This ensures that these pieces of information, once entered, remain consistent and unchangeable.
The field vat_withholding in our API could apply for both individuals and companies, specifically to B2B transactions that include complete invoices and their corrections. This field caters to a specific tax system scenario involving self-employed individuals who, when issuing invoices to companies or other self-employed, are required to withhold a portion of the IRPF (personal income tax) on their income. In this system, it's the buyer, not the seller, who directly remits a part of the tax to the authority.
Response
Upon receiving a request, the Bizkaia Tax Authority’s systems automatically undergo validations, and the outcome of these validations are reflected in the response, just like in other provinces.
Ideally, the registration state should be REGISTERED. SIGN ES helps minimize instances of rejection by ensuring the accurate structure of XML files and the correct format of introduced data through applied validations.
However, if the invoice's registration state shows REQUIRES_INSPECTION, it is likely that the files need to be resubmitted to Bizkaia Tax Authority's system, as long as a correcting invoice is not required according to the invoicing regulation in Spain. Depending on the case, this can be done either by re-sending of subchapter 1.1 for invoices issued with guarantor software or via subchapter 1.2 for invoices issued without guarantor software.
Re-sending of the invoices
SIGN ES enables the re-sending of invoices in the REQUIRES_INSPECTION registration state via REMEDY invoices through subchapters 1.1 and 1.2. The re-sending of invoices with PENDING and STORED registration state is not allowed. These invoices are either awaiting submission by SIGN ES or stored because either transmission to the tax authority is not required or important information is missing.
Re-submitting via subchapter 1.1 is possible if,
- the error is due to invalid data introduced in the fields of the
annotationsblock - the device certificate was either not registered or was incorrectly registered by the taxpayer at the time of transmission
Re-submitting via subchapter 1.2 is possible if,
- subchapter 1.1 was rejected, and re-sending through 1.1 is not possible
- if the invoice has already been remedied and sent through 1.2. Remedying the remedied invoice is also possible if the remedy invoice is in the
REGISTEREDstate
Offline invoices
Invoices issued offline in Bizkaia are classified as "issued without guarantor software" and must be transmitted to LROE subchapter 1.2.
To transmit these invoices, you must first register them in the SIGN ES system as external invoices, using the invoice type EXTERNAL. This step is essential to assign a UUID to the invoice generated offline.
When the invoice is uploaded as an EXTERNAL invoice, it will not be transmitted to the tax agency. Instead, like any other external invoice, it will have a registration state of INVALID.
To transmit the invoice, the next step requires creating an invoice of type REMEDY, referencing the UUID previously assigned to the external invoice.
Test Environment
The Test Environment in Bizkaia requires specific NIF, VAT Number and device certificate to avoid rejection errors. At fiskaly, we have formally requested and obtained this information from the authorities. These specific details will automatically override the test data provided during the creation of XML files, ONLY IN TEST ENVIRONMENT. By doing this, we ensure a seamless testing workflow with effective transmission responses.
SIGN ES API performs validations that prevent rejection of the XML files when sending them to the Tax Authority.