The Future of VAT part 2. Q&A Fiscalis Workshop

The road ahead

Previously we analysed the outcomes of the Fiscalis workshop where real-time reporting was discussed. We showed how summitto’s solution could help solve many issues that were raised during the workshop. However, some questions remained which were posed to the VAT Expert Group (VEG). With this blog post, we hope we can help by providing feedback on these questions. In the following we try to answer questions around (1) design, (2) harmonisation, (3) transmission of the invoices and (4) benefits for business.

Design: characteristics of the real-time reporting system

When implementing a real-time reporting system, there are a lot of aspects that need to be taken into account such as: how will it be implemented, when will it be implemented, should it be real- or near-time etc. Fiscalis posed many of these relevant questions to the VEG, in the following we try to discuss them in depth.

Should real-time reporting be implemented gradually? If that is the case, how?

Although real-time reporting is a relatively new phenomenon in the European Union (EU), luckily there are many Latin-American countries that already implemented such systems and from whom we can learn. For example, in one of our episodes of VAT Talks we spoke with Alfredo Collosa from the Argentine Tax Authority. He told us that in Argentina first the bigger companies had to comply with the new real-time reporting regime, while smaller companies came later. In other words, a gradual approach was used. The same thing holds true for the Spanish Suministro Inmediato de Información (SII), where only companies with a turnover of €6 million or higher are required to submit their information in near-time.

A similar model will be used in France as we learned from PwC’s Laurent Poigt. He told us that France is considering making e-invoicing combined with e-reporting mandatory for large companies in 2023, for Intermediate Sized Enterprises (ETIs) in 2024 and for SMEs and VSEs in 2025 .

We believe this is an excellent approach for the implementation of real-time reporting as many bigger companies have the means to quickly adapt to the new legislation. Furthermore, by requiring them to report invoices to the tax authority, they might also encourage their smaller suppliers to do the same. Even before it is made mandatory for them as well. The gradual implementation also gives smaller companies some extra time to adapt. Also smaller companies are making more and more use of cloud based bookkeeping systems. Those systems can easily adjust their backends to support any real-time reporting system, the advantage is that with one bookkeeping system adjusting their systems suddenly thousands of small companies are immediately compliant. This lowers the administrative costs for small companies which is mostly the biggest hurdle for real-time reporting systems. This differs though on the adoption of cloud bookkeeping systems. In the Netherlands for example around half of all smaller companies are using some kind of cloud solutions which can be made easily compliant with new rules.[1][2]

Are you in favour of reporting in real-time or do you prefer a different periodicity?

We believe real-time would be the most efficient way to implement such a system, both for the tax authority and for businesses. When the tax authority has access to real-time information it has the highest chance of detecting fraud, because as Indirect Tax Professor Redmar Wolf told us: ‘VAT fraud is a timing-issue.’ Reporting invoices in real-time would also make sense from a business perspective. This will allow companies to immediately report their invoices to the tax authority at the same time they issue their invoice to their buyer. Important to note is that many bigger companies are processing invoices in batches, therefore real-time could best be defined as within the next 4-8 hours. It could also be beneficial to allow for certain exceptions for e.g. companies that are reporting a very low number of invoices and revenue.

Do you think that one of the data to be reported should be the description of the transaction? In that case, do you think the use of codes for each type of transaction, instead of a free-text field, would be helpful?

When registering transactional data, it may certainly be useful to include information about the type of invoice, e.g. whether it is a credit invoice or not. In any case, the use of free text fields should be minimized as much as possible, given the fact that this greatly increases the difficulty of the data analysis, by for example buyers, financial intermediaries and auditors. Standard codes and strict validation should be used for as many fields as possible. A fast data analysis process is essential in the fight against fraud, because it should be completed before the taxpayer is paid out. Otherwise, there will still be time for the fraudulent taxpayer to disappear.

Note, importantly, that the data that is registered by companies, might not be the same as the data which is reported and sent to the tax authority. It is essential that the tax authority will only receive the data that is needed to mitigate fraud and increase overall compliance. To achieve this goal, the tax authority does not need to know any specific details of the transactions. So we would argue that ‘the description of the transaction’ is not necessary. Moreover, as varying e-invoicing standards spring up like mushrooms, there can be benefits to keeping the national reporting requirements to a minimum. What the tax authority minimally needs for domestic transactions is the total amount of the invoice, the VAT amount, the VAT number of the supplier, the VAT number of the buyer and the invoice number. This is needed to link the VAT of the supplier with that of the buyer, which is the core function of a real-time reporting system.

Reporting Process

Even this data is highly sensitive, because when pricing information is exposed it could hurt the company. Therefore, an ideal real-time reporting system has no actual invoice data that can be seen by tax authorities (see also the image above and our explanatory blog post about encrypted invoice fingerprints). One can store only a unique fully encrypted fingerprint of the invoice and by leveraging modern cryptography make sure that the tax authority can make calculations on those fingerprints. This results in the situation where the tax authority cannot see the actual content of the invoice without the permission of the owner of the invoice, while at the same time it can assess if the correct amount of VAT is reported to the tax authority. This approach comes with more benefits for businesses, which we discuss below.

Do you think that the information in some invoices could be aggregated? If so, what type of information and how should this aggregation take place?

We believe that the early-detection of VAT fraud is one of the most important benefits of real-time reporting. For that, information on the invoice level is needed. When only aggregated data is reported, not all benefits of a real-time reporting system will be achieved because the individual invoices of suppliers and buyers will not be linked. Moreover, new contentious questions arise with regards to standardizing the extent to which aggregation is allowed for certain types of transactions and sectors. Therefore, we would prefer a per-invoice information flow.

However, after information is reported per-invoice, the information presented to the tax authority could indeed be aggregated. As explained above, by only storing fingerprints all information can be reported per-invoice while at the same time the tax authority will only see aggregated information. For this, only the aggregated VAT amount needs to be revealed. With the permission of the taxpayer, the tax authority can then require the per-invoice information.

Do you see the possibility for simplified invoices? What minimum data should be included in them?

The information that should be sent to the tax authority can indeed be simplified as was also mentioned above. From our perspective, in order to reduce fraud and increase compliance only the VAT amount, the VAT number of the supplier and the VAT number of the buyer are needed. Important to note however, is that the exact implementation and the required amount of data always differs per specific case. Asking for more data could provide a better insight into the economy, while on the other hand comes with costs. Think about for example an increased administrative burden, but as well a higher chance of exposing valuable invoice data.


While for intra-Community transactions harmonisation was the preferred option, for domestic transactions there were divergent views. What are the minimum elements that should be harmonised or at least standardised or coordinated, as far as domestic transactions are concerned, in order to further simplify life and reduce costs of businesses operating cross-border? How could they be harmonised?

In a previous blog post, we already mentioned that one of the reasons why harmonisation for domestic real-time reporting systems is difficult to achieve, because some EU Member States already decided to implement a variant of a real-time reporting system. Although this is an excellent step forward in the fight against fraud, it does result in a difficult situation for companies that are active in multiple EU Member States.

Therefore, we argue that all newly implemented real-time reporting systems should be as harmonised as possible, where companies should only have some minimal or preferably no changes to their systems to be compliant in all different EU Member States. We believe the minimum harmonisation is that all systems should be near-time, so that fraud can be tackled fast and information can be exchanged at almost the same speed.

Furthermore, for those countries that already implemented such a solution, we proposed a Basic Reporting for Intra-Community Documents and General Exchange (BRIDGE) to achieve at least a certain level of harmonisation. Although tongue-in-cheek, a simple software platform which acts as a BRIDGE can help companies that are active in certain countries to also be compliant in other countries. This will reinforce the European Single Market.

Transmission of the invoices

How should the transmission of information to the tax authorities be done? Transmission of data without compulsory e-invoicing, transmission of e-invoices or transmission of data with compulsory e-invoicing?

In general we are advocates of the implementation of proper EU-wide e-invoicing standards together with real-time reporting. This will give the companies something in return for the adjustment of the accounting systems. Their AR and AP processes will be more efficient and exchange of invoices digitally not only saves paper but can also provide faster payments for SMEs for example.[3] Nonetheless, we on purpose designed a system that can fight fraud with just a minimal set of data to the tax authority: an encrypted fingerprint for each invoice (see the section about simplified invoices above). Companies don’t have to do this manually, existing bookkeeping systems, ERP systems and a new tax authority owned bookkeeping portal can create and transmit fingerprints based on the invoice data which companies register automatically or manually.The reason we support both methods of registration is to make the hurdle to get any real-time reporting system deployed as easy as possible. Changing regulation and even on EU level can be a painstaking endeavour that is why we want to provide options to regulators to choose from to at least get a minimal system deployed which can still fight adequately fraud.

Furthermore, when tax authorities want to audit certain companies, and more information is requested, there are a couple of possibilities for the transmission of information to the tax authority. Compulsory e-invoicing for both B2B transactions and transmission to tax authorities could allow for a highly efficient setup. This would allow companies to streamline their invoice flow and it would give them a lot of additional benefits through automation. However, this requires a derogation of Article 218 and 232 of the VAT Directive as that stipulates that sending an e-invoice requires the consent of the receiver of the invoice.[4] Although the EC did grant a derogation for the Italian e-invoicing regime, there is no guarantee that all countries asking for this derogation will also receive this derogation. Moreover, some Member States might be of the opinion that implementation costs for the private sector are too high.

Therefore, the best option for countries that aspire to adopt real-time reporting would be a hybrid model which allows for companies to transmit invoice data to tax authorities either as e-invoice or in another accepted format. This is exactly the set-up of summitto’s TX++ system. In case in the future a derogation is granted or Article 232 is adapted and Member States have a positive attitude towards e-invoicing, the requirement of mandatory e-invoicing will still be possible.

Costs and benefits for businesses

What measures could be adopted to reduce the costs for businesses and tax administrations? Let’s first tackle the costs for tax authorities. In general, the implementation of a real-time reporting system could save individual tax authorities up to billions of euros in VAT revenue as Michel Schrauwen and Oscar Smeets showed us via their case study. Such a system can also automate the fraud detection mechanisms of the tax authority, thus increasing the overall efficiency. To keep implementation costs as low as possible it is advised to choose an open source solution. In our ‘open source 101 for public officials’, we discuss that open source software prevents the so-called vendor lock-in the user becoming too dependent on the vendor of the software. Furthermore, by making use of open source the software can be easily rolled out to all EU Member States. Finally, security costs can also be decreased by making use of publicly and externally audited open source software.

Speaking of security, the collection of massive amounts of invoice data is a huge honeypot of data.[5]

What services could be provided to businesses by tax administrations with the information received through TBR?

When implemented in a clever way, real-time reporting can also come with many benefits for businesses. We already mentioned the benefits of coupling real-time reporting with e-invoicing to automate businesses processes. Another benefit which is the result of the modern technology that is used in summitto’s real-time reporting system is that the data of the taxpayer can be reused for other purposes than just for preparing VAT returns. Because the encrypted unique ID codes (also called fingerprints) will be publicly available, companies will be able to prove that they have used their invoices for VAT purposes. This could be very helpful to e.g. automate audits, or prove to your investor that you have actually generated a certain revenue. There are many more applications where companies can make use of their already verified information, which can all create absolute advantages for them.

In particular, is there a potential for quicker refunds or pre-filled VAT returns?

Over the last couple of years there have been problems with late refunds.[6] When invoices are reported to the tax authority via a real-time reporting system, VAT returns can be pre-filled because the VAT can be based on the invoice information sent to the tax authority. This also means that VAT refunds could be to a high extent automated. Simply put, both quicker refunds and pre-filled VAT returns are a potential of any real-time reporting system. It is even implemented already in some countries (e.g. Chile). An important side note is that this does not include e.g. any necessary pro-rata adjustments. For simple VAT returns (which are most SME VAT returns) these quicker refunds and pre-filled VAT returns will be very easy, for bigger companies manual adjustment will still be necessary.

Should recapitulative statements be abolished if a TBR system for intra-Community transactions is implemented?

To abolish the recapitulative statement when a real-time reporting system for intra-Community transactions is implemented would be the most business friendly solution. Under the current recapitulative statement the following data should be reported to the local tax authority:

  • code of the country where the acquirer is registered,
  • VAT ID of the acquirer,
  • total value of goods and relevant services supplied to the acquirer in a respective month / quarter.

This is data that can be perfectly extracted by means of a real-time reporting system, preferably completely harmonised with the national one so that companies can adhere to a simple rule (register all invoices) and so all processes can be 100% automated.


In this article we tried to answer all questions Fiscalis posed to the VEG regarding (1) design, (2) harmonisation, (3) transmission of the invoices and (4) benefits for business. We argued that it is important to implement such a system gradually in a real-time manner. Furthermore, tax authorities should be very careful with the data they are requesting from the taxpayer, only the data that is absolutely essential in fighting fraud should be reported. We see a way forward in a EU VAT system where all newly implemented real-time reporting systems will be harmonised, while existing ones could be made interoperable by building a BRIDGE. To achieve this goal, e-invoicing is not a necessity, but it would help to provide businesses with the most benefits from the implementation of a real-time reporting system. Lastly, in terms of costs, we showed that summitto’s open-source solution enables businesses to reuse their data for various financial services, and that VAT refunds can be pre-filled and quicker VAT refunds can be realised. By registering as little data as possible, risks of data loss and security costs can be kept to minimum.


[2] For example, the Dutch bookkeeping company Informer already enables taxpayers to prepare their VAT return within their bookkeeping environment:



[5] See our Twitter feed for many different data breaches: