What is ViDA and how does it affect Polish businesses?

ViDA, or VAT in the Digital Age, is an EU package that modernises e-invoicing and digital transaction reporting, VAT rules for selected digital platforms, and VAT registration across Member States. It is neither a single IT system nor an EU version of Poland's KSeF. The package consists of three legal acts and is being introduced in stages through 2035.

ViDA has three pillars: digital reporting based on e-invoices, new rules for platforms facilitating short-term accommodation and passenger transport by road, and Single VAT Registration. The main implementation milestones fall on July 1, 2028, July 1, 2030 and January 1, 2035.

KSeF gives Polish businesses experience in working with structured invoice data, but it does not prove that the Polish system already meets the future EU model. Businesses should improve data quality and integrations now, while waiting for final implementing documents before coding detailed ViDA rules.

ViDA is increasingly discussed alongside KSeF because both concern the digitalisation of invoices and VAT data. Their scope is different. KSeF manages Poland's domestic flow of structured invoices, while ViDA changes common EU VAT rules, particularly for cross-border activity.

The topic matters even to a Polish business that does not currently sell abroad. ViDA can influence ERP data design, counterparty records, platform operations and the number of VAT registrations required in other Member States. Older proposal dates still circulate online, so this article uses the package adopted in March 2025 and the European Commission timeline current as of July 23, 2026.

1. What is the ViDA package?

2. Why did the European Union introduce ViDA?

3. How do the three ViDA pillars work?

4. When will the ViDA changes take effect?

5. What does ViDA mean for a Polish business?

6. What remains unclear about ViDA and KSeF?

7. Frequently asked questions

ViDA should be treated as a long-term VAT reform, not as one system that every EU business must start using on the same day.

ViDA stands for VAT in the Digital Age. The Council of the European Union adopted the final package on March 11, 2025 after the European Parliament was consulted again. The acts were published on March 25, 2025 and the package entered into force on April 14, 2025.

Directive (EU) 2025/516: changes the common VAT rules, including e-invoicing, digital reporting and selected cross-border arrangements.

Regulation (EU) 2025/517: changes administrative cooperation and the exchange of information needed for the new model.

Implementing Regulation (EU) 2025/518: adjusts implementing rules for the practical application of the common VAT system.

An e-invoice is a structured document that a system can process automatically. Digital reporting means sending specified transaction data to a tax administration. A national e-invoicing system, such as KSeF in Poland, is a solution operated by one Member State. These concepts are connected, but they are not interchangeable.

ViDA does not mean one directive, one EU-wide IT system or a central database containing every European invoice. It also does not establish PEPPOL as a universal mandatory channel or justify applying one 48-hour deadline to every reporting obligation.

Once ViDA is understood as a package of rules rather than a ready-made application, the next question is why the reform was introduced.

The single market is digital, but parts of the VAT framework still rely on later returns, recapitulative statements and obligations that vary between Member States. In cross-border trade, this makes irregularities harder to detect quickly and leaves businesses with separate registrations and processes.

Fiscal objective: tax administrations should receive comparable data sooner and identify cross-border VAT fraud more effectively.

Business objective: a company operating in several countries should need fewer local VAT registrations and repeat fewer similar obligations in different formats.

Technology objective: structured e-invoices should support more automated data exchange and reporting.

The European Commission estimates that e-invoicing-based reporting could reduce VAT fraud by up to EUR 11 billion per year and lower administrative and compliance costs for EU traders by more than EUR 4.1 billion per year over the next ten years. These are Commission estimates, not guaranteed outcomes.

The objectives address three distinct groups of problems. That is why ViDA has three pillars with different main audiences and implementation dates.

The first pillar covers Digital Reporting Requirements (DRR) based on e-invoicing. Its main impact is on reporting cross-border B2B transactions between businesses in different Member States.

Digital reporting and e-invoices: primarily businesses trading across EU borders and the finance systems that create and exchange invoice data.

Platform economy: platforms facilitating short-term accommodation and passenger transport by road, together with service providers using those platforms. The deemed supplier model does not automatically cover every digital platform.

Single VAT Registration: businesses selling goods and services in several countries that currently need local registrations in some scenarios. Expanded OSS and IOSS mechanisms and mandatory reverse charge are intended to reduce that number.

All three pillars digitalise VAT, but each solves a different problem. A date applying to platform rules is therefore not automatically the starting date for cross-border B2B reporting.

ViDA is being introduced in stages. There is no single date on which every EU business moves to an identical invoicing and reporting process.

2028: this stage primarily covers elements of Single VAT Registration, mandatory reverse charge in specified cases and new rules for selected platforms. It is not the start date for all cross-border B2B digital reporting.

2030: Digital Reporting Requirements for cross-border B2B transactions are scheduled to apply from July 1. This is the main date for the e-invoicing-based reporting pillar.

2035: by January 1, domestic real-time digital transaction reporting systems based on legislation in force on January 1, 2024 must be aligned with the EU model and standards.

The timeline below reflects the official schedule as of July 23, 2026. These milestones should not be confused with short operational deadlines described in older proposals and industry commentary.

The staged timeline helps separate preparations that make sense today from changes that should wait for detailed requirements.

The best preparation is not to build a separate ViDA module today. It is to improve data quality and reduce dependence on one format, channel or manual re-entry.

Do now: standardise counterparty identifiers and countries, check invoice-data completeness, document mappings between ERP, KSeF and accounting systems, and keep source data separate from its visualisation.

Monitor: the scope of DRR, implementing standards, the future relationship between KSeF and the EU model, OSS and IOSS changes, and platform requirements if the business operates in short-term accommodation or passenger transport by road.

Do not implement in advance: rules based on a universal 48-hour deadline, an assumption that PEPPOL will be mandatory for every business, or an architecture built around one central EU invoice database.

Example: a Polish distributor selling to businesses in Germany and Czechia does not need a separate ViDA module today. It can standardise tax identifiers and counterparty countries, document mappings between ERP and KSeF, and keep reporting rules configurable. Later requirements will then be less likely to force the company to reconstruct logic hidden in code or spreadsheets.

The screen below shows the current KSeFGPT integration layer. It illustrates how connections and data flows around KSeF can be organised today. It is not a view of a future ViDA or DRR system and does not claim future compliance.

This decision matrix reduces the risk of spending money on requirements that do not yet exist. The remaining question is which parts of Poland's KSeF experience can support the future EU model.

Poland has practical e-invoicing experience. Businesses and software providers already work with structured invoices, validation, submission statuses and API integrations. These capabilities are useful for any further digitalisation of VAT.

That does not make today's KSeF an automatically ready component of DRR. The scope of reported data, mapping of the Polish FA(3) structure to EN 16931, data exchange channels and the role of the national system after 2030 still require separate decisions.

The European Commission published a ViDA implementation work programme for 2026 and early 2027 on May 13, 2026. This confirms that technical and implementing details are still being developed. Architecture decisions should therefore follow official documents rather than simplified diagrams circulating online.

The relationship between KSeF and ViDA deserves a separate analysis of legislation and standards. It will be covered in the next article in this series because combining both subjects too quickly creates promises that current law does not support.

Future ViDA requirements are not yet an implementation specification, but the current process can already be improved. A business can maintain one source of counterparty data, check invoice completeness, document mappings between systems and preserve a history of what was sent and received.

KSeFGPT currently helps users issue invoices in a form or through AI Chat, submit them to KSeF and download readable visualisations in Polish, English, German or Ukrainian. These are tools for today's KSeF process, not a claim of future ViDA DRR compliance.

What is KSeF AI and when is it useful? - see where automation helps with invoices and where human control remains necessary.

KSeF and JPK - learn why similar data sets do not mean the same system or obligation.

XML and the FA(3) format in KSeF - understand the structure of a Polish structured invoice and its role in integrations.

KSeF invoices in English, German and Ukrainian - see how source invoice data differs from a readable visualisation for a foreign counterparty.