Christine Butchko
Hello. Oh, yeah. We're live. Hey, everyone. How's it going? Feel free to pop in and tell everyone where you're calling in from today. I'll start. Sunny, Hoboken, New Jersey. Got n y c. Sweet. Alrighty. Well, welcome to today's session, mastering Stripe accounting, um, for manual reconciliations to daily close with Cody Lynch, CPA. I know I'm super excited about this because what's going on in with Stripe accounting is always, uh, top of mind. So without further ado, we have some very typical housekeeping for CPE. So we'll kick it off.

Cody Leach, CPA:
Cool. Um, Yeah. I guess we'll get started. So just a quick bit of background. So I'm the head of product experience at Abbify, which is a funny title. But, basically, I'm the head of designing the product and getting customer experience in there, uh, and then also, like, doing implementations. So I lead our bigger implementations. Um, my background is I'm a CPA. I started with KPMG in California in Silicon Valley. Heated it, Uh, very quickly burned out and moved to North Carolina and did what I I refer to as the lowest form of accounting, which was internal outsource internal audit, uh, where I learned SQL and a lot of, like, the systems mapping, uh, that goes into modern accounting. Um, But, yeah, the last basically seven, eight years, it's been focusing on high volume revenue, uh, recognition accounting, like the whole order to cash cycle, and very specifically with Hubify, around Stripe, uh, Apple, Google, and all the kinda, like, systems that are very much, uh, ingrained in this, like, self serve motion that a lot of folks are dealing with. Um, and Stripe's, like, our most common one. So, internally, there's probably maybe one or two people that have more knowledge than me, uh, on Stripe. Um, but, apparently, I'm the one that they wanna have to do the events. So, uh, quick agenda just so everyone knows kinda what we're gonna be going through. Uh, just instruction on housekeeping. So we need our structure. We already passed that. Official compliance and statements and policies to the stuff in order for our CP to be valid. Uh, and just some information to reuse. We're gonna go through the Stripe fundamentals. So Stripe data structure to understand, like, how does Stripe actually work? Are you looking at the UI? What am I looking at? Uh, a UI tour, but more focused on, like, where to go get the stuff that you need to do the actual accounting for it. Um, and then we're gonna go into more, like, actual accounting for Stripe and the relevant, like, errors that we typically see and the, like, really relevant accounting, uh, ASC code that is related to what Stripe like, how Stripe touches it. Uh, and then also to how to reconcile it for completeness and accuracy. Um, and then we'll also show how different companies are automating it when you get past the point where manual, uh, accounting doesn't work anymore. Effectively, we're all all admitted to the world of a million, uh, Excel lines. So we'll kinda go through how that works and how certain people are are doing automation to scale, uh, really quickly and and very, uh, large on Stripe alone. And then we'll have a q and a at the end. Uh, feel free though to ask questions throughout. If I have time, we can we can answer them. Um, but worst case scenario, we'll be able to answer the questions, uh, after the after the event. So just as an overview, uh, this program level is beginner. The field of study is accounting. You get one free CPE. Group Internet based, there are no prerequisites. Uh, advanced preparation, there's many. Um, and then this will be live instruction with polling questions, interactive q and a to reinforce learning. Uh, and then you can see our NASBA, uh, sponsor number. Just as a note, in order to get your credit, there are four four polling questions will be applied at random intervals during the each hour of the programming. So in order to get your credit, you need to at least answer three of the poll questions. And the poll questions will be sporadic, so you won't know when they're gonna happen to ensure continual engagement. Um, if you don't answer three poll questions, you will not receive credit for the program.

Christine Butchko:
Um, and just a quick note on that. Um, in order to answer the poll questions, they will pop up on screen, but you have to go to the right side of the chat, uh, or right side of the module under polls, um, and they will pop up, and that's where you answer them. So we'll leave them open for a few minutes, but that that's where you answer the poll questions.

Cody Leach, CPA: 
Cool. Alright. And then, yeah, CP credit confirmation. So participation is tracked using a lot of poll questions with session evaluation and live q and a. Upon completion, participants will receive one CP credit, and the CP showcase will be issued no later than one week from today. Alright. Now we get to the actual fun stuff. So Stripe fundamentals. So the easiest way to start from this is that most of the folks, when you get into Stripe, there's a bunch of different screens. Um, when it comes to doing the accounting, there's, like, certain screens and objects within Stripe that are really uh, relevant and useful. And understanding the underlying structure so you know how to go between the screens is probably the the best place to start when it comes to Stripe. Um, Stripe has, I think, 30, I think, 32 different endpoints now. So 30 different places that they maintain data that they have to come together in order to do the manual accounting for all the different edge cases. Um, so we'll kinda start from the top. Uh, and then what I'll do is it when we get into the actual Stripe UI, I'll reference back to this. So within Stripe, there's, like, the customer is kinda the highest level, and then a customer can have a and this will be, you know, a a customer underscore ID. Um, this will be an individual person that's buying a subscription or some sort of service. Uh, Stripe allows for subscriptions, which is effectively a billing, uh, tool in their world. And within that subscription, we'll have subscription items, which is effective like a template for creating invoices at some cadence, monthly, annual, etcetera. Uh, and then within a subscription, we'll generate a invoice, and that invoice actually will have almost three different layers. You'll have an invoice header, which will have, like, an invoice number ID, invoice item, which will be, like, a subheader within an invoice, and then invoice line item. Uh, in Stripe's world, they they kinda mess up the the data model behind or the cash in the sense that they conflate the idea of a, like, subscription and contract with the underlying invoice. And so the performance allegations are actually stored on the invoice line item. So if anyone's ever, like, looked at Stripe in-depth, you'll find yourself very constantly going into invoice line item because that's where the actual, like, when's my subscription and what's the term of the subscription. They also have the concept of a credit note, which can be used to apply to an invoice as, like, a payment method. Um, and then an invoice, if it's not fully credited out or voided, will get paid. And this is where Stripe, I guess, adds a little bit of complexity, um, but it's why they're so good at this, like, self serve motion is Stripe has this concept of a payment intent, which is this is an attempt basically to pay a invoice. Uh, and so what happens is you can pay that invoice a lot of different ways. You can pay it via ACH. You can pay it via credit card. There's different ways. The most common way, if there's, like, a credit card payment, which is probably the vast majority of the way folks interact with Stripe, is you'll have a charge. And so when there's a successful charge, that will have a successful payment intent, which will consider the invoice paid. Um, but then what can happen is you have multiple charges where it's like I tried one credit card, failed. Another credit card failed. Okay. The third credit card worked. And then a charge can be disputed, and that will mean no initiate dispute. You could win it. You could lose it. Um, but that's another object within Stripe. And then, uh, the charges will ultimately get paid out, and this will be what actually hits your your bank account. Uh, and then you can refund customers, which is separate. Uh, and then there are also fees that Stripe will charge you. Um, so within Stripe, there's actually two types of fees. And I don't wanna say they're inventing a third, but they are kind of inventing a third as we go. Uh, you have the fees that are related to an actual payment. So charge a credit card. They successfully capture a payment. They take a, you know, a couple of cent fee. Uh, and then they also have standalone fees that they charge for the services outside of it. So things like, uh, invoicing. Uh, if you buy rev rec, they'll they'll basically do a volume based to say, hey. For this day, use this this much of our services. We're gonna charge you x. Um, and so you in order to get the full, like, order to cash and you get payouts to tie out, you'd need to do the accounting for both of these. Uh, and further, Stripe's basically moving to a a newer pricing model for fees, uh, that obfuscates the fees even further, um, where they actually bill you outside of Stripe. And so those are things also to think about too where, like, they'll give you, like, a gross billing just for being in their service on top of these other three. Uh, that's kinda like the happy path. Uh, one thing to note is that when you get into the payment world, most folks here and that is our experience is that the balance transactions pick up only on payment. So there's all this accounting that happens up here that doesn't show up in the balance reports because they don't have any actual, like, cash ramifications in Stripe's world. Um, only balance transactions are covered in this area. Uh, one area that's a little bit I will talk a bit more in-depth that confuses a lot of people and is probably one of the more opaque parts of Stripe is this concept of a bust customer balance transaction. You can think of it as based like an unused time credit, um, gift card credits issued to customers, and stuff like that, and we'll go into that more detail as well. But the way these relate to each other is very useful, uh, to, like, memorize because it means that if you're on an invoice, you can go click to a subscription. And if you're on a subscription, you can go click to a customer. If you're on an invoice, you can just click to the payment intent, to the charge, etcetera. And so I found myself when I was first on Stripe that this is the easiest way to, like, know what you're looking at when you're looking at a screen, and it helps just give context. One thing that's gonna I guess, a couple of things that are not shown here. This is kind of a happy path for Stripe. And as they innovate, they add new things. Uh, so some of the things that you don't see here that you guys might be familiar with is the concept of connected accounts, um, which is basically their way of allowing you to have a little mini bank account within embedded within your app. Uh, we'll talk about some use cases around that in the accounting. Application fees and transfers, which is how they pay through connected accounts. Um, that's the whole, like, connected account process that allows for, like, net versus gross accounting. Uh, metering and credit credit grants are newer flows that they've invented to support a lot of usage based billing that is really popular these days. Um, and then probably more importantly is that the data model for Stripe is constantly changing as they change their API versions. Um, so one of the more interesting things you'll see is that what's not set here because it's not as widely adopted is that this relationship here indicates that basically a one payment to one invoice. But anyone here who's worked in enterprise billing knows that there can be multiple invoices made on payment. You can also have multiple payments on one invoice. So Stripe actually has split this up in their most recent API to basically allow multiple payments to hit an invoice, which makes this relationship a little more complex than it's presented here. But this will be something where I I actually have this saved as a bookmark because I reference it almost every day since I hang out with Stripe almost every day. So that gets us to our first polling question, which is, how do you use Stripe today? Uh, do you use the subscription and contract management invoicing and payments? So subscriptions, invoices, and payments. Do you only use invoicing and payments where, you know, technically, your usage stuff is maybe in a data warehouse stream, captured like a website, uh, or all payments only, in which case your team does some stuff, and then they collect payments from Stripe, and the only thing you interact with are payment intents and charges. And d, uh, no clue. And I like this question because a lot of times, the accounting team only sees c, and they're not even aware of upstream a and b because they're like, whoever owns engineering, uh, around that doesn't really, um, give them much privy to it. And it becomes problematic as we'll show because a lot of the accounting in order to get your revenue recognition correct is actually before you ever see payments, which means that anyone doing their accounting on payments is is doing it incorrectly. Cool. Alright. Let's see. We're gonna show the, uh, we should be able to show the results. I'm sure you'll see what the answer. Hey, Cody. I think, um, we're having a little bit of a hard time, uh, putting SQL polls up on the screen. Ah, okay. So that's what that's that pink, white page you just keep seeing, but you can see the answers on the right. Alright. Cool. Yeah. I'm not surprised with the, uh, with the outcome here. Pretty much evenly split, which is interesting. It's cool that everyone actually knows. Uh, I don't think we got anyone answering no clue, which is good. Okay. Cool. Sweet. So then we'll go through a, uh, a Stripe UI tour. So keep in mind, uh, this image because this is gonna be basically where, uh, all the accounting takes place and where you need to go in Stripe, and it indicates which reports you have to pull to get all this data. So I will go ahead and pull up. This is gonna be our, like, test box. Um, so it's where we do a lot of our testing, um, to pass things through. It's how it works. Everyone should have a Stripe instance that has, like, a test box component to it. Uh, they're changing to, like, a sandbox, but this is in test mode. Um, but it it lets you at least walk through the whole UI. So when we think about, uh, the way, like, it's, uh, Stripe is structured, it doesn't really indicate, like, how the structure sits up here, but customer is kinda like the highest level. Like, you have an account that's the actual account for your org or for, like, the subsidiaries, but this is the highest level that, um, it goes through. And so I'll actually pick a, uh, a subscription that is a good example so we can kinda see how the whole flow works. So you can see this is the customer, dad f at test. Um, and this customer has a subscription. And so within the subscription, you're gonna have the actual subscription ID, which is like the header, and then you're gonna have what they call, uh, subscription items, which has this little SI reference. So this is effectively a template that either your rev ops team or the accounting team who recommends it will actually set. Uh, and this will generate and basically stamp out an invoice at any point in time with these different pieces. So, for example, you can see within the subscription, it says, okay. These are the the SI. Uh, this is the customer it's related to, and it's generated this invoice. So in this case, it's only generated one, but then next month, it'll generate another one with the exact same footprint. Uh, and you can see here the the, um, invoicing that's come through. Uh, and so this invoice will have a invoice, which is the invoice header reference. And then you'll also have the invoice line items, which, like I said, have the actual, uh, forms obligation, uh, on there. And so this one, as an example, doesn't have a invoice item, but it can be things like, like discount codes. Uh, Stripe uses different things over time in terms of, like, trying to, uh, like, pull discount the whole invoice as opposed to individual line on the invoice, uh, and stuff like that. Stripe also has taxes as well. So some older systems like Avalara and Enrock, they'll actually create an invoice item here, uh, versus using Stripe's standard tax, which will have its own, um, line on there. So there's also a tax item component as well that shows up as an invoice line. Um, and then what happens is this invoice will be paid. And so you'll see payments on this invoice, and you'll see there's a payment intent. And so from, like, a happy path standpoint, you can see customer subscription, subscription item, payment intent. And that payment intent can have will have a charge associated with it. Uh, and so one of the things you can see in the UI is it has all the basic information that you'd expect around a a payment. So there's the fees. Um, there's the net amount that you'll be paid, uh, the payment method, uh, and stuff like that. You'll also see, uh, if it was paid out, it'll go to a a payout, and you can see the actual charge that generated the successful payment. Uh, and then also the linking to around the actual, like, invoice. One thing that can be useful, uh, is the event stream. So this will be, like, everything that's actually happened to this individual item. So you can see, like, when this charge is created, the payment was succeeded, etcetera. So if you're ever wondering, like, what's going on with an invoice within Stripe, usually, you go into the invoice works, and then you can kinda work through the event stream to see what exactly happened. Um, that's one of the things that makes Stripe a lot different than a lot of other billing tools you'll probably interact with is that Stripe is very API and engineering forward. So they make it really easy to go see what's going on if you're, uh, willing to kinda poke through the the JSON. And with that too, the same example. So you could see, uh, the fees, uh, and then the actual, uh, payout, which will happen. And then in this case, actually, there's also a refund. So you can see here that this payment has a partial refund, which will have a, um, which will be have a r e underscore, um, reference that you can go look up when in the here's the refunds. So you can see, like, that r e underscore. One thing to note is the relationships here. It opens up a really interesting dynamic in a sense that, uh, disputes and refunds are not of an invoice. They are of a payment of an invoice, which when we get to a little bit later, you'll see is very important from, like, an accounting policy standpoint. And then customer balance transactions. So these will actually be on a customer, um, and you'll see it under, uh, customer val customer invoice balance, in which case you can actually just give customers credits. So, like, in this case, you're just giving $50. And now this customer has a customer balance of $50 that can be used to pay something else. Um, Stripe also does this via unused time credits. If you credit an invoice too much and they pay too much, then they'll get credit for their next purchase. Cool. So it's a light overview of the Stripe UI. I find that once you live in it, it's good practice, but I'm always happy to give people more tours because it's I spend way more time in it than I than is healthy for any for any accountant out there. See. Cool. So now we'll move on to the next section, which is accounting for Stripe. So once you have the actual UI and you're comfortable with how the UI works from an accounting standpoint and you understand the data model, then now we get to the actual accounting for it. So I'll go into kinda, like, how we think of word of cash accounting. It's, uh, Hubify generically and then how this manifests itself within Stripe given their data model. So when when it comes to doing rev rec and ASC six zero six accounting, it's very important to differentiate the idea of a contract and the related performance obligations to the actual billing and then the actual payment of those of those invoices. And so in Stripe's world, technically, when a invoice is generated, because they kind of, you know, overlap the concept of a subscription invoice and they put the from a sideways on invoice, that is kind of the contract except for certain edge cases that are important for getting the accounting correct, which we'll cover in a little bit. But, technically, when an invoice the subscription generates an invoice. There's an initial entry of deferred revenue and then unbilled they are. And then from that, the performance obligation will come from the actual Stripe from our delegation in terms of, like, this is a monthly, this is an annual, this is a point in time, etcetera. And then almost immediately, there's a second entry, which is, okay. This invoice is generated. I now have a credit to my unbilled AR and a debit to my AR. So now you have the end result that you're expecting, which is invoice AR, deferred revenue. Most people we find when they're doing the Stripe accounting skip that step and inappropriately assume that the invoice is the contract and do to do that accounting without ever going for a bill they are, which you'll find generates a lot of the edge cases that make Stripe accounting really, really nasty. Um, and then the last bit is the actual payments. Like, as we saw, the payment intent will pay an invoice, in which case, we go to cash in transit. And then if you're on automatic payouts, Stripe will pay you out, uh, and then you'll actually credit the cash in transit and then debit your bank. And then that's what will actually hit your bank account. Um, and so when we think about where these things sit within the Stripe data model, there's there's the concept of the subscription invoice, which is a the contract. There is no reporting in Stripe for this just because they don't model it correctly. Um, in terms of, like, the actual billing for invoicing, the closest that they have is the actual invoice report, which for better or worse is literally just a dumb invoice listing report that you can query. Um, also, credit notes will be on there as well. And then your payment intense refunds and disputes will be the minutes. All of that information will come out from the payout reconciliation report. Uh, and then you have the standalone fees, which have to come from the balance transaction report. So to do the accounting for Stripe manually, you effectively all you have that'll go on is the invoice report, payout reconciliation report, and balance transaction report. Uh, and I'll show you kind of where those, uh, sit in the actual, um, UI. So for your invoice report on the left here, you'll see invoices. So this is the only reporting Stripe has natively around invoicing, um, in which case, in order to, like, pull a report, you'll pull what has gotten created during the month. Um, so in Stripe's world, there's three statuses for invoices. There's, uh, draft, which has no revenue impact. There is open, which means there it needs to be paid, which has revenue impact that generates that deferred and, uh, unbilled entry. And then you also have uncollectible and paid, um, in which case if you want to get a list of, like, quote, unquote, what were my invoices I issued in this month, you'd have to go to this screen. Uh, you wanna basically pick the created date for whatever date it is that you're you're looking for. So if you wanted to do a month, you you could do February, which should be or January, which should be January 31. Um, and then you'd basically, uh, I would recommend filtering by zero so that way you don't get your free trial invoices that are usually very voluminous. Uh, and then you would simply export it. The only downside to this is that, technically, on the accounting, the finalization date is really the date of booking, um, because you can create an invoice and then not touch it for a month and then finalize it later. And so this report for better or worse generates a lot of false positives, which are voided invoices or invoices that are in draft status, but not that have been created, but haven't been finalized yet. So when you filter this, you filter it for voided invoices, draft invoices, and, technically, things that, uh, haven't been finalized yet. So that's the invoice report in order to do, like, your actual booking entry. And then for the payment attempts to figure out, okay, I have outstanding invoices that need to be paid, you'll go to the reporting, and you just go to reports. And then these will be the two reports that matter. You have the payout reconciliation report, which you can basically download, and this is going to only, uh, this will basically pull all of the successful charges, refunds, fees, etcetera to do the second half of the account, which is I got paid and what are the fees that Stripe charged me. And so this one, you can basically export the detail down here. And you don't have to do all the columns, but there's obviously a ton of data you can, uh, generate. The main ones you need is, okay, what order invoice and subscription IDs that these relate to so you can go trace them back and and do that matching exercise to see what was paid and what wasn't paid. So that would be the actual, like, downstream paid cash in transit accounting knowing that, technically, your customer can pay you, and then you get paid. So this will be what actually hits your bank account, the payouts, and this ending balance will be what have your customers paid that Stripe hasn't paid you out yet. And so effectively, it becomes your cash in transit balance. And then the last bit is the actual fees. So this is a cash report. So the fees that you see here are the fees you've paid in cash, which isn't necessarily the fees you've actually paid to date. In which case, this is gonna be the fees that should actually hit your p and l, and the difference is gonna be sitting in cash in transit, which is going to be money that Stripe has taken for cash in transit that they're not gonna pay you on payout. And so those are the the places you have to go to do the happy path accounting uh, for Stripe. If you're in connected accounts, then there's an application fees report that is luckily pretty straightforward. It's credit revenue, uh, debit AR, um, or sorry, debit cash. This is just money that comes out, uh, in which case there's not a whole lot of complexity there. Um, there are transfers and stuff like that to to think through. But that's more, I guess, a more advanced, uh, Stripe scenario. Cool. So now that we kinda know what the, like, the the happy path and how to actually do the accounting from Stripe, uh, I'm gonna go through kinda some of the most common accounting errors that we see. So, like, we do a a ton of volume through Stripe, we use we actually work and I work with the controllers of some of Stripe's largest, uh, customers. And so these are the most common mistakes that we see for folks that, uh, have a manual process. Um, so the first one is that almost everyone that we see on Stripe does it on cash basis. So they will take the payout reconciliation report, which is cash basis, and then they will try to back into, like, a rev rec schedule. This is problematic. Uh, you know, like, I I'd call it a specific customer client we work with, but every single person that we've worked with has had to go off cash basis because there isn't good invoice reporting in Stripe to be able to support, uh, the doing the accounting right. And it's really, really hard to do manually. As you can see, like, you basically match all these invoices to the payments. So everyone's usually on cash basis, and then maybe they'll do some sort of hybrid, uh, version of cash basis and then try to do a deferred waterfall by looking back at the related invoice to get the performance obligations. Still very problematic when you start going through audit. Uh, the second most common error we see is under recording liabilities. So you'll saw when I went through there and added that customer balance transaction, that is a liability in the sense that it's free credit that somebody has been given. Unfortunately, there is no reporting natively within Stripe to get to that except for clicking through every single customer. And so most of our the folks we work with maybe a predecessor or customer success is giving out these credits, and there is no easy way within Stripe's UI to go find these credits, which is true liabilities hiding on the balance sheet. And so very often when we work with folks, like, there could be several million dollars worth of these because a predecessor or a previous, like, management decided to run a special that the finance team never knew about. In which case, they may find that they literally have, you know, several million dollars of balances in their sheet. Um, Motion is a good example of this where PPA Finance comes in. He got hired a year ago, and then five years prior, when he was over there or anyone that was in the finance team, they ran this giant program where they basically gave away all these free credits. That's all revenue that if someone comes along, they can just use it, and no one would know any know any better. Um, and then, technically, they're also just under recording liabilities for GAAP purposes. The third most common accounting error is under recording revenue, uh, and bad debt expense. And this is very much related to the cash basis accounting we're talking about, which is if you are only doing the accounting from the payout reconciliation, that means you're not capturing all of the unpaid invoices that were potentially generated, uh, beforehand, which means that for most folks, they're actually very much under recording revenue, uh, and they're also very much under recording bad debt expense. And it hides a lot of revenue leakage because if they could go get it and go find those invoices, they can potentially work the collection rate up, which means just more money. It also means that if you have a high cost to get sold, which is really common for these AI companies, it also means that you're gonna have a ton of costs in the back end that you know what I mean paid for. That would be hidden if you're only doing the accounting from the payout reconciliation. So not only is it not gap compliant, it's also shooting the org to flip to do it wrong, uh, from an accounting standpoint. The fourth is the accurate revenue recognition based on performance obligations. So one of the things that we see a lot in Stripe is that if you're not setting up Stripe correctly, you're gonna get bad performance obligation dates. So if the rev ops team is doing things that are immediate, but they're really over time, I think that's the that's the metadata you have to work with. And so you'll see basically common issues around rev ops up upstream. Uh, another one is the discount and contra revenue accounting. So certain folks will do, uh, the provision for discounts on the balance sheet or they'll net it in liabilities. Well, I've never seen this in actual, like, like, somebody poking on an audit because it's more of like a balance sheet, uh, geography question. Technically, if it's a discount that is given over time and would go away if there's a cancellation, it should actually be a provision for discounts. And if it's a immediate discount that's given regardless of future cancellation, then it can be netted against deferred. Um, but just in practice, we've seen most people just net it outright. Uh, the third most common is the fee timing, which is if you're taking the fee on the payout report and you're not technically accruing for when it actually took place, which is typically two or three days earlier before they actually take it out of your payout. Uh, seven is the actual FX gain and loss, in which case you have to do the revenue you have to do the invoice accounting and do the difference between what you got paid in Stripe versus what you accrued, uh, on the actual booking of the invoice. If you're not doing that, then there's no FX gain or loss, and that gets hidden as well. Uh, the eighth most common is sales tax. So while most folks are using a third party tax, so, like, Stripe bought TaxJar. Uh, so that's that's Stripe's native tax reporting. Uh, Anrock or Avalara, we'll find that those folks, while they're really, really good operationally for helping you do your tax reporting, we do constantly find that they are incorrect in terms of whether they should be reducing a liability because of refunds or because of lost disputes and stuff like that. And so we very much find, uh, issues around sales tax reporting when we when we do it the correct way, and we're actually tracking and reversing the liability when there's actual reversal revenue and stuff like that. Ninth, and I see this as last but not least, uh, it's been really, really intense, and I don't know if anyone saw, uh, the head of revenue. It's like go to market at Stripe that even posted about it yesterday on LinkedIn. But, um, Stripe has extremely high levels of unused time credit fraud, um, and especially for, like, really high profile, like, AI companies. They users will basically, like, make fake users and generate a bunch of unused time credits that are fraudulent. Uh, while very problematic from a, uh, like, a reference standpoint, operationally, it's a huge deal, and the finance and accounting team are the main folks that are, uh, that can can look at it and show the account that work. Um, but it also ends up creating a lot of concepts around, you know, if it's fraud, is there actually ASC six zero six contract? And should I even be recognizing revenue immediately or recognizing revenue at all? And, like, should I reverse it? Should I have reserve to offset that? Because I know it's gonna happen. Um, it's some it's definitely things that you want to think about as they start actually understanding what the what's actually going on with Stripe. Cool. Uh, so some key accounting considerations. So So when we talk about, uh, and work with folks in Stripe, we work with a lot of different organizations, and there's a couple of areas that six zero six, uh, and Stripe interact with very greatly. Uh, one of them is the fee treatment. So under $6.00 6, like, you're allowed to basically amortize fees alongside revenue as a cost of commission. In Stripe's world, depending on if you consider that a commission, it'll go through cost of revenue and match your revenue, or it could also just be considered an operating expense as payment process fee, in which case it goes into OPEX and, uh, falls under $3.40. We've seen folks fifty fifty, uh, opt for how they wanna do the accounting for it. Obviously, conceptually, if you want if you can argue for $3.40, it's a a margin improvement. Um, but we've seen folks kinda do it either way. And I I mean, given that the the business cares a lot about the 3% fees from a margin standpoint, it's not as big of a deal. But in any case, that's something to think about is, like, do I wanna consider them as commission expense, which then falls under cost of revenue and affects my margins, or are they operating expenses like a bank fee, in which case they go below the line? This actually ends up being a really big deal for, um, buy now, pay later kind of customers because that means the payment processor is very much involved in their, um, like, business operations, in which case, there's no short argument for cost cost of revenue versus if you are if it's one of your many payment processors and they could technically go around it and pay via ACH or whatnot, then it makes a much stronger argument that it should actually be OPEX. Uh, the second accounting consideration is bad debt expense. Uh, so a lot of folks will default to marking only paid invoices as revenue, which is conservative, but it is technically wrong when it comes to doing six zero six in the sense that every single one of those invoices is going through the five step process to determine if there is, um, revenue. And while collectability is a component of it, it's not the only component of it. And so if you're only doing it based on paid, there's many, many times where there should be revenue recognized because there's performance being given and there's a true contract where revenue should be recognized even if not paid yet. In which case, we see a lot of folks just under recording revenue because of lack of granularity and uh, unsupported conservatism and application of six zero six. Um, in which case, like, most of the time, folks should actually record all that revenue. And then if they do have the bad debt expense, they should be holding a seesaw reserve from the $3.26. A third very important key consideration, and it's very much related to this concept of payment, is the idea of proration of a subscription if it's canceled early and also variable consideration. So in the sense that if collectability is not assured, then there should be a backing off of, uh, variable consideration. In which case, if you're refunding, then you can basically reverse that that revenue. Um, and then proration for the same thing, which is if a customer of your contract in your terms of service and Stripe they that they're paying for is I have a right to return versus not, then this may be an argument for a cancellation would then reverse out future revenue versus if there's not a right to return, then technically, you've met all of your performance criteria, in which case then you would actually recognize all that revenue immediately, and then it would go into that debt. Uh, and so there's different considerations around Stripe around how you would handle those different scenarios for really high volume customers whether they're paying or not, uh, and whether there's actually a source of like, there's actually a legitimate contract under six zero six with the regards to payment. Um, we kinda talked about it before, but the contra revenue deferred presentation, it's a decision that folks need to make in terms of how they wanted to present on the balance sheet. Uh, and this relates to the connected accounts in Stripe. Uh, we do have folks that are running a, uh, a net accounting where they're the, uh, agent versus principal, in which case that shows up in Stripe if you're using connected accounts and the nature of what service you're providing. Um, And then the last one we kinda talked about already, which is, uh, just six zero six and whether fraudulent revenue should be recorded at all or should be backed off. So these are all things kinda like we see in in the space where everyone should be at least speaking to them in their ASC six zero six model at some form of fashion and our decisions that they all depend on making when we work for them. And there are questions that the auditors are always gonna be asking too. So I guess it's a pulling question too. Where do you see the most risk with your Stripe integration? Cool. So cash basis accounting, uh, unable to glean operational insights. The scale of your volume is breaking your current systems, uh, and then just manual errors from doing this manually. Let's take a look here. Yeah. So it's interesting to see the results. Looks like cash basis accounting is probably the most common, which makes total sense. Like, usually, the accounting team comes in way after Stripe gets, uh, implemented. That's actually why Stripe ends up being probably the most common, uh, payment processor because, like, when you think about a company starting, it's like the founder and then the engineer. And the engineer is like, I have to take payments. How do I gonna do that? I'm just gonna go use Stripe because it's six lines of code. And then, you know, that happens from $0 to $1,015,000,000. Oh, crap. I need to go get funding. Let me hire my first accounting person. And now they're stuck with Stripe and whatever they decided to do upstream. And then the next one is scale breaks current systems since Stripe is, like, the leading self serve motion. We see that very often. Miro is a really good example, um, um, where they, uh, they basically tried to do their own, where they try to push all of that data into NetSuite. So directly from Stripe, push it in NetSuite. NetSuite charged them an arm and a leg to store all that data. Every single transaction and all the concurrency, they said push as much as they can, and they still got to the point where they couldn't open up NetSuite just because NetSuite is not designed, and and your ERP is not designed to carry that much volume. And, like, Miro is not even the biggest customer we deal with. Like, they get much bigger than that. So that scale breaks down pretty quickly. Cool. Alright. I've kinda covered this, but just to make sure you guys are aware. So you do this accounting. If you wanna make sure that your bookings are complete so that way I booked all of my gross sales, then, again, you'll go to the invoices report, and you'll download it, and you'll do some manual finagling. It'll be what supports your journal entry, but then this would be the actual support that you would take a screen print out and and support for, like, SOC purposes. Uh, the cash in transit and cash payout reports. So you can basically tie out cash to what hit your bank to what came from Stripe. That will be the payout reconciliation reports. And So you should be able to tie out the ending balance being your cash in transit, uh, and then your net payout should be what actually hits your bank account for that that coming period. Uh, and then the balance transaction report, uh, you can either get it right here, which will be what the fee and the p and l and the differential, like I said, will be what's produces cash in transit early. Um, you can also just get it from the balance summary report, which is and probably the most confusing part is this is the activity report regardless of what happened to cash versus this is the the filters for here are when did I get when did the payment, uh, occur for this activity. So very small nuance, but knowing that we're seeing the two makes your life a lot easier because you're always gonna sync three days if you did the wrong one. Cool. So now the I guess, what happens if you get into a unfortunate situation where doing it manually doesn't work anymore, which it happens sooner than you think, um, but you can go longer than you think because most of us can use Excel, uh, better than most folks. Um, if you do get into a world where it's too large for Excel to handle, then you are forced to do an automation for it. Um, and that's where, like, I work with customers all the time in the sense that, hey. We can't do this manual anymore. This is great that I need some sort of option to automate it. So why does doing it manually suck? Well, it's risky. I think we just saw our last, um, poll question, which is we know we're doing it on cash basis, so we're hoping we we can get the auditors sign off on it. Uh, the manual errors, like, you know, that happens from those Excel files. That's not compliant. Um, and then what's even more important is by doing it manually, it actually very much demotes and devalues the accounting organization. Um, the example like this is John. He was the revenue accounting manager, Alfie, uh, and he was basically spending his entire month just taking Stripe rev rec reports, correcting them for their business, and then reporting on them. But by doing that, you end up having to drop it in Excel and just even get it right. You don't have any of that granularity. And so what happens is the FP and A team, they go get their own revenue number. They go, okay. Cool. I'll pull it and pull all the invoices and go report that to management. And then now the rest of the month, the accounting team is trying to argue the relevance to that number. Why is our number less or more than the FP and A number that they're trying to plan off of? And it just it just ends up being a complete fabulous exercise and gets seen as a compliance exercise as opposed to, know, the most important data in the business to generate decisions is not, I guess, not useful. And that's because, effectively, like, you have to go to all these different places to go get it. So if you're lucky and everything's in Stripe, then you can just go pull these Stripe reports. But I imagine some of the folks here, you guys aren't just selling through Stripe. You'll sell through other systems, in which case you have to go all of those other systems in order to do the accounting, which makes it take even longer and even less accurate. Um, and so yeah. But this is a really common one. It's because all the, like, decentralization, like, NetSuite's great, but NetSuite was made twenty years ago. Now people are selling through whole different ways than NetSuite's ever evolved to do. And so they're now stuck between these upstream systems, Stripe being the most common one and their ERP. So this is where, like, we, as a company at Hubify, we specialize in, which is we do a full end to end automation specifically for Stripe. Um, and when I say we're the number one rev rec account integration for Stripe, we are the number one rev rec account integration for Stripe. Um, you'll see on the next one, like, we work with Stripe's highest volume customers, um, and their newest and, like, highest profile customers. So folks like Cursor, um, Perplexity, Eleven Labs. Um, but we also work with pretty much every AI company that they have, so like Motion, Warp, um, then all the app stores that sell through their webs their web. They also we work with them. Um, public companies like Eero, it's a subsidiary of Amazon. And this is even a full list of all of our Stripe customers. It's by far our most, uh, common integration, and we we do several billion transactions of Stripe accounting every single month. Cool. So what integrations do you use to support your PLG revenue? Um, and I know it's probably not a term that maybe everyone uses, but, like, think of it as, like, self serve, uh, b to c, d to c, your consumer sales. Like, you sell them through the website, and so you're selling them through Stripe. Eventually, here, like, are is everyone here lucky to have just Stripe? In which case, cool. I only have to go to three different reports to get this account in. Am I selling through Stripe, like, app stores? In which case, cool. I'm having to go through Apple and Google, but they're basically gonna do Stripe next because we wanna I wanna count those fees. Um, do I do it through a website where I sell it through our website and then collect payment in Stripe? Um, or do I use something other than that? It's charge me for Curly, etcetera, and I'm looking at trying to use Stripe, and so that's why you guys are here. Cool. I I I should have known that pretty much everyone here uses only Stripe, which is why you would come to a Stripe, uh, accounting, uh, CPE. That doesn't surprise me, though, because that actually matches pretty much the volume that we see, um, across our customers. Like, almost two thirds of them use Stripe, and then maybe about a third of them use something other than Stripe, whether it's upstream or the app stores or whatnot. Cool. Uh, so I'm gonna just do a quick tour of, like, how we've solved this problem. Um, Stripe does have a rev rec module, and we'll talk through, uh, I guess, reasons why that Stripe rev rec doesn't give out gap compliant, uh, accounting, um, which is a reason why most of our customers come to us after using Stripe Ryb req because while it's great for, like, a kinda rough estimate, um, if you're going into a world where you have to pass audit, uh, highly compliant where you're gonna go public or whatnot, Stripe Direct just doesn't it just doesn't work. Um, it also has surprisingly a volume issue where they can't handle the volume that most of their, like, really high profile customers and even their lower profile customers have, um, in which case that's why we end up working with folks. So this is what a fully automated Stripe order to cash, uh, cycle would look like. And so what you can see here is basically we would we hit those APIs for Stripe, all 32 endpoints. Uh, that is basically all of this data plus the ones that are connected accounts, application fees, transfers, metering, credit grants, etcetera. Uh, we also handle this nine different APIs that they have at this point. Uh, what you see here is basically every single day, it's a full order to cash close for Stripe. Uh, in fact, what it does is, like, creates Stripe to be, like, little its own little ERP module, if you will, uh, because you'll be able to get all the reporting that's in Stripe attached to all of the terminal entries that tie to your channel. So, uh, in this example, you can see, like, this all the word to cash accounting, but it can then be broken out by any of the upstream data. And so you can see, like, this is by state. So in this case, you can see we can drill into, let's say, deferred revenue by customer. And then what I'll show you is we have a single customer that has a subscription. So this customer would have two subscriptions within Stripe. That would be the equivalent of, you know, one of these users. And then within that, you have the subscription. And then within that, we have the the performance allegations that actually drive the order to cash accounting in the in the rev rec. So I'll just pick one to kinda show the the detail of what it looks like to do the full order to cash accounting for Stripe, uh, correctly and GAAP compliant. So this would be an individual subscription that generated an invoice for 300 or $275. So this would be the equivalent of a $275, uh, invoice. And so you can see here that we do we have basically, keeping track of all of the operating accounts that Stripe touches as well as the p and l accounts. Uh, and so what you can see is that when that initial invoice is generated, there is the general, uh, the revenue entry that will be the $275 going to unbilled AR. Uh, and what'll happen is in Hubify, we actually maintain, like, what is that source system record that generates that entry. So in Stripe's world, they don't have this concept of a contract. So we actually make one, which is the invoice line generated by the subscription item for that product. Um, and then immediately, it gets billed because there is an invoice generated at the same time, and then you can see the unbilled to build entry happening with the reference being the actual invoicing, uh, in the upstream system. And so then you can see that flow through the bill they are. And then when it gets paid, you can see the payment intent that pays that invoice, uh, as well as all the, like, metadata attached to it if you need to see it, but this is the actual, like, accounting behind it. Uh, And then what'll happen is you have the cash in transit, in which case your customer pays you if it's a customer charge. Now I'll go to cash in transit, and then it'll actually be dispersed, which is going to be the activity that we're seeing on this page. So the cash in transit and then what actually got paid. There's also the fee accounting, in which case that this one had a dollar 50 fee. So you can see that you didn't actually get paid $2.75. You got paid two dot 207 $273.50 for a dollar 50 fee. Um, and then on the other side of that unbilled entry is the deferred revenue entry. And so you can see that on the initial booking date, we now booked two $275 worth of deferred revenue. And then since we do it on a daily basis, this was generated mid month, then you'd have, you know, fifteen days of the recognition happening that will then be recognized into revenue. And so you can see that recognition happening into revenue, and you can see it happening over time. And so that's an individual contract, uh, that you can see. But if you open up everything, this is gonna be all of your revenue across all of your, uh, contracts. So this would be all of your subscription revenue. And then what happens is is now you have all of this accounting stored at effectively a giant pivot table layer, uh, which is what our UI is. Um, but this is what then the FP and A team, uh, can do can use. So what happens is, like, once this accounting is done, then each month, you can push the journal entry to your GL, um, in which case, you can build out whatever segmentation is required. I don't know why someone would do, like, a state, but I'm sure those department codes that you're maintaining are classes in QBO, um, in which case then you can have that as your draw on your upload template. Um, we also support pushing it to the RP. So for example, like, Euro, since they're a public subsidiary of Amazon, um, they're required to basically have an automated, uh, push, and so we support pushing it to NetSuite every month for them, um, at least their part function, and then they post it via their review. Um, but they also we have customers too that also just post a QBO, and they're able to actually just not worry about their, uh, changing their GL. So, like, people will take QuickBooks, you know, from 50,000,000 to 500,000,000 because it's, like, all the revenue is sitting in my sub ledger, and I can just post summary entries into my my GL, which is an interesting use case. Uh, but what that means is is that whatever you post to your GL is also gonna be what the accounting team or the, uh, FP and A team is using. So in this example, go to my Stripe demo. You can see that, effectively, the print up. This will be all of the the revenue, uh, number for the time period, and then you can see it's the same, uh, general revenue. Put it all up. And so it ends up being the same data, and the FPA team can use it. And since it's happening every single day, they don't have to wait for the accounting team, and so they get to basically use the same data, um, which is really cool when you see that. Because what we're seeing with our customers is, like, it's very much a if the accounting team can't do it on a daily basis, the green the FPA team leads in, they'll do it themselves. Um, and so Cursor is my favorite example of this where Will is their revenue, um, accounting manager. And so he basically took the Helpify data, showed FP and A that they had been doing it wrong because I've been calculating their own number wrong for the last, like, two years. And then what they did is they basically take this data and they push it to a warehouse, and they actually run Cursor, their internal AI, over it to do their FP and A. Um, and so it's, like, a really cool use case where, like, the accounting team basically said, no. This is our data to govern. FP and A team, you have everything you need from us. Just use this data, and the FP and A team just runs Cursor on it to do their analysis and analytics and their flux analysis, stuff like that. So really cool use case when, like, you can do this daily and the granularity you need to be able to, like, drive business decisions. Um, back to the healthy example, John, basically, when he he implemented Hubify, he now is head of FP and A because they don't need a revenue manager because he just takes the data that gets calculated every single day and does actual FP and A analysis for the business, um, which is a cool use case. Uh, the other thing too that's useful about having all this data done and, uh, correctly is that you can build out all of the basic reporting that you need. So, like, deferred revenue, you just take your booking entries and your progression entries, and you can now look at your for revenue by cohort. But more specifically, then you can drill into it and say, okay. Like, well, where is my cohort by customer or by invoice or by subscription or by whatever cut you want, uh, which is a really cool and useful exercise for forecasting. So now you can forecast out, k. Well, what's my revenue look like that I already have? And then you can build on your something players. Same thing with, like, ARR reporting. And so, like, if you're not doing the rev rec right, you're not doing ARR reporting right. So a lot of times, folks will have to the kinda team can then now say, hey. You guys are doing ARR correctly. So, yes, that's kinda how folks are automating this end to end. Um, at the end of the day, that's the outcome for the accounting that you need in order to get it right. Uh, we just do it every single day. And so we live and breathe it, uh, which is why folks will come to us around their Stripe lows very often and help you if you can. If we can, then we'll send you the right place. Cool. And that gets us to our last polling question. What is your current method for doing rev rec? Is it spreadsheets? So Excel file, uh, GSheets. Maybe now it's GSheets with Claude or GC philanthropic or chat QVC or whatever. Is it using Stripe Rev Rec? Since most of the folks here seem to be using Stripe, is it using their, like, native revenue recognition tool? Um, c, that's the next controller's problem. Uh, I'm not gonna worry about it. Uh, or d, maybe some other, like, uh, there's a lot of people trying to do rev rec, uh, in the space, but they don't really get they don't really do it right. Cool. That's interesting to spread, actually. I would have thought more people use Stripe Direct. But, again, most people don't wanna pay for it, which is part of it too because I think they charge they charge a flat fee plus, like, a volume fee, which I don't know, makes no sense to me because, like, accountants it was already hard enough to get budget for software. It's, like, not being able to tell people how much it's gonna cost makes that conversation harder than it needs to be, which is why they charge a lot of fees. Cool. Um, and then, yeah, one thing too, like, much much to my wife's chagrin who, funny enough, is actually on this call. Say, hey, Danny. Uh, because she's also a CPA, which makes for a very riveting dinner talk. Uh, I love talking about this stuff for better or for worse, so feel free to connect to me on LinkedIn. More than happy to ask questions, answer questions, um, and, like, talk through your Stripe environment if that's helpful. Uh, and then talk through, like, how we see other folks do it. Because at this point, we do I've seen dozens of different Stripe integrations and ways folks have interacted with their self-service and enterprise billing, etcetera. More than happy to share that with anyone here if that's helpful. Cool. And then the last bit from a CP evaluation standpoint, um, if there's any questions, you can reach out to me. Uh, but participants must complete evaluation form of this event. So if you want your CP, you gotta do that part. Um, you'll receive the evaluation form as soon as this we get off. Uh, and then the latest that can be sent is January 15. Oh, I guess it's an update. We need to think it's gonna be March 15. Um, and then the attendees will also receive evaluation form via email, uh, uh, and then a completed evaluation form is required to get your CP. So uh, other thing, participants are tracked using live polling questions. Uh, kind of the same thing we saw before, which is you'll get their CP whenever you actually fill the form, um, and then we'll give you guys the certificate no later than a week. So I'll stop there. I don't there might be questions in the alright. So we have about five minutes. So let's let's go through them. So, Franco, how would this work if we use manual payouts? Therefore, no payout rec report available. Yeah. It's a really, really good question. Um, so Stripe supports two different payout methods. They automatic payouts, uh, and then manual payouts. Unfortunately, when you do manual payouts, Stripe does not maintain the granular detail, uh, for those payouts. So, like, let's say you collected, I don't know, a thousand different transactions generated or payout. If you do manual payouts, Stripe can't tell you which of those transaction balance transactions were paid out for that. Um, in those in that world, our recommendation is to turn automatic payouts, uh, because, like, otherwise, you lose that granularity. Um, but if you don't, then the next the, like, the best accounting for it would be to take, uh, your, like, activity and take out your payments available on date into a a Stripe wallet account, if you will, or a Stripe cash clearing. And then whatever happens is you just have this ever building balance that Stripe allows for you to have, and then you would do a credit to it whenever the actual payment goes out. So that way, that maintains, like, a a cash available in Stripe, like, a wallet concept. Um, kind of annoying, a little bit manual. Uh, very much can be facilitated by just turning automatic payouts, but the, uh, I can understand why some folks don't wanna do it mainly because they wanna have control over, um, their, like, the cash balances and stuff like that. So really good question. We see that a lot in the sense that, like, a lot of times when we implement Hubify, they'll turn on the automatic payouts because they realize, like, how much more painful it is suited to the accounting if they don't. Alright. Uh, Alex, do you have a lot of customers using Stripe's direct model? Uh, well, so our customers don't use it anymore. Uh, but I would say probably 75% of them were using, uh, Stripe before they partnered with us. Um, Cursor is an example. Um, Perplexity is an example. Um, Motion is an example. Plus Dojo is an example. Dub Club is an example. Healthy is an example. Um, there's many, many more off. I can't think of top of my head, but this is why most of the, like, Stripe's largest especially because, like, if you've seen any of these AI companies, like, they their revenues are, like, within two years, you know, they're talking half half $1,000,000,000 in revenue, which is a ton of, uh, transaction volume in Stripe. Uh, Copyi is a really cool story about this too. It's, like, what Copyi doesn't have a ton of, like, revenue volume. They have a ton of free trials, like, point o 2% of their, like, um, customers were actually, like, paying customers. So there's, uh, so much volume flowing through Stripe Rev Rec that we basically did a bake off with Stripe Rev Rec where it's like Stripe doesn't wasn't able to pull all the data into the Rev Rec module to even do the accounting incorrectly when we were done with implementation within a week. So, like, I guess, yeah, all most of our customers try StripeRev rec, realize that either it can't handle their volume or it's spitting out really bad, um, like, non non gap accounting, especially, like, around the, like, variable consideration and proration stuff. Like, it just doesn't handle it right, and you can't really mess with it because it's it's internally baked. Good good question. Um, alright. That's Alex. I think we have time for maybe one more, and I'll I'll get back to you guys afterwards. Um, Alice. So we had trouble reconciling Stripe transaction when it's the payment processor for another sales platform. Any tips off of that? Yeah. This is actually the, um, so while Stripe is typically like, if you're using just the payments module, that means your upstream sales are happening somewhere else. That's actually very much the problem that we solve for, um, AllTrails. So they sell through Recurly, and that's managed in subscription invoicing, but Stripe is the payment gateway along with a bunch of other payment gateways. So what happens is Hubify will connect to those to drive the deferred revenue and the billing accounting and then do the matching to pick up Stripe to do it as the actual payment. And then also too, back and forth too, for if there's something that happened in Stripe and your policy is, um, variable consideration, well, that refund in Stripe then could have an effect on the upstream revenue, in which case we handle that accounting. Um, Yeah. Like, to do it manually, though, it's a huge pain because it means you need to go to Recurly or wherever that stream system is to get your bookings data. You have to figure out what that that matching looks like, do it with, like, an x lookup, and then keep your AR, uh, going and basically manage it that way. Other than doing some sort of automation with, like, a Hubify, I you basically are just doing a bunch of vlookups at that point between the two different systems and hopefully have the reporting you need. Cool. I think it gets us to the end of our, uh, our time. So thank you everyone for joining. Uh, I'll any of the questions I didn't answer, I'll I'll send a follow-up just to make sure I get your questions answered. Um, Yeah. Thanks for the time, and hopefully everyone has a good rest of their Wednesday

‍

‍