Ireland e-invoicing 2028: the enterprise readiness guide

What changed—and what has not yet been finalised

Ireland's e-invoicing programme is no longer a broad policy intention. Revenue published its implementation pathway on 8 October 2025, confirmed the Phase One definition on 10 February 2026 and consolidated the timetable and scope on 20 July 2026. The first operational date is 1 November 2028. From that date, the in-scope large corporates must issue structured eInvoices for domestic business-to-business transactions and report a subset of relevant invoice data to Revenue. Every business must be capable of receiving structured eInvoices from suppliers that are required to issue them.

The legal status still needs precise language. Council Directive (EU) 2025/516—the VAT in the Digital Age Directive—was adopted on 11 March 2025, published on 25 March and entered into force on 14 April 2025. It establishes EU changes with their own transposition and application dates, including cross-border digital reporting from 1 July 2030. Ireland's 2028 and 2029 domestic phases are Revenue's published implementation programme. Revenue says it has begun analysis and technical work on the legislative changes, strategic processes and IT systems, and that detailed guidance and technical specifications will be published ahead of each phase. A programme announcement should not be presented as though every domestic rule, schema and penalty has already been enacted and released.

This distinction changes procurement. A vendor can reasonably demonstrate EN 16931 capability, structured-invoice ingestion and controls already used in other markets. It cannot credibly promise conformance to an unpublished Irish reporting schema or a final network design. Contracts signed in 2026 should separate current capability from future regulatory deliverables, state the assumptions behind each, and make change control, testing and evidence export contractual obligations.

It also changes the internal business case. The near-term investment is not a speculative build against a guessed endpoint. It is remediation of invoice and counterparty data that will be required under almost any final architecture. Legal names, VAT registrations, establishment facts, customer status, invoice references, dates, amounts, corrections and source evidence are durable dependencies. They are also the parts most likely to fail when programmes are compressed into the final year.

Who is affected: do not invent a size threshold

For Phase One, Revenue defines a large corporate through tax administration and establishment, not through a published employee count, revenue threshold or Companies Act category. The business must be VAT registered, have its tax affairs managed by Revenue's Large Corporates Division, and be established or have a fixed establishment in Ireland. All three facts need to be resolved. A multinational's global size alone does not answer the scope question, and a subsidiary cannot assume it is out of scope because its local revenue looks small.

Revenue says it will write to large corporates to notify them of inclusion. That notification should become controlled regulatory evidence linked to the specific legal entity and VAT registration, not an email stored in one employee's mailbox. Groups should reconcile the notified entity against their statutory company record, Irish VAT account, ERP company code and billing systems. If the recipient name is a group label or an old legal name, the discrepancy needs to be resolved with Revenue before it becomes a configuration assumption.

The receiving obligation is broader. From 1 November 2028, all businesses must be able to receive and process structured eInvoices from suppliers required to issue them. A business outside Phase One can therefore face a mandatory operational dependency even though it is not yet required to issue. Accounts payable, procurement and vendor-management teams cannot wait for the company's outbound mandate. They need to know which Irish suppliers will move first, where structured invoices will arrive, how they will be matched to purchase orders and how exceptions will be handled.

Phase Two begins on 1 November 2029 and extends the domestic obligation to VAT-registered businesses engaged in cross-border EU B2B trade, described by Revenue in connection with the zero-rate arrangements for that trade. Phase Three on 1 July 2030 brings the EU cross-border regime. The populations overlap but are not identical. A group-level programme should therefore maintain an entity-by-entity scope register with the evidence, effective date and transaction flows behind each classification.

Classify the transaction before choosing the invoice route

An Irish VAT registration is not enough to decide whether an invoice enters Phase One. The first domestic obligation concerns B2B transactions. Teams must identify the supplier legal entity, customer legal entity, their relevant establishments, the VAT registrations used and whether the transaction is domestic, cross-border EU, business-to-government or business-to-consumer. A billing address or delivery country can support that analysis, but neither is a universal proxy for place of supply or customer status.

Domestic B2B invoices issued by the Phase One population are the core 2028 outbound flow. Cross-border EU B2B transactions sit on the July 2030 ViDA path, although companies entering Phase Two in November 2029 will first use the Irish domestic system. Business-to-government has a different history: Irish public bodies have been required since June 2019 to receive and process qualifying EN 16931 invoices under S.I. No. 258/2019, implementing Directive 2014/55/EU. The European Commission's country sheet records Peppol BIS Billing 3.0 and the Peppol network in that public-sector model. That installed base is relevant experience, but it does not prove that every B2B transport and reporting decision is final.

B2C is not described by Revenue as part of the first domestic B2B issuing mandate. Systems must still classify it correctly because mislabelling a consumer or non-business legal person as a business can route a document and its data into the wrong workflow. Similarly, a group invoice between related companies is not automatically outside scope. The relationship between the parties does not replace the supply, establishment and VAT analysis.

The practical control is a transaction routing table owned jointly by tax and finance. It should list representative flows, expected invoice type, reporting path, required identifiers, evidence, effective date and exception owner. Use actual transactions from sales, procurement, intercompany, credit notes, self-billing and recurring billing. A vendor demonstration using one clean domestic sale will not reveal whether the operating model can classify the real population.

A structured eInvoice is data—not a PDF in a faster channel

Revenue defines the future eInvoice as one issued, transmitted and received in a structured electronic format that permits automated processing and complies with European Standard EN 16931. It expressly excludes PDFs and scanned paper. A PDF may be produced as a human-readable view, but it cannot be the authoritative data object if the mandated process depends on structured fields. Emailing a PDF from an ERP therefore does not become compliant simply because no paper is involved.

EN 16931 provides a semantic model: common business meanings for invoice information. It does not remove country rules, transaction classification, syntax choices, network rules or buyer-specific validation. Ireland's public-sector implementation uses Peppol BIS Billing 3.0 and the Peppol eDelivery network. Revenue's 2025 implementation paper says existing infrastructures including Peppol will be used and evaluated as adoption expands, while its July 2026 material says detailed technical specifications will follow. Procurement should treat current Peppol capability as relevant readiness, not as permission to invent the final B2B architecture.

The receiving side is usually underestimated. A technically delivered document has not completed the business process. It must be associated with the correct supplier record, legal entity, VAT registration, purchase order or contract, supply and tax treatment. It must pass duplicate, arithmetic and master-data controls, enter an approval route, post to the ledger, preserve the original structured payload and return a machine-readable response where required. An accounts-payable team that prints the data to PDF and rekeys it has preserved the old control weakness inside a new transport layer.

Enterprises should also separate the invoice from its lifecycle events. Rejection, correction, cancellation, credit note, disputed amount, payment status and tax reporting are not interchangeable. Each needs a stable reference to the original document, sender and recipient. If the final Irish design changes a message type or reporting field, that event model should absorb it without rewriting the history of the commercial transaction.

Real-time reporting moves identity errors to the front of the process

Revenue describes VAT Modernisation as the reporting of transaction details as they occur, with a subset of relevant eInvoice data sent to Revenue. The exact Irish data subset, validation rules, response model and operational timing have not all been published. That uncertainty is not a reason to postpone data work. Every plausible model needs the parties, invoice identifiers, dates, taxable amounts, VAT treatment and document relationships to agree across billing, accounts payable, tax and the reporting record.

Legal-entity identity is the first control. A trading name, website domain or supplier portal label may not be the company that issued the invoice. A VAT number can be syntactically plausible yet belong to a different entity or registration. A valid authority response is useful evidence, but it does not establish every fact about the company, the supply or the risk of payment. Equally, an unavailable VIES response, a missing name or an apparent mismatch is not proof that a company is fictitious. The workflow needs separate states for verified response, invalid response, unavailable service, conflicting identity and unresolved evidence.

A good master record links the legal company, Irish company number where applicable, VAT registration, establishment, addresses, trading names, group relationships and effective dates. Each field should have a source and retrieval time. Invoice systems should consume the governed identifier rather than store a new uncontrolled copy. When a supplier changes name, address, VAT status or group entity, the change should trigger review of open orders and future invoices without rewriting historical evidence.

The reporting object should also preserve provenance. Store the invoice version, source application, transformation rule, schema version, sending and receipt timestamps, authority or network acknowledgements, validation results, correction chain and final accounting record. If a vendor returns only a green status and retains the payload in a proprietary portal, finance cannot reconstruct the submission or migrate providers safely. Evidence export is therefore a core buying requirement, not an optional reporting feature.

The 2030 reporting change does not remove the need for zero-rate evidence

Revenue's current guidance for an intra-Community supply of goods lists five conditions for zero rating: the customer is VAT registered in another Member State; the supplier obtains and retains that VAT number with country prefix; both parties' VAT numbers are quoted on the invoice; the goods are dispatched or transported to another Member State; and correct VIES Returns are made. If a condition is not satisfied, Revenue says Irish VAT must be charged at the appropriate rate. That is the current operational baseline, not a future-state shortcut.

Under ViDA, the cross-border digital reporting regime applies from 1 July 2030 and replaces the current recapitulative-statement model for the transactions in scope. Revenue's implementation paper explains that structured invoices must be issued within the EU rule's time limit and specified data reported to the relevant authority. The fact that a summary return disappears does not make the customer VAT number, transport evidence or transaction identity irrelevant. It moves them into a more immediate, transaction-linked control.

Do not redesign today's process as though the 2030 rule were already live. Businesses must continue to meet current Irish invoicing, VIES-return and evidence requirements until the applicable rules change. At the same time, do not build a 2028 domestic solution that cannot connect to the 2030 cross-border model. The durable design is an effective-dated rule engine with separate current and future reporting routes, backed by the same governed party, tax and transaction evidence.

VIES results need disciplined interpretation through the transition. An invalid result can arise because a number is not activated for intra-EU transactions or because the input is wrong; an unavailable result means the requested service did not complete. Name and address disclosure also varies by Member State. The correct response can be correction, retry, request for evidence or manual review. Automatically describing the business as fake turns a tax-service state into an unsupported company-risk conclusion.

Buy against what is confirmed; configure for what is open

The safest 2026 buying decision is neither to wait nor to buy a black box labelled Ireland compliant. Divide requirements into three groups. The first is confirmed and stable enough to implement: the dates, Phase One definition, universal receiving direction, structured-data principle and EN 16931 baseline. The second is directionally clear but awaiting detail: the subset of data reported to Revenue, validation responses and how real-time will be operationalised. The third should remain explicitly open until Revenue publishes it: final technical specifications, complete network and interface rules, detailed fallbacks, transition tolerances and any penalty framework tied to the domestic rollout.

A vendor statement that it supports Peppol is useful but incomplete. Ask which Peppol profiles, identifiers, access-point responsibilities, acknowledgements and country-specific rules it supports. Then ask which parts are being assumed for Irish B2B rather than drawn from a published requirement. Require assumptions to be listed in the contract and implementation design. When Revenue releases new specifications, the impact assessment should be a defined deliverable with a deadline—not a discretionary professional-services project.

Commercial resilience matters because the programme spans several years. The contract should provide full export of invoices, original payloads, transformations, acknowledgements, validations, audit logs, configurations and counterparty mappings in usable formats. It should define regulatory-update obligations, test-environment access, support during cutover, service levels and exit assistance. If changing provider means losing the evidence needed to defend historical VAT treatment, the business has bought lock-in disguised as compliance.

Internal governance should mirror that separation. The steering committee can approve data remediation and receiving architecture now. It can approve a configurable EN 16931 capability subject to assumptions. It should not sign off an Irish reporting schema that does not yet exist publicly. A decision log should record what evidence existed, which assumptions were made, who owns the watch item and what event triggers review.

What finance, tax, procurement and data teams should do now

Start with entity and flow inventories, not software selection. Tax should identify Irish VAT registrations, establishments, Large Corporates Division status and domestic versus cross-border transaction populations. Finance should map every invoice source and receiving channel, including shared-service centres, billing platforms, procurement networks, expense tools and outsourced processes. Data teams should quantify missing or conflicting legal names, VAT numbers, addresses and document references. Procurement should identify suppliers likely to issue first and vendors on which the future process will depend.

Build a representative evidence pack of real transactions. Include a domestic sale, domestic purchase, intra-EU supply, intra-EU acquisition, B2G invoice, B2C transaction, intercompany charge, self-billing arrangement, credit note, duplicate, rejected invoice and supplier with changed VAT details. For each, state the legal parties, tax treatment, required fields, expected structured message, reporting outcome, accounting entry and retained evidence. That pack becomes the basis for vendor demonstrations, design reviews and user acceptance testing.

Assign ownership at field level. Tax may define why a VAT number is required, but procurement or customer onboarding often collects it; finance may approve the invoice, while master-data operations maintain the supplier; IT moves the message, while the provider applies validation. A RACI chart at system level is too coarse. The programme needs a named owner for the source, quality rule, correction and evidence of every critical business term.

Create a regulatory watch process with dated sources. Revenue has said it will publish further guidance and technical specifications. The watch owner should record each release, compare it with assumptions, decide whether the architecture or contract changes, and preserve the decision. This is especially important where vendor roadmaps use unpublished interpretations. A change log that says only 'Ireland update applied' will not support testing or audit.

• Confirm which Irish entities are managed by Large Corporates Division and retain Revenue's notification.
• Map every domestic B2B, intra-EU, B2G, B2C, intercompany, credit-note and self-billing flow.
• Measure legal-name, VAT-number, address, establishment and invoice-reference defects at source.
• Design inbound structured processing for all businesses—not only the first issuing cohort.
• Make the original structured message authoritative and retain any human-readable view separately.
• Define unavailable, invalid, mismatch, rejected, corrected and unresolved states independently.
• Require exportable payloads, acknowledgements, validations, rules, mappings and audit logs from vendors.
• Keep the Irish reporting subset, transport choice and future fallbacks configurable until official specifications arrive.
• Test historical and future effective dates; never apply a new rule retrospectively by default.
• Report readiness through evidence coverage and unresolved exception volumes, not a single percentage score.

Questions for vendors—and how implementation will fail

Enterprise buyers should force vendors to demonstrate the full control chain with customer data. A polished EN 16931 sample proves only that one document can be generated. It does not prove Irish scope determination, counterparty matching, inbound processing, correction handling, reporting, reconciliation or audit export. Ask the vendor to run the representative evidence pack and show every input, transformation, decision, message and exception.

The most common failure will be treating compliance as an accounts-receivable format project. The universal receiving direction makes accounts payable equally important, and real-time reporting makes master data and tax determination upstream dependencies. A second failure will be hard-coding assumptions before Revenue publishes the details. A third will be using group names and VAT numbers interchangeably, producing invoices that are syntactically valid but addressed to or reported against the wrong legal entity.

Procurement can prevent several failures through acceptance criteria. Require field-level lineage, effective-dated configuration, test evidence for each flow, outage and retry behaviour, immutable logs, reconciliation reports and complete export. Require the vendor to label a feature as current, planned or assumption-based. Refuse a generic warranty that the software is compliant while every legal decision and data-quality obligation is pushed back to the customer.

Leadership should also resist a single traffic-light readiness score. One green number can hide that outbound generation is complete while inbound matching fails, or that technology works while legal-entity scope is unresolved. Report distinct verdicts for scope coverage, counterparty data, outbound issue, inbound processing, reporting readiness, exception handling, reconciliation and evidence export. Each should show the tested population, date, owner and remaining gap.