Christine Butchko:

Alrighty. I think we're live. Good afternoon to everyone on the East Coast, and good morning to everyone who's joining us from Pacific time frame. If you wanna pop in and tell everyone where you're calling in from, I think that would be a good way to get it started. Um, so let's go ahead and start. Uh-huh. Here you go, Cody. 

‍

Cody Leach, CPA:

Correct. 

‍

Christine Butchko:

Sorry about that. Do you mind sharing your screen? Perfect. Beautiful. Alrighty. So welcome to today's, uh, CPE webinar, revenue restatements, identification, execution, and prevention through automation with, uh, Cody Leach. 

‍

Cody Leach, CPA:

There we go. 

‍

Christine Butchko:

Yeah. Cody, why don't you introduce yourself instead of me, uh, reading through your many illustrious accolades? 

‍

Cody Leach, CPA:

Something like that. Uh, Yeah. So I'm Cody Leach. I'm a CPA. I'm the head of product experience here at Hubify. So that means running product to make sure that the app works, uh, and the past is like socks and PCOB audits. But also just been in the accounting space now for, I guess, last fifteen years. Um, started out with KPMG, so big four public audit. Hated it. Moved to outsource internal audit. Also hated it. Did, uh, outsource, like, automation and process consulting for finance groups. That was okay. Uh, then implemented, uh, SaaS software for a while, which was okay. And then now I've been in this accounting automation space for around last five or six years. Um, Yeah. Pretty much exclusively deal with ASC six zero six, uh, and all the nuances are on over to cash accounting pretty much every single day, much to my my wife's chagrin. 

‍

Christine Butchko:

Sweet. Alrighty. So we have some standard housekeeping and compliance information that we have to share with you. Um, so first things first, the official compliance statement. So Hubify is registered with the National Association of State Boards of Accountancy, NASBA, as a sponsor of continuing professional education on the national registry of CPE sponsors. State boards of accountancy have final authority on acceptance of individual courses for CPE credit. So complaints regarding registered sponsors may be submitted to the national registry of CPE sponsors through the website, ww.nasbaregistry.org, and there's our sponsor ID, um, in case you need it. Uh, this program is free, but if you have questions, comments, uh, or complaints, you can contact me, uh, just christine@hubify.com. And record retention, just so you know, uh, we're going to retain your records, including your polling responses, evaluations, attendance for a minimum of five years in compliance with NASPA standards. So sweet. And, uh, yeah. So this is group Internet based through live instruction, pulling q and a. Um, it is one credit, accountancy focused. It's intermediate. Best if you have three to five years of experience. Doesn't matter, though. And then no advanced preparation needed. 

‍

Cody Leach, CPA:

Sweet. 

‍

Christine Butchko:

And, yeah, four polling questions are gonna be deployed at random during this hour of programming. CPE hours, fifty minutes, just so you know. Um, in order to receive full credit for attending this course, you need to answer at least three of the poll questions. Um, poll questions are sporadic, so, you know, they're unpredictable to make sure that you're engaged throughout the entire session. Um, and if you don't answer at least three of them, then you won't receive credit for the program. But I think all of you already know the drill. So sweet. With that, I will kick it over to Cody. 

‍

Cody Leach, CPA:

Cool. Yeah. So just a quick agenda. To start, I got woke up with a cold this morning, so pardon me if I have to do a lot of coughing. Um, just we'll do some introductions, which we've already kinda started, uh, and go through the kind of the CPU requirements. Um, but we'll go through the leading cause of of revenue restatements and the traditional means of how folks do these restatements, um, and then specifically how to automate those restatements, in this case, uh, with Helpify. And then at the end, we'll have a a q and a. So you can ask questions, uh, as we go. And if I can answer them, I will. Otherwise, we'll answer them at the end so you can get, uh, a little bit of time again to go through them. Cool. So we can go ahead and get started then. Um, so revenue recognition still is one of the leading, uh, causes of of restatements. Um, I think anyone here who's been in the profession for a while I smile. My profession started with the move from, um, moved to ASC six zero six back in the beginning of, like, 1314. Um, and, basically, restatements skyrocketed after that point, specifically around revenue, uh, with 2020 being the peak. And while it's not a leading cause of of restatements at this point, um, it's still in the top three, and it's not trending out of that by any means. Um, really, it becomes to the fact that, like, the from its obligations that come from applying ASC six zero six and the allocation of the transaction price is just kind of a tricky, uh, tricky item that people I don't have time transitioning, but it looks like we finally got into the the end of that, but it still remains like a really risky area. Um, I like this one because I when I found the slide, uh, 2020, 2019, that's when I was doing outsourced internal audit, and almost all of our engagements were basically material weaknesses around revenue specifically related to the ASC six zero six transition. Um, and so, yeah, our partner, we we made fun of him because he was a we called him the ambulance chaser because he would just find anyone who had a material weakness or restatement in revenue, which would trigger the needs of remediated revenue internal control. Um, and so, like, you can tell, like, some of the traditional businesses this was a real problem. Like, uh, we're they're we're doing it for a rental company, a large rental company. And, like, when trying to explain to the sales reps that, like, hey. You have to get a signature from all these people to, like, commensurate a contract. They're like, no. We're not doing that. Like, most of our people, like, wanna give us their name, let alone, like, actually sign a sheet for. And so just kinda like, the company, they're just trying to work through these nuances for 06/2006, and finally kinda christened in 2020. Um, so we're up to our first polling question. So where do you see the most risk of error and or restatement in your current reporting? Uh, so revenue, uh, expenses, deferred revenue, or unbilled accounts receivable. 

‍

Christine Butchko:

I'm gonna pop up as well and say so to answer the poll on the right of your screen should be a polling place. Click in there, and that should be the first poll. If you have any questions, add it in the chat. Um, it's a bit not intuitive, but, uh, yeah, that's where that's where you can answer the poll. 

‍

Cody Leach, CPA:

Sweet. I'm actually just seeing what the answers are to this one because, uh, uh, I don't imagine it's expenses, but deferred revenue and unbilled ARR are typically really painful areas. So we'll give everyone, like, maybe twenty or thirty more seconds to answer. But, yeah, so I'm not surprised that it's deferred revenue on bill AR and revenue, which, interestingly enough, are all, um, all driven by the actual contract, uh, and not by the invoicing. So make sure you hear what the expenses one is as well. But, yeah, so, like, when it comes to the restatements, essentially, to compare this to what we see when we're working with folks, which is, uh, the expenses are usually less risky, and so there's usually not a a restatement that would come from that. Um, but it's always revenue, deferred revenue, and then the unbilled AR. Uh, deferred revenue probably being the biggest. Cool. Alright. So for root causes, so when we talk about, like, what was the driver of all of these restatements and why it's such a common reason for restating is basically the complexity of the six zero six standards, inadequate systems and controls, misclassification and interpretation of errors, uh, control gaps and rev ops, and then just just underestimating the materiality and the legwork that went into, like, setting your policy, uh, on a backdrop of never doing it before. Um, when it comes to, like, the the complexity of the standards, like, trying to do identify performance obligations, contract modifications, and, like, variable consideration, all new concepts. So now at this point, we've kinda figured it out, but still applying them in certain scenarios is really tough, which is why it's still a a leading cause of restatements. The adequate systems and controls is interesting because and we'll talk about this more a little bit later. But a lot of the tools that most of the companies are and even folks here at PI are working with, they were built for an era before 06/2006. So it meant that, like, for accountants, they could hang out in their billing tool, right, that they owned and do all the revenue recognition until so 06/2006 came along, which meant now they're having to go into a tool like Salesforce or, um, uh, a contracting system or HubSpot that was not built for accountants. So they don't have concepts of periods, but that's where they have to go to get this contract data to do RevRec properly. And so you have this, like, weird mashing of, like, I'm having to deal with systems now that don't care about accounting, but I have to go into them to get the accounting rate. My old system doesn't have this concept of a contract because it's just a billing tool. And so now you're having to, like, figure out and stay in between these two to get it right, which made opens a lot of risk. Um, misclassification interpretations, so it's like applying your performance obligations. Like, it's just a new a new idea. And then control graphs in your rev ops, which is, again, that, like, mashing of two departments that typically didn't have to work together, starting to have to work together, um, and then underestimating the policy for work. We'll talk about it more in, like, the PLG space, but there's a lot of work to try and decipher your contracts to figure out if there's, like, revenue, uh, and variable consideration of the different bits and performance obligations. Um, and so, specifically, this has been compounded by, like, we call it PLG growth, uh, so product led growth. Um, and so, traditionally, when people think about SaaS, they think about b to b SaaS, which is I get a contract with the salesperson. I put it into my contract module, Salesforce, whatever. They sign it, and then the accounting team picks it up and does the accounting for it or and the billing for it. And so while that's already hard enough, right, because you haven't do 50 page contract reviews, um, there's, like, human error involved. Uh, now there's a lot more AI tools to do that contract review, um, which is really cool. Like, I just got off a call where somebody with AI built their own contract review tool internally in a night. Um, so some of that, that's getting a little bit easier. Um, but then now with the, like, the main growth lever for AI companies and the big, like, new tranche of companies is through product led growth, which is you put a credit card at the website, get, like, a free trial, and then they charge you. That has a whole different level of complexity and problems that come with it. Um, and so classic b to b SaaS, you know, has its own problems that have kind of been their systems involved and people have gotten used to it. But when you get to the PLG, now you have things like I'm dealing with 100,000 contracts with consumers who have fickle, um, ideas around disputes and refunds and chargebacks and stuff like that. But then it gets even more complex when you get to AI, which is, okay, now it's not just a subscription. Right? Now it's usage based contracts, token purchases, percentage completion, um, and upgrades and downgrades. So now you're adding this huge volume with this level of complexity, and it's caused like, basically, it's causing more more pain in the revenue side than even before. Um, and so, like, the same issues with systems and controls, like, the typical tools for, uh, PLG revenue is, like, Stripe is probably the most classic, but, like, the app stores, the other ones would be, like, Recurly, Chargebee, those guys. Um, none of these systems were ever, like, built with six zero six in mind. And so the reporting and the reports available mean that doing the accounting for them is very risky and and really manual. Um, and it creates a lot of pain, especially if you have to do millions of them. Uh, there's not as much in the PLG around, like, interpretation errors because your contracts are consistent, at least. It's like a single terms of service that somebody clicks through to go to your app. Um, but still the control gaps and run ops, like issues between the provisioning of services and the actual billing of it in Stripe, there's still, uh, pain and restatement issues that can happen there. And then it's still a whole lot of pain to basically write out a six zero six memo policy for your terms of service and applying the five steps and making sure that gets right. Um, and then more specifically, like, you have them, but how do I apply it at scale? It just is a recipe for a lot of restatement work. And so, yeah, actually, I like this list because the fastest companies that are growing right now are all these these AI companies. Um, you have to appreciate that, like, this is the next next tranche of comp of companies that basically have to do revenue statements. Uh, some of these guys, like, they only started less than three years ago, and they've just hired their first accounting person. But after a thousand percent growth year over year, somebody's coming in having to basically how do I get revenue right for my three years of, uh, accounting that no one's ever actually done the accounting right? And it's like, how do I go about doing that? And we deal with customers like this all the time, like Cursor, Perplexity are both customers ours with a couple of other folks on this list that we're basically talking to. And they all have the same problem, which is I'm the first accountant that got hired three years into this, like, hyper growth, uh, company. And, like, the revenue is not even close. Like, how do I go about restating, you know, uh, millions and millions of subscriptions? And it's only gonna become more problematic as, like, these companies hit scale. And if they try to go public or do any kind of funding rounds, they all basically have to restate this and do it, uh, at scale in a way that no one's ever really had to do it before. And so I would be surprised if you end up finding out some of these folks have to do restatements before they end up going, um, like, to their next next level. Uh, actually, before we do that, so, like, the other thing too around, uh, the complexity here is that not only so, like, when you have, like, app stores, the subscription accounting is is already complex enough. But for these guys, it's also, like, how do you restate around, like, usage, uh, tokens and whatnot? Because all these different companies are, um, like, they're doing a lot more, uh, like, playing around and and experimenting with different pricing models, which then does all sorts of crazy things to your revenue, uh, depending on the contract setup. And so these are the companies that are, like, at the funny the, uh, cutting edge of, like, what does six zero six look like at scale and high complexity, um, in trying to get that restatement work done. Like, the traditional ways of doing it just don't really work for them. Cool. And this actually is the the next polling question, um, which is, what is your company's revenue model? So I think I talked about it. We have, um, we call PLG, so product led growth. So this is where somebody goes to your website, puts a credit card in, and usually, it's like a Stripe or a curly, and you just take credit cards that way. Typically, the lower dollars, um, free trial for new models. SLG, which is you have exclusively a sales team, um, which is gonna be, like, I have a outside sales rep, and he goes and sells it, uh, and then gets a contract. I review it, and then I, you know, post the revenue and and the billing and stuff. Um, or what we see most often, which is traditionally, SLG, which is, hey. I started as a b two b enterprise business, but we're now going have a self serve arm that we've never dealt with before, uh, which is really common, or vice versa. Hey. We are a company who's exclusively sold through our website, but now we're basically having to go into sales like growth, which is a whole different beast. Um, and this is always an interesting one because a lot of times when we talk to folks, it's because they'll they'll have all of their infrastructure around one, but trying to go into the next one's really hard. And so a company that might traditionally have a a decent b two b process, it breaks down when they try to do it, uh, in Stripe. Um, a good example of this is a full cast and copy. So copy.ai is one of our customers who sold through Stripe, um, and we'll talk about them a bit more. But we basically restated five years of their financials, um, because they needed to get acquired. We didn't know at the time, but they got acquired. And they got bought by this company, FullCast, which only did sales like growth. And so the controller there is like, okay. I just bought this PLG arm. I have no idea how to do the accounting for it. Um, and so it puts the controllers and the finance teams in a weird spot when you're hanging out in this hybrid space, which is more and more companies are doing that as they try to grow. So can't say I'm surprised that people are more, uh, SLG or hybrid. Cool. Now the it's kind of the more technical aspect of this restatement work. So the ASC that governs, uh, restatements is ASC, uh, two fifty, um, which is specifically around accounting changes and error corrections. And there's kinda like it's, like, four levels, if you will, of restatement. Uh, one is just a change in estimate or principle, which obviously is where people wanna be because it's more prospective. Um, if it turns out that there is an error and it's not just a change in accounting policy, then you go into the this decision tree, which is actually codified in, um, in in ASC. And so you can have an outer period adjustment, which is probably the easiest that everyone likes, which is it's small enough to where I can just have it be in the wrong period, and it's not gonna cause any problems. Um, two phrases that you'll hear, which is called the little, uh, r restatement. So this is a revision restatement, um, and a big r restatement, which is a reissuance, which is the one that no one really wants to do. So, like, the big r, uh, to differentiate them, the big r restatements are like, if there's a material error in past, then you basically have to reissue the old financials, which is obviously a huge deal, um, versus a little, which is, hey. We have an issue this year, but it's not material for past years, um, which means you can just recast the current financials. Um, and it also has to do with, like, your requirements if you're public around issuing an eight k. So you wanna try to have an out of period adjustment if you can. Uh, could send material, but a little restatement's not the worst thing in the world. The big r restatements, that's the big deal that you hear in the news. And six zero six or, uh, two fifty has a really useful chart, um, which is if you identify an error in the financials, um, deciding what to do. And so if this is an error under GAAP, uh, it's not, then there's no restatement, obviously. Um, if you determine that it's actually a change in principle, uh, which a lot of our customers, like, you can argue that, especially if you're recasting your financials for the first time. But if it is determined that it is a true error, then you assess materiality, uh, which is governed by SAP 99. Um, and if it is determined material, then, um, is it material to the previous financial statements? In which case, if it's not, then that's great. You get to actually just post in the current financials. If it is material to the previous one, that's when there's a restatement required, and it kicks off a whole body of work that's not very fun. So one is you have to identify the impact of periods and the transaction population and then recompute the revenue under the correct accounting guidance. And then you have to determine your method for how you want to actually, uh, make this adjustment. Is it a month by month or a cumulative catch up? And then you would record the adjusting entries. Uh, typically, this is gonna be since we're talking about revenue restatements, revenue, deferred revenue, um, and potentially, um, and retained earnings if it's in the previous period or if it's in the off go forward period as an opening or as a a balance adjustment. And then you actually restate the financials and, uh, update the disclosures, uh, depending on where like, if you're public or not. Um, and then you remediate the root cause. So this is this spoke to me because as a a practitioner on internal controls, this is always where we made our money, which is somebody's gotta go fix the internal controls and remediate the the weakness. If there's a if there's a material error, then you already know you had a material weakness, and you have, uh, a working until two in the morning trying to get SOX controls together, uh, to get companies back in the graces of the SEC. So when we talk about restatements for PLG specifically, the part that we've talked we're gonna dig into more here is this recomputing revenue under the cracked accounting guidance. Uh, so nothing changes in the sense that you're always gonna still be using professional judgment in the guidelines here to actually do the, um, like, the restatement work. But then it's like, how do you go about actually doing the restatement? Um, so the steps all stay the same, but the hardest part for TLG is the recalculation and the recasting of revenue. Um, the reason why is because the traditional systems for these newer age companies are going to be it's it's actually a very small list. It's the likes of Stripe, uh, Apple, Google, Recurly, Chargebee, Adyen, PayPal, Braintree, a lot of the ones where they're more for the newer age SaaS consumer, uh, focused, uh, companies. And the problem with these is they were never designed for accounting in mind. And so doing the accounting for them is really miserable. Um, they lack the reports. Uh, like Stripe, for example, doesn't have the reporting you need to do the accounting correctly. Uh, Apple and Google are the exact same way. Google at least has decent ones, but Apple, like, doesn't even have the reports available manually to do the accounting right. Um, and so what it means is, like, okay. Let's say you go through an audit or you identify that there is a material, like, error and you need to restate. How do you even go about doing that given the data is not really available for you to do it right in the first place? So it creates a lot of risk, um, and it makes it really, really manual. Uh, it takes a long time. And so when you're trying to do the restatements for, like, this newer PLG AI company, it's a lot it's a it's a much different exercise than doing it for your traditional b two b, which is, okay. I need to reread my contracts, apply this new standard, recalculate the revenue, etcetera. For the PLG, it's a it literally is just gonna be, like, take the reports down, recast all the revenue for, you know, could be hundreds of thousands of subscriptions, and it just makes that restatement process even more painful and more risky. So I guess so kinda how the restatements are done today. So, traditionally, when you get a restatement, you pull in a third party, uh, to do that work, and it's usually one of the highest margin professional services activities these companies sell. Because usually, if you're doing a restatement, something really bad has happened. And so it means that you basically, like, uh, it means that your kinda back is against the wall. And these companies will will do it for you, but they'll do it for a very high price. When it comes to the b two b side of the house, that makes sense in the sense that, like, okay. You need manpower to go through and do these contractor views, recalculate them, and potentially do, um, the actual, like, accounting for them. But when you get to the PLG, there's, like, not even that much manpower that can can fix this because they don't have access to the reports in the same way that you don't have access to the reports and the necessary data. Um, but they'll still charge you for it. And so, typically, these restatements are extremely costly. So, like, 100,000 plus engagements. Um, Um, they're also time consuming because they are being done manually. So they're having to basically redo the calculations and then do the adjustments, and then it's very risky still. So even if you have the restatement work, the support behind it's gonna be very manual. It's gonna be Excel files and calculations, uh, to support the adjustments. And so while this works for b two b, it doesn't really work that well for PLG, and there's definitely lots more options, uh, today than there were in the past. And I say that as somebody who, like, my first part of my career was basically helping with these these processes. So some of the cause common errors when it comes to, like, this PLG, uh, and what forces the risk statement to work and what makes the risk statement work that that much more difficult. So Stripe is probably the largest, like, payment processor and billing tool used in, like, product led growth and among these AI companies. Uh, even now with, like, I think Stripe bought Metronome, so it's even more consolidated around Stripe. But when it comes to trying to do this restate network, uh, the customer balances, if you're trying to do it manually, like, you the Stripe has this concept where you basically can issue credits to a customer, but it sits on the customer, and there is no reporting natively within Stripe to get to this. So, like, when we work with folks, one of the most typical adjustments that end up happening is, oh, I have, you know, a million, $2,000,000 of liability that I never really knew about, which means that you're overstating understating liabilities and overstating or understating your, um, marketing expenses or your contra revenue depending on the way your contracts are written. And so if you're going to do that manually and have a firm come in and do it, they also don't have access to the data to do it right. And so we've actually worked with three or four folks where they had a restatement done or they had a third party firm do their accounting and they still missed it because you can't get to it manually. Uh, the other one too is the proration application. So Stripe has the nuances around their subscriptions and their invoicing model. And, again, they don't have actual reporting to support doing the recalculation, um, let alone doing it scale. And so, again, you hire a third party to do this adjustment, they're gonna have the exact same data limitations, uh, that anyone else is gonna have. Uh, the other one too is variable consideration application. So some of the nuances around Stripe is that when you issue an invoice, potentially, if there's, uh, a refund given, is that considered variable consideration? And so trying to do that and apply that to, you know, millions of transactions manually is a really tough, uh, thing to do, especially when Stripe does not have the, like, reporting around refunds to their subscriptions. So trying to even see if, hey, this leading contract ultimately got refunded. Trying to even get that comparison is almost impossible to do with Stripe's native reporting, let alone doing it, you know, for millions of contracts. And so what we find is when folks are dealing with Stripe and they have to do restatement work, usually, they use Stripe's revenue recognition, realize that it's inaccurate, and then go try to find someone to fix it, but they can't because a third party, like, professional services also can't access the data correctly. Uh, in which case then you're pretty much left to trying to have someone recalculate it for you, which is typically where we'll jump in. Uh, the same thing goes for the app stores. So for example, uh, Apple, they have two reports that are available to the finance team, but they lack the granularity to actually do the six zero six accounting correctly. And so, um, like, FX gain and loss is hard to calculate. Uh, unpaid, uh, subscriptions are hard to calculate. And so trying to get to, like, the correct ASC six zero six outcome before passing an audit is really, really tough. Same thing when it comes to trying to, like, do fee recognition and and and matching. So if you're a policy in terms of, like, how you, uh, amortize fees to match revenue, trying to, a, do that manually with the reporting is really hard, but trying to hire a third party to fix it is the same. They're gonna have the exact same limitations. Um, and so what it means is that, like, the detail needed to actually do the accounting right, while not available to you, is also not available to a third party. Um, and so they're just gonna basically take on your risk and charge you for it. And the other piece that's really uh, hard too is around data warehouses. Um, and so this is probably the leading cause I'd have to say is that a lot of times, companies will create a contracting or a provisioning tool, uh, upstream through the website, in which case, like, the actual provisioning, issuing of the contract, the beginning of the contract, the recognition of the contract, and the doing of the performance obligations, they just get really one per job when you're, uh, dealing with data engineers and engineering data upstream that's not built for accounting process. And so one of the really big problems you run into around the restatement is that these data warehouses, data is always changing. So if you go back to restate the data, it doesn't even exist to be able to do the restatement in the past. And so, uh, constantly changing dates will mean that it's there's out of period adjustments and the accounting gets done correctly, and that causes a lot of restatement work where it's we'll now have to restate it because our underlying data has changed. Um, we haven't been doing the contract modification like we're supposed to. And so I would say probably half our customers have to do some level of restatement, um, just because the way they're doing it manually just is not not feasible. Um, and so it's a really common problem. Now they're not all doing restatements for, like, being public and they answered issue a restatement disclosures and whatnot, but they do have to do restatements for things like trying to get acquisition acquired, uh, trying to pass an audit, or trying to just even report, uh, six zero six compliant revenue. And that gets us to our third polling question. So what integrations do you use to support your PLG revenue? So this one will be interesting to see if it matches what we see across our customers. Um, so I think I saw some folks who will actually use then they're I don't think I saw anyone that is exclusively product led growth, but there was a couple of people I think I saw that had, um, yeah, that had a hybrid approach. So yeah. Do you use Stripe? Do you sell to the app stores, like Google and Apple? Customer web and data warehouses, so you have something you built on your website, and then Recurly or Chargebee or some other. Cool. That that actually checks out almost perfectly with the way our customer base is set up. Uh, Stripe is by far the most popular just because it's so easy to plug plug and play. Like, you literally just put a URL in and you're off to the races in terms of collecting money, which is what the business wants. But then the second most common is the customer website data warehouse because Stripe doesn't facilitate what they want exactly and the nuances of more of how they wanna handle it, and so they go build their own internally. If I have any any suggestion, I would I'll stick with Stripe if you can just because the controls work that comes from having to maintain your own data warehouse is just it's very expensive. Cool. Uh, so now we get to what does automating a restatement for PLG companies look like. Um, if you're in a world where you're in the b two b, uh, this still can be kind of automated, but there's still gonna be the contract review piece that has to happen. Um, for the PLG, because the data for these transactions are typically in a structured format already, it makes actually recalculating and recasting them easy if you have the right software for it. Uh, and so in order to do the six zero six accounting properly, you have to connect to the contract system, the billing system, the payment system, and do the entire order of the cash cycle because some things that can happen in the cash piece can affect upstream revenue, variable consideration being, uh, the best example. Um, and so I'm gonna go through a couple of stories of examples of folks in terms of what they did to basically automate this restatement. So an example of Stripe, uh, is copy.ai. So Sarah was the controller there, and they were trying to get acquired. We didn't know it at the time, but they were like, hey. I need to basically get my my revenue in order because we're going through some financial transactions. Um, we just need to pass an audit. Uh, and so, originally, when she went to go do this, they need to recast five years of their financials, so, basically, from the beginning of time, uh, for that company. And, originally, they tried to do it manually, but they couldn't because they couldn't get the data needed for it. So then they tried Stripe's revenue recognition to basically have Stripe recalculate their revenue from for the last five years, uh, but they were not able to to do that. Um, and so they work with us. And within forty eight hours, we took the API data. We already know what the order of cash accounting looks like for all the different metadata, and we're able to re recalculate and restate their revenue in forty eight hours. Obviously, with, like, a different accounting policy choices that they wanted to add, like, refunds as a variable consideration or operation logic, um, those kind of things. But compare that to the quote that they would get for doing it traditionally, which was get a consulting firm to come in, grab all the same reports that they were gonna grab from Stripe, and then redo the calculation themselves. It was a way faster. B is a lot cheaper because it was just it was actually for free because it was just the implementation of of Hubify in that case. Um, and they were quite happy in this instance. After forty eight hours, they had a true revenue number that they could go take to the board. Uh, and that was the same number they end up using for the acquisition because it was right. Uh, another example too is, like, um, we have a couple of other customers that are doing the same thing where, like, you have you know, they've only been in business for two or three years. They just had their first finance hire, and they have to basically restate revenue because what they're doing before isn't isn't right. Um, probably the most common for Stripe is because Stripe doesn't have good invoice reporting, people will report revenue on paid invoices, uh, which is problematic because you basically miss invoices that weren't paid, uh, which is true revenue that ultimately turns to bad debt, uh, which means that people are understating their revenue, but also understating their bad debt expense. So that's one of the Stripe's a really common one because there just isn't really a good way to do it manually. Uh, other examples would be the app stores. So, uh, I it might people here might have seen it, but Strava's are the best example of this where, um, they basically were in a in preparing to go IPO, and so they needed to get their revenue in a state that they could basically, uh, go public. I think they just announced earlier this week that they're gonna go public. But what this meant was that they had to basically re restate, uh, and get gap compliant accounting. And so the question was, how do we do that in a timely manner since we're facing the bear down the barrel of a an IPO for, you know, five different systems, Google and Apple being the biggest ones. And so, uh, traditionally, the way they would do this is they have, like, just giant Excel sheets, so they're doing it manually. Um, and they knew there was errors there, but that's the only way they could figure out how to do it. And so they compared what is trying to calculate this and restate it using Hubify versus using a third party, uh, consulting firm. And it's literally gonna be, like, half $1,600,000 to basically restate, uh, their f y twenty five financials when it was part and parcel with the Abbify implementation. And so, yeah, they were able to basically just recalculate all of f y twenty five, make the adjustments that they needed to make. And, yeah, we're able to file their the papers to basically go go public, which is a pretty cool use case. Um, so it's interesting to see, like, the options for trying to get ready for something like that. Like, the timelines are shrinking, uh, which is really interesting to see. Um, the other one too is the the data warehouse situation. So my, uh, example of this one would be one of our customers, Packback. So they sell, yeah, they sell, like, um, classes either directly to students, um, or, like, uh, or they sell, like, placements, like books and stuff, or they sell, uh, classes that people can sign up for through schools, um, like access to, like, like, education materials, basically. Uh, but Pac Pack had the problem where this was all being maintained in a warehouse upstream where people would basically buy, uh, through their website or they'd have some process where they'd have a third party, um, managing, like, the actual sales. Uh, and then the billing would come through on Stripe. Uh, and so what their problem was is they were doing all their revenue off of, um, the the Stripe data because that's what was readily available. But Pack Hacker was in the process of getting, uh, acquired and gotten acquired by a a private equity firm, and they weren't able to do the reporting that they needed to just, like, pass due diligence. And so they get into this due diligence period, and they're being asked these questions around revenue, and they can't they can't answer them because they don't have six zero six compliant revenue for it. Uh, and so they partner with us to basically automate that by going to the upstream data warehouse, going into Stripe, and getting the actual, like, word to cash accounting and doing that within a month, um, which then let them actually, like, pass their due diligence, uh, and have the acquisition go through. And so, traditionally, if you had that situation, it the deal would probably have fallen through because there wouldn't be a third party that could basically turn around the restatement work, uh, that quickly, uh, just because the data is not available, um, on the upstream warehouse or just trying to get the data together to do it. It's just not it's not feasible to do it in a manual way. So it's, uh, the actual restatement calculation that is something that can be automated if you have the right systems upstream. So some of the benefits of, um, um, automating the restatements over traditional professional services. So it's a lot faster. So, typically, once we get set up with someone, it's it's less than a month. Um, and you also get the the benefit of like, implementing a revenue, uh, reconciliation or revenue recognition in the cash, like, accounting system. Um, it's far less costly. Uh, one of the things that I find really interesting is, uh, basically, these restatements are just part and parcel, uh, to implementation. And so while we don't charge for them, it's a reason that folks will work with us because they're in a spot where they have to actually get compliant. Um, and it's also highly honorable and much much lower risk. Um, so everything in Hubify is gonna be at the actual journal entry level, and so there are no summary adjustments that have to pass audits. There's no Excel spreadsheets that are supporting these adjustments to pass audit. Um, and so it actually reduces your risk, which it's very rare when you're dealing with financials where there's the, uh, beneficial trade off on both sides, which is lower cost and lower risk. Uh, typically, it's the other way, in which case, pay more, lower risk, or pay less than I I take on risk. And one of the things that I think is interesting too is that the, uh, it turns a compliance exercise into a value add exercise. So, historically, if you have to go through a restatement, it's just a cost of doing business. So I'm I'm gonna go public. I have to restate. Or, hey. I'm, um, I had a restatement, and I have to restate my my financial. It's a huge cost, uh, exercise just exclusively due to compliance. Um, in which case, when you are able to automate it and add all the reporting and all of the details that come with doing it correctly, it turns something that was traditionally a compliance exercise into something that is a that's an actual value add. So you go through this exercise not while you're compliant, but at the end, you have FP and A reporting. You have ASC six zero six reporting that the rest of the organization can use for FP and A. Um, An example is Strava. So, originally, when we partnered with Strava to do their restatement work to get them ready for, uh, going public, uh, the it was just for the accounting, uh, point of view. Um, but then once, like, internally, it got wind that, hey. This is, like we're actually gonna go public now. Like, I remember the controller was like, yeah. We you can't walk around our office without hearing about Hubify because I went super excited about it. And I was like, well, that's interesting. Um, but it's because the FP and A team realized that all of their disclosure, uh, reporting can come out of Shopify because now they have all this detail. And so the very next thing is we push this data to a BI tool, and now the rest of the organization can do all of this data and have all this analysis to basically run the business and do all the disclosure requirements all because of a compliance exercise that was done properly and quickly. And so, um, yeah, the the the way that people are doing three statements is a is changing. You no longer just kinda go to a the big four, a name brand. Hey. Um, take six months and and restate it. Uh, now it can be something that can be done in a month and actually add value at the same time, which is a cool cool thing to see. Alright. And for polling question four, uh, what color do you see debits? That's what I'm interested to see. And so I always ask my, uh, amateur to see how this works because I I've always asked my my wife disagrees with me, uh, on exactly what this is, but I'm always interested to see how folks, uh, see this. So my answer is I actually see debits in red. So only red and black. So there's not a single person that sees it in green. I think people that do, um, accounting outside that, like, learn accounting outside of the official means, they see green because it's it's usually money. Cool. Yeah. So I think it seems like red wins, but black's the second one. Cool. Um, Yeah. I guess one thing, uh, to note too is you're trying to do restatement work. I'm more than happy to chat with anyone, um, as we kinda go through it. There is a, uh, yeah, when people go through restatements, it's usually pretty stressful, but trying to work with them and do them timely. So we end up helping folks with that, uh, a lot of times. Um, the other thing I was gonna say too is that, uh, yeah, like, whenever you're going through a restatement, um, trying to hire for, like, the the, like, some folks will do, like, a bake off, which can be really helpful in terms of, like, working through the the best path forward. So, um, yeah, I guess with that said, wanted to see if there's any kind of questions that we can go through. I'll go through the evaluation times. Yeah. So when we uh, if there's any kind of questions, we can go through the evaluation instructions. Um, I guess, Christine, if you want to, we can go through the the last bits and then go into the q and a to make sure we 

‍

Christine Butchko:

have Yeah. That sounds good. Alrighty. So, uh, you need to sorry. So first things first, you need to complete an evaluation of this event in order to get your CPE credit. I'm gonna pop a CTA up right here on the screen, um, covering my face, uh, where you can fill it out. Um, so do that at your earliest convenience. We will send out a link after this webinar, um, which will have a link to the evaluation form. If you can fill it out before next Wednesday, that would be great. And then once you have filled it out, uh, we will send over your CPE, and we'll do that within a week. 

‍

Cody Leach, CPA:

Cool. 

‍

Christine Butchko:

Cool. Is that everything? If not, we can hop into the q and a. 

‍

Cody Leach, CPA:

Cool. Let's see. 

‍

Christine Butchko:

Alrighty. Sweet. Let me see if I can bring this up. First question for you is, why do you think there's been such a significant increase in the number of revenue restatements that we're seeing? 

‍

Cody Leach, CPA:

Yeah. Uh, that's an interesting one. So, like, I think the first wave, and we kinda talked about it, which is, historically, for revenue recognition, it was the invoice and collectibility were the two main criteria. And I actually remember this from the beginning of my career where when we're doing these revenue restatements, like, I don't remember having to learn the criteria for recognizing revenue with, like, the four rules around give an invoice, the collectability bit. And I remember during the transition, and this was actually on that rental company, where, like, halfway through, it was like, okay. They needed to use a whole different standard for determining revenue recognition. Um, and so what it meant is that, like, you had a lot of historical accounts that I had to learn. Um, and the idea of, like, splitting out this concept of the invoice from the contract is a very natural notion. Although, it's the right one. Um, it just gets people really confused. But more importantly, like, all the systems that were set up were set up around the idea of the invoice as the true source. Um, and so what happens is the the accounting team owns the invoicing, and so they traditionally own the mechanism for recognizing revenue, which meant that they had access to all the data. The tools were built for it, and then they knew how to actually do the the recognition over it versus now they have to go up the upstream systems into, like, the contract systems, and those are not built for accountants. Uh, and the sales teams really did not care about maintaining data quality to make that happen. And then more importantly, the connection between the two, uh, like, it's really hard to maintain that. Um, I think one of the examples like, one of the questions before was basically, like, what's the most risky area? Uh, unbilled AR is on there because it's, like, really, really painful because it's where the accounting team and the contracting team meet on the on the balance sheet. And any problems between the two, which is contract signed but not billed, show up there. And so the unbilled AR rec is, like, typically one of the most painful parts of a company that has, like, a b to b SaaS arrangement or a subscription arrangement. Um, and it's just because it's it's gonna be all the revenue leakage that sits between the two systems. Um, and even now, like, ten years into the six zero six regime, but you still see Salesforce Zuora, Salesforce Maxio, and the handoff between those two systems is still really bad. Um, and so until that until somebody is able to build out the contracting and the billing and the payment and the same thing and actually get the accounting right and the model right, you're still gonna see, like, revenue recognition, um, causing problems and control gaps just because it's there's a manual handoff there. And anytime there's a manual handoff, there's gonna be risk to to restatement into revenue. 

‍

Christine Butchko:

Awesome. Um, just gonna call this out. I made a mistake. Um, only human. And the CPU CPE form was actually to connect with Cody, which is obviously I mean, feel free to do that, but I've updated the link, so you should it should go to the form now. Um, next question for you. Uh, Cody, can you give an example of big r versus little r again, uh, for restatements? 

‍

Cody Leach, CPA:

Yeah. So, uh, the way that, like, the big r is gonna be a situation where, like, something was, like, materially wrong in the past. So for example, it could be an accounting policy misapplication. It could be, you know, a multiyear contract that is material to someone's revenue. It turns out that they misapplied the funds obligation. The contract wasn't didn't meet the five steps or criteria upon further, like, analysis. Um, if that's the case, then a big r would be, hey, investors or whoever it is that's using these financials. We had last year wrong. You can no longer rely on those because they were materially misstated, and we're going to basically reissue those financials with updated amounts. And that's, like, the worst thing possible because people have made decisions on those previous, uh, on the previous data, um, which is why it has the highest threshold in February for disclosure requirements for, uh, meeting the criteria for, like, a big restatement. The little r is the same thing, but let's say this contract had a very small amount of revenue in the previous year, and the misapplication of the performance obligations meant that, hey. This year, we did it wrong, but doing it wrong in the past did not have a material effect on it. Which case, you would restate the current year of financials, but you wouldn't have to restate the previous year. You would restate the current year with the disclosure around, hey. The previous years had this error, but it was a material for, like, making investor decisions. Um, and so that's kinda the the big difference between the two. Like, neither of them are good. Um, and typically, they don't if you're a public company, they don't result in in, like, a positive stock price jump. Um, but all things considered, you wanna do a little r restatement if you have to do a restatement. Um, what's interesting is that, like, the difference between a out of period adjustment and a little restatement, like, that's a huge jump in effort. Like, that period adjustment is, like, no one ever knows about it, basically. You just make the adjustments and material on the current period, and no one needs to know a little bit wiser, which is where everyone wants to be. But that's the constant analysis accountants are doing when something goes wrong where it's like, was this big enough to cause an issue in the past or is this small enough to where I can just kinda let it ride? Um, and that's, like, in all the different angles too. It's like, is it a cough? Is it material from a cough standpoint? Is it material from, like, just a overall revenue standpoint? Is it material for the quarter? These are all, like, the judgments that accounting teams are having to put into place to, like, determine, like, what the right methodology for disclosing it is. And the auditors will look at it too. 

‍

Christine Butchko:

Awesome. Um, what are the biggest controls gaps causing your statements? Another question for you. 

‍

Cody Leach, CPA:

Yeah. This one's uh, this one hearkens back to my my days being outsourced into a lot of it. I always make the joke that it's the least, um, it's like the lowest form of accounting. But I take that's how I got here is because, um, you learn a lot of system stuff because that's where the controls typically lie. Uh, but, yeah, the biggest control gaps are usually going to fall around, um, like, contractor view and making sure that those are being applied. So, like, the typical way for, like, b to b, and I I'd bifurcate into b to b and PLG because they're they're entirely different revenue streams and run out processes. And so then the controls are a lot the control gaps are different. But for, like, your b to b, you're gonna be, basically, having a contract intake. Right? Whether it's through a Salesforce process, which then has you know, do you have the right controls around Salesforce to get all the signatures and documentation you need to basically actually make this contract pass the the first step of the five step criteria? And then doing a contract review to make sure that you're getting, like, eyeballs on something and that all the different pieces match match, um, and then getting that into your actual, like, system to do the revenue calculations and the the bill billing calculations. Typically, that's the place where there's the most amount of risk, which is why if you look at companies that, um, are, like, just large, right, b to b, like, this this is a whole department dedicated to getting the data from Salesforce and putting into Azure or whatever revenue tool they have and making sure that unbilled AR is happening. Um, and so the biggest risks are typically, like, misapplying and missing pieces to from some obligations and not carving out, um, contract values in the way that you're supposed to, uh, on the B2B side. On the PLG side, uh, the biggest control gaps are usually, like honestly, it's the it's the bookings and and cash controls to make sure that, like, whatever you're doing is complete. So, for example, yeah, like, if you're doing, uh, revenue off of Stripe, if you're doing it off of paid invoices, then you're already missing revenue, which means that you have a control issue because you're not not actually doing your bookings right. Um, and so, yeah, a lot of times the control gaps are, am I actually getting everything out of the the upstream system and getting actual, like, commercial substance of the transactions right? Uh, the customer balance transactions, the other ones for Stripe where it's like, you have all of these customer credits you've issued. There's liability owed, but you don't actually, um, you don't actually pay for it. Or you don't you don't actually, um, uh, like, but, like, you don't actually record it, in which case you now have understated your liabilities. So those are the ones that we typically see. I think the other one too is, like, uh, for PLG, if you have an upstream system that's not one of these standard systems like Stripe, or Curly app, or Google, that warehouse is a huge pain in the butt to try and pass audit. So you have to have change management controls. Um, it's gonna have to go through an IT advisory audit where they're gonna map out all the systems and whatnot. Um, and so that's probably the biggest area of risk we see is people trying to put all this stuff in a data warehouse. And if they don't use a third party tool like Albify to do their work cash accounting, then all of those accounting rules and policies details come into the scope and can't be covered by a SOC one, SOC two. Um, and so, yeah, that's usually where the pain is is anytime it's a there's an internal build aspect to it. 

‍

Christine Butchko:

Awesome. And one last question for good measure is how far sorry. How far back do we need to go when doing a restatement? 

‍

Cody Leach, CPA:

This is an interesting one. Um, I guess it ends up being the, uh, well, there's the there's the ASC two fifty requirement in terms of, like, the length of time for this, uh, restayment policies and disclosures and whatnot. And conceptually, you have to go back to the opening balance for that and restate the periods that, like, like, have the missed reality. Um, but to actually do it right, and this is one of the benefits that we see of doing it, like, in an automated fashion, is you really actually need to restate all of history as crazy as that sounds. So, So, like, one of the things that we do at Hubify is, like, when we restated copies, um, like, history, we didn't just go back three or four years. But we went back to the entire history because in that scenario, you could have a customer credit that was issued in the first year that's still around today. And if you don't do the, like, restatement for the entire period and take into account all the activity, then you're gonna get it wrong. Um, and so, like, the actual length of presentation is driven by, um, like, your investors and the guidance and the c two fifty. Uh, but the actual, like, doing of it, you really need to take up into account all of the data or else you're gonna get it wrong. Um, which is, again, another reason why doing it manually is, like, not only is it lower quality and higher risk, it's more expensive. Just you're probably gonna get it wrong at the end of the day because they would have gone and taken every single report from Stripe to get that right. Uh, same thing if you have an upstream system. It's like, if you're not taking all the history, then you're not gonna get the balances right potentially. 

‍

Christine Butchko:

Awesome. Those are all the questions that we have for today. So, um, yeah, take us home, Cody. 

‍

Cody Leach, CPA:

Sweet. Well, well, thank you everyone for the time. Um, I know that we're in the middle of year end close, so thank you guys for taking the time to to learn about restatements and automating. And, yep, good luck with the rest of, uh, the year in close. 

‍

Christine Butchko:

Sweet. Yeah. And as mentioned, we'll send out an email in about two hours with access to the form, again, if you missed it during the session, and we'll send out the CPU credits within a week. So have a good year, um, and hope to see you at the next one. 

‍

Cody Leach, CPA:

Cool. Thanks, guys.

‍