Stripe Managed Payments in QuickBooks

You switch on Stripe Managed Payments. Tax compliance in most of the countries you sell to stops being your problem, disputes stop landing in your inbox, and your checkout starts converting in local currency. Then month end arrives, you open QuickBooks, and your Stripe fee expense has grown by far more than any fee change explains.

Nothing is broken. The number is real. It just is not only fees.

Managed Payments is Stripe's merchant of record product, shipped in the 2026-04-22 Dahlia release for businesses selling digital products. It changes who the seller is, and once you change who the seller is, three things move at once: which figure Stripe reports as a fee, whose liability the collected tax is, and what a refund costs you. All three land in QuickBooks.

Automate your Stripe to QuickBooks sync →

What actually changes when Stripe is the merchant of record

Stripe's own comparison table is blunt about the distinction. Under Managed Payments the merchant of record is Stripe. Under every other Stripe product it is your business.

That is not a billing detail. It travels all the way to the customer. They check out through Link, their card statement reads LINK.COM* followed by your statement descriptor, and their purchase shows as Sold through Link. Receipts, invoices, refund notices and certain subscription emails are sent by Stripe from Link, and your own receipt settings in the Dashboard do not affect them.

The scope is deliberately narrow. Managed Payments is for digital products: SaaS, software, and digital content or downloads. It works with Stripe Checkout and Payment Links, and not with Elements, other advanced integrations, or Connect. Adaptive Pricing is enabled by default, so customers see prices converted into their local currency.

In exchange, Stripe takes on indirect tax compliance in more than 80 countries. In those countries Stripe calculates and collects the tax, registers with local authorities, files the returns, remits the money, and issues tax invoices where they are required. Stripe's documentation states it plainly: no action is required from you to satisfy indirect tax compliance requirements on sales of digital products in those countries.

And when the payment completes, Stripe withholds the indirect taxes.

That word, withholds, is where the accounting starts.

The fee column stops meaning fees

Here is the sentence that should change how you read your Stripe reports. From Stripe's Managed Payments documentation:

By default, the fee column in the following reports includes both Stripe fees and withheld tax.

The reports named are the Balance Change from Activity Report, the Payout Reconciliation Report, and the Ending Balance Reconciliation Report. Those are the three reports most reconciliation work is built on.

Stripe does give you the breakdown, but you have to ask for it. Two optional columns exist: withheld_tax, which isolates the indirect tax Stripe withheld and remitted on your behalf, and fee_net_of_withheld_tax, which gives you your actual Stripe processing fees with the tax stripped out.

Run the arithmetic on one sale. A 100.00 USD digital product sold to a customer in an EU country with 19% VAT. The customer pays 119.00. Stripe withholds 19.00 of VAT to remit. Your processing fee on the transaction is, say, 3.50.

With default columns, that sale reports a fee of 22.50.

Book 22.50 to a Stripe fee expense account and two things are wrong at once. Your processing cost for the sale reads as 22.50 against a real cost of 3.50, which inflates an expense line by more than six times. And 19.00 of tax, money that was never yours, has been reclassified as an operating expense and disappeared from anywhere a tax figure would be looked for.

This matters specifically for anything that syncs on balance transactions rather than on the Dashboard view, because that is where most of the automated reconciliation in this space happens. Acodei's own fee handling splits Stripe fees into two categories along Stripe's balance-transaction taxonomy: transactional fees, meaning the fee field on a charge, payment or refund balance transaction, and non-transactional fees, meaning standalone fee balance transactions such as stripe_fee, network_cost, application_fee, and adjustment rows with a reporting category of fee. Each category is routed independently, either onto the daily balance summary or into a separate expense.

Both categories are defined in terms of what Stripe reports as a fee. So the practical question to answer before you enable Managed Payments is not whether your sync tool works. It is which figure reaches it, and whether the withheld tax is still bundled inside that figure when it arrives.

If you want the background on how those fee categories behave normally, reconciling Stripe fees in QuickBooks is the full treatment, and non-transactional Stripe fees covers the standalone ones.

The tax you collected is not a liability you owe

The second change is quieter and harder to spot, because the records look completely normal.

Acodei supports two documented ways of getting Stripe tax into QuickBooks. US companies generally use the Tax Product approach: you create a non-inventory product in QuickBooks, map it to a liability account, and every Stripe tax amount rolls into a single line against it. You then use the Stripe Tax report to file with each jurisdiction, and you pay what you owe out of that liability account. Non-US companies can instead map each Stripe tax rate ID to a QuickBooks tax code, so QuickBooks tracks GST and VAT natively in its own tax module.

Outside those two approaches, plus the admin option for non-US companies that apply tax in QuickBooks after the fact, tax tracking from Stripe to QuickBooks is not possible. Stripe has to be the one calculating and reporting the rates, or QuickBooks has to apply them itself.

Notice what both approaches assume. They assume the tax Stripe calculated is tax you will later hand to a government. The liability account is a holding pen for somebody else's money that is passing through you.

Under Managed Payments, in the covered countries, it is not passing through you. Stripe registered, Stripe collected, Stripe files, Stripe remits. A liability account fed by those sales has nothing to draw it down, because you never write that cheque. Left alone across a year it becomes a growing balance on your balance sheet representing an obligation you do not have.

That is the kind of error that survives a long time. A liability that only ever grows does not fail a sync, does not error, and does not look wrong on a profit and loss statement. It shows up when somebody finally asks what the balance in that account is for.

Some of your tax is handled, and some of it is not

This is the part that makes Managed Payments genuinely awkward to account for, and it is worth being precise rather than reassuring.

Stripe's coverage is a list, not a blanket. For cross-border sales it covers a specific set of countries across Africa, Asia Pacific, Europe, the EU, Latin America and North America. For domestic sales it covers every country where Managed Payments is available with two carve-outs: Japan, where all domestic transactions remain your responsibility, and Singapore, where domestic business-to-business sales remain your responsibility. For Singapore, a sale counts as B2B if the customer indicates at checkout that they are buying as a business.

For anything outside the covered set, you are responsible for the whole compliance chain: registering locally, calculating and collecting, filing, and remitting. Stripe still acts as merchant of record on those transactions for payments, fraud, disputes and support, and you can use Stripe Tax to handle the tax side, with no additional charge for Stripe Tax calculation fees on Managed Payments transactions. Stripe Tax is the only tax solution compatible with Managed Payments, so a third-party tax engine is not an option here.

There is also an invoicing difference that follows from the split. For the transactions where you remain responsible for tax, Managed Payments sends invoices to your customers under your business name and tax details rather than under Sold through Link, LLC, and you configure that information in your Dashboard invoice settings.

So one QuickBooks file can hold two kinds of sale that look identical on the surface. One kind carries tax that Stripe will remit and you should not be tracking as a liability. The other carries tax that is entirely yours to register for, report and pay. They arrive through the same checkout, on the same payouts, in the same reports.

Telling them apart is a bookkeeping design problem, and it needs solving before the transactions exist rather than after. In practice that means keeping Managed Payments sales separable at the point they enter QuickBooks, whether by product mapping, by a distinct set of prices, or by the withheld_tax column on the reconciliation reports. What you cannot do is infer it later from a sales receipt.

A refund takes back more than you received

Refunds under Managed Payments have an asymmetry worth knowing before it happens rather than after.

When a transaction is refunded, the customer gets back the full amount including any sales tax they paid. That is what they should get. But Stripe documents that in certain jurisdictions it is required to retain and remit the original sales tax even on refunded transactions. In those jurisdictions, your account balance is reduced by the amount corresponding to the original sales tax.

Put the numbers on it using the sale from earlier. You received roughly 96.50 on a 119.00 charge, because 19.00 went to VAT and 3.50 to the fee. If that sale is refunded in a jurisdiction that keeps the tax, your balance gives back the full 119.00, including the 19.00 you never held. You are 22.50 down on a sale that netted you 96.50, which is the same 22.50 the default fee column reported at the start of this post.

Your customers can also request refunds directly from Link support, and Stripe can issue refunds within 60 days of the original transaction in certain cases. There is a second clause attached: if Stripe escalates a support case to you and you do not respond within 48 hours, Stripe might issue a refund without your approval. Whatever your refund posture is today, it needs to survive a refund you did not authorise.

On the QuickBooks side, the shape of the refund record decides whether the tax can be reversed accurately at all. A refund raised as a Stripe credit note carries a line-level tax breakdown, and Acodei's documentation is specific that tax refunds process correctly where the account uses advanced tax mapping together with credit memos. A payment-level refund with no item breakdown does not carry that detail, and the refunded tax cannot always be determined from it. That distinction is not specific to Managed Payments, and refunding tax on a Stripe charge goes through it in detail, but Managed Payments raises the stakes because more of your refunds now originate somewhere other than your own team.

Disputes are handled, and still cost you money

Stripe manages disputes on Managed Payments transactions. It reviews each one with automated and manual processes, submits evidence on your behalf when it decides to counter, and does not come to you for more evidence. If Stripe judges that you are unlikely to win, it may accept the dispute instead of fighting it.

"Handled" is not the same as "free", and the fee structure is specific:

A received dispute still incurs the dispute received fee.
When Stripe submits evidence to counter a dispute, Stripe covers the evidence submission fee.
If you counter a dispute yourself from the Dashboard, the evidence submission fee applies to you.
Dispute prevention tools, if Stripe enables them on your account for Managed Payments transactions, are charged to your account.

So dispute costs keep arriving in your Stripe balance, just with less correlation than before to anything your team did. Those fees reach QuickBooks the way other uncommon balance transaction types do, through Balance Transaction Mapping, rather than as per-dispute journal entries. If chargebacks are a material line for you, the accounting treatment for Stripe chargebacks is the place to start.

What Managed Payments takes off the table

Several integration paths are simply unavailable, and a few of them have accounting consequences worth checking before you commit:

Connect is not supported. Platform and marketplace integrations cannot use Managed Payments.
Advanced integrations are not supported. Elements and other advanced payment flows are out. Checkout and Payment Links are the two supported surfaces.
Subscriptions must be created through Checkout or Payment Links. Billing still runs the subscription, but you cannot create one outside those two surfaces.
One-off invoices on a Customer are not supported, nor is generating an invoice for a subscription outside the billing period, nor attaching invoice items on a Customer object to a Managed Payments subscription.
Third-party tax integrations are not supported. Stripe Tax or nothing.
Custom domains are not supported on Managed Payments checkouts.

The invoicing constraints are the ones to think hardest about if your QuickBooks file runs on Accounts Receivable rather than on sales receipts. If you currently raise ad-hoc Stripe invoices alongside your self-serve checkout, that half of your workflow does not move to Managed Payments with the rest. Our Stripe invoicing with A/R in QuickBooks page covers what the invoice-based workflow depends on, which is the thing you would be splitting.

What to settle before you switch it on

Managed Payments is a good product for the business it is built for. It is also a change of seller, and a change of seller is an accounting policy decision rather than a settings change. Five things are worth resolving first:

Decide, with your accountant, whether you present revenue gross or net. The customer pays 119.00, Stripe remits 19.00 of it as the merchant of record, and you receive the remainder less fees. Which of those figures is your revenue is a judgement about your arrangement with Stripe, and it is not a question a sync tool answers for you.
Turn on the breakout columns. Pull the Balance Change from Activity, Payout Reconciliation and Ending Balance Reconciliation reports with withheld_tax and fee_net_of_withheld_tax included, and compare them against what your books currently show as Stripe fees.
Work out how covered and uncovered sales will be told apart in QuickBooks, before the first one posts. Japan domestic, Singapore domestic B2B, and every country outside the coverage list are still yours.
Check your tax liability account. If you are using a tax product mapped to a liability account, decide what should happen to sales where Stripe remits, because that account will otherwise accumulate a balance nobody discharges.
Re-read your refund policy against a 48-hour clock you do not control.

One honest note to close on. Acodei's product documentation covers how Stripe fees and Stripe Tax are categorised and mapped into QuickBooks, and that is what this post draws on. It does not yet cover Managed Payments specifically, which is a gap we are closing rather than one we are going to paper over with a guess. If you sync Stripe to QuickBooks and you are weighing Managed Payments up, the useful conversation is the one before you enable it.

Frequently asked questions

Does Managed Payments change who my customer thinks they bought from?

Yes. Stripe is the merchant of record, customers check out through Link, and their purchase shows as Sold through Link. Their card statement reads LINK.COM* followed by your statement descriptor. Receipts, invoices and refund notices are sent by Stripe from Link, and your own Dashboard receipt settings do not apply to those emails.

Why did my Stripe fee expense jump after enabling Managed Payments?

Most likely because of the report columns rather than the fees. In the Balance Change from Activity, Payout Reconciliation and Ending Balance Reconciliation reports, the fee column includes both Stripe fees and withheld tax by default. Pull the same reports with the optional withheld_tax and fee_net_of_withheld_tax columns to separate the two before comparing against your books.

Should the tax Stripe collects still go to a tax liability account in QuickBooks?

For sales in the countries where Managed Payments handles compliance, Stripe registers, files and remits, so there is no payment for you to make out of a liability account. For sales outside that coverage, including all domestic Japanese sales and domestic B2B sales in Singapore, the compliance obligation is still yours. A single QuickBooks file can contain both, which is why the two need separating at the point they post rather than at year end.

Can I still send Stripe invoices to customers under Managed Payments?

Subscriptions created through Checkout or Payment Links still run on Stripe Billing and produce invoices. What is not supported is generating a one-off invoice on a Customer object, generating an invoice for a subscription outside the billing period, or attaching invoice items on a Customer to a Managed Payments subscription. If a meaningful share of your revenue is invoiced ad hoc, that part of the workflow stays where it is.

Does a refund cost me more than the sale earned?

In certain jurisdictions, yes. The customer is refunded the full amount including tax, and Stripe documents that it is required in some jurisdictions to retain and remit the original sales tax even on refunded transactions. In those cases your account balance is reduced by the amount corresponding to that original tax, which you never received.

Does Managed Payments work with Stripe Connect?

No. Connect platform and marketplace integrations are explicitly unsupported, as are Elements and other advanced payment flows. Managed Payments runs on Checkout and Payment Links only.

Can I use my existing tax software with Managed Payments?

No. Stripe Tax is the only tax solution compatible with Managed Payments, and third-party tax providers are not supported. For transactions in countries Managed Payments does not cover, Stripe Tax calculation fees are not charged on Managed Payments transactions.

Managed Payments removes a genuine burden, and it does it by moving the seller. The work that moves to you is smaller but sharper: making sure the numbers landing in QuickBooks still mean what your chart of accounts says they mean.

Start a free trial →

Stripe Managed Payments in QuickBooks: Who Owes the Tax