You've just launched an Irish B2B checkout. A customer enters an Irish VAT number, your Stripe tax logic sees an Irish billing address, and the invoice adds the standard 23% VAT rate. The customer's accounts team rejects it because the transaction should have used reverse charge treatment. Your product team now has to correct the invoice, explain the discrepancy, and decide whether the next subscription renewal will make the same mistake.
That failure usually starts with an oversimplified rule: “Irish customer equals Irish VAT.” In practice, reverse charge VAT Ireland logic depends on the customer's registration status, the type of supply, the parties involved, and the wording and accounting treatment attached to the invoice. Revenue describes reverse charge as a specific self-accounting mechanism, not a general exemption, and its construction guidance sets conditions that country-only logic can't evaluate reliably. (Revenue's reverse charge and self-accounting guidance)
Table of Contents
- When an Irish B2B Invoice Quietly Shifts Who Pays VAT
- What Reverse Charge Means in Irish VAT Law
- Which Irish Supplies Trigger Reverse Charge
- Invoicing Requirements and the Box T1 Pairing
- A Worked Example for an Irish B2B SaaS Invoice
- Validating Irish and EU VAT IDs Without Building a SOAP Wrapper
- Common Pitfalls When Automating Reverse Charge
- Developer Checklist Before You Ship Reverse Charge Logic
When an Irish B2B Invoice Quietly Shifts Who Pays VAT
A SaaS founder bills an Irish holding company for a recurring plan. The checkout collects the customer's company details, but the tax code only looks at the billing country, so Stripe adds Irish VAT. The customer's finance team spots the problem before payment is posted. They've supplied a valid business VAT number and expect the supplier invoice to show no Irish VAT, with the recipient accounting for the tax instead.
The commercial issue is easy to understand. The supplier has charged money it may need to repay or correct, while the customer can't post the invoice cleanly into its VAT workflow. The technical issue is more important: the tax decision happened before the system had established whether the customer was a qualifying taxable person and whether the service fell within a reverse-charge rule.
Practical rule: Don't make VAT treatment from country alone. Make it from customer status, validated registration data, supply classification, and the applicable rule.
A billing flow should answer four questions before creating the final invoice:
- Who is buying: Is the customer a VAT-registered business, an end user, an intermediary supplier, or another customer type?
- What is being sold: Is this an ordinary service, construction work, an intra-EU acquisition, energy, scrap, or another defined category?
- Which party accounts for VAT: Does the supplier charge VAT, or does the recipient self-account?
- What must the documents say: Does the invoice carry the required statement, VAT number, and reporting metadata?
Revenue's construction rule is a useful warning for developers. A VAT-registered subcontractor can issue an invoice without VAT, but only where the transaction satisfies the relevant conditions. The principal contractor then records the tax and, where entitled, claims the corresponding input credit. The system must therefore make a transaction-level decision, not apply a blanket “B2B Ireland” switch.
The rest of the implementation follows from that distinction. Validate the VAT ID before checkout completes, classify the supply before calculating tax, generate the correct invoice language, and persist the evidence used to make the decision. That's how you prevent a seemingly small tax-code shortcut from becoming a recurring finance problem.
What Reverse Charge Means in Irish VAT Law
Reverse charge is self-accounting. The supplier does not collect Irish VAT from the customer. The recipient calculates the VAT due and reports it on its own VAT return. Revenue defines this arrangement as one where the recipient, rather than the supplier, is responsible for accounting for the VAT due. (Revenue's explanation of reverse charge self-accounting)
For a billing system, the practical effect is a paired accounting entry. The recipient records the VAT as output tax and, where entitled to recover it, records the same amount as input credit. The cash result may be neutral for a business with full recovery, but the return still needs both sides of the transaction.
Reverse charge is therefore different from exemption. An exempt supply generally has no VAT charged and does not create the same input recovery route. Reverse charge moves the accounting obligation to the recipient, so the ledger, tax engine, and VAT return integration must retain that distinction even when the net amount payable remains unchanged.
The legal framework sits in the VAT Consolidation Act 2010, including provisions covering the person liable for tax and the accounting mechanism. Revenue's administrative guidance is the working reference for conditions and invoice treatment. The legislation remains the legal anchor when the implementation needs a more precise answer than a generic B2B rule provides.
| Aspect | Reverse Charge | VAT Exemption |
|---|---|---|
| Who accounts for VAT | The recipient accounts for the VAT on its return. | No reverse-charge liability moves to the recipient. |
| Supplier invoice | The supplier generally does not add Irish VAT and must identify the reverse-charge treatment where required. | The invoice identifies the exempt treatment. |
| Recipient records | The recipient records output VAT and, where eligible, a matching input credit. | The recipient does not normally create a matched reverse-charge entry. |
| Cash effect | Often neutral where the recipient can recover input VAT, but reporting remains mandatory. | No output VAT is charged, and input recovery follows exemption rules. |
| Developer implication | Store the liability, rate, invoice wording, and return mapping. | Store the exemption reason and recovery treatment separately. |
For a billing engineer, vat_rate = 0 is an incomplete model. Store a structured decision such as reverse_charge = true, together with the reason, validated customer identifier, applicable rate, and reporting destination. The zero amount on the invoice is only the customer-facing result. The tax liability still belongs to a defined party, and your integration must preserve who that party is and why.
Which Irish Supplies Trigger Reverse Charge
Irish reverse charge rules apply to defined transaction types. Revenue identifies construction, certain intra-EU acquisitions, energy-related supplies, and other specific domestic and cross-border cases. The important implementation detail is that each category has its own eligibility conditions. (Revenue's guidance on intra-Community acquisitions and self-accounting)
Construction services
Construction is the classic domestic edge case. A VAT-registered subcontractor can issue an invoice without VAT to a principal contractor when the parties and supply meet the relevant requirements. Revenue's guidance states that the rule applies where both parties are registered for Relevant Contracts Tax and VAT, the customer isn't an end user or intermediary supplier, and the supply is liable at the standard or reduced rate.
The policy objective is anti-fraud. Moving the accounting obligation to the principal contractor reduces the risk that a subcontractor collects VAT and then fails to remit it. For software, that means the customer role matters as much as the product category. A construction company buying ordinary SaaS isn't automatically receiving a construction reverse-charge supply.
Intra-EU acquisitions
When an Irish VAT-registered business buys goods from another EU member state, the purchaser self-accounts for VAT in Ireland rather than paying the supplier's VAT. This is an acquisition rule, so the system needs goods classification, dispatch and arrival details, and the relevant place-of-supply analysis. It isn't interchangeable with a domestic Irish service rule.
Cross-border B2B services
Services supplied to an Irish business by a supplier established outside Ireland can fall under customer accounting where the applicable place-of-supply rules put the liability with the Irish recipient. The VAT number helps establish business status, but it doesn't independently decide the place of supply or whether a special exception applies.
Gas and electricity
Revenue describes tightly defined domestic reverse charge treatment for gas or electricity supplied by a business in Ireland to a taxable dealer in Ireland. It also covers certain gas and electricity certificates sold between Irish businesses. A normal customer buying electricity for internal use shouldn't be treated as a taxable dealer merely because it has a VAT number.
Scrap metal and other designated supplies
Practitioner guidance identifies areas including scrap metal, greenhouse gas emission allowances, wholesale gas and electricity, construction, and certain property transactions. (Irish reverse charge sector guidance from Marosa) These categories demonstrate why a product catalog needs a supply classification layer.
Northern Ireland and other EU goods also require separate handling. Don't assume that every transaction involving an Irish VAT number follows the same domestic path. Check the parties, movement of goods, establishment, and place-of-supply rules before selecting the tax code.
Invoicing Requirements and the Box T1 Pairing
A reverse-charge invoice must show clearly who accounts for the VAT. For Irish construction transactions, the subcontractor omits VAT and includes the statement “VAT on this supply to be accounted for by the principal contractor.” A generic zero-rate label can imply an exemption rather than recipient accounting, so it is not an adequate substitute. Use the prescribed wording for the relevant supply and keep the rule tied to the transaction type.
Your billing record should store the customer's VAT number, country code, taxable value, supply description, and the rule that produced the tax treatment. The invoice should state that reverse charge applies, or use the wording required for that sector. Keep the text configurable by rule. A single global template will fail when construction, services, goods, and cross-border cases require different wording.
Supplier-side document output
At invoice generation, the system should:
- Omit Irish VAT from each supplier invoice line covered by the reverse-charge rule.
- Add the required reverse-charge wording for that supply.
- Print the customer's validated VAT number and member-state code where required.
- Save the rule reason and validation result in the invoice snapshot.
- Prevent later customer-profile changes from altering the issued document.
The VAT invoice requirements reference provides a useful checklist for turning document rules into a billing-service template contract. Validation status belongs in the stored invoice data, not only in a transient checkout response.
Recipient-side VAT3 treatment
The recipient records the VAT due under reverse charge. For construction, the principal contractor records the tax in box T1 of the VAT return and, where entitled, claims a corresponding input credit. Other acquisition or service flows need their own VAT reporting configuration, because the same invoice shape does not determine every return entry.
| Element | Supplier Invoice | Recipient VAT3 Treatment |
|---|---|---|
| Net supply | Shows the taxable value without Irish VAT added. | Posts the purchase or acquisition value to the relevant expense or asset account. |
| VAT amount | No Irish VAT is collected by the supplier under the reverse-charge rule. | Calculates the VAT due and reports it as recipient-accounted VAT. |
| Invoice wording | States that reverse charge applies or uses the prescribed sector wording. | Retains the invoice as evidence for the self-accounting entry. |
| Customer identity | Includes the recipient's VAT number and member-state information where required. | Uses the identity and transaction data for return and audit support. |
| Return mapping | The supplier does not report the customer's reverse-charge liability as collected output VAT. | The recipient maps the liability to T1 and claims input credit where eligible. |
Country-only logic is not enough for production billing. A valid VAT number supports the customer's business status, but the supply classification and reporting configuration still decide the invoice and VAT3 treatment. Northern Ireland transactions can follow a separate UK protocol, particularly where goods are involved, so keep that path outside the Irish domestic rule set.
A Worked Example for an Irish B2B SaaS Invoice
An Irish SaaS supplier bills a Dublin-registered construction contractor €12,000 for an annual subscription. The buyer has a valid Irish VAT number, but the subscription is SaaS, not construction work. The customer's industry does not automatically determine the VAT treatment of every purchase. This example covers recipient accounting for a qualifying reverse-charge service.
The supplier issues an invoice for €12,000 with no Irish VAT line and a clear reverse-charge statement. Its ledger records €12,000 of SaaS revenue and no Irish VAT collected on the invoice. The customer records the purchase and calculates Irish VAT for its self-accounting entry. At the standard Irish rate of 23%, that VAT is €2,760.
Supplier entries
- Debit: Accounts receivable, €12,000.
- Credit: SaaS revenue, €12,000.
- VAT: No Irish VAT collected where the qualifying reverse-charge rule applies.
The PDF invoice should show the customer's VAT number, supply description, net amount, and reverse-charge wording. Storing the result internally as “VAT 0%” is poor practice because that label can collapse reverse charge, zero rating, and exemption into the same state. Your billing model should preserve the reason for the treatment.
Customer entries
- Debit: SaaS expense, €12,000.
- Debit: Recoverable input VAT, €2,760, where the customer can deduct it.
- Credit: Reverse-charge VAT liability, €2,760.
- Credit: Accounts payable, €12,000.
The recipient reports the VAT liability in T1 and mirrors eligible input credit in the relevant input-credit field, commonly represented as E1. The supplier does not report the recipient's self-accounted amount in its own T1 as collected output VAT.
For Stripe, run the tax decision only after validating the customer's tax ID and evaluating the service rule. A validated ID can feed the invoice item's tax treatment, but Stripe configuration does not replace the legal eligibility check or the customer's accounting responsibility. Country-only logic breaks when the buyer's status, service classification, or reporting treatment differs from the checkout assumption. Keep those decisions explicit in code rather than deriving them from the customer's address alone.
Validating Irish and EU VAT IDs Without Building a SOAP Wrapper
VAT ID validation is the boundary between a customer's typed claim and your tax decision. A VAT number stored in a checkout form is not proof that the customer is registered, that the number belongs to the named business, or that the registration remains usable for the transaction.
Raw VIES
The EU VIES service is the authoritative route many teams start with, but its SOAP interface creates friction inside a synchronous checkout. Your code has to construct XML, parse XML responses, handle service failures, and decide what to do when a member-state service is unavailable. A hard dependency on a live remote response can turn a tax lookup problem into a failed purchase.
An in-house wrapper
A wrapper can add retries, circuit breakers, request queues, response normalization, and caching. That architecture works when tax validation is a core platform capability and the team is prepared to own service behavior, but it still leaves you maintaining country-specific formats and operational handling around an external system.
TaxID
TaxID is one managed option for this layer. Its published product description says it provides a REST API that validates VAT and company identification numbers, returns registration status and company details in JSON, and wraps VIES with format checks, caching, and machine-readable errors. The guide to validating EU VAT numbers through a VIES API covers the integration pattern.
The important design choice is failure behavior. A cached result can keep a renewal or checkout moving when a live authority endpoint is temporarily unavailable, but you need a clear policy for when a stale result is acceptable. For a new customer, you may block reverse-charge treatment until validation succeeds. For an existing subscription, you may queue revalidation and temporarily route the account to manual review rather than applying a tax code.
| Dimension | Raw VIES | In-House SOAP Wrapper | TaxID |
|---|---|---|---|
| Interface | SOAP and XML handling. | Your own normalized interface around SOAP. | Managed REST and JSON interface. |
| Failure handling | Your application owns retries and outage behavior. | Your team builds and operates resilience features. | The service provides managed handling and structured responses. |
| Caching | Must be implemented by your application. | Must be designed and maintained internally. | Published product information describes Redis-backed caching and cached responses. |
| Error shape | External response handling can be awkward to normalize. | Your team defines the contract. | Published error categories include machine-readable statuses such as invalid or unavailable. |
| Checkout fit | Brittle for a blocking synchronous call. | Better, but operationally expensive to own. | Designed for API-driven billing and validation workflows. |
| Control | Direct dependency on the underlying service. | Maximum implementation control. | Less infrastructure ownership, more managed dependency. |
Keep validation separate from tax calculation. The validator tells you whether the identifier is registered. Your rules engine still decides whether the particular supply qualifies for reverse charge.
Common Pitfalls When Automating Reverse Charge
In billing code reviews, the recurring failure pattern is rarely the reverse-charge definition itself. One incomplete field can decide the entire tax result, especially when Stripe checkout reduces the decision to country, customer type, and VAT ID.
Treating every Irish customer as qualifying B2B
An Irish billing address does not establish that the buyer is a qualifying VAT-registered taxable person. Sole traders, public bodies, end users, and intermediary suppliers may require different treatment.
Guard: Require a validated VAT ID and an explicit customer classification. Store the legal customer type separately from the billing country, rather than deriving both from an address.
Printing a generic zero-VAT invoice
A zero amount without an explanation can resemble an exemption, export, or application error. For construction supplies, the invoice also needs wording that identifies the principal contractor's accounting responsibility.
Guard: Generate invoice text from the selected tax rule. Test the rendered PDF, not only the internal tax code, and retain the rule reason in the invoice record.
Trusting a VAT number forever
Customers enter VAT IDs manually. A previously valid identifier can later become invalid or relate to a different legal entity. Renewal billing exposes the gap because checkout is not revisited by a person.
Guard: Validate at signup, then revalidate on renewal or after legal details change. Save the validation response, timestamp, member-state code, and normalized identifier so the later tax decision is explainable.
Classifying only B2B versus B2C
That binary is too coarse for Irish reverse charge. Construction, scrap, energy, acquisitions, and cross-border services have different triggers, so the customer type alone cannot select the tax treatment.
Guard: Classify the supply before tax calculation. Product records should expose tax-relevant attributes, rather than making the tax engine infer them from a marketing description.
Freezing the rules in application code
Revenue guidance can change, and a permanent if customer_country == "IE" branch is difficult to audit. A rule update then becomes a risky deployment instead of a controlled tax-configuration change.
Guard: Keep rules versioned, effective-dated, and reviewed against current Revenue guidance. Add fixtures for eligible, ineligible, and ambiguous transactions, including unavailable validation responses.
| Pitfall | Code-Level Guard |
|---|---|
| Wrong customer type | Require customer-role classification and validated VAT registration. |
| Missing invoice wording | Select legally appropriate text from the tax rule, then test the final document. |
| Stale VAT ID | Revalidate at signup, renewal, and legal-entity change events. |
| No supply classification | Evaluate service, goods, construction, energy, and other categories before tax calculation. |
| Frozen exemption logic | Use versioned tax rules with review ownership and effective dates. |
Reverse-charge treatment should fail closed. If the evidence is missing, keep the normal tax path or send the transaction for review. Do not issue a zero-VAT invoice and leave finance to correct the decision later.
Developer Checklist Before You Ship Reverse Charge Logic
A good pull request should prove more than “the checkout shows zero VAT.” It should demonstrate that the system can explain why it selected reverse charge, reproduce the decision later, and produce documents and accounting data that agree.
Use this checklist in the PR description:
- Verify the buyer: Validate the VAT ID at signup and again for annual renewals. Persist the timestamp, normalized number, member-state code, response status, and legal-name data returned by the validation service.
- Classify the supply first: Mark whether the line is a B2B service, construction-related supply, intra-EU goods acquisition, energy transaction, scrap transaction, or another defined category before the tax engine calculates VAT.
- Separate zero outcomes: Keep reverse charge, zero rating, exemption, and out-of-scope treatment as different enum values. They may all display no VAT on an invoice, but they don't create the same accounting result.
- Render the invoice: Confirm the document includes the customer's VAT number, member-state code, taxable value, and the applicable reverse-charge wording. Test both HTML and PDF output.
- Map the ledger: Confirm the supplier records no collected Irish VAT for the qualifying invoice, while the recipient's workflow can create the self-accounted liability and matching input-credit entry.
- Reconcile the return: Compare invoice-level tax decisions with the VAT3 mapping. Revenue's guidance specifically places the principal contractor's construction reverse-charge amount in T1, with eligible input credit claimed separately.
- Log the evidence: Store the rule version, validation result, tax decision, invoice text, and event timestamps. An audit trail is part of the feature, not an afterthought.
- Review the rules: Assign an owner to review the configuration against current Revenue guidance and update the effective-dated rules when the treatment changes.
The strongest implementation treats VAT as a decision record rather than a rate lookup. When finance asks why an invoice was issued without VAT, your system should answer with the customer classification, validated VAT ID, supply rule, invoice wording, and accounting mapping that produced the result. The VAT compliance checklist for billing teams can help turn those controls into an operational review.
TaxID provides a developer-focused API for validating Irish and EU VAT IDs before your Stripe checkout or subscription renewal applies reverse-charge treatment. Visit TaxID to connect structured VAT validation and machine-readable results to the billing workflow you're shipping.