The Stripe Fees Report, and the Month a Fee Belongs To

Stripe deducts its fees before the money reaches you. By the time a payout lands in your bank account the fees are already gone, netted out of the gross, and the only way to see what was taken is to go and look.

The Fees report is where Stripe itemises it. It is the third of Stripe's reconciliation reports, and the one most bookkeepers never open, because the other two answer the question "did the cash tie out" while this one answers a different question: what did Stripe charge me, and for what.

That second question has a harder edge than it looks. The same fee carries several different timestamps, Stripe publishes a separate version of the report pivoted on two of them, and the two versions put the same fee in different months whenever the originating event and the balance impact straddle a period end.

<p><a href="https://app.acodei.com/signup">Start a free trial</a></p>

Where this report sits

Stripe's two cash reconciliation reports, the Balance report and the Payout reconciliation report, are alternatives to each other. Which one you should be running is decided by your QuickBooks setup, and we have written that comparison up separately.

The Fees report is not an alternative to either. It is orthogonal. The cash reports tell you how much money moved and when. The Fees report tells you what the deductions inside those movements were for, broken down by the Stripe product that charged them.

You will find it in the Dashboard under Reports, as All Fees, and through the Reporting API. Stripe's own documentation for it is at docs.stripe.com/reports/all-fees.

Two pivots, and the month a fee belongs to

This is the part worth slowing down for.

Stripe publishes the report in four shapes. Two are pivoted on the date the fee hit your balance, and two are pivoted on the date of the event that incurred it:

Report type	Pivot
all_fees.balance_transaction_created.summary.2	When the fee hit your balance
all_fees.balance_transaction_created.itemized.2	When the fee hit your balance
all_fees.incurred_at.summary.2	The originating event
all_fees.incurred_at.itemized.2	The originating event

Most of the time these agree, because a card fee is assessed the instant the charge settles and both dates fall on the same day. They stop agreeing at the edges. A fee for activity that spanned a billing period, a fee assessed on a payout, a fee from a product that bills on a cycle rather than per transaction: any of these can be incurred in one month and hit your balance in the next.

That is not a reporting curiosity. It is the accrual-versus-cash question in miniature. If you are closing on a cash basis, the balance transaction pivot is the one that matches what actually left your balance in the period. If you are matching fees to the revenue that generated them, the incurred_at pivot is the one that puts the fee alongside its charge.

Pick one, write down which one you picked, and use the same one every month. The failure mode here is not picking wrong. It is picking differently in March than you did in February, and then spending a day trying to find a discrepancy that you created yourself.

The same fee actually carries four timestamps

Two of those dates get their own report. The itemized download carries more than two, and knowing what each one means saves a lot of guessing:

• incurred_at is the time of the originating event that incurred the fee.
• balance_transaction_created is the time the fee transaction affected your Stripe balance.
• fee_transaction_created is the creation time of the fee transaction that deducts the fee from your v1, v2, or credit balances.
• settled_at is the time the fee settled. For an invoice, Stripe defines this as the date it sent the invoice.

The last two are the ones people trip on, because they exist for a reason that only becomes obvious once you look at the next column.

settled_via, or the fee that never touched your balance

The itemized report carries a settled_via column. Stripe documents five possible values: credit, balance, v2_balance, invoice, and multiple.

Only balance and v2_balance describe a fee that came out of a Stripe balance. A fee settled via credit was paid out of your fee credits balance. A fee settled via invoice was billed to you rather than deducted. A fee marked multiple was settled across more than one of these.

For anyone reconciling fee expense against a balance movement, that column is the first thing to filter on, because a fee that never debited a balance will never appear in your clearing account, no matter how carefully you reconcile it. It is not missing. It was settled somewhere else.

One honest caveat, which Stripe's own documentation creates. The report excludes "any post-paid invoiced fees", while invoice appears as a legal settled_via value. The two statements are not easy to reconcile from the outside. The practical reading is that invoiced fees are represented incompletely, so the Fees report should not be your only record of what Stripe billed you if you are on a post-paid arrangement.

incurred_by, or which charge produced this fee

If you have ever stared at a fee and wanted to know which transaction caused it, incurred_by is the column. It holds the ID of the object that incurred the fee, and incurred_by_type tells you what kind of object that is. Stripe lists the common values as charge, refund, payout, transfer, and invoice.

Note refund and payout in that list. Fees attached to refunds and fees attached to payouts are exactly the ones that confuse a reconciliation, because they are not attached to a sale and so they do not show up where a bookkeeper instinctively looks for them. Filtering the itemized report by incurred_by_type is the fastest way to account for them.

Two columns are on their way out and are worth not building a process around. fee_category is deprecated, no longer maintained, and may have incomplete data; Stripe directs you to product and suite instead. And balance_transaction_description is deprecated in favour of fee_description.

What the report leaves out

The Fees report is not a complete record of everything Stripe has charged you. Stripe states the exclusions plainly: Terminal device purchases, Stripe Capital fees, Atlas fees, and any post-paid invoiced fees.

If you sell in person, the hardware you bought is not in here. If you have taken Stripe Capital financing, those costs are not in here either. Treat the report as authoritative for transaction and product fees and as silent on everything else.

There is also a documented discrepancy against the Balance Summary. In Stripe's words, the Balance Summary "might not subtract revenue share from its total fees, which can lead to discrepancies". If you are on a revenue share arrangement and your two reports disagree by an amount you cannot place, that sentence is probably your answer.

The 96-hour rule

Fee data becomes available in this report 96 hours after a fee affects your balance.

Four days. That single constraint decides whether the Fees report can be part of your close at all. If you close on the first or second business day of the month, the last few days of fee data will not be there yet, and pulling the report early will silently understate the month. If fees are material to your close, either move the fee step later or accept that you are closing on a partial figure and truing up afterwards. Our month-end close checklist has the rest of the sequencing.

What your QuickBooks books show instead

Acodei builds your QuickBooks records from Stripe balance transactions. The two views line up on substance but not on layout, so knowing the mapping saves you from chasing differences that are not differences.

A few things are worth knowing about how the fees reach QuickBooks.

During onboarding Acodei creates a dedicated Stripe fees product in QuickBooks and maps it to an account you pick, so that fees do not need a separate product each. On accounts eligible for the newer product mapping, advanced fee mapping is live: transaction fees resolve through the mapping rules with more granularity, falling back to the legacy fee product otherwise.

Where the fee line physically lands is decided by your holding account and your Invoice Sync setting, not by the fee itself. With Undeposited Funds, a fee can sit as a line on the Sales Receipt or on the Bank Deposit. With a regular asset clearing account, it can sit on the Sales Receipt or post as an Expense. With Invoice Sync enabled it can never sit on the invoice itself, because adding it there would throw the invoice total out against the payment.

Acodei also splits fees into two categories, following Stripe's own balance transaction taxonomy. Transactional fees are the fee field on a charge, payment or refund balance transaction. Non-transactional fees are standalone fee balance transactions: stripe_fee, network_cost, application_fee, and adjustment rows with a reporting category of fee. Each category can be routed independently, either onto the daily balance summary lines or into a separate Purchase, which is how you end up with Radar and Billing fees sitting somewhere different from your card processing fees. That routing is covered in more depth in our post on Radar and Billing fees in QuickBooks.

Two specific cases catch people out. Instant payout fees are captured on the daily balance summary with the day's other fees. And if you change your fee method later, historical transactions do not update themselves; they need a resync to take the new shape.

One more, on currency. If a transaction converted, the fee matches the converted currency. A CAD charge settling into a USD balance produces a USD fee, so do not expect the fee currency to match the charge currency.

Tying the two together

A short sequence that works:

1. Wait until at least 96 hours after month end.
2. Pull the itemized report on whichever pivot you committed to, for the period you are closing.
3. Filter out any row where settled_via is not balance or v2_balance. Those did not come out of your Stripe balance and will not be in your clearing account.
4. Total the remainder by product or suite.
5. Compare against the fee account in QuickBooks for the same period.
6. If the QuickBooks figure is higher, check tax first. On Stripe's side the amount column is the fee and any tax on it sits in a separate tax column, so a QuickBooks account that carries both will read higher than amount alone. How fee tax lands in your books depends on your Stripe Tax configuration in Acodei, which has a default fee tax rate setting of its own. Our post on VAT and GST on Stripe fees covers it.
7. If a gap remains, work it through the fee reconciliation process.

Frequently asked questions

What is the Stripe Fees report?

It is a Dashboard and Reporting API report listing the fees taken from your Stripe balance, fee credits balance and financial accounts, including fees charged by Stripe, by card networks, and by external partners. It comes in a summary form and an itemized, transaction-level form.

Why do two Stripe fee reports show different totals for the same month?

Because they are pivoted on different dates. One version keys off when the fee hit your balance, the other off the originating event that incurred it. A fee incurred in one month whose balance impact falls in the next will appear in a different month in each version. Both are correct; they answer different questions.

Why is a fee missing from my clearing account?

Check settled_via on the itemized report. If it reads credit or invoice, the fee was not deducted from a Stripe balance, so it will never appear as a balance movement. Only balance and v2_balance rows correspond to money leaving a balance.

How soon after month end can I pull the Stripe Fees report?

Fee data is available 96 hours after a fee affects your balance, so a report pulled sooner than four days after month end will be incomplete for the final days of the period.

Does the Stripe Fees report include everything Stripe charges me?

No. Stripe documents that it excludes Terminal device purchases, Stripe Capital fees, Atlas fees, and post-paid invoiced fees.

How do I find which charge a Stripe fee came from?

Use the itemized report and read incurred_by, which holds the ID of the object that incurred the fee, alongside incurred_by_type, whose common values are charge, refund, payout, transfer, and invoice.

Why does my QuickBooks fee account not match the report total?

Tax is the first thing to rule out. The report's amount column carries the fee and puts any tax on it in a separate tax column, so an account in QuickBooks holding both will not equal amount on its own. After tax, the next two candidates are rows that never touched a balance, which you can spot through settled_via, and fees Stripe excludes from the report altogether.

The point

The Fees report answers a question your cash reports cannot: not how much moved, but what it was for. It is worth adding to your close, with two conditions attached. Wait the 96 hours, and commit to one date pivot and stay on it.

If you would rather the fee side of this posted itself into QuickBooks correctly in the first place, mapped to the account you chose and split the way you want it split, that is what Acodei does.

<p><a href="https://app.acodei.com/signup">Start a free trial</a></p>