Most Irish businesses have filed this one under “2028 problem”. That is a mistake, and not for the reason you would expect. The headline of Ireland’s VAT Modernisation programme is that large corporates must start issuing structured electronic invoices from 1 November 2028. The part that gets left out of the headline is that from the exact same date, every VAT-registered business in Ireland must be able to receive them. There is no turnover threshold on that obligation. If you invoice or get invoiced in this country, you are in scope on day one.
This is not really a tax story. It is a systems integration story with a statutory deadline attached, and the work it implies sits squarely in the part of your business that nobody has assigned an owner to: the collection of tools that emit invoices without your finance team ever touching them.
TL;DR
- 1 November 2028: large corporates managed by Revenue’s Large Corporates Division must issue structured e-invoices for domestic B2B transactions and report a subset of that invoice data to Revenue.
- Same date, everyone else: all Irish businesses must be capable of receiving structured e-invoices, whether or not they have to issue them.
- November 2029: the issuing obligation extends to VAT-registered businesses trading cross-border within the EU. 1 July 2030: full EU ViDA compliance for intra-EU B2B.
- The standard: EN 16931 structured XML exchanged over the Peppol network using a five-corner model, with Revenue as the fifth corner. PDFs stop being invoices.
- The real work is data completeness and invoice-issuing architecture, not buying software. Both are spec-agnostic, which means you can start now despite Revenue’s technical specifications not being published yet.
What Ireland has actually committed to
Revenue published its VAT Modernisation action plan in October 2025 following a public consultation, and has been confirming detail steadily through 2026. The rollout runs in three phases.
Phase One, from 1 November 2028, applies to large corporates: businesses whose tax affairs are managed by Revenue’s Large Corporates Division and which are established, or have a fixed establishment, in Ireland. Those businesses must issue e-invoices for domestic B2B transactions and report a defined subset of the invoice data to Revenue. Revenue has said it will write to the businesses in scope to notify them directly, so there is no self-assessment guesswork at the top end. Worth noting that the Large Corporates Division turnover threshold itself moved from €190 million to €350 million in October 2025, which quietly changes who sits inside Phase One.
Phase Two, from November 2029, extends the issuing and reporting obligation to VAT-registered businesses engaged in cross-border EU B2B trade, the ones benefiting from zero-rating on intra-community supplies. That is a substantially larger population, and it includes a great many Irish SMEs who think of themselves as small.
Phase Three, from 1 July 2030, is the EU-wide one: full implementation of the VAT in the Digital Age directive, adopted in March 2025, mandating e-invoicing and digital reporting for cross-border intra-EU transactions across all member states.
The driver is not efficiency evangelism. Revenue is chasing a VAT gap estimated at around €1.7 billion. When a tax authority builds infrastructure to close a revenue gap, the compliance dates tend to hold.
The receiving obligation is the one that will catch people out
Ireland has required public bodies to receive electronic invoices since 2019 under the EU public procurement directive, so the concept is not new here. What is new is universality. From November 2028 a structured XML invoice can arrive at your business from any large corporate you supply, and “we only accept PDFs” stops being a policy you are allowed to have.
In practice, being able to receive means three things: you are registered on the Peppol network with a resolvable participant identifier, you have an access point connection, and something on your side can parse an EN 16931 document and get it into your accounts payable process without a human retyping it. The first two are procurement decisions. The third is where the engineering time goes, particularly if your purchase approval workflow currently consists of a shared inbox and a person with good judgement.
“Our accounts package will handle it” is half right
It probably will, for the invoices your accounts package generates. Xero, Sage, QuickBooks and the mid-market ERPs will all ship Peppol connectivity well before 2028, because they have already done it for Belgium, Poland, France and Germany. If every invoice your business issues is typed into that system by a person, you have a licensing conversation and very little else.
Almost nobody is in that position any more. The invoices that will break are the ones generated outside the finance system:
- Subscription billing engines, whether that is Stripe Billing, Chargebee or something your team wrote in 2021.
- Ecommerce platforms issuing B2B invoices at checkout.
- Custom job management, booking or field service systems that produce a PDF and email it.
- Marketplace or platform models where you invoice on behalf of a third party.
- Self-billing arrangements, where your customer raises the invoice for you.
- Any process that ends in “and then we manually raise the invoice for the annual renewal”.
Each of those is a separate integration decision. This is exactly the inventory exercise most businesses have never done, because no single person has ever needed the complete list before.
EN 16931 is a data quality requirement wearing a compliance costume
A structured invoice is not a PDF with better plumbing. EN 16931 is a semantic data model that specifies which fields must be present and what they must mean. VAT must be broken down per rate with the correct category codes. Buyer and supplier need proper legal identifiers, not just a company name and an address blob. Line items need structured quantities, units and tax treatment. Credit notes and corrections need to reference the original document by its identifier.
Systems that have been producing perfectly acceptable human-readable invoices for a decade routinely fail on this, because a human reader forgives what a schema validator will not. If your database stores the customer address as a single free-text field, if your VAT rate is a number with no category code behind it, if your invoice numbering has ever been reset or duplicated across entities, you have work to do that has nothing to do with Peppol and everything to do with your data model.
That is the good news, oddly. The remediation is spec-agnostic. Revenue has said detailed guidance and technical specifications will follow before each phase, and the Peppol format itself is moving from BIS 3.0 towards the PINT-EU 4.0 generation. You cannot sensibly build against the final specification today. You can absolutely fix your invoice data model today, and every hour spent there will still count in 2028.
Five corners, and why an invoice error becomes a compliance error
Peppol’s familiar four-corner model routes a document from sender, through the sender’s access point, to the receiver’s access point, to the receiver. Ireland is adopting a five-corner model, where the fifth corner is Revenue. Invoice data and tax reporting travel together rather than being reconciled after the fact in a periodic return.
The practical consequence is worth sitting with. Today, an invoice with the wrong VAT treatment is a customer service problem you resolve with a credit note and an apologetic email. In a five-corner world, the same error has already been reported to Revenue at the moment of issue. Correction mechanics stop being an internal housekeeping matter. Anything in your stack that can issue an invoice is now, functionally, a tax reporting endpoint, and it should be governed accordingly: tested, monitored, and not deployable by whoever is on support that week.
The architecture decision worth making early
The instinct will be to bolt a Peppol connector onto each system that issues invoices. Resist it. You will end up with four access point integrations, four sets of credentials, four places where the format changes when PINT-EU 4.0 lands, and no single answer to the question “did that invoice actually get reported”.
The better shape is the one that works for payments, and for the same reasons we have argued for a provider abstraction layer in payment infrastructure: a single canonical invoice document inside your business, one service that owns issuing and reporting, and every upstream system feeding it rather than talking to the network directly. One place to validate against EN 16931. One place to handle retries, acknowledgements and corrections. One audit trail. When the specification moves, and it will, you change one integration.
This also gives you something to test against long before Revenue’s specifications are final. A canonical invoice model with strict validation will surface every data gap in every upstream system, which is the genuinely slow part of the work.
What to do in 2026 and 2027
- Inventory every system that can emit an invoice. Include the ones finance does not know about. Name an owner for each.
- Validate a real sample against EN 16931. Take a month of live invoices from each source, map them to the semantic model, and count the fields you cannot populate. That number is your project scope.
- Get your ERP or accounts vendor’s Peppol roadmap in writing, with dates and pricing. “It is on the roadmap” is not a plan, and their timeline determines yours.
- Decide access point versus managed service. Most SMEs should buy this. The question is whether it comes bundled with your accounts package or sits as a separate provider serving multiple systems, and that follows from the inventory in step one.
- Fix the receiving path before the issuing path. It applies to you sooner and it is cheaper. Accounts payable that can ingest structured invoices pays for itself regardless of the mandate.
- Budget in the 2027 cycle, not the 2028 one. Integration work of this shape runs three to six months of elapsed time for a mid-sized business, and that assumes vendor readiness. Leaving it to the year of the deadline means paying a scarcity premium for Peppol expertise alongside everyone else.
There is a wider pattern here that Irish businesses should be tracking rather than absorbing one shock at a time. The Cyber Resilience Act reporting duties land in September 2026. The EU AI Act obligations phase in through the same period. Now e-invoicing from 2028 to 2030. Regulation is increasingly arriving as a specification your systems have to satisfy, not a document your solicitor has to read, and the businesses that treat it as an architecture question keep their costs proportionate.
Where we come in
REPTILEHAUS builds the integration layer this mandate demands: canonical document models, ERP and accounts package API work, billing system integration, and the validation and monitoring that keeps a compliance-critical pipeline honest. If you are trying to work out how many of your systems issue invoices and what shape the gap is, that assessment is a short, cheap piece of work and it is a great deal cheaper in 2026 than in 2028. Get in touch and we will scope it with you.
