Custom e-invoicing and digital reporting software development
ViDA is often summed up as a new invoice format. That is the smallest part. What really changes is that the same data for each transaction goes to the tax authorities rather than being aggregated in a return. That removes the space in which most bookkeeping currently operates: the weeks between booking and filing, during which errors are quietly corrected.
What changes and when
The Council of the European Union adopted the ViDA package on 11 March 2025, following approval by the European Parliament. The package has three pillars, of which e-invoicing with digital reporting is the most far-reaching. From 1 July 2030, an invoice for an intra-community B2B transaction must comply with the European standard EN 16931, and the data of that transaction must be sent digitally to the tax authorities.
In 2026 the Netherlands published a proposal for the first phase. Under that timetable, 1 January 2030 applies to domestic e-invoicing, 1 July 2030 to the European obligation, and 1 January 2032 to domestic digital reporting. The government wants the legislation in place at least two years before the European date, so by 2028 at the latest.
The real change is not in the format but in the timing. Today you book an invoice, later discover an error in a VAT number or a rate, and correct it before the return is submitted. With transaction-level reporting, the invoice has already been reported. Correction is still possible, but it becomes a visible correction rather than an unnoticed one. That means data quality has to move forward, to the moment the invoice is created.
How we build this
Here the invoice line is the unit, not the return. If every line is correct at the moment it is created, reporting becomes a technical step.
We pull from your current invoicing which fields are often missing or wrong: VAT numbers, country codes, units, rates. That list is almost always shorter than feared and more concrete than a standards analysis.
Every check that currently happens at the point of filing we move to the moment of creation. There it costs a second; afterwards it costs a correction.
EN 16931 describes what an invoice must contain. We structure your data so that the standard follows from it, because the standard will still be extended in the years up to 2030.
We have the system reprocess a closed month and show which invoices would have been rejected under transaction-level reporting. That figure is your actual exposure.
What the software actually does
Data quality on the invoice line carries everything. Which components you need depends on how much cross-border trade you do and on what your current package can already handle.
Checks at the moment of creation
Missing or invalid fields are flagged before the invoice leaves. That is the only moment at which correcting is still free.
Invoice built to EN 16931
The structural invoice follows from your data rather than from a template. If the standard changes, the output changes and not your administration.
Transaction-level reporting prepared
The data sent to the tax authority is assembled per transaction and stored exactly as it was sent. If a question arises later, what you reported at the time is what counts.
Deviations with follow-up
A rejected invoice, a VAT number that is no longer valid, a counterparty that does not respond. Each of these becomes an action with an owner, because a list of errors without follow-up only grows.
Connecting to your own package
The invoice originates in your ERP or accounting system. We build the layer in between through integrations rather than replacing your package, and connect to your Peppol integration if you have one.
Record of what has been sent
For each invoice and each report, what was sent, when, and with what outcome. With transaction-level reporting, that is your only defence if discussion arises later.
Who we build for
How much work this is depends on your transaction flow. Four situations.
Trading within the EU
You supply customers in several member states, and precisely those transactions fall under the obligation first. Your biggest risk is incorrect or lapsed VAT numbers of counterparties.
Production with cross-border deliveries
Your invoices contain lines with units, weights and sometimes partial deliveries. Translating those into a standardised invoice is the real work, and it gets harder as soon as there are customer-specific agreements.
Sales through multiple channels
Invoices originate in different systems, each with its own assumptions. Until those come together in one place, you will report different versions of the truth about the same business. The purchasing side, with receipts generated outside the office, is covered by the ViDA app.
Administration and accountancy firms
You do this for dozens of clients at once and therefore benefit more from an overview per client than from a system per client. The filing side itself is covered by VAT compliance software.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology and integrations
The precise detail of Dutch legislation and of the reporting messages is not yet fixed. Everything connected with that should be configurable and kept per version.
Why Appfront
The deadline seems distant, but your invoicing flow is slow
Changing an invoicing process affects sales, logistics and administration all at once. Anyone starting in 2029 will find that the data the standard requires is not being recorded anywhere.
Correcting afterwards is no longer a route
We move the checks to the moment an invoice is created, because that is the only point where they cost nothing yet.
Your package stays in place
We build the layer in between through integrations. Replacing your ERP to meet a standard is the most expensive route to the same result.
Honest about what is still moving
Dutch legislation has not yet been finalised and the message definitions are still being completed. We build these as configurable settings and make no claims about how they will eventually read.
Security and privacy
Invoicing data is both commercially sensitive and tax evidence. Anyone who can view your invoice flow knows your customers, margins and volumes; anyone who can change it can render your administration unusable. We therefore strictly separate read rights from write rights and record every change to a sent invoice as a correction rather than an edit.
Per-transaction reporting adds a requirement that does not apply today. You must be able to show later what you reported and when, even if the invoice has since been corrected. We therefore keep the sent message exactly as it left, with timestamp and outcome, not just the current state of the invoice. A system that only knows the latest version cannot explain, when the tax authority asks, what was reported at the time. For how we handle security ourselves, see our information security policy; reports from outside come through our CVD policy.
Frequently asked questions about ViDA and e-invoicing
For intra-community B2B transactions from 1 July 2030, under the European standard EN 16931, with digital reporting of those same transactions. In the Dutch planning, domestic e-invoicing is set for 1 January 2030 and domestic digital reporting for 1 January 2032. Those national dates are not yet fixed; check the current state of Dutch legislation before you set your plan.
Not in the sense ViDA means. It refers to a structured invoice that a system can read without human intervention, built according to EN 16931. A PDF is an image of an invoice; what the standard requires is the data itself.
Peppol is the network the invoice travels over, ViDA governs what it contains and what must additionally be reported to the tax authority. If you already send through an access point, the transport is sorted but the data quality may not be. See Peppol integration for that side.
VAT compliance concerns the return chain: rate determination, reverse charge rules, the ICP declaration and One Stop Shop. ViDA concerns the invoice as a data carrier and reporting per transaction. They overlap, because the data comes from the same source; see VAT compliance software.
Rarely. Most packages can create an invoice and export it; what is missing is validation at line level and the reporting side. A middle layer that connects to them is cheaper and less risky than a migration, and you can still replace it later with a package feature once your supplier delivers one.
Then it is not sent, and your delivery gets stuck on the administrative side. That is precisely why validation belongs at the front: a rejection at creation takes a second to fix, a rejection after sending costs a conversation with your client. We therefore build an exceptions list with an owner and a deadline, rather than a simple error message.
Commercial agreements remain possible, but they must be expressible in a standardised invoice. Discounts, tiers and surcharges that now sit in a free-text line become fields. For most businesses this is the underestimated part of the work, and the reason to start early.
That depends on the number of invoicing sources, the state of your master data and whether reporting needs to be included. The validation layer on existing invoices is usually quick to deliver and yields the most, because it reveals your actual error rate. We give a reasoned estimate after the initial assessment.
Preparing for e-invoicing?
Take a closed month and count how many invoices had a missing or invalid field that was later corrected. That number is what will become visible. We build this as a standalone application and as part of a broader custom software project.