Home/Research library/Compliance Slows Launches

Guide · Tax and invoicing

Payment Tax Reporting

A merchant can have five numbers describing the same period and all five can be correct: Customer payments: $1,000,000 Refunds and chargebacks: $70,000 Net settlement received: $900,000 Amount appearing on a tax information report: potentially something else again, depending on t

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.

Payment Tax Reporting: What Payment Providers May Report—and What It Means for Merchants

A merchant can have five numbers describing the same period and all five can be correct:

Customer payments: $1,000,000

Refunds and chargebacks: $70,000

Payment and platform fees: $30,000

Net settlement received: $900,000

Amount appearing on a tax information report: potentially something else again, depending on the reporting regime.

None of those numbers automatically tells the merchant how much tax it owes.

That is the central point of payment tax reporting.

Payment providers, acquiring entities, marketplaces, and digital platforms can have obligations in certain jurisdictions to report information about merchants, payees, sellers, or transactions to tax authorities. Those reports are designed to provide information. Their definitions can differ materially from the accounting and tax rules the merchant uses to calculate revenue, deductions, VAT, GST, sales tax, or taxable income.

For finance teams, the practical job is therefore:

Report received → identify reporting rule → understand what the number represents → reconcile to transaction records → determine tax treatment separately

A payment report should be an input to the merchant's tax and accounting process—not a substitute for it.

What does payment tax reporting mean?

Payment tax reporting is the disclosure of defined payment, merchant, seller, or transaction information by a payment entity or platform to a tax authority under a specific jurisdiction's information-reporting rules.

Depending on the regime, the reporting party might be:

a payment settlement entity;

merchant acquirer;

third-party settlement organization;

online marketplace;

digital platform operator;

another entity specifically defined by law.

The information can include:

merchant or seller identity;

tax identification number;

payment volume;

number of transactions;

amounts paid or credited;

fees or commissions;

amounts withheld or charged;

financial-account information;

other jurisdiction-specific fields.

But the existence of a report does not by itself establish:

whether every reported payment is taxable income;

the merchant's profit;

the VAT or GST due;

sales-tax liability;

deductible fees;

cost of goods sold;

corporate income tax;

whether another tax return must be filed.

Those questions are determined under the applicable tax rules.

Who may have payment-reporting obligations?

There is no universal rule saying that every PSP reports every merchant's payments to every tax authority.

The responsible entity depends on the jurisdiction and reporting regime.

United States: Form 1099-K

In the United States, Internal Revenue Code section 6050W requires certain payment settlement entities to report qualifying payment-card and third-party-network transactions on Form 1099-K, Payment Card and Third Party Network Transactions.

The IRS explains that for payment-card transactions, the merchant acquiring entity that transfers funds to the participating payee is generally responsible for reporting. Where a processor and payment settlement entity both have contractual payment obligations, the entity submitting the instruction to transfer the funds to the payee is generally the reporting party.

That distinction matters.

The company technically processing a transaction is not automatically the reporting entity merely because the merchant casually calls it “the payment processor.”

European Union: DAC7 platform reporting

The EU's DAC7 framework creates a different type of reporting obligation.

It places reporting responsibilities on qualifying digital platform operators for certain activities including:

sale of goods;

personal services;

rental of immovable property;

rental of transport.

Platform operators report identifying and financial information about reportable sellers. The European Commission explicitly states that DAC7 itself does not impose a new tax or determine how seller income is taxed.

United Kingdom: digital platform reporting

The UK has implemented OECD-style reporting rules for digital platforms separately from EU DAC7.

Qualifying platform operators are required to conduct seller due diligence and report specified seller information to HMRC, while also providing the reported information to affected sellers. The rules took effect from January 1, 2024 and were subsequently amended to refine the UK reporting framework.

These examples show why the phrase “payment provider tax reporting” needs context.

A U.S. card acquirer filing a Form 1099-K and an EU marketplace filing seller information under DAC7 are performing different reporting functions under different laws.

What amount gets reported?

This is where merchant confusion often begins.

There is no universal definition of “reported payment amount.”

Different reporting regimes deliberately use different measures.

U.S. Form 1099-K reports gross payment transactions

The IRS instructs Form 1099-K filers to report the gross amount of reportable payment transactions.

For 2026 reporting, the instructions define gross amount without adjustments for items such as:

fees;

credits;

refunds;

shipping;

discounts;

other adjustments.

IRS guidance has also specifically explained that sales, excise, or value-added tax included in a payment-card transaction can be included in the Form 1099-K gross amount even though those amounts may not represent the merchant's taxable income.

That means this can happen:

Customer pays: $110

including:

Product: $100

Tax collected: $10

The payment-reporting system can see a $110 payment.

The merchant's tax accounting may treat the $10 collected for the taxing authority differently from its $100 of sales revenue.

The payment report and the accounting treatment are answering different questions.

DAC7 uses a different reporting concept

EU DAC7 defines consideration for its purposes as compensation paid or credited to a seller in connection with a relevant activity, net of certain fees, commissions, or taxes withheld or charged by the platform operator.

The platform separately reports specified financial information including consideration, number of relevant activities, and fees, commissions, or taxes withheld or charged.

So even the word “amount” means something different depending on the reporting system.

A merchant should therefore never write reconciliation logic based on the assumption:

Tax report amount = global PSP gross volume

First identify the actual statutory reporting definition.

Gross payment volume is not net settlement

Consider an illustrative merchant statement:

Payment data

Amount

Gross customer payments

$1,000,000

Refunds

-$40,000

Chargebacks

-$10,000

PSP/platform fees

-$30,000

Reserves or other settlement adjustments

-$20,000

Illustrative bank settlement

$900,000

Under a gross-payment reporting regime, the reportable number can begin much closer to the $1 million payment volume than the $900,000 deposited into the merchant's bank account.

That does not mean the missing $100,000 disappeared.

It means different systems are measuring different stages of the payment flow.

Payment flow

Customer payment

→ transaction processed

→ refunds / reversals

→ fees

→ reserves or other adjustments

→ settlement

Reporting flow

Reportable transactions

→ statutory reporting definition

→ threshold and scope test

→ payment report or information return

The two flows overlap, but they should not be expected to produce identical numbers.

Why processor fees do not automatically reduce the reported amount

Under current U.S. Form 1099-K rules, processing fees do not reduce Box 1a's reported gross amount.

The IRS specifically instructs recipients to use their own books and records to identify adjustments such as fees and refunds when determining the correct tax treatment.

Suppose a merchant processes:

$100,000 in payments

and pays:

$3,000 in PSP fees.

The merchant might receive approximately $97,000 before considering other adjustments.

That does not mean a U.S. Form 1099-K reporting the relevant transactions should necessarily say $97,000.

Its reporting framework is based on gross reportable payment transactions.

Whether the $3,000 is deductible, and how it is treated on the merchant's return, is a separate tax-accounting question.

Refunds can create the same mismatch

Suppose:

January sale: $1,000

February refund: $1,000

From the merchant's commercial perspective, the sale has ultimately been reversed.

A gross-reporting regime can nevertheless capture the original reportable payment without reducing the reported amount for the later refund.

The merchant therefore needs transaction-level records linking:

original payment → refund → reporting period → accounting adjustment

rather than trying to force the PSP's gross figure to equal net revenue.

Reporting thresholds are not tax thresholds

This distinction is mandatory for any payment tax reporting analysis.

A reporting threshold answers:

At what point does this reporting entity become required to send information under this reporting rule?

A tax threshold answers a different question:

Under the applicable tax rules, when does a tax, filing, registration, or other obligation arise?

Crossing one does not automatically mean crossing the other.

Current U.S. Form 1099-K threshold

As of August 2026, current IRS guidance reflects the threshold restored in 2025:

For a third-party settlement organization, reporting is generally required when both:

gross reportable third-party-network payments exceed $20,000 for the calendar year; and

the number of transactions exceeds 200.

Payment-card transactions follow a different rule: payment-card processors can have Form 1099-K reporting for payment-card transactions regardless of the dollar amount or transaction count.

This is not an income-tax exemption.

The IRS states explicitly that the Form 1099-K reporting threshold does not determine whether payments are taxable or whether a return must be filed.

DAC7 has its own threshold concept

Under the current EU DAC7 text, a seller involved in the sale of goods is excluded from seller reporting where the platform facilitated fewer than 30 relevant sale-of-goods activities and the total consideration paid or credited did not exceed EUR 2,000 during the reporting period.

Again, this is a reporting exclusion.

It is not an EU-wide rule saying:

“Below EUR 2,000, no tax can be due.”

The European Commission expressly distinguishes DAC7 reporting from the underlying taxation of seller income.

This distinction is so important that merchants should label threshold fields internally as:

Reporting threshold

rather than simply:

Tax threshold.

Why merchant identity data matters

Payment tax reporting is not only about transaction amounts.

Authorities need to know whose transactions are being reported.

In the U.S. Form 1099-K framework, merchant/payee information includes the taxpayer identification number, or TIN, and identifying information connected to the payment account.

The IRS advises recipients to verify that the TIN and merchant identity information on the form are correct. If a Form 1099-K is issued to the wrong taxpayer or legal entity, correction may be necessary.

EU DAC7 likewise requires platforms to collect identifying information about reportable sellers, potentially including:

legal name;

primary address;

tax identification numbers;

VAT identification number where applicable;

business registration information for entities;

specified financial-account information.

For a merchant, this creates an operational requirement:

The legal entity receiving payment needs to be correctly mapped to its tax identity.

This becomes especially important when a business has:

multiple legal entities;

multiple merchant IDs;

multiple PSP accounts;

regional subsidiaries;

marketplace accounts;

different settlement bank accounts.

If three PSP accounts belong to one legal entity but accounting treats them as three different businesses—or the reverse—year-end reconciliation becomes much harder.

A tax form is not an invoice

Payment tax reports should also be distinguished from transactional documents.

A tax information form or report communicates defined information to a tax authority and/or merchant.

An invoice documents a transaction between seller and customer and can have separate tax, legal, or commercial requirements.

A U.S. Form 1099-K is not a customer invoice.

A DAC7 seller report is not a VAT invoice.

Likewise, an invoice does not replace a payment provider's statutory information-reporting obligation where one applies.

A payment report is not a VAT or GST return

Another common mistake is treating payment data as though it can be copied directly into an indirect-tax return.

Payment systems know useful facts such as:

transaction amount;

currency;

payment date;

payment method;

merchant entity;

some customer-location indicators.

But payment data alone may not establish:

whether the supply is taxable;

which VAT/GST jurisdiction applies;

B2B versus B2C treatment;

applicable product classification;

place of supply;

applicable rate;

marketplace or deemed-supplier responsibility;

tax already reported through another mechanism.

A merchant's VAT or GST return reports amounts determined under the applicable tax regime.

A payment information return reports information according to the reporting law governing the provider or platform.

Those are separate processes.

Marketplace and platform reporting can create additional records

Marketplace sellers can have more than one reporting layer.

Imagine a merchant that sells through:

its own website

and

two marketplaces.

It might receive:

processor reporting for direct card payments;

seller statements from Marketplace A;

seller reporting from Marketplace B;

settlement statements from all three;

internal accounting records covering the complete business.

Those sources can overlap.

A merchant should not simply add all reported numbers together without determining whether the same underlying transaction appears in multiple datasets.

The same caution applies where one payment intermediary reports settlement information while another platform reports seller activity.

EU platform example

Under DAC7, platform operators report seller financial information to the relevant tax authority, including total consideration paid or credited and relevant activity counts. The platform also has due-diligence responsibilities relating to the information it collects and verifies.

UK platform example

UK rules similarly require qualifying reporting platform operators to provide specified seller information to HMRC and give the seller a copy of the reported information.

Neither framework means the marketplace report has calculated the seller's complete income-tax, VAT, or other tax position.

[Internal link opportunity: Marketplace Facilitator Rules]

Payment reporting is not withholding tax

A reduced settlement does not necessarily mean tax has been withheld.

A payment provider can deduct:

processing fees;

FX costs;

chargebacks;

reserves;

platform commissions;

other contractual amounts.

Tax withholding is a distinct concept in which a party retains an amount under applicable tax rules and remits or accounts for it accordingly.

A line item labeled simply “deduction” should therefore not automatically be classified as tax withholding.

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

Payment reporting is not the merchant's tax return

This is the most important distinction in the article.

A reporting entity reports what its statutory rules tell it to report.

The merchant files tax returns based on the laws governing the merchant and its transactions.

Those two calculations can use different:

definitions;

periods;

currencies;

thresholds;

entity scopes;

transaction classifications;

adjustments.

A payment tax report should therefore be treated like a third-party data source that needs to be reconciled against the merchant's books.

It is not a ready-made tax return.

The Payment Tax Reporting Reconciliation

A practical reconciliation starts with the underlying transaction data.

Payment activity

Gross customer payments

↓

Refunds and payment reversals

↓

Chargebacks

↓

Taxes collected where relevant

↓

Payment / marketplace fees

↓

Reserves or other settlement adjustments

↓

Net settlement

Separately:

Reportable transactions

↓

Jurisdiction-specific reporting scope

↓

Reporting threshold

↓

Reported amount / tax information form

Then:

Reconcile the two paths

Do not assume they will equal each other.

A merchant should be able to explain why they differ.

A practical merchant reconciliation table

Finance teams can use a structure such as:

Reconciliation item

Merchant ledger

PSP/platform data

Tax report

Difference explained?

Gross processed payments

Refunds

Chargebacks

Tax collected

PSP/platform fees

Reserves/adjustments

Net settlement

N/A

Reportable amount

N/A

The objective is not to make every column equal.

The objective is to understand why each number is different.

What merchants should reconcile

At year-end—or preferably throughout the year—finance and payment-operations teams should be able to connect payment reporting to several datasets.

Gross processed volume

Confirm the total underlying payment activity represented by the report.

Refunds

Identify whether refunds reduce the statutory reported amount or must be reconciled separately.

Chargebacks

Understand how chargebacks affect accounting versus payment reporting.

Fees

Separate PSP, marketplace, acquiring, and other fees from the gross transaction amount.

Tax collected

Identify VAT, GST, sales tax, or other amounts collected from the customer and determine how the relevant accounting and reporting rules treat them.

Net settlement

Reconcile the amount actually received into bank accounts with the processor's settlement reports.

Reported amount

Identify exactly how the reporting regime defines the amount.

Merchant identity

Confirm that the legal name, tax ID, merchant account, and reporting entity correspond to the correct legal business.

Multiple providers

Check whether transactions have been duplicated across PSPs, marketplaces, or reporting forms.

Currency

Where a merchant operates internationally, determine what exchange-rate methodology each source uses rather than assuming the tax form and ledger use identical FX conversion.

Build reporting reconciliation before year-end

Payment tax reporting becomes a launch and scale problem when merchant architecture cannot answer basic questions such as:

Which legal entity received this transaction?

Which PSP processed it?

Which marketplace facilitated it?

Was tax included in the payment?

Was it refunded later?

Which bank settlement contains it?

Which reporting regime can include it?

Those questions are easier to solve when payment data is designed with reconciliation in mind.

Useful transaction attributes can include:

legal merchant entity;

merchant account;

PSP;

marketplace;

transaction ID;

gross amount;

currency;

customer tax amount;

refund ID;

chargeback status;

processing fee;

settlement batch;

settlement currency;

tax-reporting category where appropriate.

Payment availability alone is therefore not tax-reporting readiness.

A merchant can launch successfully, receive customer payments, and settle revenue for an entire year before discovering that its payment, accounting, marketplace, and tax-reporting datasets cannot be reconciled cleanly.

Key takeaway

Payment tax reporting is a data-reporting obligation, not a tax-return calculation.

A payment provider or platform can be required to tell a tax authority:

who received payments

and

what defined amount was paid, processed, or credited

without determining the merchant's complete tax liability.

That is why these numbers should remain separate:

Gross payment volume

Reported payment amount

Refund-adjusted sales

Net bank settlement

Accounting revenue

Taxable income

They can relate to the same business and still legitimately differ.

The merchant's job is not to force them into one number.

It is to establish a reliable reconciliation:

Transaction → PSP/platform record → settlement → information report → merchant ledger → tax return

When every step can be traced, a third-party tax report becomes useful evidence instead of a year-end accounting surprise.

When those systems are not connected, reporting requirements can become another late-stage operational problem—particularly for merchants expanding across multiple processors, marketplaces, currencies, and jurisdictions.

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

[Internal link opportunity: Tax Requirements for International E-Commerce]

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 Form 1099-K show taxable income?

Not necessarily. Form 1099-K reports gross reportable payment transactions under U.S. information-reporting rules. The IRS expressly states that receiving a Form 1099-K does not mean every reported dollar is taxable income.

Why is my Form 1099-K higher than the amount deposited into my bank account?

The reported gross amount is not reduced for items such as payment-processing fees, refunds, credits, discounts, or shipping. Net settlement can therefore be materially lower.

What is the Form 1099-K reporting threshold in 2026?

For third-party settlement organizations, current federal reporting generally applies when a participating payee has more than $20,000 in gross reportable payments and more than 200 transactions in the calendar year. Payment-card transactions follow separate rules and are reportable regardless of those TPSO thresholds.

Does being below a payment-reporting threshold mean I owe no tax?

No. A reporting threshold governs whether a third party has a reporting obligation. It does not automatically determine whether the underlying income or transaction is taxable. The IRS and European Commission both make this distinction explicit in their respective reporting frameworks.

Do online marketplaces report seller payments to tax authorities?

They may, depending on the jurisdiction and applicable platform-reporting rules. EU DAC7 and the UK's digital-platform reporting framework are examples of regimes requiring qualifying platform operators to report seller information.

Is a payment tax report the same as a VAT or GST return?

No. A payment report communicates payment or seller information under a specific reporting regime. A VAT or GST return is based on separate indirect-tax rules concerning taxable supplies, rates, deductions, and other relevant factors.

Is a payment-provider tax form an invoice?

No. An information-reporting form communicates information to a tax authority and/or payee. An invoice documents a transaction between seller and customer and can have separate tax and legal requirements.

What should merchants do if a reported amount looks wrong?

First reconcile the report to transaction records and verify the merchant identity and tax ID. In the U.S., the IRS instructs Form 1099-K recipients to contact the issuer/payment settlement entity to seek correction when the form contains incorrect payee or payment information.

🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

Payment Tax Reporting: What Payment Providers May Report—and What It Means for Merchants

Meta title

Payment Tax Reporting: PSP Reports, 1099-K & Merchant Reconciliation

Meta description

Learn how payment tax reporting works, why reported gross payments can differ from net settlement, and how merchants should reconcile PSP and platform reports without confusing reporting with tax liability.

Suggested URL slug

/payment-tax-reporting/

The article and recommendations below follow the supplied brief's core distinction: payment-provider and platform reporting is an information-reporting function, not a calculation of the merchant's final tax liability.

Recommended supporting visual

Payment Tax Reporting Reconciliation

This should be the signature graphic for the article.

Left side — Payment and settlement flow

Customer pays $100

↓

Gross processed payment: $100

↓

Branch into:

Refunds / chargebacks

Tax

PSP / marketplace fees

Reserves / adjustments

↓

Net settlement

Right side — Tax reporting flow

Payment transaction data

↓

Who is the reporting entity?

↓

Is the merchant/payee reportable?

↓

Which reporting definition applies?

↓

Reporting threshold / scope

↓

Tax authority report or form

Then reconnect both flows at:

RECONCILIATION

Reported amount ≠ automatically net settlement ≠ automatically taxable income

Suggested footer:

Reconcile the numbers. Do not assume they mean the same thing.

Recommended filename

payment-tax-reporting-reconciliation.svg

Recommended visual alt text

Payment tax reporting reconciliation comparing gross payments, refunds, fees, net settlement, reportable payment data, and merchant tax records

Additional visual recommendation

A second small comparison graphic would add substantial value:

Number

What it tells the merchant

Gross processed volume

What customers paid through the payment system

Net settlement

What the provider transferred after settlement adjustments

Reported amount

What a particular tax-reporting rule requires the provider/platform to report

Accounting revenue

Revenue recorded under applicable accounting treatment

Taxable income

Amount determined under applicable tax law

Headline:

Five Numbers That Are Not Automatically the Same

This would probably be the most shareable asset for finance audiences.

Sources / research references

For U.S. payment reporting, current claims were verified against the IRS's 2026 Form 1099-K instructions, current Form 1099-K FAQs, and current merchant guidance. These confirm the restored TPSO threshold of more than $20,000 and more than 200 transactions, the separate treatment of payment-card transactions, and the gross-reporting methodology.

The IRS also directly confirms that a Form 1099-K amount does not by itself determine whether a payment is taxable and that merchants should reconcile fees, refunds, and other adjustments using their own records.

EU platform-reporting treatment was verified against the European Commission's DAC7 guidance and the current consolidated directive. DAC7 covers defined platform activities and seller information while expressly not determining the underlying taxation of seller income.

UK platform-reporting claims were checked against the UK Platform Operators regulations and subsequent amendments.

Form 1099-K or equivalent tax statements;

tax-reporting exports;

marketplace seller reports;

year-end reconciliation reports;

merchant tax-ID validation;

gross-versus-net tax reconciliation fields;

downloadable tax documents.

Claims requiring tax/legal review

A qualified tax-reporting specialist should review:

the description of Form 1099-K reporting parties;

the treatment of tax amounts within gross Form 1099-K reporting;

the distinction between reportable amounts and taxable income;

DAC7 seller/reporting scope;

any future UK platform-reporting threshold examples;

the legal-entity implications where a merchant operates through multiple PSP accounts or platforms.

The article intentionally does not prescribe how a merchant should enter a payment report on a particular income-tax, VAT, GST, or corporate-tax return.

Date-sensitive claims requiring re-verification

Immediately before publication, recheck:

the Form 1099-K TPSO dollar and transaction thresholds;

whether payment-card reporting remains reportable without the TPSO de minimis threshold;

the current Form 1099-K revision and instructions;

EU DAC7 seller-reporting thresholds, especially because the European Commission was considering changes to the sale-of-goods threshold in 2026;

UK platform-reporting rules and excluded-seller thresholds;

any tax form names, reporting deadlines, or reporting periods added during editing.

I would give this page a visible Last reviewed: August 20, 2026 field because information-reporting thresholds are unusually prone to legislative change.

Need help narrowing down payment options?

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

Explore matching options ↗