iDynamics SII - Setup Examples
Given that the most frequent queries we have received since the implementation of the SII have to do with how to configure VAT records, we have decided to create this document where we include the most particular combinations or the ones that may raise doubts. Remember that the examples included here are only a starting point, and that each client could have particularities, so in case of doubt, we recommend getting in touch with your advisor.
Note: the concept of Reverse Charge will appear with its Spanish abbreviation ISP several times within this document.
Setting up the IRPF
IRPF amounts of invoices issued should not be reported to the tax agency. For its setup, we have two options: set up the type of VAT calculation as non-taxable (this would be the only exception to the rule mentioned above), or select the SII Breakdown: Ignore option available in the iDynamics SII block, within the sales (and purchases) section of the VAT setup file.
When you select this option, the amounts of the lines that have this configuration will be treated as if they did not exist, both at the breakdown and totals level.
Sales to the Canary Islands
If the purchaser is going to pay the IGIC tax (which is the most common situation), the VAT will be setup just as exports outside the EU, as exempt due to article 21 of VAT law (E2), with "02" as the special regime key.
If however, the issuer is going to pay the IGIC tax, then the VAT should be setup as not subject to VAT (TAI) and "08" should be set as the special regime key.
Sales/Purchases with ISP within the EU
For purchases, you should set "09" as the purchase key.
For sales, Exempt due to article 25 should be set as the VAT exemption cause.
Although UE invoices do have ISP (reverse VAT charge), the Spanish Tax Agency only requires the ISP check in invoices issued to/from Spanish customers, and checking it for UE customers would raise an error when sending the invoices to the tax agency.
Sales for customers outside the EU
According to the setup specified by the Spanish tax agency in their FAQ, export VATs should be treated as exempt due to article 21 (E2), and configured with purchase key "02".
Non-Taxable National Sales
The important thing in this case is, as in the rest of cases that are not subject to VAT, to indicate that the Type of calculation is Normal, and the reason for exemption 714 (Amounts not subject by article 7, 14, others). This will cause the amounts in issued invoices to be sent to the tax agency within the field intended for this purpose.
Imports
In import cases, up to three process-related invoices may be generated within Dynamics 365 Business Central:
- The one issued by the vendor outside the EU.
- The one issued by the importer, corresponding to the DUA.
- An invoice with the freight forwarder's costs.
The first invoice should only be sent to the tax agency (as F6) in cases where it is received prior to having the DUA. As in most cases, it should not be necessary to report it, the recommended VAT configuration is 0% with the option Issue Breakdown: Ignore (invoices that only have lines of this type will be archived without being sent to the tax agency).
The second invoice must contain the taxable amount of the first invoice, with the corresponding VAT %, accompanied by a negative line with the same taxable amount but with 0% VAT (this importer's invoice will only contain the VAT amount). This is the invoice to be sent to the tax agency, and for it to be correctly reported it will be necessary to configure the amounts in the following way:
- Line with taxable base and calculation: "normal" setup, as if it were any other national invoice amount (the VAT and taxable amounts will be broken down for the tax agency).
- Line with negative taxable base and 0% VAT: 0% VAT configuration and SII Breakdown: Ignore. This way the total amount of the invoice in Business Central will just correspond to the VAT, and only the line with the positive amount will be sent to the tax agency.
For practical purposes, the aforementioned setup will cause the tax agency to be sent a single invoice (which must be of the F5 type), with the company itself sending the data to the tax agency as counterparty, with the DAU number, and the breakdown of the VAT corresponding to the taxable base of the vendor's invoice.
Finally, if the freight forwarder has charged any extra management costs, these amounts must be reported in a separate, regular invoice.
Invoices Received from the Previous Month
When an invoice from a vendor has been issued at the end of one month, and received at the beginning of the following month, the tax agency allows you to include the invoice within the period corresponding to any of the two months.
If you want to send it within the period corresponding to the month of issue, we have a problem, and that is that within Dynamics 365 Business Central we want to indicate the previous month as the G/L record date, so that the VAT reports in the ERP match the information sent to the tax agency. But it is not this date (G/L record) that we want to send to the tax agency as the date of registration in the system, since in that case it would seem that we are informing the tax agency outside the 4-day deadline.
In order for iDynamics SII to generate the documents in the queue according to this special case, it will be necessary to indicate that the Registration Date is used as Registration Date of Invoices Received, within the setup document.
With this setup, the field Received Invoice Posted Tax Agency of the document in the document queue will be filled automatically, using the date of creation of the G/L entry.
If you want to send it within the period corresponding to the month of reception, we recommend configuring the previous field with the value Registration date.
The Sign up Date option will only work correctly if the G/L entries are aligned with the entries of customers and vendors. If this is not the case, the creation date (obtained from the creation date of the G/L record) may not be correct, and it will be necessary to correct this data error, or perform a code customization to obtain the creation date.