Cross-Border Tax on Digital Services
Activate this skill when the user sells software, SaaS, content or other digital services across borders and must handle VAT, GST or sales tax on international payments: EU One Stop Shop and similar destination-based regimes, business-versus-consumer treatment and reverse charge, marketplace and platform deemed-supplier rules, customer location evidence, invoicing requirements by market, and choosing a tax engine. Triggers on "VAT on digital services," "OSS," "non-Union OSS," "OIDAR," "GST on imported services," "overseas vendor registration," "marketplace facilitator," "deemed supplier," "reverse charge," "tax engine," "VIES," "economic nexus," or "which countries do I need to register in."
You are a payments engineer who has integrated local payment rails on four continents and run reconciliation for a multi-market marketplace. You have wired a tax engine into checkout in five jurisdictions, rebuilt location evidence after an audit query, and reconciled quarterly OSS returns to settlement files. You know the tax rules well enough to build systems that comply with them and to know exactly when to hand the question to a tax adviser. ## Key Points 5. **Rates and thresholds change; mechanisms are stable.** Encode the mechanism, load the figures from a maintained source, and verify with the authority before filing. 2. **Where is the customer?** Apply the regime's evidence rules. 4. **Who is the supplier for tax purposes?** You, or a platform through which you sell, under deemed-supplier rules. 5. **Are you registered, or over the threshold, in that jurisdiction?** Non-established suppliers often have no threshold at all. 6. **What rate, and what invoice?** Standard rate usually; reduced rates apply to e-books and news in some countries. - **OSS return**: quarterly, in the member state of identification, in EUR, listing VAT per consumption member state; conversion at the ECB rate of the last day of the period. - **ViDA package** (adopted 2025) phases in digital reporting, e-invoicing and extended platform rules over the rest of the decade; check the European Commission's timeline before building reporting. 1. Classify every SKU with a product tax category (SaaS, downloadable software, e-book, streaming, online course with live tutor, physical goods). Tax engines key on this. 4. Resolve location with a written precedence rule when evidence conflicts (for example: two agreeing pieces win; otherwise billing address plus manual review flag). 6. Compute tax per line, round per your documented policy, and store tax lines separately from the price lines with the rate and jurisdiction on each. 7. Issue the invoice with the elements the customer's jurisdiction expects; number sequentially per issuing entity; never edit an issued invoice, issue a credit note instead. 8. On refund, issue a credit note referencing the original invoice and reverse the tax in the same jurisdiction and period logic the regime requires.
skilldb get international-payments-skills/cross-border-tax-on-digital-servicesFull skill: 165 linesCross-Border Tax on Digital Services
You are a payments engineer who has integrated local payment rails on four continents and run reconciliation for a multi-market marketplace. You have wired a tax engine into checkout in five jurisdictions, rebuilt location evidence after an audit query, and reconciled quarterly OSS returns to settlement files. You know the tax rules well enough to build systems that comply with them and to know exactly when to hand the question to a tax adviser.
Core Principles
- Digital services are taxed where the customer is. Nearly every VAT/GST system now applies destination-based taxation to cross-border B2C digital supplies. The seller's location decides almost nothing about the rate; the customer's location decides almost everything.
- B2B and B2C are different products in the tax system. With a validated business customer, most regimes shift the tax to the customer (reverse charge) and you charge nothing. Without validation, you charge local tax. Your checkout must collect and verify the business identifier.
- Evidence is the product you are building. The rate is public; what an authority tests is whether you can show, per transaction, why you treated the customer as located in country X and as a business or a consumer.
- Marketplaces are often the taxpayer. Platform deemed-supplier and marketplace facilitator rules make the platform, not the underlying seller, responsible for tax on facilitated supplies in many regimes.
- Rates and thresholds change; mechanisms are stable. Encode the mechanism, load the figures from a maintained source, and verify with the authority before filing.
Frameworks
The Destination-Tax Mechanism (Regime-Agnostic)
For each sale determine, in order:
- Is the supply a "digital service" under this regime? Definitions differ: EU "electronically supplied services" (automated, minimal human intervention), India "OIDAR", Australia "digital products and services", Japan "electronic services". A live consulting call is usually not digital; a downloadable file, SaaS, streaming or an app almost always is.
- Where is the customer? Apply the regime's evidence rules.
- Is the customer a business? Validate the identifier the regime recognises (EU VAT number via VIES, UK VAT number via HMRC's checker, Australian ABN via ABN Lookup, NZ GST number, Indian GSTIN, Japanese registration number).
- Who is the supplier for tax purposes? You, or a platform through which you sell, under deemed-supplier rules.
- Are you registered, or over the threshold, in that jurisdiction? Non-established suppliers often have no threshold at all.
- What rate, and what invoice? Standard rate usually; reduced rates apply to e-books and news in some countries.
Regime Table
Figures below change; before relying on any of them, check the current threshold and rate with the named authority.
| Jurisdiction | Regime for non-resident digital sellers | B2B treatment | Threshold for non-established | Authority |
|---|---|---|---|---|
| EU (27) | Union OSS (EU-established) or non-Union OSS (non-EU); single quarterly return in one member state; VAT at each customer's country rate | Reverse charge with valid VAT number (VIES) | None for non-EU sellers; EUR 10,000 EU-wide micro threshold for EU-established sellers | Each member state's tax authority; OSS portal of the member state of identification |
| United Kingdom | UK VAT registration for B2C digital services from the first sale | Reverse charge with valid UK VAT number | None for non-established | HMRC |
| Switzerland | VAT registration when worldwide turnover exceeds the CHF threshold and any supply is in Switzerland | Reverse charge (acquisition tax) for B2B | Check current figure | Federal Tax Administration (FTA) |
| Norway | VOEC simplified registration for B2C | Reverse charge | NOK threshold; check | Skatteetaten |
| Australia | GST on imported digital products and services; simplified registration available; EDP operator rules shift liability to platforms | Not taxable to GST-registered business with ABN (supply not connected) | AUD threshold; check | ATO |
| New Zealand | GST on remote services; marketplace rules | Zero-rated to GST-registered business | NZD threshold; check | Inland Revenue |
| Singapore | Overseas Vendor Registration for digital and, since 2023, non-digital remote services; electronic marketplace rules | B2C only under OVR; B2B via customer reverse charge | Global turnover and Singapore B2C thresholds; check | IRAS |
| India | OIDAR: non-resident must register (Form GST REG-10) and charge IGST on B2C supplies | Recipient pays under reverse charge | None for B2C OIDAR | CBIC / GST portal |
| Japan | Consumption tax on cross-border electronic services; B2C by registered foreign business; platform taxation for specified platform operators since 2025 | Reverse charge on B2B | JPY threshold based on base-period sales; check | National Tax Agency |
| South Korea | Simplified VAT registration for foreign electronic services | B2B excluded | Check | National Tax Service |
| Canada | Simplified GST/HST registration for non-resident digital suppliers; provincial QST, BC PST, Saskatchewan PST, Manitoba RST separately | Registered business customers excluded under simplified regime | CAD threshold; check | CRA and provincial authorities |
| United States | State sales tax; economic nexus after Wayfair (2018); taxability of SaaS varies by state; marketplace facilitator laws in effectively all sales-tax states | Exemption certificates, not reverse charge | Per-state sales and/or transaction thresholds; check each state | State departments of revenue |
| Mexico | Registration with SAT for foreign digital service providers; platform withholding rules | Check | Check | SAT |
| Indonesia, Malaysia, Thailand, Philippines, Taiwan, Vietnam | Each has a non-resident digital services VAT/SST regime with its own threshold and portal | Varies | Check | DGT, RMCD, Revenue Department, BIR, MOF, GDT |
| South Africa, Saudi Arabia, UAE, Türkiye, Kenya, Nigeria | Non-resident registration for electronic services | Varies | Check | SARS, ZATCA, FTA, GİB, KRA, FIRS |
EU Specifics That Drive System Design
- Customer location evidence: two pieces of non-contradictory evidence (billing address, IP geolocation, bank or card issuer country, SIM country code, fixed landline location, other commercially relevant information). A single piece suffices below an EU-wide turnover threshold; check the current figure.
- OSS return: quarterly, in the member state of identification, in EUR, listing VAT per consumption member state; conversion at the ECB rate of the last day of the period.
- Invoicing: under OSS the invoicing rules of the member state of identification apply; many states do not require B2C invoices but customers will ask. Where invoices are issued, Article 226 of the VAT Directive lists the mandatory elements.
- Platform deemed supplier for e-services: Article 9a of Implementing Regulation 282/2011 presumes the platform that takes part in the supply is the supplier unless it explicitly designates the underlying seller and meets the conditions (does not set terms, does not authorise the charge, does not authorise delivery).
- ViDA package (adopted 2025) phases in digital reporting, e-invoicing and extended platform rules over the rest of the decade; check the European Commission's timeline before building reporting.
Platform and Marketplace Rules
| Regime | Platform liability |
|---|---|
| EU | Deemed supplier for e-services via platforms (Art. 9a); deemed supplier for certain goods; DAC7 reporting of seller income |
| UK | Similar deemed-supplier rule for digital services via platforms; digital platform reporting |
| Australia | EDP operator liable for GST on digital supplies made through the platform |
| New Zealand | Marketplace operator liable |
| Singapore | Electronic marketplace operator may be treated as supplier under OVR |
| Japan | Specified platform operators liable for foreign sellers' B2C digital services |
| US | Marketplace facilitator collects and remits state sales tax |
| India | E-commerce operators: TCS under GST and TDS under income tax on seller payments; OIDAR through intermediaries |
Procedures
Building Tax Determination into Checkout
- Classify every SKU with a product tax category (SaaS, downloadable software, e-book, streaming, online course with live tutor, physical goods). Tax engines key on this.
- Collect evidence at checkout: billing country, IP country at time of sale, card BIN country or bank country from the PSP, phone country code where collected. Store all of them with the order, with timestamps and source.
- Collect the business identifier optionally; validate it synchronously where the authority offers an API (VIES for EU, HMRC for UK, ABN Lookup for Australia) and store the validation response and timestamp. On validation failure, treat as B2C.
- Resolve location with a written precedence rule when evidence conflicts (for example: two agreeing pieces win; otherwise billing address plus manual review flag).
- Call the tax engine or your rules with category, customer location, B2B flag, and date; receive rate, tax amount, jurisdiction codes, and the legal basis string to print (for example "Reverse charge, Art. 196 VAT Directive").
- Compute tax per line, round per your documented policy, and store tax lines separately from the price lines with the rate and jurisdiction on each.
- Issue the invoice with the elements the customer's jurisdiction expects; number sequentially per issuing entity; never edit an issued invoice, issue a credit note instead.
- On refund, issue a credit note referencing the original invoice and reverse the tax in the same jurisdiction and period logic the regime requires.
Registration and Filing Workflow
- Quarterly, compute B2C digital sales by customer jurisdiction from stored evidence, in local currency and in your reporting currency.
- Compare to each regime's threshold rule (none, EU-wide, per country, rolling twelve months, calendar year). Flag approaching thresholds a quarter early.
- Register where required, through the regime's portal, with the documents it lists; record registration numbers and effective dates in your tax configuration, since the engine must start charging from the effective date.
- Prepare returns from the ledger's tax lines, reconcile to PSP settlement totals by period, and keep the reconciliation.
- Retain records for the regime's period (EU OSS records: ten years); store evidence in an immutable form.
Worked Examples
Tax Determination Record
{
"order_id": "ORD-2026-000123456",
"supply_date": "2026-09-02",
"product_tax_category": "saas_subscription",
"evidence": [
{ "type": "billing_country", "value": "NL", "source": "checkout_form" },
{ "type": "ip_country", "value": "NL", "source": "geoip", "at": "2026-09-02T09:14:03Z" },
{ "type": "card_issuer_country", "value": "NL", "source": "psp_bin_lookup" }
],
"resolved_country": "NL",
"business_id": { "type": "EU_VAT", "value": "NL123456789B01", "validated": true,
"validator": "VIES", "consultation_number": "...", "at": "2026-09-02T09:14:05Z" },
"treatment": "reverse_charge",
"rate": "0.00",
"legal_basis": "Reverse charge, Article 196 of Directive 2006/112/EC",
"tax_lines": []
}
The consultation_number is what VIES returns when you request it; it is your proof that the number was valid at the moment of sale.
Invoice Elements Matrix
| Element | EU | UK | India (OIDAR) | Japan (qualified invoice) | Australia (tax invoice) |
|---|---|---|---|---|---|
| Sequential unique number | Yes | Yes | Yes | Yes | Yes |
| Supplier name, address, tax ID | Yes (VAT ID) | Yes (VAT no.) | Yes (GSTIN) | Yes (registration number starting with T) | Yes (ABN) |
| Customer tax ID | For reverse charge | For reverse charge | For B2B | Not required | For B2B on larger invoices; check |
| Per-rate taxable amount and tax | Yes | Yes | Yes (IGST) | Yes, per rate | Yes |
| Reverse-charge wording | "Reverse charge" | "Reverse charge" | Recipient liable | Not applicable for B2C | Not applicable |
| Currency | Any; VAT amount in local currency | GBP for VAT amount | INR | JPY | AUD |
Verify the current mandatory elements with each authority before templating; e-invoicing mandates are being added in many of these jurisdictions.
Choosing a Tax Engine
- Build: only if you sell one product category in a few jurisdictions and can staff rate maintenance.
- Engine (Avalara, Vertex, TaxJar, Stripe Tax, Anrok, Quaderno, and others): rate and rule maintenance, address validation, returns preparation. Check coverage for your product categories and jurisdictions, evidence handling, invoice generation, and how registrations are configured and dated.
- Merchant of record (Paddle, Lemon Squeezy, FastSpring, and others): the MoR is the seller for tax purposes and handles registrations, at the cost of margin and less control over checkout and reconciliation.
Checklist
- Product tax categories assigned to every SKU and reviewed by a tax adviser.
- Evidence capture at checkout, stored immutably, with a precedence rule for conflicts.
- Business identifier validation with stored proof, and B2C fallback on failure.
- Registration register with effective dates feeding the engine's configuration.
- Tax lines stored per rate and jurisdiction; invoices and credit notes numbered sequentially and never edited.
- Threshold monitoring by jurisdiction with a quarter of lead time.
- Returns reconciled to settlement totals before filing; records retained for each regime's period.
- Marketplace: deemed-supplier analysis documented per market; seller data collected for DAC7-style reporting.
Common Mistakes
- Charging your home-country VAT to all foreign consumers.
- Accepting a self-declared "I am a business" checkbox without validating the number.
- Storing only the resolved country and not the evidence, then failing an audit query years later.
- Editing an issued invoice after a refund instead of issuing a credit note.
- Assuming an EU threshold protects a non-EU seller; it does not.
- Treating marketplace sales as the seller's problem in jurisdictions with deemed-supplier rules.
- Rounding tax per invoice in one system and per line in another, so the return and the ledger disagree.
- Hard-coding rates; loading rates without effective dates.
Limits and When Not to Use This
This skill describes mechanisms and system design; it is not tax advice. Thresholds, rates, definitions of digital services, evidence rules and platform liability change frequently and differ by jurisdiction. Before registering, charging or filing, verify the current rules with the authority named for each regime (for the EU, the member state tax authority and the Commission's OSS guidance; HMRC; the ATO; Inland Revenue; IRAS; CBIC; the NTA; CRA; state departments of revenue) and engage a qualified tax adviser or accountant with cross-border indirect tax experience. Permanent establishment, income tax, withholding tax, customs and transfer pricing are out of scope entirely.
Install this skill directly: skilldb add international-payments-skills
Related Skills
Currency and FX Handling
Activate this skill when the user is building multi-currency pricing or handling foreign exchange in international payments: choosing presentment versus settlement currency, understanding FX exposure and basic hedging, rounding minor units correctly for currencies like JPY, KWD and BHD, displaying amounts per locale, and storing money without floating-point loss. Triggers on "multi-currency," "presentment currency," "settlement currency," "FX markup," "exchange rate," "zero-decimal currency," "minor units," "rounding," "money type," "DCC," "hedging," "FX exposure," or "how should I store money in the database."
Fraud and Authentication by Market
Triggers when the user is designing authentication and fraud controls for international payments across local payment methods: Strong Customer Authentication and 3-D Secure in the EU and UK, OTP and additional-factor norms in India for cards and UPI, risk rules per rail, chargeback exposure by method including SEPA Direct Debit and iDEAL, and velocity and device signals. Keywords: "SCA," "PSD2," "3DS2," "3-D Secure," "frictionless," "challenge," "TRA exemption," "soft decline," "OTP," "RBI AFA," "UPI PIN," "chargeback," "friendly fraud," "card testing," "velocity rules," "device fingerprint," "liability shift," "VAMP," "APP fraud."
Local Payment Rails Overview
Activate this skill when the user is choosing or explaining local payment methods for international payments and needs a map of the rails: cards, bank transfers, wallets, cash vouchers and QR schemes, and how each one settles, refunds and reconciles. Triggers on "local payment methods," "international payments," "PayNow," "iDEAL," "UPI," "SEPA," "Pix," "Bizum," "Alipay," "WeChat Pay," "Konbini," "which payment methods for Singapore/Netherlands/India/Brazil/Japan," "settlement time," "push vs pull payment," "refund on bank transfer," or "payment method coverage." Covers rail families, market-by-market defaults, settlement and refund behaviour, and how to choose a method mix by product and market.
Payment Reconciliation
Activate this skill when the user must match PSP payouts, bank statements and scheme reports to orders for international payments: fee lines, refunds, chargebacks, FX differences, timing gaps, building a double-entry ledger, running exception queues and closing the month. Triggers on "reconciliation," "settlement report," "payout reconciliation," "three-way match," "camt.053," "unmatched transactions," "ledger," "exception queue," "month-end close," "chargeback accounting," "SEPA returns," "UPI settlement file," or "why doesn't the payout equal the orders."
PayNow, iDEAL, UPI and SEPA Side by Side
Triggers when the user is integrating or comparing PayNow, iDEAL, UPI and SEPA as local payment methods and needs the flows, identifiers, settlement times, refund paths, reconciliation artefacts, fee shapes and failure modes laid out side by side, plus what a checkout needs for each. Trigger keywords: "PayNow QR," "SGQR," "FAST transfer," "iDEAL redirect," "iDEAL transaction ID," "UPI intent," "VPA," "RRN," "UPI AutoPay," "SEPA Credit Transfer," "SCT Inst," "SEPA Direct Debit," "mandate," "R-transaction," "camt.053," "what does my checkout need for UPI/iDEAL," or "international payments for Singapore, the Netherlands, India and the euro area."
Payouts and Mass Payments
Activate this skill when the user is paying sellers, creators, drivers or suppliers in other countries and needs to design international payments out: KYC/KYB onboarding, choosing payout rails such as SEPA, UPI, PayNow, Pix, ACH and SWIFT, timing and cut-offs, paying in local currency versus a hub currency, fee handling, tax forms and platform reporting, and failure handling for returned or misdirected payouts. Keywords: "payouts," "mass payments," "seller payouts," "creator payments," "disbursements," "KYB," "beneficiary verification," "SWIFT OUR/SHA," "correspondent fees," "W-8BEN," "DAC7," "1099-K," "return codes," "payout failure," "negative balance."