Cash vs Accrual for Stripe Revenue: What Actually Posts

Ask ten Stripe businesses when they book revenue and you will get three answers: the day the customer paid, the day the money showed up in the bank, or whatever QuickBooks happened to do. All three can produce books that reconcile. Only one of them is a considered answer to the question your accounting method is actually asking.

The confusion is understandable, because Stripe hands you several different dates for the same dollar and none of them is labeled "recognize revenue here." This post walks through which date belongs to which method, why the payout date is the wrong answer under both of them, and what has to be true of your QuickBooks file before the distinction can even show up in a report.

If you want the general comparison first, the cash versus accrual fundamentals are covered separately. This one is about what Stripe specifically does to that decision.

Start a free trial and see how your Stripe activity lands in QuickBooks.

Stripe gives you three dates for one sale

A single $100 charge produces at least three distinct timestamps, and they are genuinely different events rather than three names for one thing.

The charge date. The customer's card was approved and Stripe created the objects that represent the sale.

The available-on date. Every charge produces a balance transaction, the object that records what the sale did to your Stripe balance. It carries a created timestamp, which Stripe defines simply as the "time at which the object was created," and separately an available_on timestamp, defined as "the date that the transaction's net funds become available in the Stripe balance." Alongside those, a status field that Stripe documents as being "either available or pending."

The payout date. Money leaves your Stripe balance for your bank account.

Stripe describes the gap between the first and the second as settlement timing, "typically expressed as 'T+X' days," where T is "the time of the original payment confirmation or capture." So a business on T+3 sees funds from Monday's sales become available on Thursday, and the payout that carries them arrives after that.

The important structural point is that the third date is downstream of a setting rather than of anything financial. Stripe is explicit: "choosing a payout schedule doesn't change how long it takes for your pending balance to become available. It only controls when payouts are sent." You can switch to weekly payouts tomorrow and nothing about your revenue changes. That should already tell you the payout date is not carrying accounting meaning.

What each method is actually asking

Both methods ask a question about timing, but they ask different questions, and neither of them is "when did the bank balance change."

The cash method asks when you received the money. The subtlety that matters for Stripe is that "received" is a broader idea than "withdrew." The IRS describes constructive receipt this way: income "is constructively received when an amount is credited to your account or made available to you without restriction," and adds plainly that "you do not need to have possession of it." Its own example is a bank crediting interest in December that the taxpayer did not withdraw or record until the following year, and the answer is that it belongs to December, "the year you constructively received the interest income."

The accrual method asks when you earned it. The standard here is the all-events test, met "when all events have occurred which fix your right to receive the income and you can determine the amount with reasonable accuracy." Delivery, in other words, not payment.

Read those side by side and you can see why the two methods collapse into each other for a lot of Stripe businesses. If you sell a digital download and the customer pays at the moment they receive it, you earned it and you received it in the same instant. The methods agree. They diverge when payment and delivery separate: annual plans paid up front, deposits, retainers, anything prepaid. That gap is what deferred revenue exists to hold, and it is the real reason a subscription business ends up on accrual.

The payout date is wrong under both methods

This is the single most common mistake, and it is worth being blunt about, because it survives in a lot of otherwise careful books.

Under accrual, booking revenue on the payout date is obviously wrong. You earned the money when you delivered, which was days earlier and has nothing to do with Stripe's transfer schedule.

Under cash basis it is also wrong, and this is the part people find surprising. When your customer's payment settles into your Stripe balance, that money has been credited to your account and made available to you. You can spend it, refund from it, or trigger a manual payout with it. By the constructive receipt standard above, you received it then. The payout is you moving your own money from one account you control to another account you control.

That is exactly how a well-built QuickBooks file represents it, too. The holding account is a real asset account standing in for your Stripe balance, sales land in it, and the payout moves the balance from there to checking. Acodei records that movement in one of two shapes depending on the holding account you chose. On a regular asset holding account, a payout becomes a single QuickBooks Transfer from the holding account to your mapped bank account for the payout's net amount. On Undeposited Funds, it becomes a Deposit that itemizes the underlying charges, refunds and fees moving into the bank.

Look at either of those record types and notice what is missing: an income line. A Transfer is not revenue. An itemized Deposit is not revenue either, because the revenue was already recognized when the sales records posted into the holding account. If your books instead recognize income on the payout, you have a system in which changing a Stripe dashboard setting from daily to weekly payouts moves revenue between periods. That is a fair test of whether the model is right.

There is a tidy confirmation of this in how failed payouts behave. When a payout fails or is canceled, Acodei closes it out without creating any record at all, on the reasoning that the money never moved. If payouts were the revenue event, a failed one would have to reverse revenue. It does not, because there was nothing to reverse.

What available_on is good for

Having established that available_on is not a revenue recognition date under either method, it is worth saying what it genuinely is, because it is the most useful and least used date on the object.

It is a cash forecasting date. It tells you when a specific dollar becomes eligible to leave for your bank. The status field splits your balance into pending and available on exactly that basis, which is the distinction between your available and pending Stripe balance.

It also explains the single most common reconciliation surprise, which is a payout total that does not match any obvious group of sales. A payout carries the transactions that became available in its window, not the transactions created in it. Sales from three different days, minus a refund from last week, minus fees, can land in one payout. If you are chasing that, the payout reconciliation walkthrough covers the mechanics.

One last thing available_on is not: it is not the date the money hits your bank. It is the date it becomes eligible for a payout, and the payout has its own timing on top.

Whether your books can express the difference at all

Here is the part that gets skipped, and it decides more than the method choice does. A cash-versus-accrual distinction can only appear in your reports if your books contain the accounts that carry it. In practice that means Accounts Receivable.

QuickBooks reports have a basis toggle, and switching it changes what the report includes. Accrual reporting counts an invoice when it is issued. Cash reporting counts it when it is paid. The mechanism is A/R: the report is deciding what to do about invoices that exist and have not been paid.

Now consider what your Stripe sync actually writes, because there are two very different shapes.

The sales receipt shape. On a real-time account, each successful charge becomes an itemized sales receipt deposited into your holding account by default. A sales receipt records the sale and the receipt of money as one event. There is no A/R stage, because there was never a moment when you had earned the money and not been paid.

The invoice shape. With Invoice Sync enabled, a finalized Stripe invoice becomes a QuickBooks Invoice reproducing its line items, and the payment that follows becomes a Payment Receipt applied against that invoice. Now there are two records with two dates, and a genuine window between them where revenue is recognized and cash is not received. That window is A/R.

The consequence is direct. If every sale in your file is a sales receipt, flipping the report basis to cash changes almost nothing, because there are no unpaid invoices for the basis to treat differently. Your books are cash-shaped regardless of what the toggle says. Acodei's own documentation frames Invoice Sync as being for businesses that generate customer-facing invoices in Stripe but manage A/R and reporting in QuickBooks, and names cash-basis or accrual accounting in QuickBooks as the point of it.

So the practical order of operations is backwards from how people usually approach it. Choosing accrual is not a decision you make in a settings menu. It is a decision about whether your billing produces invoices your books can hold open.

A third shape is worth knowing about because it changes the granularity rather than the basis. On daily summary accounts, individual charges do not get their own records at all. A payout's balance transactions are aggregated by day and currency, and each day group becomes one sales receipt when the day nets positive or one refund receipt when it nets negative. The revenue still lands on day-level records rather than payout-level ones, so the argument above holds. You simply have one record per day instead of hundreds.

The dates you can actually control

Assuming an invoice-shaped file, a few dating controls exist and are worth knowing before you go hunting for a workaround.

Acodei documents three mutually exclusive service and supply date toggles for invoices, set on the admin side rather than self-serve: add the invoice date as the service date, use the Stripe supply date as the invoice date, or use the Stripe supply date as the service date. If your revenue recognition depends on when service was delivered rather than when Stripe cut the invoice, that is the lever, and it is a conversation with support rather than a checkbox in your dashboard.

On the payout side, the date on the Transfer honors a payout date setting and your account's timezone, which matters more than it sounds at a month boundary. A payout initiated late on the 31st in one timezone is an entirely different month in another.

What you should not do is hand-edit the synced records in QuickBooks to force dates. Acodei's documented guidance is to resync from the Data Feed rather than modifying transactions directly in QuickBooks, and the reasoning is that the sync's view and your file's view stop agreeing once you edit one side.

Fees are an expense under both methods

One thing genuinely does not change between the two methods, and it trips people up in both.

Your customer paid $100. Stripe took a fee and moved $96.80 into your balance. Your revenue is $100 and the fee is an expense. It is not a $96.80 sale. Netting the fee against revenue understates both your top line and your costs, which distorts every margin calculation downstream and, if you take card payments at volume, misstates a genuinely large expense line.

Stripe's own data model agrees: the balance transaction carries amount, fee and net as three separate fields, with net documented as amount minus fee. The gross number is right there.

How that lands depends on configuration. By default a sales receipt records the Stripe fee as a negative line using your mapped fee product, so the receipt nets to what actually entered your balance while the gross sale is still on the record. With fee-as-expense configured, the fee posts as a separate Purchase or Expense and the receipt stays gross. On invoices, fees are never added to the invoice at all, because that would make the QuickBooks invoice total disagree with the Stripe invoice; they are handled as expenses or on the deposit instead.

Standalone fees that do not belong to any single charge, such as monthly billing or fraud-tool charges, are aggregated onto a daily summary record rather than being attached to a sale, and Acodei splits fee handling into transactional and non-transactional categories that can be routed to summary line items or to a separate expense.

A worked example

A $100 charge on Monday 30 March. A $3.20 processing fee, so $96.80 net. Funds available Thursday 2 April. Payout arrives Friday 3 April. Assume the customer bought a one-year subscription starting 1 April.

Cash basis. You constructively received $96.80 when it settled into your Stripe balance. Revenue of $100 and a fee expense of $3.20 belong to the period containing the charge, not to April because that is when the bank saw it. In a sales-receipt file this happens automatically, because the receipt posts when the charge syncs.

Accrual basis. You have earned none of it on 30 March. You have collected cash for a service you have not delivered, which is a liability. The $100 moves to revenue across twelve months from April, and the $3.20 fee is an expense of March when the service was rendered to you.

The payout, under both. Friday 3 April, a transfer of $96.80 from the holding account to checking. No revenue impact under either method. The transaction that touches the bank is the only one in the story that touches no income account.

Notice that the two methods disagree about almost everything here, and the payout is the one event they agree about completely. That is the whole argument for why it cannot be the recognition date.

Where to actually make the decision

Method choice has tax consequences and eligibility rules, including gross receipts thresholds that determine whether the cash method is available to you at all. Those depend on your entity, your size and your inventory position, and they are a question for your accountant rather than for a blog post or a sync tool.

What you can settle without an accountant is the mechanical part. Get the shape right first: revenue recognized on sales records, fees as an expense on the gross amount, and the payout modeled as a transfer between two accounts you own. A file built that way supports either method and produces a report basis toggle that means something. A file that books income on payouts supports neither, and no amount of adjusting entries at year end fully repairs it.

For the recurring close work that sits on top of this, the month-end close checklist covers the period-boundary cases, including in-transit payouts that straddle two months.

Acodei writes the records described in this post directly into QuickBooks Online: itemized sales records deposited into your holding account, the Stripe fee as a negative line or a separate expense depending on how you configure it, invoices and payment receipts when your billing produces invoices, and payouts as transfers or itemized deposits. Start a free trial.

Frequently asked questions

Should I book Stripe revenue on the charge date or the payout date?

Not the payout date, under either accounting method. Under accrual you recognize revenue when you earn it, which is delivery. Under cash basis you recognize it when you receive it, and the IRS treats income as constructively received once it is "credited to your account or made available to you without restriction," which describes money sitting in your Stripe balance. The payout is a transfer between two accounts you control, and it happens on a schedule you can change without changing anything financial.

What is the difference between created and available_on on a Stripe balance transaction?

created is when the object was created, effectively when the sale happened. available_on is "the date that the transaction's net funds become available in the Stripe balance," which is when that money becomes eligible to be paid out. Stripe expresses the gap as T+X settlement timing, which varies by country. The status field reflects the same split, reading either pending or available.

Does changing my Stripe payout schedule change my revenue?

No, and if it does in your books, your books have a modeling problem. Stripe states that choosing a payout schedule "doesn't change how long it takes for your pending balance to become available. It only controls when payouts are sent." Revenue should be recognized on the sale, so switching from daily to weekly payouts should move nothing between periods.

Why does switching my QuickBooks reports to cash basis change nothing?

Most likely because your file has no Accounts Receivable to treat differently. The report basis toggle mainly decides how to handle invoices that have been issued and not yet paid. If your Stripe sales all post as sales receipts, each one records the sale and the receipt of money at once, so there are no open invoices for the basis to change. Getting a meaningful difference requires an invoice-shaped file, which in Acodei means Invoice Sync writing a QuickBooks Invoice on finalization and a Payment Receipt when it is paid.

Should my QuickBooks sales be gross or net of Stripe fees?

Gross, under both methods, with the fee recorded separately as an expense. A $100 sale with a $3.20 fee is $100 of revenue and $3.20 of expense, not a $96.80 sale. Stripe's balance transaction keeps amount, fee and net as three separate fields for exactly this reason. Acodei can record the fee as a negative line on the sales receipt or as a separate expense, and on invoices fees are never added to the invoice itself.

Do I need accrual accounting if I sell subscriptions through Stripe?

That is a question for your accountant, since eligibility and tax treatment depend on your entity and size. What is true structurally is that subscriptions are where the two methods actually diverge, because the customer pays up front for service delivered over time. That gap is deferred revenue, and representing it requires invoices your books can hold open rather than sales receipts that close immediately.