Merchant of Record and Tax Responsibility
Merchant of Record and Tax Responsibility: What the MoR Handles—and What Can Still Remain with the Merchant “Our Merchant of Record handles global tax.” That sentence sounds reassuring. Operationally, it is almost useless. Which tax? For which transactions? In which countries? Wh
Merchant of Record and Tax Responsibility: What the MoR Handles—and What Can Still Remain with the Merchant
“Our Merchant of Record handles global tax.”
That sentence sounds reassuring. Operationally, it is almost useless.
Which tax?
For which transactions?
In which countries?
Who determines whether VAT, GST, or sales tax applies?
Who calculates it?
Who displays it at checkout?
Who collects it from the customer?
Who issues the invoice?
Who files the return?
Who remits the tax?
Who adjusts the tax after a refund?
Who retains the records?
And what happens to corporate income tax, permanent establishment, payroll, withholding, transfer pricing, or other obligations that exist outside the customer transaction?
Those questions are the real substance of Merchant of Record tax responsibility.
Merchant of Record should be evaluated as a responsibility-allocation model, not as a binary “tax handled / tax not handled” feature.
A well-structured Merchant of Record arrangement can centralize significant transaction-level obligations for international sales. Depending on the contract, jurisdiction, supply, and customer type, the MoR may become the customer-facing seller and assume responsibilities involving payment acceptance, indirect-tax determination, tax collection, invoicing, filing, remittance, refunds, and transaction records.
But those responsibilities should never be inferred from the words Merchant of Record alone.
The merchant needs to ask:
Which tax? Which transaction? Which country? Which responsibility?
That is the framework this article applies.
What is a Merchant of Record?
A Merchant of Record, or MoR, is an entity that takes the customer-facing merchant role for defined transactions under a particular commercial and legal structure.
A simplified arrangement can look like:
CUSTOMER
↓
MERCHANT OF RECORD
↓
UNDERLYING PRODUCT / SERVICE PROVIDER
The MoR may:
Contract with the customer
Accept payment
Appear on the payment record
Determine applicable transaction taxes
Collect those taxes
Issue customer invoices or receipts
Process refunds
Handle payment disputes
File and remit specified taxes
The underlying business continues to provide the product or service according to the commercial agreement.
That is materially different from a conventional payment-processing model:
CUSTOMER
↓
MERCHANT / SELLER
↓
PSP / ACQUIRER
In the second structure, the PSP moves or facilitates the payment while the merchant generally remains the seller.
The entity receiving or processing payment is therefore not automatically the legal seller for tax purposes.
Why “the MoR handles tax” is too vague
The word handles can conceal several independent obligations.
Consider a digital subscription sold into another country.
The complete tax workflow might be:
SUPPLY CLASSIFIED
↓
CUSTOMER LOCATION DETERMINED
↓
TAX REGIME IDENTIFIED
↓
TAX LIABILITY DETERMINED
↓
TAX CALCULATED
↓
PRICE DISPLAYED
↓
TAX COLLECTED
↓
INVOICE / RECEIPT ISSUED
↓
TRANSACTION RECORDED
↓
RETURN FILED
↓
TAX REMITTED
The same entity does not necessarily own every step.
That remains true even when an MoR is involved.
A merchant evaluating a provider therefore should not accept:
“VAT included.”
or:
“We handle sales tax.”
as a complete operating answer.
Instead break the promise into specific responsibilities.
Who is the legal seller and who contracts with the customer?
This is the starting point.
The tax result often depends on who is legally making the supply.
Under the EU VAT framework, the basic rule is that VAT is generally payable by the taxable person making the taxable supply unless the rules make another person liable.
That makes the legal supply relationship fundamental.
For an MoR arrangement, verify:
Which legal entity is named in the customer terms
Which entity sells the product to the customer
Which entity appears on the invoice
Which entity accepts the payment
Which entity handles cancellation or refund rights
Which entity is treated as supplier under applicable tax law
Do not infer the seller merely from:
Checkout branding
Payment descriptor
PSP account
Settlement destination
Those can be operational facts without conclusively determining the tax role.
Who determines whether tax applies?
Tax determination comes before tax calculation.
It asks:
What is being sold?
Where is the supply treated as taking place?
Is the customer a consumer or business?
Is the customer tax registered?
Is the supply taxable?
Does an exemption apply?
Which party is responsible?
For example, an online software business may sell:
SaaS
Downloads
Professional services
Digital content
Physical goods
Those categories can receive different treatment.
A tax engine cannot correctly calculate tax if the underlying product and transaction have been classified incorrectly.
An MoR can perform determination for the transactions within its contractual and legal scope.
But the merchant may still need to provide accurate data about:
Product type
Customer
Business model
Refund
Delivery or consumption
Seller entity
The provider's tax function is not independent of merchant-supplied facts.
Who calculates VAT, GST, or sales tax?
Once tax treatment has been determined, someone must calculate the amount.
That means identifying:
taxable amount
×
applicable rate
=
tax amount
For an MoR transaction, the MoR may operate or integrate the tax-calculation layer.
But merchants should verify:
Which countries are supported
Which taxes are supported
Which products are supported
Whether B2B and B2C transactions are handled differently
How customer tax IDs are validated where relevant
How exemptions are handled
How product classification is maintained
How future rate changes are implemented
“Global VAT support” is not a sufficient specification.
Who controls checkout tax display?
The tax result also affects customer experience.
Depending on the jurisdiction and transaction, checkout may need to support:
Tax-inclusive price
Tax-exclusive price
Tax line item
Customer tax identification
Business/consumer status
Exemption information
Invoice information
If the MoR determines and collects the tax but the merchant controls the checkout UI, the technical responsibility can still be shared.
For example:
MERCHANT CHECKOUT
↓
customer + product data
↓
MoR tax determination
↓
tax amount returned
↓
MERCHANT DISPLAYS TOTAL
↓
MoR ACCEPTS PAYMENT
The tax responsibility may sit with the MoR while implementation work still sits partly with the merchant.
This is one reason compliance can slow launches even when the tax liability itself has been outsourced.
Who collects the tax?
Collection is a distinct step.
Suppose a sale is priced at:
Product price 100
Tax 20
---------------------
Customer total 120
Illustrative only.
The MoR may collect the 120 from the customer and allocate the 20 to its tax obligation under the relevant transaction model.
But the merchant should verify:
Whether the MoR actually collects the tax
Whether the price remitted to the merchant is net or gross of tax
How tax appears in reports
Whether tax is separately identifiable
Whether merchant revenue reporting includes or excludes tax
What happens if the payment fails
What happens if the transaction is partially refunded
Tax collected should not disappear into a generic settlement deduction.
Who issues the invoice?
This is often under-specified in MoR proposals.
The question is not simply:
“Does the provider generate invoices?”
It is:
Whose invoice is it, under which country's rules, for which transactions?
EU VAT rules illustrate why this matters. VAT invoicing has a common EU framework but also national variation, and invoices can contain requirements such as sequential numbering, supplier and customer details, VAT identification numbers, supply description, transaction date, applicable VAT, and other transaction-specific information. EU rules also allow invoicing operations to be outsourced to third parties in certain circumstances.
That means the relevant questions in an MoR arrangement include:
Is the MoR legally the invoice issuer?
Does the invoice show the MoR or merchant as supplier?
Are B2B and B2C invoices treated differently?
Which VAT/GST/sales-tax identifiers appear?
Who generates credit notes?
Who stores invoices?
Who handles e-invoicing mandates?
Does the merchant receive a copy?
Can invoice data be exported?
An invoice should reflect the actual tax and supply model.
It should not merely reproduce the brand shown at checkout.
Internal link opportunity: E-Invoicing Requirements
Who files the tax return?
Collection does not equal filing.
An MoR can collect VAT, GST, or sales tax from the customer and also assume responsibility for filing relevant returns for the covered transactions.
But merchants should confirm:
Which legal entity files
Which tax registration is used
Which countries are included
Which transactions are included
Which returns are filed
Whether marketplace/direct transactions are excluded
What records the merchant receives
What happens after termination
A merchant should be able to connect:
customer transaction
↓
tax collected
↓
MoR tax report
↓
MoR return population
even if the merchant is not itself submitting that return.
Otherwise the merchant has delegated filing but lost visibility into the transaction-level tax result.
Who remits the tax?
Filing and remittance are separate responsibilities.
Filing means reporting the relevant transaction or tax position.
Remittance means transferring the amount due to the tax authority.
In a mature MoR arrangement, the same MoR entity may perform both for the taxes it owns.
But that should be verified.
Ask:
Who holds the collected tax?
Under whose tax registration is it remitted?
When is it treated as removed from merchant proceeds?
How is it shown in merchant reporting?
What happens after an amendment or correction?
What happens if a return is later adjusted?
Avoid a reporting model where the merchant sees only:
Gross sales: 10,000,000
MoR deductions: 2,170,000
Merchant proceeds: 7,830,000
with tax, processing, FX, refunds, and other deductions collapsed together.
Tax remittance should be separately explainable.
Who adjusts tax when a customer receives a refund?
A tax workflow does not end when the original sale succeeds.
A customer may later receive:
Full refund
Partial refund
Credit
Cancellation
Chargeback
The payment reversal and tax adjustment may interact, but they are not automatically identical.
A useful MoR workflow is:
ORIGINAL SALE
↓
tax recorded
↓
customer refund
↓
tax adjustment evaluated
↓
credit document / tax record
↓
return adjustment
↓
merchant report updated
The merchant should verify:
Who calculates the tax adjustment
Who issues the credit note where required
Who updates the return
How tax appears in the merchant ledger
How partial refunds are treated
How disputes/chargebacks differ from ordinary refunds
Do not assume the MoR's payment refund function automatically proves the correct tax adjustment occurred.
Who retains the records?
A merchant should know which records it continues to possess after outsourcing transaction-tax functions.
Potential records include:
Customer order
Customer location evidence
Product classification
VAT/GST/sales-tax calculation
Tax ID
Invoice
Refund
Credit note
MoR tax statement
Payment reference
Filed-period summary
Retention requirements vary by jurisdiction.
Do not invent one global retention period.
But from an operational perspective, the merchant should answer:
If we change MoR providers three years from now, can we still explain historical transactions?
Tax operations should not become permanently dependent on an inaccessible provider dashboard.
Who handles payment-related tax reporting?
Payment reporting and indirect-tax collection are separate topics.
A Merchant of Record may be responsible for a particular VAT/GST/sales-tax return while another law creates a separate information-reporting obligation for:
Payment processor
Platform
Merchant
Payee
Financial institution
Do not use:
“The MoR files taxes.”
to infer:
“All tax reporting is therefore handled.”
Internal link opportunity: Payment Tax Reporting
The merchant needs to map each reporting regime separately.
What can remain with the merchant?
This is the most important boundary in the article.
An MoR can centralize transaction-level tax administration without replacing the merchant's entire tax identity.
The following obligations can remain.
Corporate income tax
VAT, GST, and sales tax are generally indirect taxes associated with transactions or consumption.
Corporate income tax is different.
It asks whether and where the merchant company's profits are taxable.
An MoR collecting transaction tax does not, by itself, determine the merchant's corporate-income-tax position.
For example, the U.S. IRS separately evaluates whether a foreign corporation is engaged in a U.S. trade or business and whether it has effectively connected income, based on the company's activities and facts.
That analysis does not disappear merely because another entity processes customer payments or collects sales tax.
Permanent establishment
Permanent establishment, or PE, is a corporate-tax concept used in many tax treaties and domestic systems to determine whether a foreign enterprise has sufficient taxable presence in another jurisdiction.
The OECD Model Tax Convention framework generally associates PE with factors such as a fixed place of business and, in certain circumstances, dependent-agent activity.
Most importantly for this article, the OECD has explicitly noted that VAT/GST registration is analytically separate from permanent establishment for income-tax treaty purposes.
Therefore:
MoR VAT responsibility does not automatically eliminate PE risk.
The merchant's own:
Employees
Offices
Contracting activity
Agents
Warehousing
Local operations
may still create corporate-tax questions.
Internal link opportunity: Permanent Establishment Risk
Taxes on the commercial relationship between the merchant and the MoR
The customer transaction is only one side of the arrangement.
There is usually also a commercial relationship between:
MoR
↓
underlying merchant
Payments the MoR makes to the underlying company can have their own:
Accounting treatment
Revenue treatment
Withholding questions
Transfer-pricing considerations
Contractual characterization
depending on the countries and legal entities involved.
Do not assume:
Customer VAT handled by MoR
means:
No tax analysis remains on payments between MoR and merchant.
Those are different transactions.
Withholding tax
Cross-border payments between entities can potentially trigger withholding-tax questions depending on:
Country
Payment category
Domestic law
Treaty
Documentation
For example, the U.S. has separate withholding regimes for certain U.S.-source fixed or determinable income paid to foreign persons.
This should not be confused with:
PSP fees
MoR commissions
Sales tax
VAT
Settlement deductions
The dedicated Withholding Tax on Cross-Border Payments article should own that analysis.
Merchant's direct transactions
An MoR may cover:
Website A
Country group B
Product C
while the merchant still sells:
Enterprise contracts
Direct invoices
Marketplace channel
Physical products
Another website
Legacy subscriptions
outside the MoR.
Those transactions require their own tax model.
A merchant should therefore track:
sales_channel
MoR_or_direct
seller_entity
country
product
customer_type
tax_owner
A company can be:
MoR-covered for one transaction
and:
direct seller for the next.
Tax registrations that remain necessary
An MoR model can reduce the merchant's transaction-tax registration burden in some arrangements.
It should not be assumed to eliminate every registration.
A merchant may still require registrations because of:
Direct sales
Local inventory
Local entity
Employees
Separate B2B activities
Imports
Existing historical obligations
Another tax regime
Whether an existing VAT, GST, or sales-tax registration can be closed is a jurisdiction-specific tax question.
Do not cancel a registration merely because MoR traffic has gone live.
Payroll and employment taxes
If the merchant hires people in a market, an MoR used for customer sales does not generally transform those employment relationships.
Payroll, social contributions, employment taxes, and employer registrations are separate from transaction-tax collection.
This article does not own that topic, but the distinction is important:
Customer commerce architecture and employment tax architecture are separate.
Transfer pricing
A global group can have intercompany arrangements involving:
Intellectual property
Services
Distribution
Licensing
Local entities
A third-party MoR relationship does not automatically eliminate transfer-pricing obligations elsewhere in the business.
That analysis belongs with qualified international-tax advisers.
Product-specific or sector taxes
Some products can have special tax treatment.
Examples could include:
Telecommunications
Financial services
Gaming
Certain digital supplies
Physical goods subject to customs/import rules
The MoR's product coverage must therefore be verified.
“Supports this country” does not automatically mean:
“Supports every taxable product in this country.”
Legal seller vs payment receiver
This distinction deserves explicit treatment.
Consider:
Customer pays
↓
PSP
↓
MoR account
The PSP moved the money.
That does not make the PSP the seller.
Likewise:
Customer pays
↓
MoR
↓
underlying merchant
The fact that the MoR receives the customer payment does not by itself establish every tax consequence.
The commercial contract and applicable tax rules determine the seller/taxpayer relationship.
Payment flow is evidence.
It is not the entire tax analysis.
MoR vs PSP
Payment Service Provider
A PSP generally facilitates payment for the merchant.
Customer
↓
Merchant
↓
PSP
The merchant usually remains the legal seller.
The PSP can provide:
Payment acceptance
Tokenization
Acquiring connectivity
Payment methods
Fraud tools
Settlement reporting
but that does not generally make it responsible for the merchant's VAT, GST, or sales-tax position merely because it processes the payment.
Merchant of Record
An MoR goes further.
Customer
↓
MoR / customer-facing seller
↓
Underlying merchant
Depending on the structure, the MoR can assume transaction responsibilities such as:
Customer contracting
Tax determination
Tax collection
Invoicing
Filing
Remittance
The distinction is commercial and legal, not merely technical.
MoR vs payment processor
“Payment processor” is narrower still.
A processor can carry transaction messages or support authorization and settlement while having no seller relationship with the customer.
Therefore:
Processor = entity involved in processing payment
does not imply:
taxable supplier = processor.
This distinction helps prevent one of the most common tax/payment modeling errors:
assigning tax responsibility based on where the funds technically moved.
MoR vs marketplace facilitator
These two models are frequently confused.
They can overlap.
They are not the same concept.
Marketplace facilitator / deemed supplier
This generally refers to a statutory rule under which a qualifying platform is assigned tax responsibility for specified third-party marketplace transactions.
For example, EU VAT rules can make electronic interfaces the person treated as supplier in defined platform transactions, and the EU's ViDA program is expanding deemed-supplier rules in particular sectors on a phased timetable.
That responsibility arises from tax law.
Internal link opportunity: Marketplace Facilitator Rules
Merchant of Record
Merchant of Record is primarily a commercial/contractual operating model.
Its tax consequences depend on:
Contract
Legal seller relationship
Applicable tax law
Product
Customer
Jurisdiction
A marketplace facilitator could potentially also operate as an MoR in a particular arrangement.
But one label does not prove the other.
Contractual promise vs statutory responsibility
This is one of the most important distinctions for provider diligence.
Suppose an MoR contract says:
“Provider will calculate and remit applicable transaction taxes.”
That is a contractual obligation between merchant and provider.
Separately, the tax authority asks:
Which entity is legally the taxable supplier or person liable under our tax law?
Those answers should align.
But they are conceptually different.
A contract cannot simply override statutory tax law.
Likewise, a statute assigning liability does not automatically explain every commercial indemnity between merchant and MoR.
The merchant should review both:
CONTRACTUAL RESPONSIBILITY
+
STATUTORY RESPONSIBILITY
before treating the operating model as complete.
Invoicing deserves separate diligence
An MoR may say:
“We handle invoices.”
Ask what that means.
A usable invoice responsibility model should identify:
Legal invoice issuer
Seller name
Tax number
Customer information
Product description
Currency
Tax base
Tax rate
Tax amount
Invoice number
Issue date
Credit-note process
Storage
E-invoice requirements
The EU's current VAT framework, for example, contains detailed invoice requirements and permits third parties to issue invoices in certain situations, while Member State rules can still matter.
EU invoicing is also entering a substantial technical transition. The European Commission's current ViDA implementation plan says cross-border B2B digital reporting based on mandatory e-invoicing is scheduled from 1 July 2030, with broader alignment of domestic digital reporting systems by 2035.
This reinforces an important launch principle:
The correct tax liability is not enough if the merchant/MoR technology cannot create the required tax document.
Internal link opportunity: E-Invoicing Requirements
Payment flow vs tax flow in an MoR model
A Merchant of Record makes this distinction especially useful.
Payment flow
Customer
↓
PSP / acquirer
↓
MoR
↓
merchant proceeds
Tax flow
Transaction classified
↓
Tax determined
↓
Tax calculated
↓
Tax collected
↓
Tax recorded
↓
Return filed
↓
Tax remitted
The flows interact.
They are not identical.
A merchant needs visibility into both.
For example, settlement reporting should not force Finance to calculate tax with:
customer payment
-
merchant proceeds
=
tax
because the difference could also contain:
PSP cost
MoR fee
FX
Refunds
Reserves
Other adjustments
Tax needs a distinct data object.
The Merchant of Record Tax Responsibility Map
Before launch, build one responsibility map per relevant market and transaction model.
Responsibility
Potential MoR role
Potential merchant role
What must be verified
Legal seller / customer contracting
May contract as seller
Merchant supplies underlying product/service
Contract + applicable law
Tax determination
May determine transaction tax
Merchant provides product/customer facts
Tax scope
Tax calculation
May calculate VAT/GST/sales tax
Merchant may calculate outside MoR channels
Provider coverage
Checkout display
May supply tax amount/rules
Merchant may control UI
Consumer rules + integration
Tax collection
May collect covered transaction tax
Merchant handles uncovered/direct transactions
Transaction scope
Invoice issuance
May issue invoice/receipt
Merchant may still issue other invoices
Local invoicing law
Refund tax adjustment
May adjust tax/credit note
Merchant provides refund/fulfillment data
Tax + refund process
Tax filing
May file covered indirect-tax returns
Merchant handles own remaining returns
Contract + registration
Tax remittance
May remit covered tax
Merchant remits obligations outside scope
Statutory taxpayer
Record retention
Retains MoR records
Merchant may need copies/own records
Local retention rules
Payment reporting
May have certain reporting duties
Merchant may have separate reporting
Specific reporting regime
Corporate income tax
Generally its own entity's tax
Merchant retains its own corporate-tax analysis
Domestic law/treaty
PE assessment
MoR evaluates itself
Merchant evaluates its own cross-border presence
Merchant facts
Other merchant-level obligations
Depends on contract
Payroll, transfer pricing, direct sales, etc. can remain
Obligation-by-obligation
The table is intentionally not filled with universal yes/no answers.
That would defeat its purpose.
The operating rule is:
Assign each responsibility only after verifying both the contract and the applicable law.
Build the map by transaction channel
A global business may have several transaction models simultaneously.
For example:
COUNTRY A
Channel 1
Consumer website
→ MoR transaction
Channel 2
Enterprise invoice
→ Direct merchant transaction
Channel 3
Third-party marketplace
→ Marketplace facilitator transaction
Do not maintain:
Country A = MoR handles tax
Maintain:
Country A
+
Channel
+
Product
+
Customer
+
Seller entity
+
Responsibility model
The same market can therefore contain several tax architectures.
This is much closer to how international commerce actually works.
What merchants should measure operationally
The purpose of these metrics is not to measure “tax performance.”
It is to detect gaps in the responsibility model.
Markets covered by the MoR
Track only markets where the contractual and tax scope has been confirmed.
Do not equate:
payments available
with:
full MoR tax coverage.
Transactions routed through the MoR
Segment:
MoR transactions
Direct transactions
Marketplace transactions
Other
This prevents merchant Finance teams from assuming all revenue sits inside one tax model.
Direct transactions outside the MoR
These often represent the largest residual risk in a hybrid model.
Examples can include:
Enterprise sales
Legacy subscriptions
Direct invoices
Wholesale
Unsupported markets
Track them explicitly.
Invoice exception rate
Conceptually:
Invoice Exception Rate=transactions requiring invoicestransactions requiring invoice correction or manual intervention×100
Only useful if invoice eligibility and exception definitions are stable.
Tax reconciliation exceptions
Compare:
merchant transaction record
↓
MoR tax record
↓
invoice
↓
MoR settlement/report
Track mismatches by:
Country
Currency
Tax
Product
Refund status
Markets requiring merchant-side action despite the MoR
Maintain an exception register such as:
Market
MoR coverage
Merchant registration remaining?
Direct sales?
Invoice action?
PE review?
Other tax filing?
Owner
This is a far more useful executive control than:
“MoR coverage = 42 countries.”
How an MoR can reduce launch complexity
The MoR model becomes valuable when it shortens the merchant's direct dependency chain.
Without an MoR, a merchant entering multiple countries may need to coordinate:
tax analysis
↓
registration
↓
tax engine
↓
checkout logic
↓
invoice logic
↓
returns
↓
remittance
potentially across many jurisdictions.
A verified MoR model can centralize parts of that process for covered transactions:
Merchant
↓
MoR integration
↓
MoR customer/tax infrastructure
↓
supported markets
That can reduce merchant-side:
Indirect-tax registrations
Checkout tax implementations
Tax return operations
Invoice complexity
Tax remittance workflows
where the model legitimately places those responsibilities with the MoR.
But the remaining merchant obligations still need owners.
This is why the MoR can reduce compliance friction without eliminating compliance itself.
When MoR tax outsourcing does not solve the launch problem
An MoR may be a poor fit when the merchant's real blocker is outside the MoR's transaction-tax scope.
Examples include:
Permanent establishment
A local office or team may create a corporate-tax issue regardless of customer tax collection.
Product regulation
The product may require local authorization.
Employment
The business may need payroll/employer registration.
Direct B2B contracts
Enterprise transactions may sit outside the MoR structure.
E-invoicing outside MoR scope
The merchant may still issue invoices for its own direct transactions.
Marketplace sales
A marketplace facilitator may create another tax model.
Withholding
Payments between entities may need separate tax analysis.
The right question is therefore:
Which launch dependencies actually disappear under the MoR model?
not:
Does the provider say it handles global tax?
Questions to ask a Merchant of Record provider
A strong diligence process should force specificity.
Seller and contract
Which legal entity is the seller to the customer?
Where is that stated in the customer terms?
Does this differ by market or product?
Tax scope
Which taxes do you determine?
VAT?
GST?
Sales tax?
Other transaction taxes?
Which countries?
Which supply categories?
Calculation
Who owns product classification?
Who determines customer location?
How is B2B status verified?
Which tax engine or logic is used?
Checkout
Who determines tax-inclusive versus tax-exclusive presentation?
What data must the merchant send?
Who controls exemptions?
Collection
Who collects the tax?
Is the tax separately visible in reports?
Invoicing
Who legally issues the invoice?
Which entity appears on it?
Which tax IDs?
Which countries?
Do you support structured e-invoicing where required?
Who issues credit notes?
Filing
Which returns do you file?
Under which entity/registrations?
Are the merchant's direct transactions excluded?
Remittance
Who remits the tax?
How is remittance reflected in reporting?
Refunds
How are full and partial refunds handled?
When is tax adjusted?
Who creates the corrective document?
Registration
Which merchant registrations may still be necessary?
Do you advise the merchant to close existing registrations?
If so, who provides the legal basis for that decision?
Records
Which transaction-level tax records can the merchant export?
What happens after termination?
Corporate tax
What corporate-tax obligations do you explicitly not handle?
Do you provide any PE analysis, or must the merchant obtain separate advice?
Reporting
Which payment/tax information-reporting regimes fall within your scope?
Which remain with the merchant?
If the provider cannot answer those questions precisely, the phrase “we handle tax” is not sufficiently mature for an international launch plan.
A safe positioning is:
A Merchant of Record model can simplify international expansion when it centralizes defined customer-contracting, payment, transaction-tax, invoicing, and operational responsibilities across supported markets. Merchants should still evaluate the arrangement obligation by obligation and maintain visibility into transactions that remain outside the MoR model.
Cross-border payments
International market expansion
Local payment infrastructure
Payment operations
Merchant onboarding
Transaction reporting
Key takeaways
The phrase:
“Our Merchant of Record handles tax.”
should be replaced by a responsibility map.
Ask:
Who is the legal seller?
Who determines the tax?
Who calculates it?
Who displays it at checkout?
Who collects it?
Who issues the invoice?
Who adjusts it after refunds?
Who files?
Who remits?
Who keeps the records?
Who handles payment reporting?
Then ask the questions that sit outside the transaction:
Who pays corporate income tax?
Who evaluates permanent establishment?
Which registrations remain?
Which direct sales remain outside the MoR?
Which other merchant-level obligations continue?
A Merchant of Record can be highly effective precisely because it can consolidate many of the first group.
It should not be expected automatically to eliminate the second.
That is the decisive distinction.
Merchant of Record tax responsibility should be analyzed obligation by obligation, transaction by transaction, and market by market.
The contract defines what the provider promises to do.
The applicable tax law determines who is legally responsible.
The merchant's operating model has to reconcile both.
When those three layers align, an MoR can materially reduce the tax and invoicing dependencies that otherwise slow international launches.
When they do not, “tax handled” can create a false sense of readiness.
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
Does a Merchant of Record handle VAT?
An MoR can handle VAT for transactions within its legal, contractual, and jurisdictional scope, potentially including determination, calculation, collection, invoicing, filing, and remittance. The merchant should verify exactly which countries, transaction types, B2B/B2C situations, and products are covered.
Does a Merchant of Record collect sales tax?
It may collect sales tax where the MoR's legal structure and relevant state rules make it responsible for the transaction. U.S. sales-tax rules are state and local, so responsibility should not be generalized nationally.
Does a Merchant of Record handle GST?
An MoR can potentially determine, collect, and remit GST for covered transactions in relevant jurisdictions, but GST systems differ by country. The provider's current legal entity, registration, product coverage, and contractual scope should be verified.
Does a Merchant of Record issue invoices?
Many MoR arrangements include invoice or receipt issuance, but this is not automatic. Invoice responsibility depends on the legal seller, transaction type, country, and contract. In the EU, VAT invoice requirements can include specific supplier/customer and tax information, and national provisions can supplement the EU framework.
Does using a Merchant of Record eliminate permanent-establishment risk?
No. Permanent establishment concerns the merchant's own corporate-tax presence and activities. VAT/GST status and PE are separate analyses; the OECD specifically cautions against inferring PE from VAT/GST registration alone.
Does an MoR eliminate the need for tax registrations?
Not necessarily. A merchant can retain registrations because of direct sales, local inventory, employees, historical obligations, local entities, or transactions outside the MoR. Whether any registration can be closed requires jurisdiction-specific analysis.
Is a Merchant of Record the same as a marketplace facilitator?
No. Marketplace-facilitator or deemed-supplier responsibility generally arises from specific tax legislation applying to qualifying platform transactions. Merchant of Record is a commercial and legal operating model whose tax consequences depend on the contract and applicable law.
Is a Merchant of Record the same as a payment processor?
No. A payment processor facilitates the movement or processing of payments. An MoR may become the customer-facing seller for covered transactions and therefore assume broader commercial and tax responsibilities.
Does an MoR pay the merchant's corporate income tax?
Not merely because it collects VAT, GST, or sales tax. The underlying merchant remains responsible for analyzing its own corporate-income-tax exposure under applicable domestic law and tax treaties.
Who is responsible if the MoR contract and local tax law conflict?
The statutory tax position cannot generally be displaced simply by private contract. The contract may allocate commercial responsibilities or indemnities between the parties, but the merchant should obtain tax/legal advice where the contractual model does not clearly align with local law.
🙂 🙂 🙂 🙂 🙂 🙂 🙂
Merchant of Record Tax Responsibility: What the MoR Handles
Meta title
Merchant of Record Tax Responsibility | MoR Tax Guide
Meta description
Understand Merchant of Record tax responsibility, including VAT, GST, sales tax, invoicing, filing, remittance, refunds, registrations, and which obligations can remain with the merchant.
Suggested URL slug
/merchant-of-record-tax-responsibility/
SEO, EDITORIAL & PRODUCTION RECOMMENDATIONS
Merchant of Record tax responsibility
Secondary keyword priorities
Use naturally:
Merchant of Record taxes
MoR VAT
Merchant of Record tax compliance
Merchant of Record sales tax
Merchant of Record GST
who pays tax Merchant of Record
Merchant of Record responsibilities
MoR tax collection
Merchant of Record invoicing
Merchant of Record tax filing
Merchant of Record VAT responsibility
Avoid turning every heading into an exact-match variation. The article's topical authority should come from decomposing the actual obligations.
Recommended excerpt
A Merchant of Record can assume substantial transaction-level responsibilities for international sales, including indirect-tax determination, calculation, collection, invoicing, filing, remittance, and refunds. But “the MoR handles tax” is too broad: corporate income tax, permanent establishment, direct transactions, registrations, withholding, and other merchant obligations can remain. Merchants should map responsibility market by market and verify it against both the MoR contract and applicable tax law.
Featured-snippet target
What tax responsibilities does a Merchant of Record handle?
Depending on the contract and jurisdiction, a Merchant of Record may act as the customer-facing seller and handle transaction-tax determination, VAT/GST/sales-tax calculation, collection, invoicing, filing, remittance, and refund adjustments for covered sales. It does not automatically eliminate the underlying merchant's corporate income tax, permanent-establishment, direct-sales, registration, withholding, or other business-level tax obligations.
Suggested internal links
Tax Requirements for International E-Commerce
Anchor:
understanding which taxes can arise when selling internationally
Use near the first discussion of residual merchant obligations.
VAT for Digital Businesses
Anchor:
how VAT applies to cross-border digital products and services
Use from the VAT determination section.
Marketplace Facilitator Rules
Anchor:
how marketplace facilitator and deemed-supplier rules shift statutory tax responsibility
Use in the marketplace comparison.
E-Invoicing Requirements
Anchor:
when tax invoicing becomes a technical integration requirement
Use from the invoice section.
Payment Tax Reporting
Anchor:
why payment reporting is separate from transaction-tax collection
Use from the reporting discussion.
Permanent Establishment Risk
Anchor:
why indirect-tax outsourcing does not automatically remove corporate-tax presence risk
Use in the PE section.
Suggested supporting visual
Merchant of Record Tax Responsibility Map
CUSTOMER
|
v
MERCHANT OF RECORD
|
┌─────────────────┼─────────────────┐
v v v
TAX DETERMINATION PAYMENT INVOICING
CALCULATION COLLECTION / RECEIPTS
COLLECTION
| | |
└─────────────────┼─────────────────┘
v
TAX OPERATIONS
Filing | Remittance | Refunds
|
v
MERCHANT REPORTING
UNDERLYING MERCHANT
|
┌─────────────────┼─────────────────┐
v v v
Direct sales Corporate tax PE analysis
| / withholding / local activity
|
Merchant-side registrations
and other obligations
Footer:
The exact boundary is defined by contract + transaction structure + applicable law.
Recommended visual alt text
Merchant of Record Tax Responsibility Map showing transaction-level tax calculation, collection, invoicing, filing, remittance and refunds potentially handled by the MoR while direct sales, corporate income tax, permanent establishment and other merchant-level obligations may remain with the underlying business.
Secondary visual: Decompose “Handles Tax”
A horizontal flow:
“The MoR handles tax”
↓
Which tax?
↓
Which transaction?
↓
Which country?
↓
Determine
↓
Calculate
↓
Collect
↓
Invoice
↓
File
↓
Remit
↓
What remains with merchant?
This is likely the strongest social/LinkedIn derivative because it communicates the article's unique thesis immediately.
Sources / research references
European Commission — VAT liability
The European Commission's current VAT guidance establishes the basic principle that the supplier is generally the person liable to pay VAT unless specific rules shift liability to another person. This supports the article's insistence on identifying the legal seller and transaction role before assigning VAT responsibility.
European Commission — VAT invoicing
Current Commission guidance explains EU VAT invoice obligations, required invoice information, national variation, and the ability in some circumstances to outsource invoice issuance to a third party. This is useful evidence for treating invoicing as a separate contractual and operational responsibility rather than assuming “tax collection” includes invoice compliance.
EU VAT Directive
The VAT Directive provides the underlying rules for invoice issuance, third-party invoicing, invoice content, and the relevant Member State's invoicing rules.
European Commission — VAT in the Digital Age
The Commission's May 2026 ViDA implementation program confirms the phased rollout of newer VAT measures, including platform deemed-supplier reforms from July 2028 and cross-border B2B e-invoicing/digital reporting from July 2030. This makes invoicing and platform-tax responsibilities particularly date-sensitive.
OECD — permanent establishment
OECD Model Convention materials support the distinction between permanent-establishment analysis and indirect-tax registration. The OECD has specifically stated that VAT/GST registration alone should not determine whether a PE exists for income-tax treaty purposes.
IRS — foreign corporate tax
Current IRS guidance demonstrates that a foreign corporation's U.S. income-tax obligations turn on its own activities, such as whether it is engaged in a U.S. trade or business and earns effectively connected income. This is useful evidence that transaction-tax outsourcing to an MoR does not itself decide the underlying merchant's corporate-tax exposure.
Merchant of Record entity
Which legal entity is the MoR?
Which customer/supplier contract creates the seller relationship?
Market coverage
Which countries?
Which currencies?
Which products?
Digital only or physical?
B2C only or B2B too?
Do not reuse generic “190+ countries/markets” statements as an MoR tax-coverage claim without explicit verification.
Transaction taxes
Verify whether the product currently supports:
VAT determination
VAT collection
VAT filing
VAT remittance
GST determination
GST collection
GST filing/remittance
U.S. sales-tax calculation
U.S. sales-tax registration/filing/remittance
Other indirect taxes
Invoicing
Verify:
Invoice issuance
Legal issuer
Country coverage
B2B/B2C support
Credit notes
E-invoicing
Structured invoice formats
Archiving
Refunds
Verify:
Tax reversal logic
Credit-note handling
Partial refunds
Chargebacks
Records/reporting
Verify:
Tax line-item exports
Invoice exports
Transaction-level tax reporting
Return/remittance evidence
Historical retention
Contract boundary
Obtain explicit confirmation of:
Merchant obligations that remain
Product-classification responsibilities
Customer data responsibilities
Corporate tax exclusion
PE exclusion
Withholding exclusion
Direct-sales exclusion
Until verified, avoid claims such as:
“Terminal3 eliminates tax registrations.”
“The MoR assumes every merchant tax obligation.”
“One MoR integration makes the merchant tax compliant everywhere.”
Claims requiring tax/legal review
An international tax specialist and payments lawyer should review:
The legal definition being used for Merchant of Record
Whether the provider is actually seller/principal for each covered transaction
VAT/GST/sales-tax responsibility
Registration consequences
Customer-contract language
Invoicing responsibility
Refund/credit-note treatment
Transaction reporting
Direct-sales treatment
Corporate-tax boundaries
PE
Withholding on MoR-to-merchant payments
Any marketplace overlap
Contractual indemnity versus statutory liability
The highest-risk statement to prevent is:
“MoR = no tax obligations for merchant.”
Date-sensitive claims requiring re-verification before publication
EU VAT in the Digital Age
Re-check the ViDA implementation schedule immediately before publishing. Current European Commission guidance as of May 2026 describes:
Certain changes from 1 January 2027
New platform deemed-supplier measures in specified sectors from 1 July 2028
Cross-border B2B digital reporting based on mandatory e-invoicing from 1 July 2030
Broader system alignment by 1 January 2035.
These should not be described as already universally effective.
EU invoicing
Corporate-tax examples
If adding country-specific PE or corporate-tax language later, verify against:
Current domestic law
Relevant treaty
Merchant facts
Do not use the general OECD framework as a substitute for specific-country analysis.
Recommended human contribution
Primary tax reviewer: International indirect-tax specialist.
Focus on:
VAT/GST/sales-tax allocation
Seller identity
Tax collection
Filing/remittance
Registration consequences
Invoicing
Legal reviewer: Payments/commercial lawyer with MoR contracting experience.
Focus on:
Legal seller
Customer contracting
Contractual allocation
Statutory vs contractual responsibility
MoR vs PSP distinction
Corporate-tax reviewer: International corporate-tax specialist.
Focus on:
PE
Corporate income tax
Withholding
Payments from MoR to merchant
Operations reviewer: Finance Operations / Billing lead.
Focus on:
Invoice flow
Refunds
Reconciliation
Reporting
Direct/MoR transaction separation
Cluster sameness audit
Article: Merchant of Record and Tax Responsibility
Primary merchant problem: Merchant treats “MoR handles tax” as meaning all tax responsibility disappears.
Opening device: Decomposes one broad sales statement into specific responsibilities.
Primary object: Tax/invoicing obligation.
Unique evidence anchor: “Which tax? Which transaction? Which country? Which responsibility?”
Primary editorial position: Evaluate MoR as a responsibility-allocation model.
Core distinction: Transaction-level tax responsibility vs merchant-level tax responsibility.
Secondary distinctions: Legal seller vs payment receiver; collection vs filing; filing vs remittance; MoR vs PSP; MoR vs marketplace facilitator; contractual promise vs statutory liability.
Original framework: Merchant of Record Tax Responsibility Map.
Primary launch implication: An MoR can remove several market-entry tax dependencies, but residual merchant obligations need explicit ownership before launch.
Primary data implication: Transactions must be classified as MoR, direct, marketplace, or another channel so Finance knows which responsibility model applies.
Primary operational risk: Merchant assumes all transactions are covered while direct or unsupported transactions continue outside the MoR.
Primary legal risk: Commercial contract promises are treated as if they automatically determine statutory tax liability.
Primary finance risk: Tax, MoR fees, processing fees, and FX are collapsed into settlement deductions that cannot be reconciled.
Main internal-link path: Tax Requirements for International E-Commerce → VAT for Digital Businesses → Marketplace Facilitator Rules → E-Invoicing Requirements → Payment Tax Reporting → Permanent Establishment Risk.
Boundary: This article does not own general VAT/GST/sales-tax mechanics, general marketplace facilitator law, e-invoicing mandates, or full PE analysis. It owns the question of who is responsible for each tax and invoicing obligation when a Merchant of Record sits in the transaction.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗