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.
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 outcomes of these validations are reflected in the response, just like in other provinces.
In case the invoice requires_inspection, it is likely that the files need to be resubmitted through subchapter 1.2, dedicated to invoices issued without guarantor software, as long as a correcting invoice is not required according to the invoicing regulation in Spain. 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.
If specific details require correction according to the invoicing regulations in Spain, the correcting invoice has to be issued and transmitted through SIGN ES.
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.
