Stripe Radar and Billing Fees in QuickBooks Online

Radar, Billing, and Stripe Tax fees never appear on a sales receipt, because they were never on a sale. Where non-transactional Stripe fees land in...

Acodei Content Team · 8/4/2026 · 14 min read

You opened the sales receipt looking for the Radar fee. It was not there. You checked the next one, and the one after that, and eventually you checked a whole day of receipts and it was on none of them. Then you found it sitting by itself, on a date with no obvious connection to anything you sold.

Nothing is broken. The fee was never on a sale, so it was never going to be on a sales receipt. Radar, Billing, Stripe Tax, and Identity fees are charged for services rather than for processing a particular payment, and Stripe records them as free-standing movements against your balance. A fee that is not attached to a sale cannot be netted against one.

Start a free trial and connect Stripe to QuickBooks, or keep reading for where these fees actually land and why.

Stripe uses one word for two different things

Most of the confusion here traces back to a naming collision in Stripe's own API, and it is worth being exact about because the API is exact about it.

Open Stripe's balance transaction object reference. The type field can take the value stripe_fee. Stripe's balance transaction types reference defines that value as "Fees for Stripe software and services (for example, for Radar, Connect, Billing, and Identity)."

Now look at a different field on the same object. Every balance transaction carries a fee, documented as "Fees (in the smallest currency unit) paid for this transaction. Represented as a positive integer when assessed," and a fee_details, "Detailed breakdown of fees (in the smallest currency unit) paid for this transaction." The sub-field fee_details.type is documented as "one of: application_fee, payment_method_passthrough_fee, stripe_fee, tax, or withheld_tax."

So stripe_fee appears in two places, meaning two different things.

As a balance transaction type, stripe_fee is a row in your balance report. It is a standalone charge for a Stripe service, and there is nothing else on that row.

As a fee_details.type, stripe_fee is a column on some other row. It is a component of the fee deducted from a charge, a payment, or a refund that happened for its own reasons.

That distinction carries the rest of this article. A fee that is a column belongs to the transaction it sits on, and it can be netted against that transaction because the transaction is right there. A fee that is a row belongs to nothing. There is no sale on the row to net it against, because no sale produced it.

Stripe's guidance for accounting work is to classify by reporting category rather than by type, on the grounds that the reporting_category field "improves the type field by providing a more useful grouping for most finance and reporting purposes." Under that scheme stripe_fee becomes the fee category. That is the right lens for a monthly close. It does not, however, rescue you from the row versus column problem, because both kinds of fee are genuinely fees. The difference is structural, not categorical.

Which Stripe products bill you this way

Stripe's pricing page tells you which products generate rows, and the units are the interesting part.

Radar is listed at "Starting at $0.05 per screened transaction" on pay as you go, or "Starting at $10.00 per month" on the monthly plan. Billing is listed at "0.7% of Billing volume" on pay as you go, or "Starting at $620.00 per month, 1-year contract." Stripe Tax is listed at "0.5% per transaction, where you're registered to collect taxes" for the no-code version, "$0.50 per transaction" for the API version, and Tax Complete at "Starting at $90.00 per month, 1-year contract." Identity is "$1.50 per verification" and "$0.50 per lookup."

Read the unit on Radar again: per screened transaction, not per successful sale. A payment that Radar blocked as fraudulent still cost you a screening fee, and that payment produced no charge, no revenue, and no sales receipt. There is no possible bookkeeping arrangement in which that fee sits on a sale, because the whole point of the fee is that the sale did not happen. The same logic applies to an Identity verification for someone who never bought anything.

Billing at a percentage of volume is a different shape again. It is a percentage of something that already occurred, calculated over a period and charged in aggregate. Even in principle you could not attach it to a single invoice, because it was never computed per invoice.

This is why "just put the fee on the sale" is not a preference the software is withholding from you. For a large share of these fees there is no sale to put it on.

What that means for your books

If you have been reconciling by matching every fee to the sale that produced it, these are the fees that will refuse to match, and they are not errors. They are operating expenses of the same kind as a software subscription. Radar is a fraud tool you rent. Billing is a subscription engine you rent. The fact that Stripe collects payment by deducting from your balance instead of charging your card is a payment mechanism, not an accounting classification.

The practical consequence is that your Stripe fee expense for a month is made of two streams with different timing. Transactional fees arrive continuously, one per sale, spread across the month exactly as your sales are. Service fees arrive in lumps on Stripe's billing schedule. If you compare fee expense to revenue on a daily basis you will see noise that means nothing. Compare it monthly and the picture is stable.

Where Acodei puts them in QuickBooks

Acodei creates a QuickBooks product called "Stripe Fees – Acodei" during onboarding and maps it to an account you choose. All fees are assigned to that product, which avoids maintaining a separate product for every fee type.

The placement then depends on which kind of fee it is.

Transactional fees follow your sync mode. In real-time sync, Acodei adds a fee line to each Sales Receipt, by default a negative line using the Stripe Fees product for the exact fee amount. In daily-summary mode, the day's fees are summed into a single aggregated fee line on that day's Deposit, netting gross sales down to the payout figure.

Non-transactional fees do not follow your sync mode, and this is the answer to the question that brought you here. Stripe fees that are not tied to a specific charge, such as Radar or Billing subscription fees, are captured when they occur and posted as part of a Daily Balance Summary, even if your charges sync in real time. Acodei includes them in a daily Deposit or a separate Journal Entry, because they happen outside of individual customer payments. A monthly Stripe Billing fee or a Connect platform fee appears on that day's summary rather than as part of any sale.

So a real-time account has a hybrid: sales flowing through individually as they happen, plus a daily summary entry that exists specifically to catch the movements that no sale can carry. That is not an inconsistency in the sync. It is the only correct place for a fee with no sale attached.

Timing is worth setting expectations on too. Transaction fees appear immediately with their sale. Service fees such as Stripe Tax usage fees and Radar fees may post at the end of the day or whenever Stripe charges them, which is why a fee can show up on a date that looks arbitrary from inside QuickBooks. It is not arbitrary. It is the date Stripe billed it.

The routing switch most people do not know they have

Acodei splits fees into two categories following Stripe's balance-transaction taxonomy, and each category is independently routable.

Transactional means the fee field on a charge, payment, or refund balance transaction. The column, in the language above.

Non-transactional means standalone fee balance transactions: stripe_fee, network_cost, application_fee, and adjustment entries with the reporting category fee. That last group is where Billing, Radar, and Stripe Tax product fees live. The rows.

Per-user flags route each category either onto the daily balance summary line items or into a separate Purchase, which is a QuickBooks expense. That means you can have transactional fees netted on the summary, where they belong next to the sales that produced them, while Stripe service fees post as expenses, where they read like the subscriptions they are. The default preserves the original single combined Purchase behavior, so if nobody has changed it, that is what you have.

Worth knowing before you ask for it: a change to your fee method does not rewrite history. Existing transactions keep their old treatment until you resync them.

Where fees can appear at all is constrained by your holding account. Fees can be a line item on the Sales Receipt, which is the default. They can be a line item on the Bank Deposit, which requires Undeposited Funds. Or they can be recorded as an Expense, which is available by default on a non-Undeposited-Funds asset account, and on Undeposited Funds only when Invoice Sync is enabled. On a non-Undeposited-Funds account with Invoice Sync, Expense is the only option.

One rule never bends: Stripe fees are never added to invoices. Putting a fee on the invoice would make the invoice total disagree with the payment total, so fees are handled through Sales Receipts, Deposits, or Expenses instead.

The fees that travel with them

Once you are looking at the daily summary rather than the sales receipt, several other balance movements turn out to live there too.

stripe_fx_fee is Stripe's currency conversion fee, charged when Stripe converts funds. Acodei folds it into the same Stripe Fees mapping and adds it to the fee total. Multi-currency fees are recorded in the payout currency.

network_cost is a fee a payment network charged Stripe, passed through to you. It is worth noting that it does not appear among the types listed in Stripe's public balance transaction types reference, which is part of why it puzzles people when it shows up. Acodei treats it as a Stripe fee and includes it in the daily summary with the others.

tax_fee is the one that misleads. Stripe defines it as "Taxes collected by Stripe to be remitted to the appropriate local governments. Typically, this is a tax on Stripe fees." It is tax on what Stripe charged you, not tax you collected from a customer. Acodei records it against the same fee account, and it may appear as a separate line or be combined into the Stripe Fees line for the day. Critically, it should be mapped to an Exempt or Out of Scope tax code, under Account Mapping and then Stripe Tax settings, so QuickBooks does not count it as sales tax you owe. After changing that setting, resync the affected transactions. The VAT and GST Stripe charges on its own fees guide covers that case in full.

fee_credit_funding is the pleasant one. Stripe fee credits applied to your balance post as positive lines that offset fee expense. If you see a "Fee Credit" line in the positive direction, it is reducing fees you were previously charged.

application_fee is not a cost at all if you run a Connect platform. Stripe defines it as "Earnings you've generated by collecting platform fees via Stripe Connect charges." Acodei posts it as income to the platform, as a separate positive line on that day's summary deposit. Stripe does not generally fire an explicit webhook to a platform for the platform's own fee, so these are typically caught by the daily balance scan rather than in real time.

Instant payout fees also land on the Daily Balance Summary with the day's other fees, and a fee on a payout's own balance transaction is recorded against the mapped fee product at payout time.

Finding a fee you cannot find

The documented workflow is short. If you do not see a Stripe fee you expected, check the Acodei Data Feed for a Daily Summary entry on the date Stripe charged the fee. Not the date of the sale you were looking at, and not the payout date. The date Stripe billed it.

That single instruction resolves most of these tickets, because the fee is almost always present and simply not where the person was looking.

Two adjacent facts save time on the next question. Uncommon balance transaction types land where you configure them under Account Mapping and then Balance Transaction Mapping, a section hidden until you toggle Customize, and an unmapped type will prompt you to map it. And Acodei counts fees, adjustments, and payouts as separate events, so comparing Stripe's payments count against an Acodei transaction count will never match. A higher count is correct, not a duplicate.

At month end

Three habits make these fees stop being a monthly surprise.

Expect two streams rather than one. Transactional fees track your sales. Service fees track Stripe's billing calendar. A month where fee expense jumped without a sales jump usually means a Billing or Tax charge landed, not that your processing cost changed.

Decide deliberately where service fees should sit. If you want to see what Stripe's products cost you as a line you can manage, route non-transactional fees to a Purchase and give them their own account. If you only care about net payout accuracy, leaving them on the summary is fine. Both are defensible, but the default was not chosen for your business.

Check the tax code on fee tax once and never again. tax_fee mapped to a taxable code quietly inflates your sales tax liability every month it occurs.

For reconciling Stripe fees against your payouts generally, the complete guide to reconciling Stripe fees in QuickBooks Online is the place to start. For the definitions and fee types on one page, see the Stripe fee glossary entry. And if you are deciding between the two sync modes referenced throughout this article, daily summary versus real-time sync compares them directly.

Frequently asked questions

Where is my Stripe Radar fee in QuickBooks? On a Daily Balance Summary entry for the date Stripe charged it, not on a sales receipt. Radar is billed per screened transaction rather than per sale, so there is frequently no sale to attach it to at all. Check the Acodei Data Feed for a daily summary entry on that date.

Why do Radar and Billing fees not appear on my sales receipts even though I use real-time sync? Because non-transactional fees are posted on a Daily Balance Summary even when charges sync in real time. They are not tied to a specific charge, so real-time sync has no transaction to attach them to. A real-time account will have both individual sales entries and a daily summary that carries these movements.

What is the difference between a transactional and a non-transactional Stripe fee? A transactional fee is the fee field on a charge, payment, or refund balance transaction, so it arrives with that sale. A non-transactional fee is its own standalone balance transaction, such as stripe_fee, network_cost, or application_fee. Acodei follows the same split and lets you route each category independently.

Can I record Stripe service fees as expenses instead of netting them against sales? Yes. Fee categorization lets you route non-transactional fees into a separate Purchase in QuickBooks while transactional fees stay netted on the daily summary. The default keeps the original combined behavior, and changing the setting does not rewrite existing transactions, so resync anything you want restated.

Why does my Stripe fee total in QuickBooks not match my processing fees? Because several things map to the same fee account. Currency conversion (stripe_fx_fee), network costs passed through, tax on Stripe's fees (tax_fee), and Stripe product fees such as Radar and Billing all post against the Stripe Fees product alongside per-charge processing fees.

Is tax on Stripe fees the same as sales tax I collected? No, and treating it as such overstates your liability. Stripe defines tax_fee as tax it collects to remit to local governments, typically on its own fees. Map it to an Exempt or Out of Scope tax code in Account Mapping under Stripe Tax settings, then resync the affected transactions.

What is a Fee Credit line on my summary? A Stripe fee credit applied to your balance. It posts as a positive line offsetting fee expense, so it reduces what Stripe previously charged you rather than adding income.

Put your service fees where you can see them

Radar, Billing, Stripe Tax, and Identity are real operating costs, and most businesses running them cannot say what they spent last quarter, because the fees are buried in a netted payout figure. Acodei syncs Stripe charges, invoices, refunds, payouts, and every category of fee into QuickBooks Online, and lets you route service fees to their own expense account instead of leaving them mixed in with processing costs.

Start a free trial to connect Stripe and QuickBooks, or read how Stripe fees work as a whole before you decide where to put them.

Share

Automate your Stripe to QuickBooks sync

Save hours every month. Acodei automatically syncs your Stripe transactions, invoices, and payouts to QuickBooks Online.

Get more operational finance guides like this one

We will only send high-value product and finance content.