Glossary

Stripe Application Fee

A Stripe application fee is the amount a Connect platform collects from a charge made on a connected account, recorded as its own object with its own balance transaction, and moved into the platform’s Stripe balance while the rest of the payment stays with the connected account.

Also called: application fee, Connect application fee, platform fee, application_fee

Start a free trial View Pricing

Definition

Somebody bought a 200 dollar booking from a studio that runs on your software. The studio got paid. You got your 30 dollar cut. The application fee is that 30 dollars, and Stripe treats it as a first-class object rather than as a footnote on the charge.

Stripe describes the mechanism plainly for direct charges: "The payment appears as a charge on the connected account, not your platform’s account", "The connected account’s balance increases with every charge", and "Your account balance increases with application fees from every charge." Three sentences, and between them they decide what your platform’s books can and cannot show.

The object itself is small and precise. amount is "Amount earned, in the smallest currency unit". account is "ID of the Stripe account this fee was taken from", meaning the connected account, not yours. charge is "ID of the charge that the application fee was taken from". So every fee points back at a payment you never held and an account you do not own.

That is the part worth sitting with. On a direct-charge platform, the 200 dollars is not your revenue, was never in your balance, and does not appear in your ledger at all. Your revenue is 30 dollars of commission. Platforms that model the gross as sales and the seller’s share as a cost are describing a business they are not running, and the resulting revenue figure is wrong by the size of the whole marketplace.

Key points

+Stripe: "Your account balance increases with application fees from every charge" on a direct-charge Connect integration.
+amount is "Amount earned, in the smallest currency unit". It is your commission, not the customer’s payment.
+account is "ID of the Stripe account this fee was taken from", which is the connected account rather than the platform.
+charge is "ID of the charge that the application fee was taken from", so the fee always points back at a payment on somebody else’s account.
+refunded is "Whether the fee has been fully refunded. If the fee is only partially refunded, this attribute will still be false."
+amount_refunded carries the real figure and "can be less than the amount attribute on the fee if a partial refund was issued".
+With direct charges, Stripe notes the PaymentIntents and Charges "exist on the connected account, not on the platform".
+Reading that data needs "the connected account ID in the Stripe-Account header", which is why platform-level queries come back empty.
+Acodei documents application_fee as arriving as its own balance-transaction line, bucketed by day and currency.
+Which QuickBooks account it lands in is decided by the product you map to that type in Balance Transaction Mapping.

The charge type decides whether you ever see the sale

An application fee means different things depending on how the payment was created, and the difference is not cosmetic.

With direct charges, the payment is created on the connected account. Stripe is explicit that the charge "appears as a charge on the connected account, not your platform’s account", and that the connected account’s balance is what grows. Your platform balance grows only by the application fee. So your books see one number per sale, and it is your commission.

With destination charges and with separate charges and transfers, the payment lands on your platform first and a portion moves outward. There, your balance does see the gross, and what stays behind after the transfer is your margin. The accounting question flips: instead of recognising a commission, you are recognising a gross sale and a corresponding obligation to the seller.

This is why "how should a marketplace book its revenue" has no single answer. It depends on which charge type the platform was built on, and that decision was usually made by an engineer years before anyone asked an accountant. If you are trying to work out which one you have, the fastest tell is whether your own Stripe balance ever holds the full customer payment. If it does not, you are on direct charges.

Why your platform-level reports look empty

Platforms on direct charges routinely discover that their reporting tools return almost nothing, and assume something is misconfigured. Nothing is.

Stripe documents the constraint under the heading of platform visibility limitations: "Transaction objects such as PaymentIntents and Charges exist on the connected account, not on the platform." To read them, "you must query the Stripe API using the connected account ID in the Stripe-Account header".

Stripe then names the consequence for tooling directly, which is unusual and useful: "This scoping behavior affects data synchronization services like Fivetran, as well as other third-party integrations that rely on platform-level API queries. To retrieve direct charge data, they must query the connected account, not the platform."

For an accounting workflow this is clarifying rather than limiting. The data your platform can see at platform level is the data that belongs to your platform: application fees in, Stripe’s own costs out, payouts to your bank. The gross sales sitting on connected accounts are somebody else’s revenue and, on a direct-charge model, somebody else’s books. A sync that shows you only your commission is not missing the sales. It is declining to claim them.

The refunded flag hides partial refunds

If a sale is refunded, your commission usually goes back with it, and one field will mislead you about how much.

Stripe documents refunded as "Whether the fee has been fully refunded. If the fee is only partially refunded, this attribute will still be false." A 30 dollar fee with 24 dollars returned reports refunded as false, indistinguishable from a fee nothing has happened to.

The figure you want is amount_refunded, which Stripe notes "can be less than the amount attribute on the fee if a partial refund was issued". The refunds list holds the individual events if you need to date them rather than total them.

The practical rule: treat refunded as the answer to one narrow question, whether the entire fee was undone, and never as the answer to whether any of it was. A report filtered on "refunded is false" will carry every partially refunded fee at its full original value, which overstates commission income by exactly the amount you gave back.

Fees on fees, and the number that is actually yours

There are two unrelated things called a fee on the same transaction, and conflating them is the most common arithmetic error in marketplace books.

The application fee is what you charge the seller. Stripe’s processing fee is what Stripe charges for moving the money. They are different objects, they are owed to different parties, and which balance absorbs the processing cost depends on how the platform is configured.

On a direct charge, Stripe’s fees can be debited from the connected account or from the platform, and that is a setting. If Stripe’s costs come out of your balance while your income is the application fee, your real margin is the fee minus those costs, and only one of those two numbers appears on the application fee object. Recognising the commission gross and leaving the processing cost out produces a margin that looks better than it is, every month, consistently.

The application fee object gives you one half. balance_transaction is the link to the other half: it is the entry describing the fee’s effect on your balance, and it is where the net figure lives. For anything that ends up on a profit and loss statement, that is the record to reconcile against rather than the headline amount.

How Acodei handles Connect application fees

Acodei’s documentation treats Connect activity as balance-transaction types. An application_fee arrives as its own line, bucketed by day and currency, and signed by the direction of the amount. Its refund counterpart, application_fee_refund, is handled as its own type when payout lines are built, so a returned commission is a distinct entry rather than an edit to the original.

Where that line lands in QuickBooks is a mapping decision rather than fixed behaviour. Uncommon balance-transaction types resolve to whichever product you map them to under Account Mapping, then Balance Transaction Mapping, a section Acodei’s documentation notes stays hidden until you click Customize and toggle it on. Acodei is deliberate about not choosing for you here: the documentation states that determining which balance transaction types to map to which products "is entirely up to you and your accountant". The documentation notes that in some cases you may want to create a new account in your chart of accounts and link a new product to that account, and in others map the type to a product you already have.

There is a failure mode worth recognising, because it looks alarming and is not. If a type has no mapping yet, the data feed shows a message naming it: "[Balance transaction type] detected, please turn on [transaction type] in Balance Transaction Mapping." A payout containing an unmapped application fee does not sync until the mapping exists. Once it does, the fix is to resync the deposit from the Payouts tab in the Data Feed rather than to rebuild anything by hand.

One boundary is worth stating rather than glossing. Acodei’s Connect documentation flags that the specific accounting treatment of each type is a consequence of how you map it, not a behaviour fixed in the product, so this page does not tell you which account the fee ends up in. It tells you it becomes a line whose destination you choose.

Whichever way your platform is wired, the commission has to reconcile against the balance it arrived in, which is what reaches your QuickBooks holding account from a Stripe balance.

Want to see this on your own Stripe data?

Start a free trial

Frequently asked questions

What is a Stripe application fee?

It is the amount a Connect platform collects from a charge made on a connected account. Stripe defines the object’s amount as "Amount earned, in the smallest currency unit", its account as "ID of the Stripe account this fee was taken from", and its charge as "ID of the charge that the application fee was taken from". On a direct-charge integration, Stripe states that "Your account balance increases with application fees from every charge".

Should a platform book the commission or the whole sale?

It depends on the charge type. With direct charges the payment never enters your balance, so your revenue is the commission and the gross belongs to the connected account. With destination charges or separate charges and transfers the gross does land on your platform, and what remains after the transfer is your margin. Platforms frequently model one and operate the other, which overstates revenue by the size of the marketplace.

Why can I not see connected account charges in my platform Stripe data?

Because on direct charges they are not there. Stripe documents that "Transaction objects such as PaymentIntents and Charges exist on the connected account, not on the platform", and that reading them requires "the connected account ID in the Stripe-Account header". Stripe adds that this affects data synchronization services and third-party integrations relying on platform-level queries, which must query the connected account instead.

Why does refunded say false on an application fee that was partly refunded?

Because it only reports full refunds. Stripe documents refunded as "Whether the fee has been fully refunded. If the fee is only partially refunded, this attribute will still be false." Use amount_refunded for the real figure, which Stripe notes "can be less than the amount attribute on the fee if a partial refund was issued", and the refunds list for the individual events.

What is the difference between an application fee and a Stripe fee?

An application fee is what your platform charges the seller. A Stripe fee is what Stripe charges for processing the payment. They are separate objects owed to separate parties. On direct charges, whether Stripe debits its processing fee from the connected account or from the platform is a configuration choice, so your true margin can be the application fee minus costs that never appear on the application fee object.

How does Acodei record a Connect application fee in QuickBooks?

As a balance-transaction line. Acodei documents application_fee as bucketed by day and currency and signed by the direction of the amount, with application_fee_refund handled as its own type when payout lines are built. Which QuickBooks account the line reaches is set by the product you map to that type under Account Mapping, then Balance Transaction Mapping.

Why is my payout not syncing when it contains application fees?

Most likely the type has no mapping yet. Acodei’s documentation describes a data feed message in the form "[Balance transaction type] detected, please turn on [transaction type] in Balance Transaction Mapping", and the payout waits rather than posting something arbitrary. Add the mapping under Account Mapping, then Balance Transaction Mapping, which stays hidden until Customize is toggled on, then resync the deposit from the Payouts tab in the Data Feed.

What customers say about running Stripe through Acodei

★★★★★

“If you're testing out all the different Stripe/QuickBooks integration apps right now, let me save you some time. This one is the best one by far.”

RyanOwner at Indie Music Academy