Welcome and housekeeping

Christine Butchko: Hello! We're live. Hey, everyone, how's it going? Feel free to pop into the chat and tell everyone where you're calling in from today. I'll start: sunny Hoboken, New Jersey. I see NYC. Sweet.

Welcome to today's session, Mastering Stripe Accounting: Manual Reconciliations to Daily Close, with Cody Leach, CPA. I'm super excited about this one, because what's going on with Stripe accounting is always top of mind. Without further ado, we have some typical CPE housekeeping, so we'll kick it off.

Cody Leach, CPA: Cool, let's get started. A quick bit of background: I'm the head of product experience at HubiFi, which is a funny title. Basically, I lead designing the product and building the customer experience into it, and I also lead our bigger implementations.

My background: I'm a CPA. I started at KPMG in Silicon Valley, very quickly burned out, and moved to North Carolina to do what I refer to as the lowest form of accounting, outsourced internal audit. That's where I learned SQL and a lot of the systems mapping that goes into modern accounting. For the last seven or eight years, I've focused on high-volume revenue recognition and the whole order-to-cash cycle. At HubiFi, that means Stripe, Apple, Google, and all the systems ingrained in the self-serve motion a lot of folks are dealing with. Stripe is our most common one. Internally, there are maybe one or two people with more Stripe knowledge than me, but apparently I'm the one they want doing the events.

Here's the agenda. First, housekeeping: the official compliance statements and policies needed for your CPE to be valid. Then Stripe fundamentals: the Stripe data structure, so you understand how Stripe actually works and what you're looking at in the UI. Then a UI tour focused on where to get what you need to do the accounting.

After that, we'll get into the actual accounting for Stripe: the errors we typically see, the relevant ASC guidance Stripe touches, and how to reconcile for completeness and accuracy. Then we'll show how companies automate this once manual accounting stops working and you've entered the world of a million Excel lines. We'll end with Q&A, but feel free to ask questions throughout. If we don't get to them live, we'll answer them after the event.

As an overview: the program level is beginner, the field of study is accounting, and you get one free CPE credit. It's group internet-based, with no prerequisites and no advance preparation. It's live instruction with polling questions and interactive Q&A to reinforce learning, and you can see our NASBA sponsor number on screen.

To get your credit, note that four polling questions will appear at random intervals during the hour. You need to answer at least three of them. They're sporadic so you won't know when they're coming, which ensures continual engagement. If you don't answer three poll questions, you will not receive credit for the program.

Christine Butchko: A quick note on that: the poll questions pop up on screen, but you answer them in the Polls tab on the right side of the module. We'll leave each one open for a few minutes.

Cody Leach, CPA: Cool. On CPE credit confirmation: participation is tracked through the poll questions, the session evaluation and live Q&A. Upon completion, you'll receive one CPE credit, and certificates will be issued no later than one week from today.

Stripe fundamentals: the data model

Cody Leach, CPA: Now we get to the fun stuff. When you get into Stripe, there are a bunch of different screens. For the accounting, certain screens and objects are really relevant and useful, and understanding the underlying structure, so you know how to move between screens, is the best place to start. Stripe has, I think, 32 different endpoints now: 32 different places they maintain data that have to come together to do the accounting for all the edge cases. I'll start from the top, and when we get into the UI, I'll refer back to this.

The customer is the highest level, with a customer ID. That's an individual person buying a subscription or some sort of service. Stripe allows for subscriptions, which are effectively their billing tool. Within a subscription you have subscription items, which act like a template for creating invoices at some cadence: monthly, annual and so on.

The subscription generates an invoice, and the invoice has almost three layers: the invoice header with the invoice number and ID, the invoice item as a sub-header, and the invoice line item. Stripe's data model conflates the subscription, or contract, with the underlying invoice, so the performance obligations are actually stored on the invoice line item. If you've ever looked at Stripe in depth, you'll find yourself constantly going into invoice line items, because that's where the subscription dates and term live. Stripe also has credit notes, which can be applied to an invoice like a payment method.

If an invoice isn't fully credited out or voided, it gets paid. This is where Stripe adds complexity, but it's also why they're so good at self-serve. Stripe has the concept of a payment intent: an attempt to pay an invoice. You can pay it many ways, like ACH or credit card. The most common is a credit card, which creates a charge. A successful charge means a successful payment intent, and the invoice is considered paid. But you can have multiple charges: one card failed, another failed, the third worked. A charge can also be disputed, which you might win or lose, and that's another object. Charges ultimately get paid out, which is what hits your bank account. Refunds to customers are separate.

Then there are fees. Stripe has two types of fees, and they're kind of inventing a third as we go. There are fees tied to a payment: they charge a card, capture the payment and take a fee. There are also standalone fees for services outside of payments, like invoicing or Rev Rec, where they bill based on volume for how much of the service you used that day. To get the full order-to-cash picture and get payouts to tie out, you need to account for both. Stripe is also moving to a newer pricing model that obscures fees further, where they bill you outside of Stripe, on top of the other fee types.

That's the happy path. One thing to note: balance transactions only pick up payments. All the accounting that happens upstream doesn't show up in the balance reports, because it has no cash impact in Stripe's world.

One of the more confusing and opaque parts of Stripe is the customer balance transaction. Think of it as unused time credits, gift card credits issued to customers and the like. We'll go into more detail later.

The way these objects relate is very useful to memorize. From an invoice you can click to its subscription, from the subscription to the customer, and from the invoice to the payment intent, then to the charge. When I was new to Stripe, this was the easiest way to know what I was looking at on any screen.

A few things aren't shown in this happy path, because Stripe keeps adding features:

• Connected accounts: essentially a mini bank account embedded in your app. We'll cover some accounting use cases.
• Application fees and transfers: how money moves through connected accounts, which raises net-versus-gross accounting questions.
• Metering and credit grants: newer flows supporting the usage-based billing that's popular right now.
• API version changes: the data model keeps changing. Today it shows one payment to one invoice, but anyone in enterprise billing knows you can have multiple invoices on one payment and multiple payments on one invoice. Stripe's most recent API now allows multiple payments per invoice, which makes this relationship more complex.

I keep this diagram bookmarked because I reference it almost every day.

Poll 1: How do you use Stripe today?

The options: (a) subscriptions, invoicing and payments; (b) invoicing and payments only, with usage captured elsewhere, like a data warehouse or website; (c) payments only, where your team handles everything else and you only interact with payment intents and charges; or (d) no clue.

I like this question because the accounting team often only sees option C. They're not even aware of A and B upstream, because whoever owns engineering doesn't share much with them. That's a problem, because much of the accounting needed to get revenue recognition right happens before you ever see a payment. Anyone doing their accounting off payments is doing it incorrectly.

Christine Butchko: Cody, we're having a hard time putting the poll results on screen, but you can see the answers on the right.

Cody Leach, CPA: Got it. I'm not surprised by the outcome: it's pretty evenly split. It's cool that everyone actually knows. I don't think anyone answered "no clue," which is good.

Stripe UI tour

Cody Leach, CPA: Now for the Stripe UI tour. Keep that diagram in mind, because it's where all the accounting takes place, and it tells you which reports to pull to get the data.

This is our test environment, where we do a lot of testing. Everyone should have a Stripe instance with a test mode component; Stripe is moving to sandboxes, but this lets you walk through the whole UI. The UI doesn't show the structure explicitly, but the customer is the highest level beneath your account, which is the actual account for your org or subsidiaries.

I'll pick a good example subscription so we can see the whole flow. Here's the customer, and this customer has a subscription. Within it you have the subscription ID, like a header, and the subscription items, which have an "si_" prefix. That's effectively a template your rev ops team, or the accounting team that advises them, sets up, and it stamps out an invoice at each billing date. You can see the subscription items, the customer it's related to, and the invoice it generated. In this case it's generated one, but next month it'll generate another with the exact same footprint.

The invoice has its invoice header reference, plus invoice line items, which carry the performance obligations. This one doesn't have an invoice item, but those can be things like discount codes; Stripe has changed over time how it handles discounting the whole invoice versus individual lines. Stripe also handles taxes. Older third-party tools like Avalara and Anrok create an invoice item, while Stripe's standard tax gets its own tax line on the invoice.

Then the invoice gets paid, and you see a payment intent under its payments. So the happy path is customer, subscription, subscription item, invoice, payment intent, and the payment intent has a charge. The UI shows everything you'd expect for a payment: the fees, the net amount you'll be paid and the payment method. If it was paid out, it links to the payout, the charge that generated the successful payment, and the invoice.

The event stream is very useful. It shows everything that has happened to the object: when the charge was created, when the payment succeeded and so on. If you're ever wondering what's going on with an invoice, go into the invoice and work through its event stream. That's one way Stripe differs from most billing tools you'll use: it's very API- and engineering-forward, so it's easy to see what's happening if you're willing to poke through the JSON.

Same example: you can see the fees and the payout. This payment also has a partial refund, which has an "re_" reference you can look up under Refunds. Note the relationships here: disputes and refunds are not of an invoice. They are of a payment of an invoice. As you'll see later, that matters a lot for accounting policy.

Finally, customer balance transactions live on the customer, under the customer's invoice balance. You can just give customers credits. Here I'm giving $50, and now this customer has a $50 balance that can pay for something else. Stripe also does this through unused time credits: if you credit an invoice too much, or the customer overpays, they get credit toward their next purchase.

That's a light overview of the Stripe UI. Once you live in it, it becomes second nature, and I'm always happy to give people more tours. I spend way more time in it than is healthy for any accountant out there.

Accounting for Stripe: core entries and the three reports

Cody Leach, CPA: Once you're comfortable with the UI and understand the data model, we get to the actual accounting. I'll go through how we think about order-to-cash accounting at HubiFi generally, and then how it plays out given Stripe's data model.

For revenue recognition under ASC 606, it's very important to separate the contract and its performance obligations from the billing, and from the payment of those invoices. In Stripe's world, because they overlap the subscription and the invoice and put the performance obligations on the invoice, the invoice is kind of the contract, except for certain edge cases that matter for getting the accounting right. We'll cover those shortly.

Technically, when the subscription generates an invoice, there's an initial entry: debit unbilled AR, credit deferred revenue. The performance obligation comes from Stripe's line item data: monthly, annual, point in time and so on. Almost immediately there's a second entry: the invoice is generated, so you credit unbilled AR and debit AR. Now you have the end result you expect: invoice, AR, deferred revenue. Most people we see doing Stripe accounting skip that step. They assume the invoice is the contract and never go through unbilled AR, which generates a lot of the edge cases that make Stripe accounting really nasty.

The last piece is payments. The payment intent pays an invoice, which moves to cash in transit. If you're on automatic payouts, Stripe pays you out, you credit cash in transit and debit your bank, and that's what actually hits your bank account.

Here's where each piece sits in Stripe's data model:

Accounting step

Where it lives in Stripe

Report to pull

Contract (subscription)

Subscription and invoice line items

None; Stripe doesn't model it

Billing and credit notes

Invoices

Invoice report

Payments, refunds and disputes

Payment intents and charges

Payout reconciliation report

Standalone fees

Balance transactions

Balance transaction report

So to do Stripe accounting manually, you work from three reports: the invoice report, the payout reconciliation report and the balance transaction report. Let me show you where they sit in the UI.

The invoice report. Under Invoices on the left is the only native invoice reporting Stripe has. Stripe has a few invoice statuses: draft, which has no revenue impact; open, meaning it needs to be paid, which has revenue impact and generates the deferred and unbilled entry; and uncollectible and paid. To get a list of invoices issued in a month, filter on created date, for example January 1 through January 31. I'd recommend filtering out $0 invoices so you don't pull your free trial invoices, which are usually very voluminous. Then export.

The downside is that, for accounting, the finalization date is really the booking date. You can create an invoice, leave it untouched for a month, and finalize it later. So this report generates a lot of false positives: voided invoices, drafts, and invoices that were created but not yet finalized. Filter those out.

The payout reconciliation report. For payments against outstanding invoices, go to Reports. The payout reconciliation report pulls all the successful charges, refunds, fees and so on for the second half of the accounting: I got paid, and here are the fees Stripe charged me. You can export the detail; you don't need every column, but you do need the related invoice and subscription IDs so you can trace back and match what was paid and what wasn't. The payouts are what hit your bank account, and the ending balance is what customers have paid that Stripe hasn't paid out to you yet. That's effectively your cash in transit balance.

The balance transaction report. This is a cash report, so the fees shown are those taken in cash, not necessarily all the fees incurred to date. These are the fees that should hit your P&L, and the difference sits in cash in transit: money Stripe has taken that won't be paid out to you.

Those are the places to go for the happy-path Stripe accounting. If you use connected accounts, there's also an application fees report, which is fairly straightforward: debit cash, credit revenue, since it's just money coming in. Transfers and similar flows need more thought, but that's a more advanced scenario.

The nine most common Stripe accounting errors

Cody Leach, CPA: Now that we know the happy path and how to do the accounting from Stripe, here are the most common errors we see. We run a ton of volume through Stripe, and I work with the controllers of some of Stripe's largest customers. These are the most common mistakes for folks with a manual process.

1. Cash-basis accounting. Almost everyone we see on Stripe does it on a cash basis. They take the payout reconciliation report, which is cash basis, and try to back into a rev rec schedule. That's problematic. Every customer we've worked with has had to move off cash basis, because Stripe doesn't have good enough invoice reporting to support doing it right, and matching all those invoices to payments manually is really hard. Some do a hybrid, building a deferred revenue waterfall by looking back at the related invoice for the performance obligations. That's still very problematic once you go through an audit.
2. Under-recording liabilities. The customer balance transaction I added earlier is a liability: it's free credit someone has been given. Unfortunately, Stripe has no native reporting for it except clicking through every single customer. Often a predecessor, or customer success, has been handing out these credits, and there's no easy way in the UI to find them. They're true liabilities hiding on the balance sheet. We often find several million dollars of these, because previous management ran a special the finance team never knew about.
   Motion is a good example. Their finance lead joined about a year ago, and years earlier the company had run a big program giving away free credits. That's all revenue someone can come along and use, and no one would know any better. For GAAP purposes, they were also simply under-recording liabilities.
3. Under-recording revenue and bad debt expense. This ties to cash-basis accounting. If you only account from the payout reconciliation, you're not capturing the unpaid invoices that were generated. Most folks are significantly under-recording both revenue and bad debt expense, and it hides revenue leakage: if they found those invoices, they could work the collection rate up, which means more money. And if you have a high cost of goods sold, which is common for AI companies, you're carrying a lot of back-end cost for usage nobody paid for, hidden if you only look at payouts. So it's not just non-GAAP compliant; it hurts the business too.
4. Inaccurate revenue recognition from performance obligations. If Stripe isn't set up correctly, you get bad performance obligation dates. If rev ops sets up something as point-in-time when it's really over time, that's the metadata you're stuck with. We see a lot of common issues originating upstream in rev ops.
5. Discount and contra revenue accounting. Some folks book a provision for discounts on the balance sheet; others net it in liabilities. I've never seen an auditor push hard on this, since it's more a question of balance sheet geography. Technically, a discount given over time that would go away on cancellation should be a provision for discounts. An immediate discount given regardless of future cancellation can be netted against deferred revenue. In practice, most people just net it outright.
6. Fee timing. If you take fees from the payout report without accruing them for when they actually occurred, typically two or three days before Stripe takes them out of your payout, your timing is off.
7. FX gains and losses. You need to do the invoice accounting and book the difference between what you were paid in Stripe and what you accrued when the invoice was booked. If you don't, there's no FX gain or loss, and that gets hidden too.
8. Sales tax. Most folks use a third-party tax tool: Stripe Tax (Stripe bought TaxJar), Anrok or Avalara. They're really good operationally for tax reporting, but we constantly find they're wrong about whether a liability should be reduced because of refunds or lost disputes. When we track and reverse the liability on actual revenue reversals, we very often find sales tax reporting issues.
9. Unused time credit fraud. Last but not least, and this has been really intense: Stripe's head of go-to-market even posted about it on LinkedIn yesterday. Stripe sees very high levels of unused time credit fraud, especially at high-profile AI companies. Users create fake accounts and generate a bunch of fraudulent unused time credits. Operationally it's a huge deal, and finance and accounting are the main teams that can spot it and show where it's happening. It also raises real accounting questions: if it's fraud, is there actually an ASC 606 contract? Should I recognize revenue immediately, or at all? Should I reverse it, or hold a reserve to offset it because I know it will happen? These are things to think about as you start to understand what's actually going on in your Stripe account.

Key ASC 606 accounting considerations

Cody Leach, CPA: We work with a lot of different organizations on Stripe, and there are a few areas where ASC 606 and Stripe interact heavily.

Fee treatment. Under ASC 606 and ASC 340, you can amortize costs alongside revenue as a cost of obtaining a contract, like a commission. If you treat Stripe fees that way, they go through cost of revenue and match your revenue. Or you can treat them as an operating expense, a payment processing fee, which goes into OpEx. We've seen folks split about 50/50. If you can argue for OpEx, it's a margin improvement, so conceptually that's attractive. Given how much the business cares about that roughly 3% fee from a margin standpoint, it's worth deciding deliberately: is it a commission-like cost of revenue that affects margins, or an operating expense like a bank fee that sits below the line?

This is a really big deal for buy-now-pay-later businesses, where the payment processor is deeply involved in operations, which makes a strong argument for cost of revenue. If Stripe is one of many processors and customers could just as easily pay via ACH, there's a much stronger argument for OpEx.

Bad debt expense. Many folks default to recognizing revenue only on paid invoices. That's conservative, but technically wrong under ASC 606, because every invoice goes through the five-step model to determine whether there's revenue. Collectability is one component, not the only one. Many times there's a true contract and performance has been delivered, so revenue should be recognized even if it isn't paid yet. We see a lot of under-recorded revenue from lack of granularity and unsupported conservatism. Most of the time, folks should record all that revenue and, if they have bad debt, hold a CECL reserve under ASC 326.

Proration and variable consideration. Closely related to payment: if collectability isn't assured, variable consideration should be constrained, and if you refund, you can reverse that revenue. Proration works similarly. If your terms of service give the customer a right to return, a cancellation could reverse future revenue. If there's no right to return, you've met your performance obligations, so you'd recognize all that revenue and any unpaid amount goes to bad debt. There are different ways to handle these scenarios for high-volume customers, depending on whether they're paying and whether there's a legitimate contract under ASC 606.

Contra revenue versus deferred presentation. As covered earlier, this is a presentation decision folks need to make on the balance sheet.

Principal versus agent. This relates to connected accounts. Some of our customers do net accounting as the agent rather than the principal, which shows up in Stripe if you use connected accounts, depending on the nature of the service you provide.

Fraud. As discussed, whether fraudulent revenue should be recorded at all, or backed out.

These are all areas everyone should address in their ASC 606 memo in some form. They're decisions you have to make, and they're questions auditors will always ask.

Poll 2: Where do you see the most risk with your Stripe integration?

The options: cash-basis accounting, being unable to glean operational insights, transaction volume breaking your current systems, or manual errors.

Interesting results. Cash-basis accounting looks like the most common, which makes total sense. The accounting team usually arrives long after Stripe is implemented. That's why Stripe ends up being the most common payment processor: a company starts with a founder and an engineer, and the engineer says, "I have to take payments. I'll just use Stripe, it's six lines of code." Then the company grows to $10 or $15 million and says, "Oh, crap, I need funding. Let me hire my first accounting person." Now that person is stuck with Stripe and whatever was decided upstream.

The next most common is scale breaking current systems, since Stripe leads the self-serve motion. Miro is a good example. They tried pushing all their data directly from Stripe into NetSuite, and NetSuite charged them an arm and a leg to store every transaction. Even after pushing as much as they could, they got to the point where they couldn't open NetSuite, because your ERP isn't designed to carry that much volume. And Miro isn't even the biggest customer we deal with. Scale breaks things down pretty quickly.

Reconciling for completeness and accuracy

Cody Leach, CPA: I've mostly covered this, but to make sure it's clear, here's how you reconcile once you've done the accounting.

• Bookings completeness. To confirm you've booked all your gross sales, go back to the invoice report, download it and do some manual work. That supports your journal entry, and a screenshot of it serves as support for SOC purposes.
• Cash in transit and payouts. Use the payout reconciliation report to tie out cash from Stripe to what hit your bank. The ending balance should be your cash in transit, and your net payouts should equal what actually hits your bank account for the period.
• Fees. Use the balance transaction report: the fees go to the P&L, and the difference is what's sitting in cash in transit. You can also get this from the balance summary report.

The most confusing nuance: the balance summary report shows activity regardless of what happened to the cash, while the payout reports filter on when the payment became available. It's a small difference, but knowing which one you're looking at makes your life much easier, because otherwise you'll always be about three days off.

Automating Stripe order-to-cash and daily close

Cody Leach, CPA: What happens when you get into the unfortunate situation where doing it manually doesn't work anymore? It happens sooner than you think, though you can stretch it longer than you'd expect, because most of us are better at Excel than most folks. But once it's too large for Excel, you're forced to automate. I work with customers all the time who say, "We can't do this manually anymore. I need an option to automate it."

Why does doing it manually suck? It's risky: we just saw in the poll that most people know they're on cash basis and are hoping the auditors sign off. Manual errors creep in from those Excel files, and that's not compliant.

Even more important, doing it manually demotes and devalues the accounting organization. Take John, the revenue accounting manager at Healthie. He spent his entire month taking Stripe Rev Rec reports, correcting them for their business and reporting on them. When you have to drop everything into Excel just to get it right, you lose all the granularity. So the FP&A team goes and gets their own revenue number: they pull all the invoices and report that to management. Then the accounting team spends the rest of the month arguing about why their number is higher or lower than the one FP&A is planning from. It becomes a futile exercise, and accounting gets seen as a compliance function instead of the source of the most important data the business uses for decisions.

That's because you have to go to so many places to get the data. If you're lucky and everything is in Stripe, you can pull the Stripe reports. But many of you sell through other systems too, which means going to each of them to do the accounting, so it takes even longer and is even less accurate. This is really common because of decentralization. NetSuite is great, but it was built twenty years ago, and people now sell in ways NetSuite never evolved to handle. They're stuck between upstream systems, Stripe being the most common, and their ERP.

That's what we specialize in at HubiFi: full end-to-end automation, specifically for Stripe. When I say we're the number one rev rec integration for Stripe, we are the number one rev rec integration for Stripe. We work with Stripe's highest-volume and newest, highest-profile customers, like Cursor, Perplexity and ElevenLabs. We work with pretty much every AI company on Stripe, like Motion and Warp, the app companies that sell through their websites, and public companies like eero, a subsidiary of Amazon. And that's not even the full list. Stripe is by far our most common integration, and we process several billion transactions of Stripe accounting every month.

Poll 3: What integrations support your product-led growth revenue?

PLG may not be a term everyone uses, but think of it as self-serve, B2C, D2C or consumer sales: customers buy through your website, and you take payment through Stripe. The options: Stripe only, where you just need three reports; Stripe plus the app stores, where you also have to go to Apple and Google; your own website with payments collected in Stripe; or something else, like Chargebee or Recurly, and you're looking at Stripe.

I should have known pretty much everyone here uses only Stripe, since you came to a Stripe accounting CPE. That matches what we see across our customers: almost two-thirds use only Stripe, and about a third use something alongside it, whether an upstream system or the app stores.

Demo: a fully automated Stripe order-to-cash

Here's a quick tour of how we've solved this. Stripe does have a Rev Rec module, and most of our customers come to us after using it. It's great for a rough estimate, but it doesn't produce GAAP-compliant accounting. If you need to pass audit, be highly compliant or go public, Stripe Rev Rec just doesn't work. Surprisingly, it also has a volume problem: it can't handle the volume of many of Stripe's high-profile customers, or even some lower-profile ones.

This is what a fully automated Stripe order-to-cash cycle looks like. We hit all 32 Stripe endpoints: everything we covered, plus connected accounts, application fees, transfers, metering, credit grants and so on, across the nine different API versions Stripe has at this point. Every single day, it runs a full order-to-cash close for Stripe. It effectively turns Stripe into its own little ERP module, because all the reporting data in Stripe is attached to journal entries that tie to your GL.

You can see all the order-to-cash accounting broken out by any upstream data, like state. I can drill into deferred revenue by customer. Here's a single customer with two subscriptions in Stripe, and within each subscription, the performance obligations that drive the order-to-cash accounting and rev rec.

I'll pick one to show the full, GAAP-compliant order-to-cash detail. This subscription generated a $275 invoice. We track all the operating accounts Stripe touches as well as the P&L accounts. When the invoice is generated, there's the revenue entry: $275 to unbilled AR. HubiFi keeps the source system record that generated each entry. Stripe has no concept of a contract, so we create one: the invoice line generated by the subscription item for that product.

Immediately it gets billed, because the invoice is generated at the same time, so you see the unbilled-to-billed entry referencing the actual invoice upstream. Then it flows through billed AR. When it's paid, you see the payment intent that paid the invoice, with all its metadata if you need it. The customer pays, it goes to cash in transit, and then it's disbursed. There's also the fee accounting: this one had a $1.50 fee, so you didn't get paid $275, you got $273.50.

On the other side of that unbilled entry is deferred revenue. On the booking date, we booked $275 of deferred revenue. Since we run daily and this was generated mid-month, you'd see fifteen days of recognition into revenue, continuing over time.

That's one contract. Open everything up and it's all your subscription revenue across every contract, stored at what is effectively a giant pivot table layer, which is what our UI is. Each month, you push the journal entry to your GL with whatever segmentation you need: departments, or classes in QuickBooks Online, as your upload template.

We also support pushing directly to the ERP. eero, as a public subsidiary of Amazon, is required to have an automated push, so we push to NetSuite for them every month and they post it after review. Other customers just post to QuickBooks Online and never have to change their GL. People will take QuickBooks from $50 million to $500 million because all the revenue detail sits in the subledger and they post summary entries to the GL, which is an interesting use case.

Whatever you post to the GL is also what FP&A uses. In my Stripe demo, you can see total revenue for the period matches the GL revenue. It's the same data, and because it runs daily, FP&A doesn't have to wait for accounting. What we're seeing with customers is that if the accounting team can't deliver daily, FP&A steps in and does it themselves.

Cursor is my favorite example. Will, their revenue accounting manager, took the HubiFi data and showed FP&A they'd been calculating their own number wrong for about two years. Now they push the data to a warehouse and run Cursor, their own AI, over it for FP&A: analysis, analytics, flux analysis. The accounting team basically said, "This is our data to govern. FP&A, you have everything you need from us." That's what doing it daily, with real granularity, makes possible.

Back to the Healthie example: once John implemented HubiFi, he became head of FP&A, because they no longer needed a revenue manager. He takes the data calculated every day and does real FP&A analysis for the business.

With all this data done correctly, you can also build the basic reporting you need. For deferred revenue, take your booking and recognition entries and view deferred revenue by cohort, then drill into cohorts by customer, invoice, subscription or any cut you want. That's really useful for forecasting: what does the revenue I already have look like, and then you layer on new bookings. Same with ARR reporting: if you're not doing rev rec right, you're not doing ARR right either, and often the accounting team can now tell the business whether ARR is being calculated correctly.

So that's how folks are automating this end to end. At the end of the day, that's the accounting outcome you need. We just do it every single day. We live and breathe it, which is why folks come to us about their Stripe flows. If we can help, we will, and if not, we'll point you to the right place.

Poll 4: What's your current method for rev rec?

The options: (a) spreadsheets, Excel or Google Sheets, maybe now with Claude, Gemini or ChatGPT; (b) Stripe Rev Rec, Stripe's native revenue recognition tool; (c) that's the next controller's problem; or (d) some other tool. A lot of people are trying to do rev rec in this space, but they don't really do it right.

That's an interesting spread. I'd have thought more people would use Stripe Rev Rec. Part of it is that most people don't want to pay for it. I think they charge a flat fee plus a volume fee, which makes no sense to me: it's already hard enough for accountants to get budget for software, and not being able to say what it'll cost makes that conversation harder than it needs to be.

Closing and Q&A

Cody Leach, CPA: Much to the chagrin of my wife, who, funnily enough, is on this call (hey, Danny!) and is also a CPA, which makes for very riveting dinner talk, I love talking about this stuff. Feel free to connect with me on LinkedIn. I'm more than happy to answer questions, talk through your Stripe environment, and share how other folks do it. At this point I've seen dozens of Stripe integrations and ways folks handle self-serve and enterprise billing.

For CPE evaluation: if you have questions, reach out to me. You must complete the evaluation form to receive your CPE credit. You'll get the form as soon as we end, and attendees will also receive it by email. The latest it can be submitted is March 15. Participation is tracked through the live polling questions, and certificates will be issued no later than a week after you complete the form.

We have about five minutes, so let's go through some questions.

Question (Franco): How would this work if we use manual payouts, so there's no payout reconciliation report available?

Cody Leach, CPA: Really good question. Stripe supports two payout methods: automatic and manual. Unfortunately, with manual payouts, Stripe doesn't maintain granular detail. Say you collected a thousand transactions and then triggered a payout: with manual payouts, Stripe can't tell you which balance transactions were included in it. Our recommendation is to turn on automatic payouts, because otherwise you lose that granularity.

If you don't, the best accounting is to take your activity, based on the date payments become available, into a Stripe wallet or Stripe cash clearing account. You'll have an ever-growing balance, which Stripe allows, and you credit it whenever a payout actually goes out. That maintains a cash-available-in-Stripe, wallet-style concept. It's kind of annoying and a little manual. Turning on automatic payouts solves it, but I understand why some folks don't want to, mainly because they want control over their cash balances. We see this a lot: often when we implement HubiFi, customers turn on automatic payouts once they realize how much more painful the accounting is without them.

Question (Alex): Do you have a lot of customers using Stripe's Rev Rec module?

Cody Leach, CPA: Our customers don't use it anymore, but I'd say probably 75% of them were using Stripe Rev Rec before they partnered with us. Cursor, Perplexity, Motion, ClassDojo, Dub Club and Healthie are all examples, and there are many more I can't think of off the top of my head. That's especially true for Stripe's largest customers. If you've seen these AI companies, they reach half a billion dollars in revenue within two years, which is a ton of transaction volume in Stripe.

Copy.ai is a really cool story. They don't have huge revenue volume, but they have a ton of free trials: something like 0.02% of their customers were paying. There was so much volume flowing through that we did a bake-off with Stripe Rev Rec. Stripe couldn't even pull all the data into the Rev Rec module to do the accounting, correctly or incorrectly, by the time we'd finished our implementation within a week. So most of our customers tried Stripe Rev Rec and realized either it can't handle their volume, or it's producing non-GAAP accounting, especially around variable consideration and proration. It just doesn't handle those right, and you can't really change it because it's baked in.

Question (Alice): We've had trouble reconciling Stripe transactions when Stripe is the payment processor for another sales platform. Any tips?

Cody Leach, CPA: If you're using just Stripe's payments module, your upstream sales are happening somewhere else. That's exactly the problem we solve for AllTrails. They sell through Recurly, which manages subscriptions and invoicing, and Stripe is the payment gateway alongside several others. HubiFi connects to those systems to drive the deferred revenue and billing accounting, then matches Stripe in as the actual payment.

It goes both ways, too. If something happens in Stripe and your policy treats it as variable consideration, that Stripe refund could affect the upstream revenue, and we handle that accounting.

Doing it manually is a huge pain. You have to go to Recurly, or whatever the upstream system is, for bookings data, figure out the matching logic, do it with XLOOKUPs, and keep your AR going that way. Short of automating with something like HubiFi, you're basically doing a bunch of lookups between two systems and hoping you have the reporting you need.

I think that brings us to the end of our time. Thank you, everyone, for joining. For any questions I didn't answer, I'll send a follow-up. Thanks for your time, and I hope everyone has a good rest of their Wednesday.

‍