Stripe Surcharges and How to Book Them in QuickBooks

A surcharge is one of the few things a Stripe charge can carry that makes the number in QuickBooks larger than the sale you actually made. The customer agreed to pay $103 for a $100 order, the extra $3 covers your cost of taking the card, and Stripe processes all of it as one amount. By the time that charge reaches QuickBooks, the sales line reads $103 with nothing to say why. Get the treatment wrong and you overstate revenue, misread your true cost of card acceptance, and in some places mis-handle sales tax. This post covers what a surcharge is, where you are allowed to charge one, and exactly where the surcharge line belongs in your books. If you would rather stop hand-picking these lines out of Stripe, start a free trial of Acodei and let the charge sync post itself.

What a surcharge actually is, and where you can charge one

A surcharge is money the customer pays you on top of the sale price, specifically to offset your cost of accepting a card. Stripe's own framing is exactly that: surcharging "allows you to offset some of the cost of accepting card payments," per Stripe's surcharging documentation. It is not a Stripe fee, and it is not a discount. It is your revenue-adjacent line, added at checkout, disclosed to the buyer before they pay.

Where you can charge one, and how much, is not up to you. It is set by law and card-network rules, and Stripe enforces a hard ceiling per country and card type:

Two things in that table catch people out. First, in the US and Canada you can surcharge credit cards only. Run a surcharge on a debit card in those markets and Stripe returns the surcharge status as unavailable for that payment method, because the funding type does not qualify. Second, the percentage is a ceiling, not a suggestion. Stripe returns a surcharge.maximum_amount on the PaymentIntent, and it validates your surcharge against that number by default. Go over it and you get an error rather than a charge.

There is a time-sensitive change worth flagging if you operate in Australia. Stripe is disabling support for surcharging in Australia on October 1, 2026, following the Reserve Bank of Australia's effective prohibition on card surcharging. If your Australian integration surcharges today, Stripe's guidance is to remove it before that date. That is not an accounting decision, but it changes what will and will not show up in your ledger after that day.

Surcharging works across Visa, Mastercard, Amex, Discover, Eftpos, Diners, Interac, JCB, Maestro, and Unionpay where the country permits it. Beyond the caps, Stripe puts a list of compliance obligations squarely on the merchant. You must:

• Disclose the surcharge amount and the total cost to the cardholder before they buy, and show it separately on the receipt.
• Let the customer cancel or switch to another payment method after they see the surcharge.
• Surcharge consistently across card networks and card products.
• Notify your acquirer or card network of your intent to surcharge, where your jurisdiction or the network requires it.

Stripe is blunt about who owns the risk: "You're fully responsible for any fines, penalties, or losses arising in connection with your failure to adhere to applicable surcharging requirements." Some US states, and some provinces and territories elsewhere, restrict or prohibit surcharging outright, and Stripe explicitly makes checking your local rules your job, not theirs. Confirm what applies where you sell before you turn it on. None of that is the part your bookkeeper asks about, though. Their question comes after the money lands.

The bookkeeping problem: the charge arrives larger than the sale

Here is the mechanical detail that decides everything downstream. Stripe charges only the top-level amount on a PaymentIntent, and it does not add the surcharge on top for you. You have to pass the total already inclusive of the surcharge in that one field. Stripe's own example: a $10.00 subtotal with a $0.20 surcharge means you send 1020 in amount, and you record the 20 separately in amount_details[surcharge][amount].

So the surcharge is not a second charge and it is not a separate line item on the sale. It is a sub-field inside a single amount. The charge that settles, the charge that shows up in your payout, and the charge that any accounting tool reads, is $10.20. The $0.20 lives in a details field that you have to go looking for.

That is why a surcharged sale lands in QuickBooks looking like a $10.20 sale of a $10.00 product. Your revenue is overstated by the surcharge unless you split it back out, and every downstream number that leans on revenue moves with it: gross sales, your effective processing rate, revenue-based tax, and any commission or royalty calculated on sales. The surcharge exists to cover a cost, so booking it as product revenue tells you your product sold for more than it did and quietly hides part of what card acceptance costs you.

Where the surcharge line belongs in your books

The honest answer is that this is a call for you and your accountant, because it interacts with how you report revenue and how your jurisdiction taxes surcharges. But "ask your accountant" is not an answer on its own, so here is the defensible default and the reasoning behind it.

Treat the surcharge as a recovery of your cost of accepting cards, not as product revenue. That gives you two clean ways to book it:

• As a contra to your processing-fee expense. The surcharge lands in the same account where Stripe's fees are recorded, reducing it. Your profit and loss then shows the net cost of card acceptance, which is the number the surcharge was invented to move. This is the tightest match to the economic substance: you spent money to accept a card, the customer handed some of it back, and the two net against each other.
• As a dedicated income account, something like "Surcharge recovery" or "Card processing recovery," kept separate from product sales. This keeps your gross processing fees and your gross recoveries both visible instead of netted, which some owners prefer for reporting. It still keeps the surcharge out of product revenue.

What to avoid is folding the surcharge into product sales revenue. It is the path of least resistance, because the charge already arrives inside the sales line, and it is the one that does the most damage to the numbers you actually use.

One caveat you cannot skip: in several US states and other jurisdictions, the surcharge itself is subject to sales tax, and whether it is depends entirely on where you sell. Stripe does not decide that for you and neither should a blog post. If you collect sales tax, put the surcharge treatment in front of whoever handles your tax filings before you set the accounts up.

How to find the surcharge in your Stripe data

If you are splitting the surcharge out by hand, you need to know where the number actually lives. It is on the PaymentIntent, in amount_details.surcharge.amount. That is the field Stripe's own prebuilt receipts read to display the surcharge as a separate line, and the field you would read for a custom receipt or an export.

For a whole month at once rather than one charge at a time, Stripe exposes the surcharge in Sigma. The payment_intents table carries an amount_details_surcharge_amount column, which is the surcharge amount applied to the transaction and sent to the card network. A single query summing that column against your charges gives you the total surcharge to reclassify for the period, which is far less painful than opening PaymentIntents one by one. If you already run a month-end close in Sigma, this is one more line in a query you are probably writing anyway, as covered in our walkthrough of Stripe Sigma queries for month-end close.

Refunds are the piece people forget. Per Stripe's surcharge refund rules, card-network rules and some laws require you to return the surcharge when you refund. On a full refund you return all of it; on a partial refund you return a prorated share. Stripe's worked example: a customer returns a $60.00 item from a $100.00 order that carried a $1.50 surcharge, so you refund $60.90, which is the $60.00 plus 60/100 of the $1.50. If your books split the surcharge on the sale, they have to split it on the refund too, or the recovery account drifts.

What this looks like once it syncs to QuickBooks

None of the above changes how the charge itself reaches QuickBooks, and it helps to be precise about what a sync tool does and does not do here.

Acodei records each successful Stripe charge as a QuickBooks Sales Receipt, deposited into your Stripe holding account, with the line items resolved through your product mapping. The Stripe processing fee is handled on its own: by default it posts as a negative line that nets the receipt down to what actually entered your balance, or, if you record fees as an expense, it posts as a separate expense and the receipt stays gross. That fee handling is deliberate, and it is why Acodei can keep gross sales and processing fees visible as distinct numbers rather than blending them.

The surcharge is different from the fee, and this is the part to understand. Because Stripe folds the surcharge into the single amount it processes, and Acodei records the charge from that amount against your mapped products, the surcharge arrives inside the sale total rather than as its own line. It is not a separate line item on the Stripe charge, so it is not something line-item mapping can pull apart on its own. If you want the surcharge sitting in a recovery or contra-expense account, that is a reclassification you set up in QuickBooks, informed by the surcharge total you pull from amount_details.surcharge.amount or from Sigma. What Acodei removes is the manual charge-by-charge entry underneath it, so the only judgment left is the one that should stay with you: which account the recovery belongs in. For how the fee side of this is reconciled end to end, our guide on reconciling Stripe fees in QuickBooks Online is the canonical reference, and the Stripe fee glossary entry defines the fee itself if you want the distinction spelled out.

If you run more than one processor, the same discipline matters even more, since each one carries surcharges and fees in a different shape. Our post on handling Stripe, PayPal, and Square in one QuickBooks file walks through keeping those balances separate.

Ready to stop entering surcharged charges by hand? Start a free trial of Acodei.

Frequently Asked Questions

Is a Stripe surcharge revenue?

Not in the way product sales are. A surcharge is money the customer pays to offset your cost of accepting their card, so the defensible treatment is to book it as a recovery of that cost, either as a contra to your processing-fee expense or in a dedicated recovery income account. Folding it into product sales revenue overstates your gross sales and hides part of your true card-acceptance cost. Confirm the exact treatment with your accountant, because it interacts with how you report revenue and how your jurisdiction taxes surcharges.

Why does my Stripe charge show up in QuickBooks larger than the sale?

Because Stripe processes one amount, and that amount already includes the surcharge. Stripe charges only the top-level amount field on the PaymentIntent and expects you to pass the total inclusive of the surcharge, with the surcharge recorded separately in amount_details[surcharge][amount]. A $10.00 order with a $0.20 surcharge settles as $10.20, so that is the figure that flows into your accounting. The $0.20 sits in a details field you have to read separately.

Can I surcharge debit cards on Stripe?

It depends on the country. In the United States and Canada, Stripe permits surcharging on credit cards only, so a debit card returns an unavailable surcharge status. In Australia and New Zealand you can surcharge all cards, up to a 4% cap. Note that Stripe is disabling surcharging in Australia on October 1, 2026, following the Reserve Bank of Australia's prohibition.

How do I find the total surcharge for a period?

Read the amount_details.surcharge.amount field on individual PaymentIntents, or, for a whole period at once, query the amount_details_surcharge_amount column in Stripe Sigma's payment_intents table. Summing that column gives you the surcharge total to reclassify out of sales and into your recovery or contra-expense account.

Do I have to refund the surcharge?

Yes. Card-network rules and some laws require returning the surcharge on a refund: all of it on a full refund, and a prorated share on a partial one. Stripe's example is a $60.00 return from a $100.00 order carrying a $1.50 surcharge, where you refund $60.90. If your books split the surcharge on the sale, split it on the refund too.

The takeaway

A Stripe surcharge is a small line with an outsized effect on your numbers, because it rides inside the charge amount and lands in QuickBooks looking like product revenue. Decide with your accountant whether it belongs against your processing-fee expense or in a dedicated recovery account, keep it out of product sales either way, and pull the totals you need from amount_details.surcharge.amount or Sigma. Then let the charge sync itself so the only decision left is the one worth your time. Start a free trial of Acodei to get the Stripe-to-QuickBooks side handled.