TL;DR
Your Stripe balance and your earned revenue won’t usually match. In an ecommerce business, your Stripe balance is often higher than the revenue you’ve actually earned. It comes down to timing. A customer might pay today for an order that won’t be shipped until next week, a subscription box they’ll receive over several months, or a gift card they may not redeem for a year. In every one of those cases, the cash is already in your account, even though you haven’t really earned that revenue yet.
Revenue recognition is what closes that gap between money collected and revenue earned. It’s an important part of accounting for online sellers, direct-to-consumer brands, and the accountants responsible for closing the books because someone has to determine when a Stripe payment should be recognized as revenue. Below, you’ll see how that works in day-to-day accounting, how ASC 606 applies to physical products and subscriptions, why gift cards and returns make the process more involved, and what helps keep your books audit-ready as transaction volume grows.
Revenue is recognized when you’ve earned it, not when the payment comes in. With Stripe, that difference comes up all the time. Stripe shows you what you’ve collected, but it doesn’t decide when that money becomes revenue. That’s still your responsibility.
Take a customer who pays $180 upfront for a three-box coffee subscription. You haven’t earned the full $180 when the payment clears. At that point, you’ve earned about $60 as the first box ships. The remaining amount stays on your balance sheet as deferred revenue, which is a liability, until you deliver the rest. The same idea applies to a preordered product that hasn’t shipped yet or a gift card that hasn’t been redeemed.
Another detail’s easy to overlook. Stripe sends payouts after deducting its processing fees, so a $100 sale might appear in your bank account as roughly $97. The revenue you can recognize will still be $100, but the processing fee should be accounted for as an expense, so the amount reflected in the bank feed is lower than the income earned.
It helps to keep three things separate: when the cash moved, whether you’re looking at the gross sale or the net payout, and when you actually delivered the product or service.
Revenue is earned when you deliver what you promised. ASC 606 turns that principle into a set of accounting rules auditors can verify, with IFRS 15 serving as the international equivalent. It applies to virtually any company using US GAAP that uses a contract for their sales process, and since 2019, this has applied to both public and private firms.
The standard follows five steps:
For ecommerce businesses, three of those steps usually require the most attention. Physical products earn revenue when they reach the customer, so most online retailers recognize revenue upon delivery rather than on the payment or shipping date. The transaction price also needs to account for expected refunds from the beginning because, once returns become part of the picture, ASC 606 doesn’t treat every sale as final. Allocation comes into play when a single order includes more than one obligation, such as a product sold with a shipping guarantee or a warranty. Each part follows its own revenue recognition timeline.
A simple order with one product, delivered and kept by the customer, is usually easy to account for. Returns, prepaid orders, gift cards, and subscriptions are the situations that make revenue recognition more involved.
Ecommerce stores relying on Stripe tend to adopt one of the following three work processes. Some manage revenue recognition entirely in spreadsheets. Others rely on Stripe’s built-in Revenue Recognition tool. A third option is an automated Stripe QuickBooks integration, which pulls every charge, processing fee, and refund into QuickBooks.
Most businesses begin with spreadsheets. Early on, they work well enough. You export the data from Stripe, build your deferred revenue and return schedules yourself, then update them by hand as orders change. There’s no added software cost, and that process can hold up while you’re working with a manageable number of orders that don’t involve many exceptions.
It changes once more complicated transactions start showing up together. Every one of them means another calculation or another schedule to update.
As these adjustments become more frequent, mistakes are easier to miss. In the long run, month-end close can result in spending days redoing schedules manually, which makes it extremely difficult to prove that all balances and calculations are accurate.
Stripe’s own Revenue Recognition product creates deferred revenue schedules using the subscription and invoice data that’s already in Stripe. It also produces reports such as revenue waterfalls and deferred revenue balances. If almost all of your recurring revenue comes through Stripe, it can cover a large part of the process.
The limitation becomes clear once your business sells through more than one channel. The tool only works with the data inside Stripe, so revenue from PayPal, Amazon, a wholesale channel, or in-store sales isn’t included. It also calculates recognized revenue without posting journal entries to your general ledger. And if you’re selling physical goods, areas like fulfillment timing and returns usually require additional setup because those workflows aren’t available out of the box.
Once you’re selling through more than one channel, dedicated revenue recognition software often starts to make sense. These tools connect your sales channels and payment processors to your accounting system, then bring over every charge, fee, refund, and payout on a regular schedule. Each transaction is mapped to the appropriate account, so you can see the details
behind every payout instead of working from a single lump-sum deposit. A platform like Synder, for instance, connects Stripe, Shopify, Amazon, and PayPal with QuickBooks Online or Xero. Other tools in this category support a similar mix of integrations.
The stronger platforms also manage deferred revenue. They build ASC 606 and IFRS 15 schedules using your subscription and prepaid sales data, then move amounts from deferred revenue into income as each reporting period is earned. That’s the part Stripe’s native tool still leaves to a manual export.
It doesn’t take many orders before revenue recognition gets complicated. Follow one customer over a few months and you’ll see why.
Imagine a customer placing a $90 preorder in March, but it doesn’t ship until April. The payment cleared, yet you can’t recognize that revenue in March. They also use a $25 gift card, so part of the payment comes from deferred revenue recorded when the card was sold. In May, they return one of two items and start a $180 annual subscription recognized gradually over twelve months.
That’s one customer. Now picture a few thousand orders a month.
Some are preorders, others subscriptions. Gift cards are redeemed, and returns come back from earlier purchases. You’re no longer tracking one timeline but hundreds, all moving independently.
That’s when spreadsheets show their limits. Stripe records that a payment happened, but not whether the order shipped, was partly refunded, or was paid with a gift card that sat on your balance sheet for months. Those events all affect revenue recognition; someone has to account for them.
| Order type | When revenue is
recognized |
Where the difficulty shows up |
| Standard product order | When the goods reach the customer | Payment, shipment, and delivery don’t always happen in the same reporting period. |
| Prepaid, pre-order, or subscription | As each unit ships or each service period is delivered | Cash stays in deferred revenue until you’ve fulfilled your obligation. Upgrades,
downgrades, and cancellations all change the recognition schedule. |
| Returns and
refunds |
Reduced up front by the expected-return
estimate |
Your estimate should reflect your own return history and be updated as that history changes. |
| Gift cards | On redemption, plus breakage over time | Until customers redeem them, those balances remain liabilities instead of revenue. |
Each of these situations follows its own accounting rules. Here’s how they work.
A standard product order is usually the easiest case, but even here, the payment date and the revenue recognition date aren’t always the same.
Suppose a customer pays for an order on March 30. You ship it on April 1, and it arrives on April 3. The cash came in during March, but the revenue belongs in April because that’s when the customer received the goods. Payment, shipment, and delivery often happen on different dates, which means they can also fall into different accounting periods.
Preorders, subscription boxes, and annual plans all begin the same way. The customer pays first. You deliver later.
Until you’ve provided the product or service, the payment stays in deferred revenue. It doesn’t move to the income statement until each shipment goes out or each service period has been delivered.
Take a customer who prepays $240 for a year’s worth of monthly refills. Billing doesn’t create $240 of revenue on day one. You recognize $20 each month as another refill ships.
Recognizing the full amount when the payment comes in makes current revenue look higher than it really is and removes a liability that still exists. Keeping the schedule tied to fulfillment also makes subscription upgrades, downgrades, and cancellations much easier to deal with because you’re updating an existing schedule instead of rebuilding one every month-end.
Returns affect revenue that’s already been recognized. According to the National Retail Federation and Happy Returns 2025 Retail Returns Landscape report, 19.3% of online sales are expected to be returned in 2025, contributing to a projected $849.9 billion in total retail returns. When almost one out of every five online purchases comes back, recognizing every sale at its full value doesn’t reflect what the business is actually expected to keep.
ASC 606 addresses this through variable consideration. You estimate future returns, reduce recognized revenue by that estimate, and record the difference as a refund liability. If your business consistently sees a 20% return rate, your revenue should reflect that expectation from the beginning and then be adjusted as actual returns come in.
The estimate shouldn’t be copied from another business or from an industry average. It needs to reflect your own history. An apparel retailer will usually expect a much higher return rate than a supplements company or an electronics seller.
Selling a gift card doesn’t create revenue.
It creates a liability because the customer has paid before you’ve delivered anything. The balance stays in deferred revenue until the customer redeems the card for a purchase. That’s the point when the revenue is recognized.
Breakage is the portion of gift card balances that customers never use. ASC 606 doesn’t let you recognize that amount as revenue just because a card has expired. If your own redemption history shows that a predictable percentage of gift cards will never be used, you recognize breakage gradually, alongside the cards that are redeemed.
Store credit issued instead of a cash refund is treated the same way. It still represents an obligation to provide goods or services in the future, so it isn’t recognized as revenue until that obligation has been satisfied.
It’s very straightforward – your financial reports show what you have earned, not just what you have been paid.
Deferred revenue always stays up-to-date, while the allowance for returns remains consistent in each reporting period. In addition to that, Stripe transactions are recorded in your accounting system whenever they should be recognized. This way, the end of the month will no longer require solving the issues related to revenue recognition timing; you’ll only need to analyze the numbers.
In case your business operates across various channels, it becomes even more critical. If you are running your business via Stripe, but also sell using such platforms as Shopify, Amazon, PayPal, and a wholesale channel, you know that the revenue from these channels comes under different terms and time frames. Once everything is recognized according to the same rules of accounting, there will be no need to compare reports or create spreadsheets based on inconsistent numbers.
All payments, processing fees, fulfillment information, and revenue recognition will happen in one accounting system.
EcomBalance is a monthly bookkeeping service specialized for eCommerce companies selling on Amazon, Shopify, eBay, Etsy, WooCommerce, & other eCommerce channels.
We take monthly bookkeeping off your plate and deliver you your financial statements by the 15th or 20th of each month.
You’ll have your Profit and Loss Statement, Balance Sheet, and Cash Flow Statement ready for analysis each month so you and your business partners can make better business decisions.
Interested in learning more? Schedule a call with our CEO, Nathan Hirsch.
And here’s some free resources:
Effective revenue recognition in Stripe requires a cohesive approach, including compliance with the ASC 606 revenue recognition standard for your Stripe activities. While traditional product orders for most ecommerce companies don’t cause any particular accounting problems, the situation with returns, subscriptions, preorders, and gift cards is much different. Payments, fulfillment, and revenue recognition occur at different times in these transactions, which makes consistent record keeping important from the very beginning.
With increased order volumes and sales channels, month-end reconciliation will not become a time-consuming task for you, while preparation of your financial statements for the audit or fundraising will be significantly simplified. Whatever tool you choose (be it spreadsheets or built in Stripe functions or automated accounting solutions), your objective will remain the same: to build a consistent revenue recognition process that scales along with your business.
How much does Stripe revenue recognition cost?
Stripe charges 0.25% per transaction to use its Revenue Recognition service. Since the charge is volume-based, it will increase with your Stripe usage. With high volumes, the cost of using a third-party tool will be lower.
Do I have to follow ASC 606 if I’m a private ecommerce company?
Yes, if you are a private ecommerce company that uses GAAP. ASC 606 has been mandatory for private companies since 2019. Even when it is not mandatory, it is expected from private companies to apply GAAP revenue recognition.
When should I stop tracking Stripe revenue recognition in spreadsheets?
There is no set cutoff here. The majority of companies transition from spreadsheets as soon as multiple selling platforms, subscription services, gift cards, or increasing amounts of returns make monthly reconciliations too challenging to handle.
What happens to my past Stripe data when I start recognizing revenue properly?
Some businesses bring in their historical Stripe transactions, while others start from a go-live date by calculating an opening deferred revenue balance. The majority of companies choose the latter because it gets current and future reporting aligned more quickly.
Huge thanks to Synder for collaborating on this post!
