Frequently asked technical questions

By XML corresponding to the type of book and operation that you want to carry out. It concerns constantly sent invoices which are grouped into blocks of 10,000 for operational purposes to facilitate a synchronous response.

Those allowed for UTF-8.

No

No, it is not necessary to sign the XML.

Yes. Presentation must be carried out by the liable taxpayer, a representative authorised to carry out this procedure, or a social collaborator, who must have a recognised electronic certificate. Therefore, in order to use the services, it is necessary to have an electronic certificate permitted by the Tax Agency installed on the computer used to send the information

Information on certificates on the Tax Agency web portal: Home - Help - Electronic certificate

A response is sent regarding the presentation carried out, indicating that the invoice is rejected as it is a duplicate. According to this the details that make an invoice unique are: Personal Tax ID (NIF) of the issuer, invoice series and number and issue date.

The client must verify whether the HTTP request generated is lacking information (for example regarding a certificate), in which case they should send a reply with an html format error message.

In the event it is necessary to state one of the following characters in a value of an XML element, they should be escaped with the following XML element:

The certificate must be one of those accepted by the Tax Agency in any of its services. The holder that appears in the books must coincide with the personal Tax ID (NIF) of the certificate holder.

For the SII trial, the Tax IDs (NIF) showing in the invoices must be identified, but there is no validation as to whether they exist in the SII census.

A taxpayer can use different platforms and service providers to file invoices. They can entrust the supply of information on invoices to one or more authorised representatives or social collaborators and at the same time directly provide information on other invoices to the Tax Agency.

The certificate identifies the person filing invoices, and it can be that of the book holder or of a third party who complies with the criteria of representative powers or social collaboration.

The XML reply file will contain the identification of all the invoices sent with the result of the validation. In the event of error, the code will appear alongside a description for each of the invoices.

Only invoices that have passed the validations are recorded in the system.

The validation answers the first error detected in the invoice. Validation of the entire invoice is not stated, since there are details that are validated in accordance with others.

The procedure in the event of an identification error, since it is not a format error, consists of trying again later, since the Tax Agency will attempt to register it in the census if it is appropriate.

There is an ID validation service where you can validate identifying details in advance.

Tax Identification Service on the home page of the Tax Agency web portal: Home – The Tax Agency – Campaigns – Informative Tax Return – Help Services – Tax Identification.

As of 21 September, a change has being introduced in census consultations and the multiple web service for personal information quality so that, for private individuals, both tools show the surname(s) and name(s) recorded in the Tax Agency Census connected to the ID number consulted if these are similar to the surname(s) and name(s) sent, even if the taxpayer cannot be identified by means of the personal information details sent. With this improvement, the person filing can correct the personal information details of the taxpayer with those stated in the Tax Agency to avoid identification errors in filing

There is no limit, those sent must be considered continuously sent invoices for performance purposes, and in order to answer in a synchronous manner, grouped into blocks of, nominally, 10,000 invoices.

It is recommended to use the session ID details of the HTTP header, received in the first invoice filed, for those successively sent on the same day.

The client will receive in the server response a header "Set-Cookie:"

similar to this one:

JSESSIONID=s2~00010rV0Rf4nwiaxLK8Emzwz_Mx:wlp001_wlp002; Path=/wlpl/; Secure; HttpOnly

It is recommended to send the jsessionid cookie as a header in each request made to the server with the value received in the previous requests, behaving like a browser for this cookie.

In this application the http session is not used and it is only recommended so that users keep affinity with the server they have landed on to make use of caches.

For partially validated invoices, information on the imbalance with the counterpart will be offered, both via the enquiry website service as well as through enquiry in the E-Office. The enquiry into invoices itself will offer information on the state of validation.

The content must be stated in the following order: first surname, second surname, and name without punctuation marks.

Yes, amendments made after an invoice is sent (issued / received) can vary the state of balance in both senses, provided that it is in the voluntary period.

The balance attempt will be made when it is in the voluntary period. In periods that have finished, the state of the balance is not updated.

Yes, they can be sent with the late invoices mechanism.
The terms and their consequences are determined by the regulations. Invoices sent after the deadline are not impeded. The same validations are carried out whether they are in the deadline or not. The only difference is that for presentations in periods that have finished, verifying information will not be offered.

The Tax Agency only updates the balance status if the invoice can be verified and modifications are detected in the invoice (registrations, amendments, cancellations) by the counterparty or due to amendments made by the book holder, where applicable. The balance information can be obtained from the enquiry web service and from the Internet option.

The expected date is April.

The technical documents are available in English from 7 February.

They can be accessed via the English version of the Tax Agency web portal, i.e., selecting English in the header of the website.

For cases in which an issued invoice has been rejected, in a second retry, because the beneficiary identification information (NIF and name) is not registered in the AEAT census, the way to proceed to send this invoice is through the block NIFOther with the
following contents:

Country code: ES
Code NIF: 07. Not registered
ID Number: Not registered NIF of the invoice recipient
Surname and first name: Name of the person not registered receiver of the invoice.

In this case, the invoice will appear as accepted with errors. Via this route, validation will also be attempted against the census, in such a way that it can be identified, although the invoice will appear as accepted with errors. In all cases, a format error in the NIF will mean the rejection of the invoice.

The presentation of retroactive invoices for the first semester is carried out using the same validation outline with the following specifications for the mandatory fields with the following content:

. Special regime code. “16/14 First semester”. (Issued / Received)
. Transaction description: “Record of the First semester”.

Issued:

Non-exempt type: S1.

Received:

Accounting date: Sent date.
Deductible fee: Label with 0.

A mark is not necessary to differentiate the invoices of the first semester. The fiscal year will determine whether the information corresponds to the first semester of the 2017 fiscal year.

The first step is to describe the invoice as contrastable or not contrastable at the time of submitting the invoice. If the invoice is not contrastable, the invoice will remain in the status “Not contrastable” and will not be accounted.

Not contrastable means that it will never be contrasted. That is to say, that due to the characteristics of the issuer, the invoice, the record of which has been sent or the applicable regime, the possibility of contrasting this information will not be available.

Examples of this situation are simplified invoices in which the identification of the recipient is not requested. Therefore, it is not possible to locate this information reliably in the system, or when the counterpart does not participate in the SII and, therefore, is not obliged to send this information.

Once the submitted invoices have been validated and replied, the contrast process begins almost immediately,

Once the option of contrasting has been established, it is determined whether this information on the record sent by one party has been sent by the counterpart. To know whether this information is available, the unique code is used. If the same unique code of the record sent is not found, this information is understood to be not available, and the status of "Not contrasted" is conferred.

If the same unique code is located in the system, the process to contrast the information contained in both records sent by the two parties is executed.

If the contrast criteria coincides it will be considered "Contrasted", while if they do not all coincide, it will be "Partially contrasted". In the latter case, the taxpayer will be provided (via form or via web query service)
the non-matching contrast data for review.

It must be taken into account that, which each operation carried out against an invoice (amendment, cancellation, etc.) the contrast is reassessed again, and the status of the entry of the invoice according to the details received may change.
The accounting process will be attempted during the months following the invoice issue date 

This option of the SII test web portal is a basic client (with limited functionality) of the web service, which allows presentations of XML test files up to a maximum
of 100 invoices in order to assess the validation of different casuistries. Fill in the Enpoint URL of the corresponding book (Example for issued invoices: /Wlpl/SSIIFACT/
ws/fe/SiiFactFEV1SOAP) and select the XML file corresponding to the local environment you want to send. Once you have clicked on the send button, the system will respond
synchronously with a reply XML file with the result of the validation carried out.

When sending an already registered invoice, in the duplicate invoice error message, the SVC of the dispatch in which the initial registration of the invoice was made will be provided. Likewise, if the dispatch is made of a cancellation of a previously registered invoice, in the error message the SVC of the initial dispatch in which the cancellation of the invoice was requested shall be provided. 

With the aim of controlling the sending of duplicates and the option of making amendments and cancellations of investment assets, the unique code of the same is established, formed by the following data: Invoice identification number, goods identification number and details of the tax period.

A new site, www10.agenciatributaria.gob.es, has been created, where the following types of electronic certificate are accepted for identification purposes:

- A corporate person electronic seal certificate, in accordance with Regulation (EU) No. 910/2014 of the European Parliament and of the Council, of 23 July 2014, regarding electronic identification and trust services for digital transactions in the domestic market.

- A Public Administration electronic seal certificate, in accordance with Act 40/2015, of 1 October, of the Public Sector Legal Regime.

Electronic certificates accepted by the Tax Agency, in accordance with the provisions of Order HAP/800/2014, of 9 May, which establishes specific rules for digital identification and authentication systems with the State Tax Administration Agency, will be issued by the suppliers included in the Trusted list of qualified electronic trust services (TSL) elaborated by the Ministry of Energy, Tourism and Digital Strategy.

With respect to the qualified seal electronic certificates, certificates will be accepted if they can be validated on the @firma platform, for validating and signing digital certificates, and if they are classified as type 4 (Seal) and 8 (Seal qualified).

Both certificates can be used in application or server identification processes in machine to machine communications, for any services that, due to their characteristics, are considered to form part of automated and mass processes, and which do not require a natural person to authenticate them in the same process, acting as a representative of the corporate person. In this regard, the Tax Agency will report the possibility of using these certificates in the technical information for the services that accept them.

Specifically, the web services associated with the VAT record books kept in the AEAT E-Office, which require authentication with a qualified customer electronic signature, can be invoked in the new site www.10.agenciatributaria.gob.es, in the specific 'Port Name' described in the WDSL.

YES, the web service client of the pilot has been improved and it will be offered in production as a function for presenting the xml files of invoices from different books.

For the purposes of the presenter, the AEAT server returns a 405 Gateway time-out as an http response.

Error 403 is usually because a certificate has not been selected to make the connection. You need to check that the web service client is correctly set up to access the KeyStore where the certificate is stored.

Error 403 means that the request is arriving at the AEAT servers, but that the certificate (of the client) is not being used to make the request (the development is not loading correctly) and we receive the request with no certificate, or the certificate is damaged or not valid.

If the certificate is installed in a standard browser (IE, Chrome, etc.) and accesses any part of the E-Office of the AEAT (or even to any of the endpoints of the web services) without obtaining a 403, the certificate is correct and the development is not loading correctly.

No, there is no AEAT converter for xml files.

The online forms of the SII project do not have a limited period of use. They are filled out manually and individually per invoice, which are added one by one.

To make modifications or cancellations, you need to access it via the consultation tool, and once you have selected an invoice on the screen, cancellation and modification tabs appear.

The counterpart must be reported with the NIF/IDOther and NameReason corresponding with the party receiving the invoice.

This error can arise for two reasons:

The URL of the EndPoint is incorrect.

There is an error in the Envelope.

The EndPoint of the various environments are indicated in the documentation at the end of the .wsdl files

The available examples are in the document 'Web service description', which can be found at:

Home - Assistance - Forms, procedures and services - Procedure G417 - VAT Assistance. - Keeping record books (SII) - Technical help - SII technical information

The SII service accepts the submission of special Latin characters such as ñ or cedillas, or, in general, any special character used in UTF-8.

However, special characters of any other type are not accepted, such as Chinese or Arabic characters, etc.

The XML file with the presentation errors is returned at the time of presentation. The consultation web service lets you download the invoices submitted with different search parameters. They can also be viewed through the consultation web form.

Yes, the test portal will still be available. It will stay there indefinitely.

There are different reasons for which this error can take place:

The NIF (Tax ID No.) must be registered in the AEAT census.

The identification order indicated must be maintained for natural persons, i.e:

Surname 1 Surname 2 Given Name.

The content of the 'name' field must be as complete as possible so that the identification routine can find the holder.

For corporate persons, the identification system does not use the business name. 

When the 'operation counterpart (customer/supplier)' or the invoice issuer does not have an NIF (Tax ID No.) in Spain (which is the case with foreign suppliers and customers, among others), they must fill in the field 'IDOther'

This must also be filled in for the counterpart with Spanish parties with an NIF that is not registered with the AEAT for Invoices Issued, Insurance Operations and Cash Transactions. The value 07 must be entered in the field IDType.

In the case of invoices issued, the Invoice Issuer NIF must match that of the holder, however, for invoices received, the Invoice Issuer NIF must match that of the counterpart.

No. Deregistering invoices is a logical process. If you then want to register an invoice again with the same NumberSeriesInvoiceIssuer, you need to change the NIF (Tax ID No.) of the holder, the Series Number or the Date of Issue.

If you want to reactivate an invoice you cancelled in error you need to carry out an amendment on it (A1). The invoice will then return to being active with the amendment included.

If the error occurs when registering the invoice, it must be modified. If there is an error with the invoice, an amended invoice must be made, by substitution or differences.

The following section explains the different categories of amendment.

Yes, you can cancel an invoice that has been accepted with errors.

The consultation possibilities are offered through the consultation forms and the web services. Both have a range of parameters, which were deemed the most needed for narrowing down the invoice overviews. As for specificities with respect to selections and content, it must be the book holder who sets the filter.

There are two methods for consulting the invoices sent in blocks of 10,000:

- Without a paging code: you will be shown all invoices.

- With paging: you will be shown all invoices after the invoice indicated on the page.

When you make the consultation with a paging code (specifying the code of the invoice 'IDInvoice', after which you will retrieve the subsequent records ordered by date of submission), you retrieve the invoices following the one selected. But we do not resend the invoice included in the paging code.

Yes, this is perfectly possible.

Yes. You can find any errors in the Validations and Errors Document

Home - Assistance - Forms, procedures and services - Procedure G417 - VAT Assistance. - Keeping record books (SII) - Technical help - SII technical information

The country codes available are those that appear in the following document:

Any record presented must have a single code consisting in: The issuer's NIF (Tax ID No.), Invoice Serial Number and Date of Issue. If you want to reuse a record or present it again with any of these values, you must change one of the others. Take into account that cancelled records are also registered in the system, and therefore they will be rejected as duplicates if a record is presented with the same identification.

In general, this error occurs when the XML is not properly formed or does not comply with the structure defined in the corresponding Xsd.

Yes.

The SII system - Immediate Supply of Information on VAT is designed for large-scale data processing, using web services at the main means of interaction. The system allows up to 10,000 invoices to be registered per batch sent, with quick response times.

The most practical thing, therefore, is to group as many invoices per batch as possible.

it is a lot more productive to group batches for sending, even reaching one daily delivery with the total invoices for the day, or several batch deliveries if over 10,000 transactions are made each day.

Each time a batch is sent, both the taxpayer's computer system and the Tax Agency's system have to carry out preliminary infrastructure tasks (establishing communication, processing the XML message, synchronising servers, identification, etc.) before it begins to actually process each invoice. In addition, after the invoice is processed the same operations have to be done to send and process the response. Thus, in the extreme case of sending each invoice separately, both systems would be multiplying these infrastructure tasks by the number of invoices sent individually (or grouped into small batches), dedicating significant resources to tasks that could be done once every 100 or 1,000 invoices, for instance.

On the basis of all of the above, and given that the systems are capable, our recommendation is that invoices are sent to the system in batches instead of individually. This will result beneficial for the system overall and, especially, the users of the SII.

The Tax Agency establishes that the monthly limit for batch sending is 10,000 XMLs.

There are two ways of consulting invoices presented.　

If there is a large volume of invoices, use the online query service for the corresponding book, which shows the list of invoices with no size limit. 　

This service is documented with XML samples in the document describing the web service, which forms part of the SII portal technical documentation. It allows for several filter parameters. It can provide the list of invoices corresponding to the record book holder for a given year or period. The XML response file returns a block of up to 10,000 invoices. To recover larger information volumes, generate new consultations with the ID of the latest invoice obtained, stating the <PaginationKey> of the request.　

Optionally, for smaller volumes, it exists in the VAT section of the electronic office, in the VAT procedure. VAT record books on the Tax Agency E-Office, option to consult invoices presented by form online provided the number of transactions is less than 1,000. In the event that this limit is exceeded, limit the search parameters using filters, e.g. between specific filing dates. 　

The list of invoices obtained can be exported en masse onto a spreadsheet for subsequent use, obtaining for instance column totals with numeric contents, ordered by columns, etc.

Using the filter parameter "All columns", you can increase the number of data columns shown in the list until all available data is shown. From here, you can mark all columns you wish to hide in the list.

Since December 5, they have been operational in the VAT section of the electronic office, in the VAT procedure. VAT log books through the Tax Agency's E-Office, a new section where invoices reported by clients and suppliers can be consulted. This information can be viewed specifically by client/supplier or in groups. The list of invoices can be filtered by applying a series of different parameters: reconciliation status, invoice status, date of issuance, date of operation, etc.

The different consultations of invoices reported by clients/suppliers function by year/"charging" period, details of which are obtained from the date of transaction or, otherwise, the issuance date. 　

This function is available from 11/2017 onwards.

From 5 December on the invoice list screen there will be an option to export the entire batch of invoices obtained for a selection by using the "Unlimited export" option located in the top left hand corner of the screen. This export option delivers invoice records in one zipped file in standard format (CSV), which can be processed with tools of generalised use"

The summary of onscreen data has also been included in the Logbook consultation option.　

The taxation query (customers/suppliers) is available for the book holder or proxy. No access is provided to third parties as social collaborators.

The recommendation to allocate the Invoice Series/Number to fill in the 'ID Factura' (Invoice ID) field of the SII (Immediate Disclosure of Information) is as follows:

Recommended set of characters: 0123456789ABCDEFEGHJKLMNPQRSTUVXYZ. We do not recommend you use lower-case letters.

Blank space: if you use this only one character will be used, and never any more.

Special characters: Dash '-', underscore '_', forward slash '/' and full stop '.'.

If the invoice identification includes the Series, we recommend that this comes first, followed by the invoice number with a space in between.　

The ID Factura field should not start with blank spaces (therefore, text aligned to the left).

You must deregister said invoices in the production environment for the corresponding book, using the service featured in the web service documentation. If the numbering (series-number-issuance date) of the cancelled invoices are to be used again in the future, as they have already been cancelled, they must be sent as a modification (A1) and not as a new file (A0), as this would cause a duplicate key error.

You must deregister the invoices filed in the mistaken territorial environment using the service featured in the web service documentation. You must then file the invoices again in the relevant territory, bearing in mind that if you are using the same numbering (series-number-issuance date) as the cancelled invoices, you must send them as a modification (A1) and not as a new file (A0), as this would result in a duplicate key error. This option is available with the publication of version 1.1.

The only valid URLs in the SII are those included in the WSDL defined for each of the web services.
The subsites/servers available are exclusively the following:

Production Environment:   https://www1.agenciatributaria.gob.es

Production Environment (with seal certificates): https://www10.agenciatributaria.gob.es

Test Environment: https://prewww1.aeat.es

Test Environment (with seal certificate): https://prewww10.aeat.es