Stripe Reporting Category vs Type in QuickBooks

Every movement of money in or out of your Stripe balance produces a balance transaction. Every one of those balance transactions carries two different labels for what it is: a type and a reporting_category.

Almost every integration article, support thread, and mapping screen you will ever read talks in terms of type. Stripe's own documentation tells you not to account by it.

From the balance transaction types reference:

To classify transactions for accounting purposes, use the reporting_category field instead of the type field.

The API reference for the balance transaction object repeats it at the bottom of the type field description: "To classify transactions for accounting purposes, consider reporting_category instead."

That instruction is easy to nod along to and hard to act on, because the two fields are not a simple rename of each other. One splits, one merges, and several of the merges and splits are exactly where bookkeeping goes wrong. This post is the mapping between them, and what each one is actually good for when your destination is QuickBooks.

Ready to stop hand-sorting Stripe's balance report? Start a free trial.

Two fields, two jobs

type is a mechanical description of what produced the balance transaction. There are around fifty values, and they are named after the internal event: charge, payment, refund, payment_refund, adjustment, stripe_fee, application_fee, reserve_transaction, reserved_funds, and so on.

reporting_category is an accounting description of what the movement means. Stripe puts it plainly: the field "improves the type field by providing a more useful grouping for most finance and reporting purposes."

The distinction matters because the mapping between them is not one to one in either direction. A single type can produce three different categories. Three different types can collapse into one category. If you build your QuickBooks reconciliation on the wrong field, the errors are not random noise. They are systematic, and they all point the same way.

The four things reporting categories actually fix

Stripe documents four specific improvements. Each one corresponds to a real way that classifying by type produces wrong numbers.

1. It breaks adjustment apart

type=adjustment is the worst offender. Stripe describes it as a credit or debit to your balance made outside the normal payment flow, which covers a genuinely unrelated set of events.

reporting_category splits that single type across three categories:

What happened	Reporting category	Section in Stripe's monthly report
A customer disputed a charge and Stripe deducted the amount	dispute	Disputes
You won a dispute and the amount came back	dispute_reversal	Dispute Reversals
Miscellaneous balance correction	other_adjustment	Other Adjustments

Those are three different bookkeeping events. A chargeback should reverse a sale. A won dispute should restore one. A miscellaneous correction belongs nowhere near your revenue accounts. Filter on type=adjustment and all three land in the same bucket, which means your dispute total is net of your wins and your revenue is quietly wrong by the difference.

Stripe notes that other_adjustment also picks up obligation_outbound and obligation_reversal_inbound, so the category is doing real work even beyond splitting adjustment.

2. It separates uncaptured authorizations from real refunds

This one produces a wrong number on almost every account that uses separate authorization and capture, and hardly anyone notices.

If you authorize 500 USD and later capture 300, Stripe writes two balance transactions: a charge for the full 500, and a second one reversing the 200 you did not take. That second transaction has type=refund. It looks exactly like refunding part of a sale two weeks later.

Stripe is explicit about why it gave that case its own category:

To allow separate handling of these objects (perhaps counting them against the initial sale amount, rather than as a separate refund) we label these with the distinct reporting category partial_capture_reversal.

Note where Stripe files it: partial_capture_reversal sits under Payments (cards) in the monthly report, not under Refunds. It is a correction to a sale, not a return.

Classify by type and two things break at once. Your gross sales are inflated by every uncaptured authorization, and your refund rate is inflated by the same amount. If you present a refund rate to a lender, an acquirer, or a board, that is not a rounding error.

3. It merges the card and non-card duplicates

Stripe uses different type names for the same commercial event depending on whether the payment method was a card:

Balance transaction types	Reporting category
charge, payment	charge
refund, payment_refund	refund
payout_cancel, payout_failure	payout_reversal
transfer, recipient_transfer	transfer
transfer_cancel, transfer_failure, recipient_transfer_cancel, recipient_transfer_failure	transfer_reversal

charge is a card sale. payment is a sale through a local payment method. They are the same thing to your P&L.

This is the failure mode that hits businesses adding ACH, bank debits, or local methods to an existing card-only setup. A filter written when you only took cards says type=charge. It keeps working. It keeps returning a number. The number silently stops including a growing share of your revenue, and nothing errors.

4. It renames things to what they are

Five renames, and two of them change the meaning materially:

Balance transaction type	Reporting category
application_fee	platform_earning
application_fee_refund	platform_earning_refund
stripe_fee	fee
reserve_transaction	connect_reserved_funds
reserved_funds	risk_reserved_funds

application_fee is the fee a Stripe Connect platform earns on a connected account's charge. The type name contains the word "fee", which reads like a cost. It is not a cost. It is the platform's revenue, and the category name says so.

The reserve pair is the more useful rename. reserve_transaction and reserved_funds are near-identical type names for two genuinely different mechanisms:

• connect_reserved_funds (from reserve_transaction) is a Connect thing. A connected account's balance went negative, so Stripe temporarily reserves part of the platform's balance to cover it.
• risk_reserved_funds (from reserved_funds) is a risk thing, and has nothing to do with Connect. Stripe holds part of your own funds and returns them at the end of the reserve period.

Two balance transactions are created in the risk case, one debiting and one crediting back. If you have ever tried to work out which reserve you are looking at from the type name alone, the category names are the answer.

The mapping table

Consolidating the categories that show up in a normal Stripe to QuickBooks workflow:

Balance transaction type	Reporting category
charge, payment	charge
payment_failure_refund	charge_failure
refund, payment_refund	refund
refund (uncaptured portion of an authorization)	partial_capture_reversal
refund_failure	refund_failure
adjustment (disputed charge)	dispute
adjustment (dispute won)	dispute_reversal
adjustment, obligation_outbound, obligation_reversal_inbound	other_adjustment
stripe_fee	fee
tax_fee	tax
payout	payout
payout_cancel, payout_failure	payout_reversal
payout_minimum_balance_hold	payout_minimum_balance_hold
payout_minimum_balance_release	payout_minimum_balance_release
transfer, recipient_transfer	transfer
transfer_cancel, transfer_refund, recipient_transfer_cancel, recipient_transfer_failure	transfer_reversal
application_fee	platform_earning
application_fee_refund	platform_earning_refund
reserve_transaction	connect_reserved_funds
reserved_funds	risk_reserved_funds
connect_collection_transfer	connect_collection_transfer
advance	advance
advance_funding	advance_funding
contribution	contribution
fee_credit_funding	fee_credit_funding
currency_conversion	currency_conversion

One caution before you build anything on this. The two lists are maintained separately and they are not perfectly parallel. Stripe's category reference names validation as a type feeding charge, and names transferred_to_balance_transaction as the type behind unreconciled_customer_funds, while the API's own type enum lists neither and instead carries payment_unreconciled. Neither list is wrong for its own purpose, but if you are writing a lookup, read the category off the balance transaction rather than deriving it from the type, and check the result against your own export.

Where this collides with QuickBooks

Here is the part that is genuinely awkward, and the reason a post like this is worth writing at all.

Stripe tells you to account by reporting_category. But the field that governs whether a movement reaches your accounting system in the first place is type.

In Acodei, the set of balance transaction types that sync is controlled by an allowed_transaction_types table, and each type in it belongs to a display group. New types get enabled by adding them to that table, which is how advance and advance_funding (group "Advance Funding") and fee_credit_funding (group "Fee Credit") were introduced.

Where an uncommon type lands once it arrives is a separate decision, made under Account Mapping ▸ Balance Transaction Mapping. That section stays hidden until you toggle Customize. During payout and daily summary processing, each type's aggregated amount posts as a line item using the product you mapped, and any type you have not mapped prompts you to map it rather than being guessed at.

So you end up thinking in both fields at different moments:

• "Will this appear in QuickBooks at all?" is a type question.
• "Which account does it belong in?" is a mapping question, resolved per type.
• "Why doesn't my QuickBooks total match Stripe's report?" is a reporting_category question, because that is how Stripe's reports are grouped.

That third one is where people get stuck. The Stripe balance report you are reconciling against is organized by reporting category and by monthly-report section. Your QuickBooks lines came from types. Translating between them is the missing step.

What each category becomes in QuickBooks

Type	Reporting category	What Acodei posts
stripe_fee, stripe_fx_fee	fee	Fee expense against the mapped "Stripe Fees" item. Real-time puts a fee line on each sales receipt; daily summary puts one aggregated fee line on the deposit.
tax_fee	tax	Part of the fee expense. Should be mapped to an exempt or out-of-scope code so it is not counted as sales tax you owe.
adjustment	dispute, dispute_reversal, other_adjustment	No standalone QuickBooks record. The original entry is reversed or adjusted instead. Daily summary folds it into that day's deposit; real-time voids or removes the original sale or payment.
application_fee	platform_earning	Income, as a separate positive line on that day's summary, using a product mapped to an income account where one exists. Not delivered by real-time webhooks, so it arrives with the daily sync.
application_fee_refund	platform_earning_refund	Negative income offsetting the original.
reserve_transaction	connect_reserved_funds	Imported through Balance Transaction Mapping and aggregated into payout and daily-summary line items.
reserved_funds	risk_reserved_funds	Same mechanism. Holds and releases net to zero over time, so a hold in one period released in the next is a timing artifact, not a loss.
connect_collection_transfer	connect_collection_transfer	An expense or outflow via the mapped product. This one is a real loss of funds, and platforms often reclassify it to bad debt.
payout_cancel, payout_failure	payout_reversal	No separate entry. The planned deposit or transfer is voided or never finalized, so the funds stay in the Stripe holding account.
advance, advance_funding	advance, advance_funding	The instant payout itself is a Transfer. Stripe's recoup lands on the next payout, appearing on Undeposited Funds as a negative Advance line through Balance Transaction Mapping. The instant-payout fee is captured on the daily balance summary.
payment_unreconciled	unreconciled_customer_funds	Other income, usually on that date's daily summary deposit.
contribution	contribution	An expense, for Stripe Climate contributions.
fee_credit_funding	fee_credit_funding	Aggregates into payout and daily-summary lines like other balance types. A positive Fee Credit line offsets previously charged fees.
transfer	transfer	An expense or transfer out of the Stripe holding account.
transfer_refund, transfer_cancel, transfer_failure	transfer_reversal	Offsets the original, so the net effect in QuickBooks is zero.

Notice how often the category name and the QuickBooks treatment agree, and how often the type name does not. application_fee posts as income, matching platform_earning rather than the word "fee". partial_capture_reversal should count against the sale, not against refunds. The category names were chosen by people solving the same problem your bookkeeper is solving.

For the specific mess around fee naming, where stripe_fee as a balance transaction type and type inside fee_details mean different things, see non-transactional Stripe fees in QuickBooks. That collision deserves its own treatment and it has one.

A practical reconciliation order

When your Stripe clearing account does not tie out, work in this order.

Start from the category, not the type. Pull the balance report grouped by reporting_category. That is the layer your accountant will recognize and the layer Stripe's monthly report sections are built on.

Split the adjustments before comparing anything. If your Stripe side shows one adjustment number and your books show disputes and dispute reversals separately, you are comparing two different things. The category split is the fix.

Check for partial captures. If you authorize and capture separately, confirm that uncaptured portions are not sitting in your refund total on either side.

Then drop to types for the sync question. Anything present in Stripe's report but absent from QuickBooks is a question about the allowed type list and about Balance Transaction Mapping, not about the category.

One last thing that trips people up on the count rather than the amount. Stripe's Payments figure counts customer charges. A sync that reflects your whole balance counts fees, adjustments, and payouts as separate events too, so the two numbers are not supposed to match. That is a difference in what is being counted, not a sign that something failed.

Frequently asked questions

What is the difference between Stripe's type and reporting_category?

type describes the internal event that created the balance transaction, such as charge, refund, or adjustment. reporting_category describes what the movement means for accounting, such as dispute, partial_capture_reversal, or platform_earning. Stripe's documentation instructs you to classify by reporting_category for accounting purposes, because it splits ambiguous types apart and merges duplicate ones.

Which Stripe field should I use for bookkeeping?

Use reporting_category. Stripe states directly that you should use it instead of type to classify transactions for accounting purposes. The one exception is when you are asking whether a movement syncs into your accounting system at all, which is usually governed by the type.

Why does my Stripe refund total look too high?

The most common cause is partial captures. If you authorize an amount and capture less, Stripe creates a balance transaction with type=refund for the uncaptured portion. Its reporting category is partial_capture_reversal, and Stripe files it under payments rather than refunds. Classifying by type counts it as a refund and inflates both your gross sales and your refund rate.

Is application_fee income or an expense?

For the Connect platform collecting it, it is income. Its reporting category is platform_earning, which is clearer than the type name. The connected account experiences the same amount as a cost. Acodei posts application fees as income on the daily summary, using a product mapped to an income account where one is available.

What is the difference between reserve_transaction and reserved_funds?

They are different mechanisms with confusingly similar type names, which is exactly why the reporting categories rename them. reserve_transaction becomes connect_reserved_funds and covers Stripe reserving part of a platform's balance against a connected account's negative balance. reserved_funds becomes risk_reserved_funds and covers Stripe holding part of your own funds for risk, returning them at the end of the reserve period.

Getting the classification right without doing it by hand

The reason this field pair matters is that it decides what your revenue, refund, and fee numbers say. Stripe gives you the better field. Reading it consistently across every balance transaction, then landing each one in the right QuickBooks account, is the part that does not scale by hand.

That is the job Acodei does: your Stripe balance transactions posted into QuickBooks Online against the accounts you chose, with the uncommon balance types mapped explicitly under Balance Transaction Mapping rather than left to guesswork. Start a free trial, or read the complete guide to Stripe payout reconciliation first.