Analysis of different EU intra-Community transaction based reporting scenarios

Experts

Introduction

It’s an exciting period for everyone who follows VAT news. Various countries are implementing a VAT system, others are introducing carbon taxes, while recently the e-commerce legislation in the EU went into force. All extremely interesting topics, but the most exciting of them all is the surge of real-time reporting! Multiple countries all over the world are currently in the process of implementing some variant of this tool to tackle VAT fraud.

Additionally, at this very moment the European Commission is preparing a legislative proposal to modernise the VAT reporting obligations in the EU. An independently written report will assist the European Commission to get to this proposal. In the following we will analyse some of the preliminary advice that was mentioned during a Group of the Future of VAT meeting earlier this year regarding real-time reporting (or transactions based reporting) for intra-Community transactions. We do know that the new report is speaking of four scenarios but the below analysis still applies.

Alternative 1: limited change to the current VAT reporting system

The first of the three alternatives mentioned in the report will not change too much to the current way of VAT reporting. In this model, transaction data will be stored by the taxpayer. The data will however not be required to be sent to the tax authority in real-time. The idea is to require the taxpayer to store VAT data in a certain form, in a SAF-T format for example. The data only needs to be provided to the tax authority upon request. This would allow for more efficient audits as all data is stored in a structured manner.

A couple of points are worth emphasising. First (1) this would not be an enormous change to the current VAT reporting situation. In fact, in several countries such an obligation already exists (e.g. Luxembourg). Besides, some tax authorities can already quite efficiently extract data from e.g. bookkeeping software packages during an audit in case such a reporting obligation is not in place. Second (2) it will not help the tax authority to efficiently fight fraud as no actual transaction information is periodically reported to the tax authority. Therefore, the same post-audit system will be in place which results in a VAT gap of €140 billion on an annual basis. Lastly (3), it would not provide any benefit for business as it’s only an additional administrative burden without any real efficiency benefits.

All in all, although it is the solution that requires the least amount of change, it is not a very feasible solution as it does not actually significantly reduce the VAT gap.

Alternative 2: national tax authorities store transactional data

The second option requires companies to report more detailed transactional information in either a near-time or real-time manner to the relevant national authorities. In this way the tax authority will have quicker access to more detailed VAT information. An important role is here to play for VIES (which we explained in a previous blog post). Within this alternative there are two options:

  • In the first option (2.1), supplying companies send their transactional information to their national tax authority. The tax authority then shares this information with the tax authority where the buyer is located in order to cross-check transactional data. Reversely, tax authorities where the buyer is located will also be able to share acquisition data with the tax authority where the supplier is located. In short, companies will have an obligation to report intra-Community transactional data in near- or real-time fashion, while tax authorities will bilaterally exchange this information to perform cross-checks.
  • In the second option (2.2), the obligation for companies is the same as in the first option. However, in this scenario tax authorities will share the intra-Community transactional information directly with a shared database (read VIES). In this way, data can be matched automatically which enables an optimal fraud detection process.

Both options are feasible in terms of fraud detection. However, the second option would be more efficient as it allows for a direct matching mechanism for all intra-EU transactions without having to set-up multiple bilateral agreements. On the other hand, it does require EU Member States to share very detailed information in a centralised manner. Therefore, in order to make this option politically feasible modern cryptography would be an excellent tool to overcome the issue of trust. This would allow EU Member States to match intra-Community transactional data without sharing any important details. Hashing is an important aspect in this regard, which we explained further here.

When implemented in this way, the reporting obligation can be integrated in the business process of companies. It’s important to allow companies to send the invoice information in the preferred invoicing format (EDI or e-invoicing) to also provide compliance automation benefits for the business community.

Alternative 3: reporting transactional data directly to the EU

This scenario is quite similar to the second option discussed under “Alternative 2”. The main difference is that data will be first sent to the national tax authorities, but directly to an EU platform. It is argued that this “could support a central clearance system for intra-EU transactions”. Important to emphasise is that clearance means that the tax authority or an authorised third party service provider performs a check on the invoice. This check is put into place to make sure that the invoice is structured according to the standard that is in force. If successful, the invoice is approved and either sent back to the supplier (e.g. Brazilian model) or directly sent to the buyer (the so-called Italian-model). However, not the clearance tackles VAT fraud, it’s the matching that does.

With this in mind, it’s worth mentioning that clearance is not a necessity to make this alternative scenario a success. Furthermore, clearance on an EU level would also be very delicate from a political perspective as that would mean that companies become dependent on the EU in order to fulfill their business processes. An EU real-time reporting system without clearance would remove this problem. Again modern cryptography would be a great tool to allow for the data exchange in such a system in a confidential way. If it is implemented like this, the only difference between alternative 3 and 2.2 is the authority where the information will be sent to. Being the EU for alternative 3 and the national authority for alternative 2.2. One more reason for the preference of model 3 over 2.2 is the cost associated with such a system, we argue when using open source software and allowing Member States to reuse software and best practices can again combine all benefits into 2.2.

Conclusion

Some very interesting months are coming up in case you are a fan of VAT reporting obligations! In this blog post we have tried to summarise the different options that are currently on the table. Additionally we analysed the feasibility of these options. We argue that the best option is the one where companies are sending their intra-Community transactional data either via the national authorities or directly to a central EU platform (Alternative 2.2 or a certain implementation of alternative 3). The reason is (1) it would be the most efficient from a fraud detection perspective, (2) impose the lowest administrative burden and (3) in case modern cryptography is applied it would be the most feasible from a political perspective as no detailed invoice information needs to be shared.

In case you want to learn more about how summitto’s real-time reporting system exactly works and how it benefits both the public and private sector click here. For questions, shoot us a message at info@summitto.com