Learn who issues marketplace invoices, how seller and platform duties differ, and how VAT, refunds and disputes affect liability.
A buyer asks for a corrected invoice after a refund dispute. The seller says the marketplace collected the money. Finance sees a payout already released, while legal finds a seller agreement that never clearly explains who issued the invoice. This is where platform invoice liability seller-buyer questions become costly.
For marketplaces, liability is not decided by one label alone. The invoice issuer, contractual supplier, payment flow, tax rules, and processor agreement must align. If they do not, buyer invoice disputes can become chargebacks, delayed payouts, tax errors, and difficult seller recovery conversations. A practical starting point is to map each transaction: who sells, who issues the invoice, who collects the buyer’s payment, who holds reserves, and who processes refunds.
A marketplace may connect independent sellers and buyers, but its role can range from a listing service to the buyer-facing seller. The seller may issue the invoice directly or the platform may issue it as the merchant of record. The buyer receives the invoice and may challenge incorrect pricing, tax, delivery, or refund treatment.
Merchant of record is a commercial and payment-industry term, not a single EU VAT classification. The entity shown at checkout, named on the invoice, contracting with the buyer, and collecting payment may all be relevant, but VAT liability must be assessed under the applicable rules and the transaction’s substance.
Marketplace teams should separate three types of responsibility:
Clear buyer-seller responsibilities depend on all three. A seller agreement can allocate recovery rights between the parties, but it cannot replace statutory tax or invoicing duties.
The invoicing model determines who appears on the buyer’s invoice, how money moves through the marketplace, and where payment, tax, and dispute exposure may sit.
The three most common models are outlined below.
Model | Invoice issuer | Payment flow | Main platform risk |
|---|---|---|---|
Platform as merchant of record | Platform | Platform collects and pays seller net of fees | Refunds, chargebacks, invoice accuracy, tax and payout controls |
Seller as merchant of record | Seller | Seller collects, or has a dedicated payment flow | Seller compliance failures, poor invoice quality, facilitation exposure |
Hybrid model | Seller invoices for the underlying sale; platform invoices its fees | Split by transaction component | Duplicate records, buyer confusion, reconciliation complexity |
In a platform-as-merchant-of-record model, the platform has the most control over checkout, invoicing, tax calculation, and the buyer experience. It also needs strong seller liability protection because it may face payment disputes before it can recover funds from a seller.
A seller-as-merchant-of-record model can lower direct exposure, especially when sellers have mature tax and finance operations. However, the platform still needs controls for seller identity, invoice quality, fraud, complaints, and platform payment terms.
A hybrid model can work where the platform’s service fee is genuinely separate from the seller’s supply. It requires precise invoice liability agreements so buyers know which party issued each invoice and where to raise a dispute.
.webp&w=1920&q=75)
The invoicing model identifies who issues the invoice, but processor settings determine where a refund, dispute, or negative balance may land. In Stripe Connect, the losses_collector setting determines responsibility: application means the platform is responsible, while stripe means Stripe is responsible. Stripe may also recover a negative balance from an eligible connected account’s external bank account where permitted.
The PayPal platform's approach depends on its product and regional agreement. Sellers may remain liable for disputed amounts, while PayPal may recover funds from their balance, settlement account, or future payouts. Platforms should align processor terms, seller recovery rights, payout controls, and invoice records.
The invoicing model determines who records the sale, accounts for VAT, manages payouts and refunds, issues credit notes, retains invoice records, and fulfils e-invoicing and reporting obligations. The supplier shown on the invoice must match the actual commercial arrangement and VAT treatment.
A platform cannot rely solely on seller-issued invoices where EU deemed-supplier rules make it responsible for a supply. Under Article 14a of the EU VAT Directive, this can apply where an electronic interface facilitates:
The rule is transaction-specific. A platform does not become a deemed supplier simply because it facilitates sales, takes payment, or issues invoices; the outcome depends on the specific supply and the parties involved.
Contracts cannot override VAT, consumer or payment-service rules, but they can clarify roles and support recovery of seller-caused losses. They should reflect the actual transaction flow: who supplies, invoices, collects payment, handles refunds, and retains records.
Include these points in seller agreements:
Validate seller and VAT data before payouts, reconcile invoices with payments, issue credit notes for refunds, and retain an audit trail. This reduces platform risk and supports recovery from sellers.
Once a marketplace has defined who invoices, collects payment, and handles refunds, it must apply those roles consistently across sellers and countries. DDD Invoices is API-first e-invoicing infrastructure for marketplaces, payment providers, ERPs, and SaaS platforms. Through one normalized API integration, it transforms invoice data into locally compliant PDFs and structured e-invoices, applies local VAT rules, supports fiscalization, and enables real-time or periodic tax-authority reporting where required.
For marketplace teams, it provides a central compliance layer between transaction data and fragmented local tax systems, supporting invoice issuing, receiving, archiving, and validated data flows to finance systems. This helps maintain more consistent records for buyer disputes, refunds, and audits without building separate local integrations. DDD Invoices supports compliance workflows; it does not transfer the platform’s legal liability to sellers.
Still have questions?
In the 30min free call we will discuss:
Liability depends on the transaction design, jurisdiction, invoice issuer, payment flow, and tax rules. A platform that issues invoices and collects payment may have significant buyer-facing and payment exposure.
It can. Funds collected from buyers but still owed to sellers may be liabilities, while platform fees may be revenue. Gross-versus-net revenue treatment depends on the platform’s role and accounting policy.
The party responsible under the commercial and applicable tax rules should issue it. That may be the seller, the platform, or another defined entity, but the invoice must match the actual transaction structure.
Processor terms can expose platforms to losses from disputes, refunds, negative balances, or settlement-account debits.