Home/Research library/Compliance Slows Launches

Guide · Tax and invoicing

Tax Requirements for International E-Commerce

Tax Requirements for International E-Commerce: What Merchants Need to Check Before Entering a New Market Adding another country to an ecommerce checkout can take days. Determining whether the business is actually ready to sell there can take considerably more work. The payment ma

Source-imported researchEditorial verification pending

Research draft awaiting independent review. This material was adapted from an existing research library. Provider-specific promotions have been excluded automatically; facts, regulatory requirements, and conclusions must be verified before the page is indexed publicly.

Tax Requirements for International E-Commerce: What Merchants Need to Check Before Entering a New Market

Adding another country to an ecommerce checkout can take days.

Determining whether the business is actually ready to sell there can take considerably more work.

The payment may authorize successfully while the merchant still has unanswered questions about whether tax should be collected, whether registration is required, which legal entity should issue the invoice, whether an electronic-invoicing mandate applies, what transaction records must be retained, or whether a marketplace or Merchant of Record changes who is responsible.

That is the central problem with tax requirements for international ecommerce:

Payment capability is not the same as tax readiness.

International ecommerce tax should therefore be treated as a market-entry dependency map, not a tax-rate lookup exercise.

Before opening a country at checkout, a merchant should know who is selling, what is being sold, who is buying, where the relevant parties are located, which tax regimes may apply, who has responsibility under the chosen commercial model, and what operational work follows from that conclusion.

Why payment readiness is not tax readiness

A payment service provider can tell a merchant that it supports cards or a local payment method in a country.

That answers an important payments question:

Can money move?

It does not necessarily answer:

Is the sale subject to VAT, GST, sales tax, or another transaction tax?

Does the merchant need a tax registration?

Does the customer's location determine the tax treatment?

Is the customer a business or a consumer?

Does a valid tax ID change the treatment?

Does the classification of the product change the applicable rule?

Is the marketplace treated as the supplier for a particular tax?

Does the merchant have to issue an invoice?

Is a structured electronic invoice required?

Does the merchant need to report transactions periodically?

Could local employees, inventory, offices, or other activity create corporate-tax exposure?

Does using a Merchant of Record shift any of these responsibilities?

The payment flow and tax flow interact, but they are not identical.

Payment flow

Customer → PSP/acquirer → merchant, marketplace, or Merchant of Record → settlement

Tax flow

Tax treatment determined → tax calculated → collected where required → invoiced/recorded → reported → remitted

A PSP successfully settling $100 to a merchant does not, by itself, determine whether the transaction should have included VAT, whether sales tax was due, whether the customer should have been treated as B2B rather than B2C, or which party needs to report the transaction.

That analysis begins with the transaction itself.

The seven questions behind cross-border ecommerce tax

A useful framework for international expansion is the Cross-Border Tax Question.

For each market, answer seven questions before deciding the tax operation is ready.

Who is selling?

Start with the legal seller.

Identify:

the contracting legal entity;

the entity named in the customer terms;

the entity issuing the invoice;

whether a marketplace is involved;

whether another party acts as Merchant of Record; and

which entity ultimately recognizes the sale.

Do not assume the entity receiving settlement from the PSP is necessarily the entity responsible for every tax obligation.

International businesses commonly operate several legal entities, payment accounts, acquiring relationships, and invoicing systems. Tax analysis needs to follow the relevant legal transaction rather than simply the bank account receiving funds.

What is being sold?

Product classification can change the tax result.

An ecommerce transaction might involve:

physical goods;

SaaS;

downloadable software;

streaming;

games or digital content;

subscriptions;

electronically supplied services;

professional services;

education;

marketplace services; or

combinations of several products.

The merchant's commercial name for the product does not necessarily determine its tax classification.

A “subscription,” for example, tells the tax team how the customer pays over time. It does not necessarily tell them whether the underlying supply is software, digital content, a professional service, a physical product, or something else.

Who is buying?

The distinction between a consumer and a business can materially affect tax treatment.

A tax-registered business may receive different VAT/GST treatment from an individual consumer.

In EU cross-border VAT, for example, supplies of services to businesses are generally treated differently from B2C supplies, and reverse-charge treatment can apply in appropriate circumstances. For telecommunications, broadcasting, and electronic services supplied to consumers, customer location plays a central role in determining where VAT is due.

A merchant therefore may need more than a company name typed into the checkout.

Depending on the jurisdiction, determining B2B treatment can involve validating a tax registration number or satisfying other rules concerning customer status.

Where are the relevant parties?

“Which country is this transaction in?” can have several answers.

Potentially relevant locations include:

merchant establishment;

customer residence;

business customer's establishment;

billing address;

delivery destination;

place of consumption;

inventory or warehouse location;

local employee or office;

marketplace entity; and

fixed or permanent establishment.

Different taxes can use different location concepts.

For EU B2C electronically supplied services, for example, the place of taxation generally follows where the customer belongs, subject to applicable rules and exceptions. Physical ecommerce goods can instead raise questions around where goods are delivered, dispatched, imported, or stored.

That is why customer country cannot simply be inferred from one payment field and reused for every tax decision.

Which tax regime may apply?

There is no single “international ecommerce tax.”

Possible regimes include:

VAT;

GST;

sales tax;

digital services taxes;

withholding taxes;

customs and import taxes for goods;

corporate income tax; and

other local transaction or sector taxes.

Each asks a different question.

Who is responsible?

Depending on the transaction and jurisdiction, responsibility might sit with:

the underlying merchant;

a marketplace;

a deemed supplier;

a Merchant of Record;

the customer under a reverse-charge mechanism;

the payer under a withholding rule; or

another entity specified by local law.

Responsibility has to be evaluated obligation by obligation.

What operational obligation follows?

A tax conclusion needs to become an operating process.

Possible actions include:

If the tax team concludes that VAT applies but the checkout cannot calculate it, the business is not launch ready.

If registration is complete but the ERP cannot issue the legally required invoice, the business may still not be launch ready.

The tax analysis is only complete when its operational dependency is understood.

Seller and customer location can change the tax answer

Customer location has become especially important as ecommerce allows businesses to sell into markets where they have no traditional physical presence.

The EU VAT ecommerce framework illustrates this clearly.

For qualifying cross-border B2C ecommerce, the EU's One Stop Shop allows sellers to register through one Member State and declare VAT covered by the relevant scheme across Member States of consumption, reducing the need for separate registrations for those covered supplies in each destination country. The schemes can apply to both EU and non-EU businesses depending on the transaction type.

The system also illustrates why merchant and customer location have to be considered together.

The rules differ depending on factors such as:

whether the supplier is established in the EU;

whether the customer is a consumer;

whether goods or services are supplied;

where goods are dispatched;

where the customer belongs; and

whether a marketplace is treated as a deemed supplier.

This is more sophisticated than:

“Customer in France = charge French tax.”

The correct sequence is:

Identify supply → identify parties → identify relevant locations → determine applicable rule → calculate tax

[Internal link opportunity: VAT for Digital Businesses]

Physical goods and digital services can create different tax dependencies

A merchant shipping shoes and a merchant selling cloud software may both accept a card payment from the same customer.

Their tax questions can be very different.

Physical ecommerce

Physical goods can introduce issues involving:

delivery destination;

inventory location;

warehouses;

import VAT;

customs;

distance-selling rules;

marketplace import rules; and

responsibility for importation.

Digital ecommerce

Digital products and services can instead involve questions such as:

whether the supply qualifies as an electronic or digital service;

where the customer is considered located;

whether the buyer is a business or consumer;

remote-seller registration;

customer tax ID validation;

evidence supporting the customer's location; and

digital invoicing requirements.

The distinction is visible in current EU rules: electronically supplied B2C services can be taxed based on where the customer belongs, while goods have separate destination, dispatch, and import rules.

The practical consequence is that merchants should not reuse a tax configuration built for physical ecommerce when launching a SaaS product—or assume that a digital-product tax setup will work for physical goods.

The main international ecommerce tax categories

The tax name matters because different taxes create different responsibilities.

Tax area

What it generally addresses

Typical merchant question

VAT

Consumption/supply through a value-added-tax system

Where is the supply taxed, and who accounts for VAT?

GST

Consumption tax used in multiple national systems

Does this country's GST apply to our supply and customer?

Sales tax

Retail sales/use taxation, particularly relevant at U.S. state/local level

Do we have nexus and a collection obligation in this state?

Digital Services Tax

Certain taxes on revenues from specified digital activities

Is our digital business model within the local DST's scope?

Withholding tax

Tax retained from particular payments and remitted by the payer

Must part of this cross-border payment be withheld?

Corporate income tax / PE

Taxation of business profits and local taxable presence

Have our local activities created corporate-tax exposure?

Import/customs taxes

Movement of physical goods across borders

Who imports the goods and pays duties/import taxes?

VAT and GST are not interchangeable global systems

VAT and GST often share structural characteristics as consumption taxes, but there is no universal VAT/GST rule.

Registration thresholds, place-of-supply rules, B2B treatment, marketplace rules, invoicing, rates, filing, and nonresident-seller requirements can differ materially by jurisdiction.

That is why detailed treatment belongs in VAT for Digital Businesses and GST for International Merchants, rather than attempting to create one international rule here.

U.S. sales tax uses a different model

The United States does not have one national VAT-style sales tax.

Sales and use taxes are primarily state and local systems.

The U.S. Supreme Court's 2018 South Dakota v. Wayfair decision eliminated the previous constitutional rule that generally required physical presence before a state could impose sales-tax collection obligations on a remote seller. Economic activity can therefore create nexus under state law even without a traditional store or office.

The exact economic-nexus thresholds, product taxability rules, exemptions, marketplace provisions, and filing requirements are state-specific and should be verified independently.

[Internal link opportunity: Sales Tax for Online Merchants]

Digital Services Tax is not VAT on digital services

This terminology creates considerable confusion.

A Digital Services Tax (DST) is typically a distinct tax targeted at defined digital-business revenues or activities under a jurisdiction's specific legislation.

It is not the same thing as VAT or GST imposed on a digital subscription.

The OECD's 2026 commentary describes digital services taxes as generally designed around gross revenues from particular digital services and generally operating in addition to ordinary income taxes rather than as consumption taxes such as VAT.

Whether a particular DST currently applies, its scope, thresholds, rate, and interaction with international tax developments must be verified by jurisdiction.

[Internal link opportunity: Digital Services Taxes]

Withholding tax follows the payment category and applicable rules

Certain cross-border payments can be subject to withholding, meaning the payer retains part of the payment and remits it to a tax authority.

But international payment does not automatically mean withholding tax.

Treatment can depend on:

payer jurisdiction;

recipient jurisdiction;

nature of the payment;

domestic law;

applicable tax treaty;

documentation; and

other eligibility conditions.

A PSP deduction, payment-processing fee, reserve, or FX charge should not be confused with tax withholding.

[Internal link opportunity: Withholding Tax on Cross-Border Payments]

Registration, collection, and reporting are three separate questions

“Do we have to register?” is not synonymous with “is the transaction taxable?”

A merchant should separate at least four decisions:

Is the supply within the tax regime?

Determine whether the particular transaction is covered.

Does the merchant have a registration obligation?

This can depend on establishment, customer type, supply type, thresholds, marketplace involvement, inventory, or other jurisdiction-specific factors.

Who has to collect or account for the tax?

The answer may be the merchant—or another party under the applicable rules.

What reporting and remittance follow?

Registration can create periodic filing, payment, invoicing, and record-retention obligations.

Simplified frameworks can sometimes reduce registrations without removing the underlying tax.

The EU One Stop Shop demonstrates the distinction. Qualifying sellers can use one registration to declare and pay VAT for supplies covered by the scheme across multiple Member States, rather than requiring a separate registration for each covered destination.

That is a compliance simplification, not a tax exemption.

[Internal link opportunity: Tax Registration by Country]

Invoicing can become a technical launch dependency

Merchants sometimes treat invoicing as something finance can configure after payments launch.

That is becoming increasingly risky in markets where invoicing is technically integrated with government systems.

Tax invoices may require specified information such as:

seller tax identifiers;

buyer information;

invoice numbers;

supply dates;

tax rates and amounts;

particular currencies or formats;

credit-note references; and

structured electronic fields.

And e-invoicing does not simply mean emailing a PDF.

Some jurisdictions require structured invoice formats, government reporting, clearance, or direct system integrations.

Saudi Arabia provides a current example. ZATCA's Phase Two e-invoicing framework is being rolled out in waves and requires covered taxpayers to integrate their invoicing solutions with the Fatoora platform, issue invoices in prescribed formats, and include required fields. As of July 2026, ZATCA was continuing to announce additional taxpayer waves for integration.

For a merchant, that can turn a tax requirement into work for:

billing engineering;

ERP;

checkout;

customer-data collection;

invoice generation;

tax calculation;

accounting;

reporting; and

archiving.

The real launch question becomes:

Can our systems produce the transaction record the tax regime requires?

[Internal link opportunity: E-Invoicing Requirements]

Marketplaces can change who collects the tax

Marketplace tax rules can move specific transaction-level obligations away from the underlying seller.

But this should never be generalized into:

“If we sell through a marketplace, the marketplace handles tax.”

The EU ecommerce VAT framework, for example, treats certain electronic interfaces as deemed suppliers for specified transactions. In those cases, the marketplace can be treated as though it received and supplied the goods itself for VAT purposes. The rule applies only within defined circumstances.

Other jurisdictions—including U.S. states—have their own marketplace-facilitator regimes.

A seller therefore needs to identify:

whether the platform legally qualifies under the relevant marketplace rule;

which transactions the rule covers;

whether the platform collects and remits the tax;

whether seller registration or reporting obligations remain; and

what happens to sales made outside that marketplace.

Marketplace responsibility is statutory and jurisdiction-specific.

[Internal link opportunity: Marketplace Facilitator Rules]

Merchant of Record can change responsibility—but it does not mean “no tax”

Merchant of Record is a different concept from marketplace-facilitator status.

A Merchant of Record arrangement can place another entity in the customer-facing sale and may allocate functions such as:

contracting with the customer;

accepting payment;

determining certain transaction taxes;

collecting those taxes;

issuing customer invoices;

handling refunds; and

filing or remitting specified taxes.

But those responsibilities depend on the actual contract, transaction structure, service offered, and jurisdiction.

A merchant should not infer tax treatment from the phrase “Merchant of Record” alone.

And even where an MoR assumes transaction-level VAT, GST, sales-tax, or invoicing responsibilities, the underlying merchant may still have separate questions involving:

corporate income tax;

permanent establishment;

payroll;

local business registration;

transfer pricing;

accounting;

payments received from the MoR; and

other jurisdiction-specific obligations.

The useful principle is:

Tax responsibility must be mapped obligation by obligation.

[Internal link opportunity: Merchant of Record and Tax Responsibility]

Permanent establishment is separate from ecommerce transaction tax

A merchant can solve its VAT or sales-tax collection model without resolving its corporate-tax exposure.

Permanent establishment (PE) broadly concerns whether a company's activities in another jurisdiction create sufficient taxable presence for that jurisdiction to tax relevant business profits.

The OECD Model Tax Convention's Article 5 uses a fixed place of business through which the business is wholly or partly carried on as the central PE concept, while also addressing additional circumstances in the broader article and commentary. Actual PE treatment depends on domestic law, the applicable treaty, and the facts.

Potentially relevant business activity can include matters such as:

offices;

branches;

personnel;

dependent agents;

contracting activity;

warehouses in particular circumstances;

service activity; and

duration and nature of local operations.

Merely selling something to a customer does not create one universal PE result.

More importantly:

PE ≠ VAT registration.

PE ≠ sales-tax nexus.

A merchant can potentially face an indirect-tax registration question without having a PE, and vice versa.

[Internal link opportunity: Permanent Establishment Risk]

Payment data can support tax determination—but cannot replace it

The payments stack already knows useful things about a transaction.

It may contain:

amount;

currency;

billing information;

card or bank country;

merchant entity;

transaction date;

payment method; and

PSP/acquirer information.

That data can support tax operations.

But payment data alone may not establish:

what the product legally is;

whether the customer is B2B or B2C;

whether a tax number is valid;

place of supply;

delivery location;

which entity is the legal seller;

whether a marketplace rule applies;

whether a tax exemption applies;

whether corporate PE exists; or

who is responsible for filing.

That is why tax determination needs to connect the product catalog, customer data, legal-entity structure, checkout, payments, billing, and finance systems.

Tax cannot be bolted onto the settlement file after the sale.

The Tax Responsibility Map

A merchant preparing for international expansion should assign each obligation before launch.

Obligation

Question to resolve

Product classification

What exactly are we selling under the relevant tax rules?

Customer classification

Consumer, business, tax-registered business, or another category?

Customer location

What location legally matters and what evidence supports it?

Tax determination

Which tax regime applies to this supply?

Tax calculation

What taxable amount and rate apply?

Registration

Which entity must register, if any?

Collection

Who collects or accounts for the tax?

Invoice issuance

Which party issues the invoice and under what rules?

Filing

Who files the relevant return?

Remittance

Who pays collected/accounted tax to the authority?

Payment reporting

Does a separate reporting entity have information-reporting obligations?

Corporate income tax

Does local business activity create taxable corporate exposure?

Permanent establishment

Has the merchant created sufficient taxable presence?

Record retention

Which parties must retain which evidence?

The responsible party cannot be filled in universally.

That is exactly why the map should exist before launch.

International Tax Launch Readiness

A merchant planning a new country can turn the tax analysis into a launch-readiness process.

Market

Target country is confirmed.

Selling legal entity is identified.

Customer type is understood.

Product or service has been classified.

Tax

Relevant transaction taxes have been identified.

Direct-tax/PE questions have been considered separately.

Registration triggers have been evaluated.

Tax determination and calculation logic have been defined.

Responsibility

Seller is confirmed.

Marketplace responsibilities have been checked where applicable.

Merchant of Record responsibilities have been confirmed contractually where applicable.

Responsibilities remaining with the underlying merchant are documented.

Checkout

Required customer-location information is captured.

B2B/B2C logic is supported where necessary.

Tax IDs can be collected or validated where relevant.

Tax-inclusive or tax-exclusive pricing has been reviewed for the market.

Refund logic accounts for the associated tax treatment.

Invoicing

Invoice requirements have been identified.

E-invoicing applicability has been checked.

Billing systems can generate required information.

Credit-note/refund processes are defined.

Reporting

Filing responsibility is assigned.

Payment-related information reporting has been evaluated separately.

Required records and retention policies are documented.

Reconciliation between payments, taxes, invoices, and returns is possible.

Operations

Finance owns the ongoing compliance process.

Product and engineering know which tax requirements affect their systems.

Payment operations understand the transaction and entity model.

Required registrations are complete before the relevant launch dependency.

Specialist tax/legal review has addressed material unresolved questions.

A useful management metric is not simply “countries where our PSP is live.”

Track:

Markets payment-ready

versus

Markets tax-ready

versus

Markets production-ready

Those are not always the same list.

What merchants should resolve before launch

The most effective international ecommerce tax strategy begins before tax is calculated.

For each new market, determine:

Who is selling?

What is being sold?

Who is buying?

Where are they?

Which tax regime applies?

Who is responsible?

What does the business have to build or operate as a result?

Only then move into rates, registrations, tax engines, invoice formats, or filing calendars.

This ordering matters because tax errors are often architecture errors.

A customer-location rule can require checkout changes.

A registration can require an identifier before compliant invoicing can begin.

Marketplace rules can change which entity collects tax.

An e-invoicing mandate can require ERP or government-platform integration.

A Merchant of Record can change transaction-level responsibility without eliminating the merchant's broader corporate-tax questions.

And local operational activity can create a permanent-establishment question completely separate from whether VAT or sales tax has been collected correctly.

International ecommerce tax is therefore not an accounting task that begins after the first settlement.

It is part of market-entry architecture.

A payment provider may make the country technically reachable. Tax readiness determines whether the business has answered the operational questions created by making the sale.

This article provides general information and does not constitute tax, legal, accounting, financial, or regulatory advice. Tax treatment depends on the merchant's circumstances, transaction structure, product or service, customer type, and applicable jurisdictions. Merchants should confirm their obligations with qualified tax and legal advisers and the relevant tax authorities.

FAQ

Do international ecommerce businesses have to collect tax in every country they sell to?

No universal rule applies. Collection obligations depend on the jurisdiction, product or service, customer type, seller location, registration rules, applicable thresholds, marketplace structure, and other factors. A merchant should evaluate each market rather than assume either that every foreign sale creates registration or that small international sales are automatically outside the tax system.

What is the difference between VAT, GST, and sales tax?

VAT and GST are generally consumption-tax systems that can apply through multiple stages of a supply chain, although their rules differ by country. U.S. sales tax is primarily a state/local retail-sales system with separate nexus and product-taxability rules. Merchants should not apply one framework's logic to another.

Does selling digital products create different tax obligations from physical ecommerce?

It can. Digital services can have customer-location and remote-seller rules that differ from physical goods. Physical ecommerce can introduce import VAT, customs, delivery-location, inventory, and warehousing considerations. The product needs to be classified before the tax rule is selected.

Does using a marketplace mean the merchant no longer has tax obligations?

Not necessarily. Some jurisdictions shift specified collection obligations to qualifying marketplaces, but sellers can retain registration, reporting, income-tax, recordkeeping, or off-platform obligations. The marketplace rule has to be assessed for the specific jurisdiction and transaction.

Does a Merchant of Record handle international ecommerce tax?

A Merchant of Record may assume defined customer-facing and transaction-tax responsibilities under its contract and applicable law, potentially including tax calculation, collection, invoicing, and remittance. The scope varies by provider and jurisdiction, and the underlying merchant can retain corporate, PE, accounting, or other tax obligations.

Can a PSP determine whether a merchant is tax compliant in a market?

Payment availability alone does not establish tax readiness. A PSP may provide useful transaction information or payment infrastructure, but tax treatment can depend on product classification, customer type, legal seller, marketplace relationships, business presence, and other facts outside the payment transaction.

🙂 🙂 🙂 🙂 🙂 🙂 🙂

Tax Requirements for International E-Commerce: 2026 Market-Entry Guide

Meta title

International Ecommerce Tax Requirements | Global Merchant Guide

Meta description

Learn which tax requirements international ecommerce merchants should evaluate before entering a market, including VAT, GST, sales tax, registration, invoicing, marketplaces, withholding and permanent establishment.

Suggested URL slug

/tax-requirements-international-ecommerce/

Payment capability → Tax readiness → Production-ready market

This is more useful than a country tax-rate map because readers can apply it to every future market.

Secondary visual: Payment Flow vs Tax Flow

PAYMENT FLOW

Customer

↓

PSP / Acquirer

↓

Merchant / Marketplace / MoR

↓

Settlement

TAX FLOW

Transaction classified

↓

Jurisdiction determined

↓

Tax calculated

↓

Tax collected/accounted for

↓

Invoice / record created

↓

Return/report filed

↓

Tax remitted

Center caption:

The payment flow can succeed while the tax flow is incomplete.

Third visual: International Tax Launch Critical Path

Market selected

→ Transaction model defined

→ Tax treatment assessed

→ Registration assessed

→ Registration completed where required

→ Checkout configured

→ Invoicing/e-invoicing configured

→ Reporting/reconciliation configured

→ Launch

Put potential blockers underneath:

Registration · Tax ID · customer-location logic · tax engine · invoice integration · government platform · specialist review

Fourth visual: Tax Responsibility Map

Create a matrix with rows for:

Classification · Location · Calculation · Collection · Invoice · Filing · Remittance · Reporting · PE

and columns:

Merchant · Marketplace · Merchant of Record · Customer/Payer · Other

Do not pre-fill it universally. Use checkmarks labelled “depends on market/model” to communicate that responsibility must be mapped per jurisdiction.

Recommended visual alt text

Primary asset:

“Seven-step cross-border ecommerce tax decision framework showing seller, product, customer, location, tax regime, responsible party, and operational obligation.”

Payment vs tax flow:

“Comparison of ecommerce payment flow and tax flow showing that successful payment processing does not automatically establish tax readiness.”

Launch critical path:

“International ecommerce tax launch process from market selection and tax assessment through registration, checkout configuration, invoicing, reporting, and production launch.”

Sources / research references

European Commission VAT One Stop Shop guidance, including current eligibility, registration, reporting, and deemed-supplier framework.

European Commission / Your Europe current guidance on cross-border VAT, B2B/B2C treatment, and electronically supplied services.

U.S. Supreme Court, South Dakota v. Wayfair, and Congressional Research Service background on remote-seller sales-tax nexus.

OECD Model Tax Convention material on permanent establishment and the 2025 Article 5 commentary update.

OECD 2026 commentary distinguishing digital services taxes from consumption taxes such as VAT.

Saudi ZATCA current e-invoicing guidance and July 2026 Phase Two wave update.

Claims requiring tax/legal review

A qualified tax reviewer should confirm the final wording around:

the application of VAT/GST to the publication's priority merchant models;

the distinction between marketplace facilitator/deemed-supplier and Merchant of Record structures;

PE examples and any later country-specific additions;

withholding-tax terminology;

customer-location and B2B validation requirements if the article is expanded with specific jurisdictions;

any future rates, thresholds, registration triggers, or tax-treatment examples.

Date-sensitive claims to re-verify before publication

Recheck the EU VAT OSS framework and ViDA transition if publication occurs after January 1, 2027; the European Commission published revised guidance in July 2026 for ViDA changes beginning in 2027.

Also recheck Saudi e-invoicing wave criteria, any U.S. state economic-nexus thresholds, and the current status of individual Digital Services Taxes before adding specific figures or country claims.

Need help narrowing down payment options?

Answer a few questions about your business and compare the capabilities that matter to you.

Explore matching options ↗