Understanding App Store Payments and Accounting

Hello, everyone. Welcome to the understanding App Store payments and accounting chat. All kind of dilly dally. A little bit. I see quite a few people already here, but I do like to give folks a few minutes to trickle in. Wanted to introduce Ariel. He is the CEO and co-founder with your brother. Right of epic? Yes that is correct, Ariel. So I’ve known Ariel since 2009. You know, I started my company in 2008 and was beating my head against the reporting from Apple and found out figures very early. So I was probably among your first, you know, hundreds of customers. Thousands of customers. I think I maybe even have been on your boat or something. Anyways, why don’t you ask yourself and tell us a little bit about figures. Oh, I would love to. So first, Thank you for having me. This I’ve known David for so long, and I wanted to do something like this for so long, so it’s good to actually do it. And for those of you who do know me. Hi, Ariel. From that figures. And that’s how I go on YouTube. But for those of you who don’t. My name is Ariel. I co-founded figures way back in the day when the apps are just started, just kind of at the end of 2008, actually launch in 2009 with the idea of word developers. We need to understand how our business is doing. And that was back when data was not easily accessible, and there was only a little bit to begin with. So I hacked together that thing over the weekend and I liked it so much and I showed it to other people. Like, how can we have access to this? Like we need this? So I said, sure, let’s build a platform out of it. Build a platform. And the goal from day one between me and my brother, we like to solve problems and we like to connect the dots. We believe information is how you make better and more informed decisions, information and informed. And so over the years, that’s kind of been our goals. How do we give you all the dots. So you can connect them and help you connect them? It started with easy analytics and now we have very complicated analytics. We make it easy. We track pretty much everything that you can see announced or connected in Google Play and then overlay a ton of data on top of it. So we bring in data that isn’t an app Store Connect like your reviews so you can respond to them and do everything that needs to happen on that side. We have a whole new suite of App Store optimization tools. That’s been a huge, huge way for developers to get more visibility on the App Store and on Google Play without having to pay for ads. And recently, we also introduced a suite of app intelligence tools that give you the ability to understand what’s going on in the market. I think understanding your competition is such an important tool in the arsenal of growing and making more money and getting more downloads on the App Store. And there was really no solution for this. It was just like way crazily expensive or requires just abusing all of your privacy. And we do you know, they’re pretty inexpensive on honest privacy. And that’s me in a nutshell. I also do a lot of YouTube videos and a lot of content that explains how to use all these things and how to turn them into more downloads and money. Well, that was a great introduction. Thank you. And most of you all revenue. You probably came here from an email sent by us, so I well, I won’t do quite as long an intro, but revenue is the subscription platform built for mobile apps. So we and a lot of people probably are a little confused like Africa’s revenue character and your compete like you both have dashboards you both like analyze the data. We don’t actually I mean, I guess there’s some small overlap in our product, but so with revenue cap, we actually provide the SDK inside the app to manage transactions. And then by being part of that chain one, we make it so much easier. Like in my personal accounts I used to have and don’t hate me, but I used to work in app receipt validation, which is just a terrible idea and was so buggy, which is how I ended up at revenue card. I ended up there as a customer first and then eventually joined. But by being part of the transaction we do, you know, server side receipt validation. It seems like, Oh well that’s super easy. You know, what else does revenue card do? Well, you know, we have a ton of great integrations, so you can send data to attribution providers to analytics like mixpanel and segment and amplitude and others. And then some of the other stuff that’s super cool is that because we’re handling the server side, we get near real time data on people turning off auto renew on subscriptions going into grace period, which we’ll talk about here in a SEC. And so we’re able to push those to CRM tools like iterable and braze and some other tools like that. And so we have charts where you can understand your data. And again, because we have transaction level data, our charts look a little different than Ariel’s charts because we’re actually dealing with the transaction level data. We also are great for customer support teams because we can actually show an individual users entire history. So customer support teams love us because they can actually dig into and find what’s been going on with renewals and cancellations and things like that at an individual user basis. And so much more. And most again, most of you already revenue cat so I won’t go on and on but did just that a tiny think to that. A tiny think that there only 70 or 80 different events at this point that Apple is producing for subscriptions. So just doing this in any way that isn’t through a platform just makes no sense to me. Nelson and then managing it cross-platform. So we support the app store, play store, Amazon store stripe on the web. And we’ve actually got a few more web payment providers that will be integrating soon. So kind of become that one single source of truth for your subscription data. So enough pitching you guys want to hear about App Store accounting. So in preparing for this actually learned a ton. So Ariel and I both have done deep dives into App Store accounting for 14 years now, ever since the very beginning of the App Store. And we’re both still learning new things. So if you feel lost, we’re both experts in this and learning new things this week. So we’re going to try to summarize it all and we’ll probably have to do another one next year because things will change. But let’s dive into transactions on the App Store. So on the surface you would think, oh, it’s simple. Like a customer pays and then eventually Apple pays you. What’s so hard about that? Well, here are all the steps along the way and all the different ways that can go wrong. And then all the ways that that’s going to screw up your accounting. So the first thing is after a customer pays a transaction, doesn’t actually go in immediately, like if you’re at a gas station, your credit card is going to get charged immediately. Apple actually puts transactions into a pending state and tries to bundle them. And this is back from the App Store is built on top of iTunes infrastructure. And iTunes didn’t want to pay $0.30 per transaction to the credit card processors. And so what they smartly did was like, well, if you’re buying one song, maybe you’re going to buy a couple of more. And so they waited to actually charge the card until they could accumulate multiple transactions. So still to this day, what, you know, 20 years after the iTunes store originally launched with that as the reason for doing it, Apple still will delay transactions and try and bundle them. So first step is it is even if it trends, even if the customer pays, the credit card might not actually get charged immediately. Then you can branch off from there into Apple actually settling the transaction, which is hopefully and you know, probably 80% of the time what happens is that it does actually get settled within, you know, 24, 48 hours. And an interesting thing there that pending period can cross over fiscal months. It can cross over calendar months. So, you know, a payment in one fiscal month actually gets settled in the next fiscal month. So it’s all kind of straddling that then it’s a mess accounting wise. And then of course, the transaction can fail if somebody doesn’t have enough on their App Store prepaid account, if they have a debit card, if their credit cards maxed out, if a bad number expired car, I mean, there’s a ton of reasons why the transaction can actually fail. Apple has gotten really good about retrying those transactions. And then there is specifically a grace period that you can enable in app Store Connect where Apple will continue to retry. And I thought that was only 14 days, but we’ll talk later that this it can actually go, I think 40 plus days from when the customer pays to when the transaction actually get settled. Because Apple just keeps trying and then waiting and then trying and then waiting. So you kind of get in this loop now eventually, you know, if it is something like an expired credit card, where they can’t get the updated information or something, you will have canceled transactions. So now you have a payment that’s, you know, customer paid, you’ve granted them access. And then at some indeterminate point in the future, the transaction actually doesn’t go through. And so that transaction is canceled. The revenue that showed up on your daily report, the revenue that we track, that revenue card goes away. And then for the transaction. So to make it through this journey which which again, it’s a surprising number that do end up in this grace period loop. But for the ones that are settled, Apple sets aside taxes and Google does very similar things. We’re going to talk about that a little more detail. Ariel’s kind of the expert on Google. I’ve been way more focused on an Apple side of things, so I’ll talk about Apple more and then refunds get deducted. So, you know, if you do have a transaction that failed, that gets pulled out, if somebody refunds, that gets pulled out, if there’s a. Chargeback that gets pulled out. You know, there’s all sorts of, as you would expect, running any business. You know, some of that money gets pulled out of what’s accruing in Apple’s bank account. And then currency conversion doesn’t happen until the day of payment. And so there’s this whole long, perilous journey. It is sitting in Apple’s bank account in whatever currency. It was paid in. So if you made a sale in the UK, it’s in British pounds. It’s in an Apple bank account in Ireland, I believe in British pounds. And then eventually, if you meet the payment threshold and there are still payment thresholds, I thought those had gone away. But you can change. They yeah, they changed. Now it’s aggregate. That is where you look at the app at some not each individual region. Right and so the so in the u.s., it’s something like $0.03 now. Right it looks like they’ll pay you pretty much almost anything. And then but then there’s a lot of other countries where it has to be over $150 for them to make a payment. So most of us here talking will probably meet the payment threshold. One question I have for you, Ariel. Is it a per country or is it. It is the total aggregate where let’s say you made $5 in Mexico, but you made $10,000 in the US, you don’t hit the payment threshold for Mexico. Right they’ll just pay you the $105 total. Yeah, I’m pretty sure because the way they had it, if you’re in like way back in the day, they had almost like three or four regions around the world where they were doing all this collection with the or rest of World getting everything else. And now they have so many, almost every big area gets its own region. So I think they couldn’t do that anymore. And they had to make it into an aggregate because otherwise you would never make money. Right the way they split it up makes sense to me. Yeah, back when? Back when I started. Back in 2008, it was really it was even more confusing because you would make money and you’d see the reports. And then, like in smaller countries, it would just get held for indeterminate amount of time until you passed that cap. So that’s much more simplified. And to get more detailed, check out Apple’s website on that. But again, it’s really much less of an issue these days where most people are going to hit the payment threshold and get the full payment every month. So then once it’s gone through this whole journey, you get paid. And we’re going to talk through the payment calendar. But from when a customer pays to when you get paid by, Apple can be up to 63 days actually now it can be up to 68 days because you like the precision here. You can have a 35 day fiscal month and then Apple always pays except for like four exceptions in 14 years, 33 days after the end of the fiscal month. So you could have a, you know, January 1st transaction. The fiscal month is 35 days long and you actually don’t get paid. Let’s just go ahead and get to that slide. So this is Apple’s fiscal month and this is today. This is part of the confusion. I for years kind of beat my head against this wall and finally, a couple of years ago created a color coded chart to understand this. And so so this is a perfect example. January 2022 fiscal month started December 26th, and that’s actually Q2. That’s the beginning of Q2 for Apple. Now you can run your own fiscal year and own accounting, you know, whatever makes sense for you. But your payments from Apple are going to be aligned to this fiscal calendar. So so December 26, the day after Christmas, people are, you know, have their App Store cards out and are buying your app. You don’t get paid if you follow the blue Tim March 3. So the fiscal month of January is 35 days. It ends the 29th of January and 33 days later, you get paid on Thursday, March 3rd, which is actually yesterday. So I actually just saw that hit my bank account yesterday. So if we get back to that transaction again, the customer paid on the 26th, but you’re not actually getting paid and it’s sitting in British pounds that entire time. So I’ve seen a ton of this where, you know, the daily sales are way different than the payment and some of that has to do with the currency. So, you know, within revenue care, within daily reports, within others, we’re doing a best estimate on what the currency conversion rate is currently. But as we all know, currency fluctuates. And so that 65 to 68 day span can change a lot. And so it’s really important to know as you’re, you know, figuring these things out, that those currency conversions can make a big swing in what you actually get paid. And Ariel, tell us about Google’s payment calendar, which is actually nicely, much more simple. Well, it’s a calendar number one. Apple’s calendar is basically a bunch of weeks, if you think about it this way. It’s a bunch of weeks kind of clumped together in a way that made sense to Apple’s investor relations, which is really how all this happened. This is Apple’s own fiscal calendar of how they report their earnings, and that’s why they have it in a way like the five week, four week, four week. They just made it work with everyone else, but they decided it’s a actually and they basically pay you. A quick, quick anecdote, actually, I heard from somebody who said. Apple’s fiscal year starts in the holiday quarter because Steve Jobs wanted to start the year on a high and the holiday quarter was always good for Apple in consumer land. And so even the it’s like little random esoteric things. I have reasons that date back to the 80s of why Apple’s fiscal year starts in September instead of, you know, like most other fiscal years. You go ahead. So this is. Well, like everything. Apple’s so weird and so complicated and has all these different nuances, but if you think about it for long enough, it kind of makes sense. Maybe it’s not the kind of sense that we want as developers, but it kind of makes sense, which is always kind of a consistent thread across everything that I see from Apple. Maybe it’s not obviously obviously making sense, but if you think about it enough and that’s the same sort of mindset I apply when I do a solo teardowns and keyword teardowns, all these algorithms, all these decisions that Apple makes, they make sense somehow just if they figure out how. On the Google side, things are a lot simpler because they don’t align this with really anything else that doesn’t make sense to normal mere mortals. So they just pay you. It’s not always exactly on the date, but you can say that about pretty much everything. Google when it comes to getting reports out, when it comes to getting paid, it’s always within the vicinity of a few days, but overall, so much simpler. And I think also on the subscription side, it’s so much simpler, more basic as far as the data they provide. And the tools they offer for subscriptions, as I’m sure you know, even more than I do. But it is more simplistic overall. So payments are not different. Yeah and does Google work similarly as far as accruing the revenue in the native currency or do they actually convert on the day into whatever the payment currency is going to be? I’m pretty sure they convert on the date. So transactions happen because we can get transactional data from Google unlike what we get from Apple and we keep track of all of that. We have all that information at the time that we recognize the transaction. And that’s almost immediately. So unlike apple, if there is a refund or a chargeback, like I said, one of the questions in the questions list, those will happen as a separate transaction later and we’d have to account for it as we do this. The other thing about Apple and Google, that’s a little bit different. Apple provides data to us and there’s a question also in the questions about how to see all this data. And you can see a bunch of it with through revenue CAD because the transactions come in. But on our end, we track all that data directly from Apple. And so the taxes, the conversion rates, the currencies and there’s a whole slide that explains how we do it because it comes out at different times. There’s another slide about that, too, but on the Google side, it’s really all together. So gross revenue, net revenue. They only really give us one number one set of data and that’s a transaction. And we derive all of it out of it, all of it, all the data out of it. Whereas on the Apple side, we get data broken down, but some of it is also a little bit more hidden. So that’s also another difference between Apple and Google and how much accounting we need to do when we work with both of them, when we get reports from both of them. Yeah awesome. And before we get into the detailed reports, I did want to bring up taxes and compliance because this is a question we get a lot. Now, I’m not a lawyer or an accountant, so you need to talk to a lawyer and an accountant. But you know, from my business that I’ve run on the App Store for 14 years now. You know, Apple does collect all the 80 sales tax by state in the US, they handle compliance globally. So, you know, if I’m selling in Sri Lanka or Mexico or, you know, anywhere in the world, they’re making sure that they’re the stores in compliance. There’s actually been a lot of stuff recently, like India passed a law where you can’t have recurring subscriptions over a certain amount. And so, you know, one, I don’t have to think about it as a revenue care customer because revenue court has figured out that our and is part of our SDK now. But then too, I don’t have to think about it as an App Store with apps or payments because Apple’s going to make sure that they’re compliant with all those kind of things. So the caveat here is that if you do start selling on the web with Stripe or Braintree or adding Adyen or any of those others, that’s where the tax and compliance burden does fall on you. And if you do collect web payments, I would definitely suggest getting a lawyer and an accountant. And, you know, there are some SaaS tools through stripe. And you know, all of these platforms do have some help. But one of the things I’ve personally really enjoyed running an indie shop where, you know, I’ve never even had an employee is that I don’t have to worry about taxes, compliance, and it’s all just handled. Apple collects it. They remit it. You know, as I showed on that first slide, Apple actually pays the taxes out. And so my accounting and compliance side of things has been super simple, which, you know, just to wax a soldier for a SEC really blew my mind in 28. In 2008, you know, I wasn’t in tech, I wasn’t in software, and I started my app business. And when I started getting these transactions in from all these countries around the world where I wasn’t even thinking about, you know, taxes and compliance and language and all these other things. And my apps were just selling it, like, totally blew my mind. How much Apple did handle of all of that? Ariel, look like you wanted to chime in. Oh, no. I was just going to say that’s a really good point, because there’s all these things that as a developer or as a business owner, you need to be considering. Taxes is just one of them. And Apple really makes all of that mostly opaque, I think, to developers, which is good and bad. But at the end of the day, it’s mostly good for everyone. Yeah and then you tell them it’s worth trying. Yeah, exactly the same. But Yeah. So there’s a few caveats with Google, with Vanity and some other stuff. So what were you telling me about that? So let’s talk about taxes quickly. And the US taxes are fairly simple. Outside of the u.s., you have VAT value added tax, and that’s not a concept we’re used to. So I think for europeans, for people outside of the u.s., it just it’s kind of common sense. Whereas here it isn’t, but it is get added on top of pricing in general. So not only does the appstore take care of making all those payments and holding withholding all that money, they also kind of eat it into the price. So everything makes sense. And you at the end of the day as a user, you’re downloading and 99 cent app, or whatever it is in the local currency on the Google site, it’s not at all like that. So taxes are being added on top of it. And while Apple does do the reporting properly, so in your gross revenue, it will show you data. Your revenue with taxes and in your net revenue will be without taxes, which kind of makes sense, right? Google doesn’t. They never really talk about taxes. And Google also has all these really strange rules. Or if you ask them very politely to not collect taxes for you. And you give them a good enough reason, they’ll stop collecting taxes for you. And because they don’t report it correctly, it’s really hard to tell what’s going on just by looking at those transactions that I was mentioning before. So Apple definitely takes all that headache out, but they also make it opaque enough that for large enough companies who have, you know, all those accountants and financial folks who want access to that data, it’s always a little bit more difficult to get access to it. So a good and a bad depends on where you’re sitting. Nice let’s talk about the payment reports that we do get and we’ll start with Apple and then you can dive a little bit into Google. We didn’t create slides for Google because I’m so Apple focused and I’m the one who prepared the slides. But yeah, tell us about the daily and the financial and the payment reports and why only one is the real source of truth. So in the Apple. In Apple. And when it comes to reporting and you want to take Apple’s reporting when it comes to money because you want to be as accurate as possible. You don’t really get one report that gives you everything you need on a daily basis. You get a daily list of all the transactions aggregated, and then you have that for a certain amount of time. So that’s actually for a whole year of daily reports that you can go back. So you only have some limitation, you only have some limited data ultimately, and then you have some weekly reports and monthly and yearly reports. But that’s really all you get on a daily basis. So if you want to run your business, you can’t wait. You have to do on a daily basis. That’s what you get. It’s mostly almost always good. And we’ll look at some numbers in a little bit. They’ll give you an idea of what I mean by that. But those are daily reports. We check those, we show those, we include those in emails that we send out. And those are really useful because without them, you’d be completely, completely blind to how your app is performing from a business perspective. But then financial reports come out and financial reports are what we were mentioning before. Every region where money is collected at the end of Apple’s month. They close the books on that month and they give you a list of how much money you made in that particular region. And they do it by region. There’s a summary report as well, but ultimately all of that data is available by region, not always at the same time, which is very odd, but for the most part it’s at the same time. But that doesn’t really have the. The currency, the exchange rate for that currency that you’re getting paid out, like David was saying before. So on a daily basis, you have the actual transactions on a monthly basis, you have, the more accurate financial transactions. So any sort of chargebacks or transactions that didn’t clear or transactions that got cancelled, all of those kind move into the financial report. And then later on you get a payout report which has how much money Apple actually gave you in the actual currency. So if it’s coming from Europe, it will turn and you’re in the US. It will turn into dollars from all these different countries. But that comes a long time after the month actually even ended. So all those on their own are kind of useful for different purposes. But what if you want to know exactly how much money a specific app made? And I only ask that because the payments report doesn’t always have the data the way you want it to be. And because data is split up by regions and it’s not really all together and different reports don’t really have all that info. You run into this weird case where you can’t actually. So you have estimates from daily reports. You have data by country or by region, I should say, from financial reports. And then you have a lump sum total that is very accurate but is one. And so we actually create a report that uses all of them together to make sense out of them. And what it does is two things. One, it breaks down the revenue, the actual absolute actual revenue, what you got paid by app and in-app purchase. If you have those over 4 subscriptions, you will have those. But it also shows you the differences between what the daily reports say, what the financial reports say, and also what the actual amount that you got in your pocket at the end of the month. And that’s what you see on the screen. And that’s a report that Dave has been using for a long time. Yeah so actually that’s how you make sense of all of it. Before Ariel made this super easy, I was paying my out partners and doing rev share based on the daily reports, in-app figures. And I was talking to Craig hockenberry, long time in the developer part of Icahn factory. He’s like, you know, those are accurate as well. He’s like, there’s a payment report. And so there was this company at this. And then I think Craig took over part of it after app is abandon it and created a school. He helped them stay keep afloat. Yeah so they had this tool called bean counter where I would actually go manually download the payment reports, import them into bean counter is a Mac app and then it would process the payment similar to what Ariel now does without figures. And what I found out was I was overpaying my partners because the daily reports don’t have the refunds, the chargebacks and the other deductions that would come out of it. And the currency conversions were different. And, you know, they had all of the caveats that we’ve discussed with the daily reports. And so I had been overpaying my rev shares by thousands of dollars, maybe tens of thousands over a couple of years until I figured that out. And so and so I pulled this report up specifically to show how different It can actually be. I tried to find a month where the variance was high. And, you know, this is only $15,000 that was paid out by Apple. You know, if you’re talking hundreds of thousands or millionths of a month, this spread can be tens of thousands of dollars, not just, you know, $1,000 here, but if you look estimated, is that 12,500 ish? And that is the cumulative amount from the Daily reports. The actual is, again, what Ariel is saying from the financial report. It’s 13,000 125. That’s supposed to be more accurate. But then what actually Apple actually paid was the $13,000 to 43. So, you know, if I had a paid based on estimated this time, I’d actually would have shortchanged my partners because I actually got paid almost $1,000 more. And so, again, you know, this is probably due to transactions that came from the last fiscal month that actually got settled in this month. And so they weren’t actually transactions in the daily report, but they got paid in this fiscal month. It can be any combination of all these things that we’ve discussed, that currency conversion. You know, there may have been a lot of sales in Japan and the yen went up compared to the dollar. Like, there’s so many different explanations for why this could be, but this is why the payment report is the only source of truth that you can have for App Store data. And part of the reason we wanted to do this chat with Ariel is that, you know, we get asked a lot of revenue, like, well, can’t we use revenue cat data for our accrual accounting? Really? no, no, no, no, no, no. We track the transactions and revenue and provide great dashboard business tools like you want to know when somebody turns off on a renew, you want to see that trial conversion that happens seven days later. Like you need actionable business data in real time. And that’s what we provide by managing the transactions and having our back end and building. You know, we have some incredible charts. I forgot to put a slide in here with our charts, but but we have pretty sophisticated charts that track your, you know, your change in IMR. We have all sorts of great tools at revenue to help you make business decisions on a day in, day out basis. But the actual hard financial data that you need to do accounting again. Can the pay me report? Ariel actually didn’t say specifically, but it generally comes out either the day of or the day after payment. And so, again, usually, Yeah. So you have a transaction that happened the first day of a fiscal month of a 35 day fiscal month. Then you have 33 days after and then the payment report comes out. So you have 68 days from when that transaction happened to when you have actual accounting level data. And so you can’t run your business 68 days in the past. And so that’s why, you know, revenue cat, we’re dealing with the live transaction data and trying to give you as accurate and the ends up being within, you know, two 3% of the final accounting data. But we just we can’t give you live accurate accounting data because it, it doesn’t exist. It doesn’t exist until Apple actually does the currency conversion on that 33, 33rd day after the end of the fiscal month. So, yeah, it’s. A little crazy and a little, little hard to wrap your head around. But that’s just it is what it is. And I’ve been using for payments this report in app figures for probably a decade now. The minute Ariel added it, I figures I was using it and have used that as my source of truth for accounting. We’re going to get something little to add to that. Yeah, we so Apple does give you data on subscriptions. And so it’s again very different than what you would see with revenue capped because revenue cap has the ability to look at events in a way that makes a lot more sense. But even on the aggregate side, that data exists and that’s what we look at. So that’s how we compile those estimates off of subscriptions. But again, that goes back to they’re not exactly on that like down to the penny. So really no one has data down to the penny. And that’s because, like you were saying, it doesn’t exist. But one of the things that I think is probably even going to catch more people by surprise at the end of this month when eventually, when it gets into the payments report is what’s happening in Russia now. And that’s going to be a huge change in conversion rate for the ruble, and that’s going to be a problem. So something to keep in mind. Yeah, let’s I did want to leave plenty of time for questions and we will answer the questions that are in the chat. I wanted to get through the slides quickly and then we’ll get to that. So the financial report that we were just talking about, if you are trying to do, you know, to the penny accounting, especially accrual accounting, or if you need to understand exchange rates and book the difference in revenue and those sorts of things. And there’s something I just learned this week. Apple issues a financial report in process a temporary and that happens in the neighborhood of 30 days after the end of the fiscal month. But then they actually update that report after the payment is made. And that final, final, final financial report will, instead of saying estimated proceeds, it will actually say it will actually give the payment amount and the payment total and the payment bank. And when you see that payment total and payment bank on that report, you know, it’s finalized. And if you look at this list of reporting fields, you do actually get data on tax, on adjustments, on withholding, and you get the exchange rate. So this is the report where you can actually go in and country by country figure out. So all the transactions that you do get data on and we’ll get to that in the next report. But you can actually back into an accurate exchange rate once you get the final, final, final financial report that has these rates in it. Anything else you want to add url? Well, the actual conversion rate is also in the payments report or in the payment report from Apple. So when you do eventually get the real, real, real amount that they used for that particular region to convert that amount of money, and they show you the before and after and the after it will match what is in your bank account 100% So you do have that eventually. The question is just one. Yeah And then this is the payment report and this is the report that the app figures uses to generate that screen that we just saw before. And this has actually been enhanced a lot in what like there’s just like four or five years. Apple is actually taking a lot of steps in the right direction of giving more data so that we can do more precise accounting. So if you look at this, you have a transaction date, a settlement date, sku, Apple identifier, you have all this information. And this is the payment report again that gets sent once you actually get paid. And this is the report that’s actually like Penny for penny, exactly what’s listed. And they give you every single transaction that happened in that month, including the refunds and other stuff that would make adjustments. And so if you’re trying to do transaction level accounting to the penny, this is a report that you need to look at and we’ll go to the next one. This is something that blew my mind. just found this out like a few weeks ago when I was digging into this. If you take that, if you download that report, drop it into Excel or whatever, and you create a row a column for time to settle, and you do the time calculation from transaction date to settlement date. It can take 38 days for a transaction to settle. That’s, you know, going back to that very first slide that we’re looking at. It seems so simple. Customer pays the charge, the credit card developer gets paid. So 38 days can span multiple fiscal months and fiscal months with Apple or either 35 or 28 days. So this could have happened in the January fiscal month span, the February fiscal month, and actually settled in the March fiscal month. And so I didn’t go through and list the entire spreadsheet. But, you know, you have quite a few that have these long transaction time to settle. But then, you know, the bulk of them are settled within 24 to 48 hours. So, you know, these are the exception. But when you’re trying to do to the point of accounting and then especially and we’ll talk about in a sec, accrual accounting, you know, these are the things that really screw with the numbers is how long it can take. One interesting thing to and just anecdote, this number 21 here is a paid app, which is why the skew isn’t a typical like in-app purchase skew. This is one of my paid apps group text. And I would have never thought that a paid up for an app could take 10 days to settle. But sure enough. So this is an app that somebody hit the pay button, went through the process, you know, double click the Home button to the side button to confirm the transaction they downloaded. They used the app. And 10 days later is when the money actually left their bank account and hit Apple’s bank account on a paid app. And again, the ones above you can see are annual subscriptions and and annual scripts options with retrials and whatnot. And so this just blew my mind downloading this detailed financial report and doing some math on it. One thing that I think not enough people know is that when it comes to credit card transactions, it’s not a direct. Money is coming out of one bank into another at all, especially as it gets to the International level. So money comes out of one bank and goes to another bank that then usually goes to another bank. And it depends on who issued your credit card and the company that is charging your money. So apple, in that case, the gateway that they use and how they’re connected to all the banks. And normally it’s not them that are going to clear this transaction. So it has all these hoops to jump through. And when you’re thinking international, just multiply that by a bunch. And so you really the money is jumping from one to another to the point where it takes 10 days is like not absurd. It doesn’t have to mean that it was something like crazy, like a credit card declined or something like that. But that’s probably what it means. But still, it’s like it’s so long. But Apple makes this so invisible, which is so cool. And I run a subscription business that doesn’t use Apple’s platform for making money. And I don’t use stripe or any of those because when we started, those didn’t exist almost 13 years ago. So for us, we built everything from scratch. So we know all these things and we had to deal with all these things and we have to do the work. We are the ones to retrying all these transactions and it’s such a huge headache. So having that kind of happen under the hood is so nice. Yeah, that and it’s nice that Apple has gotten better and better at reporting it as well as like we’re getting more and more detailed reports that you can do better accounting. I forgot to ask you earlier. Tell us about because I actually this is going to be news to me about how Apple handles dates. Like what is a day? So that’s probably one of the most asked questions when people start using us or when people, even people who have used us for a long time sometimes don’t even know this. But Apple has its own concept of a day. A day is not a 24 hour period globally, and it kind of makes sense. But the idea is that how they charge with different regions being the places where they collect the money, those places get to take their own 24 hour period. That becomes their day. The problem is so for example, in Europe, a day is a day that makes sense in Europe. Hour wise or in the US it’s a day that makes sense in the US hour wise. Same for Asia. Same for other countries. So how do you report multiple different kind of time zones into a single time zone that is not utc? What Apple does is it takes all those different 24 hour periods and squishes them into one date that does not have a timestamp. So you end up with for example, today is Friday. The day in Europe is almost ending. The day in Azure AD ended and the day if you move out West will be ending. So when Apple reports on today, on the fourth, they will squash all of those. So you’re not going to get an actual one line that cuts across all the countries. That is the deadline for a transaction and that usually confuses people a lot. And Apple doesn’t really explain it in app Store Connect. They now allow you to look at data through UTC and that makes things even worse. But ultimately it is that 24 hour period that gets squashed into one. I think it actually makes sense because a day in the u.s., if you’re thinking about your revenue and/or you’re making more money in the day or at night, day and night are very different across different time zones. So that’s a way of doing it. Right that’s fascinating. And so they’ve always done it this way, right? From yeah, it’s just it’s probably based on how they chose to do their own internal accounting when they started the iTunes store in 2023 or whatever it was. Well, I mean, that also makes a ton of sense because microtransactions are really a great way to save money on transactions. Otherwise, like if you’re running stripe, simple stripe, basic stripe out of the gate, you’re probably paying 3 and something plus a 20 or $0.30 transaction fee on every transaction. So if they had to charge $0.99 with a $0.30 transaction fee, the world’s not going to be where it is today and lump them together. And that was a great idea. Today that gets done automatically by a whole bunch of aggregators, but back in the day that wasn’t a thing. So I totally see why this would make sense and save everyone money. Yeah Kali. I see. I didn’t even know that Apple was aggregating days in that way, which now actually makes a few things. Make it worse. I should have known that. You know, 14 years in, we have an oldie based article about it. I’ll give you a link. Yeah Thank you. A real quick, little breaking, very esoteric news here. Apple is working on a transaction tax report. When I was digging into the docs this week, I found this. Do you have any more details from Apple about what this transaction report is for? I’m going to be and when it’s evening? Unfortunately, not really. The thing is, Apple rarely says they’re going to make something happen. Usually they don’t say anything. We might get a hint because we know people who know people. But a hint, nothing even beyond that. And that’s it. So I’m not entirely sure why they have it up there. I’m not entirely sure why that C is not capitalized because really hurting my face. But ultimately, this has been probably one of the most requested features from especially from the larger developers who are paying a lot of money in taxes. And there are a lot of different tax regulations that companies now have to worry about, especially as you think about international. And the way Google handles it is by just saying if you want to take care of it yourself, just go and do it. We’re not going to touch it. Brazil is a big country for that and a lot of game companies are now opting to not let Google handle taxes in Brazil. And they do all the work because it’s so complicated. So I think that’s the reason behind this coming up. And I hope this will be what we’re all hoping for. And we can take this and bring this into our reporting and make that payments report make even more sense. Gotcha awesome. And then the last thing I did just want to touch on and appreciate touched on this earlier. But part of the reason all of this is a problem is that a lot of companies, especially larger companies, need to do what’s called accrual based accounting. So cash based accounting, this is how I’ve run my business, how a lot of businesses run. Is it when I get a payment from Apple March 3rd? It is for the January fiscal month, but I record that as revenue on March 3 and that money hit my bank account March 3. You know, to the IRS, to everyone else. It’s money that hit my account. On March 3. It doesn’t matter that it was from January. It just matters that I actually received the money in March. And it’s so simple. I mean, you know, I have zero the financial tools set up to automatically import everything. And it takes me like a few hours a year to run all my accounting for tax purposes because it’s all just automated into 0 and I just do all cash base. I just assign categories to the transactions. It’s when the money leaves my account. When the money comes into my account, it’s so simple. Now, larger companies need to do accrual based accounting, which means that you want to record the revenue the day the transaction happened. And so now if you think back again to the very first slide and then everything we’ve talked about this whole time is that if a transaction happened the first day of January’s fiscal month, which was actually December 26th, and you didn’t have accurate financial data on it until March 3rd, trying to sort that out of what revenue actually transacted on the 26th of December when that refund actually, if you get a refund, what was that transaction that it’s actually related to? And you’re having to go back and fix your December books. If you’re doing a calendar based accrual accounting, you’re having to fix the first books in March because you don’t have accurate data for December 26th until March 3. So this is a huge, huge hassle. And I’ve talked to multiple, you know, large shops. I think there’s some folks here in the chat that I’ve spoken to about this. And, you know, Apple’s making it easier and easier at figures and revenue count where both, you know, everybody’s exploring ways to help make this a little bit easier. But the bottom line is it’s just a huge hassle. Yeah, absolutely. Most of these big companies end up using our apps so they can get all those different columns from the payments report. So they get the estimated. And that’s used for just to get an idea of what they expect. And then they bring in those financial reports as soon as they become available at the slightly estimated stage before the conversion rate and everything that makes more sense. And then at the end you automate that with the API. So it all comes down with the payments report and then everything makes sense, but it’s not an easy process and we work with teams that are built around clarifying this internally in very big organizations and they really depend on this because without this it’s really problematic, you know? All right. Well, the 15 minutes of slides I prepared took us 15 minutes to go through only 50 minutes. And I like to talk, and it is a rather complex topic. And so hopefully we’ve got into enough detail, but not completely bored. Everybody out of their mind. I let’s jump right into questions and I can go over our if aerial if you need to bounce on they are totally cool but I’ll try and answer as many of these questions as I can as we go through. So start live answer what happens with chargebacks? Customers cancel a charge via their bank. I’m going to send this one to Ariel. Now I’ll take this one. It’s easy. The money gets taken from your total. So because what Apple does is they basically build kind of your own money, your own accounting of money. They can take money from that until they pay you. And so they will take that from you and pay that to you. I believe they have rules around and they fight chargebacks fiercely. So it’s not really as easy to do a chargeback unless it really, really makes sense. But when that happens, they’ll just take the money away from you and from the accounting side and pay my report side. A chargeback is basically treated as a refund, correct? So in the payment report, it will show up as a refund and as with other refunds, it gets deducted from and shown in the transaction list in the payment report. Exactly Gotcha. And feel free to ask follow UPS. I’m just going to go through, starting from the earliest question and go through because it is a confusing topic and we tried to cover everything. How can you see all of those amounts? Meaning, how can I see total settled tax set aside, refunded amount, currency conversion, net amount? I want to know how I can see the gross amount that relates to the net payment we’re receiving. We’ve been able to we haven’t been able to find this report. So I think we answered that question. And feel free to follow up. But that payment report so figures will automatically download that and aggregate it for you into that payment report that we showed with my personal data in there. And I didn’t bring this out at the time, but I love how I figures even has the individual in-app purchases listed. And so Apple does provide at the transaction level and the SKU level data. And so so I’m able to see in the app figures payment report how much of that payment is coming from lifetime subscription versus the annual subscription versus the monthly subscription. And that’s and those are the hard numbers from Apple in that report. If the level of details in app figures report is not enough for you, then what you do and I did this in the last month preparing for this chat is that you go in for the first time because I’ve been relying on app figures for more than a decade to do this for me. You go into making me blush. Yeah, you go into app Store Connect and you download it there and you get this massive CSV file that you can then, you know. A use like an Etl into a data warehouse if you want to be more sophisticated and do kind of what Ariel is doing, but with your own kind of custom needs, dump it into Excel and sort in create columns like I did to calculate the time to settle. But that report does have every single transaction listed with that transaction date. And then the settlement date. And so this is where, you know, revenue cap, we have looked into taking those financial reports or the final payment report and normalizing it against our transaction level data. But again, for the reasons Ariel discussed, normalizing those choices is probably impossible because we’re getting the time in UTC and trying to match those back, match those into the payment report, which just gives you the day they happen instead of like a timestamp for when they happened. It is tough. And, and then and I’ll go ahead and answer this. I think somebody asked it later. So Apple does not send transaction. They send transaction level data, but they don’t have any kind of a identifier on that transaction where you can tie that back to the transaction that actually happened. And they do that for the same reasons. I’m still a little confused about what’s so private about the payment data that they couldn’t provide some sort of transaction idea that ties it back to the original transaction. But for privacy reasons, they don’t let you do that. So so again, it’s like you can match to the day. The original transaction and the actual transaction data to the payment transaction data, but, but with time zones and all that other stuff trying to match them perfectly, you’re never going to get 1 to 1. You could maybe get, oh, well, 28 transactions happened in this day in the UK and and then in the payment report, these 28 transactions happen. But it’s yeah, it’s going to be difficult to get that to 100%, which is why we haven’t built it. And then, of course, at figures doesn’t actually have the transaction data that we developers have as far as the App Store receipts where and it shows the renewals. And we have all of that data as revenue cat since we managed the transaction and then continually refresh that receipt using Apple’s push notifications and then the polling feature. So we have those individual transactions with all the details of all the renewals, of all the grace periods and everything like that. But again, matching that to the actual yeah, you can say anything is, is, is a fool’s errand at this point. Yeah unless Apple can get really, really close. Yeah but close is not good enough when it comes to money. That’s where we usually draw the line. Yep so Leo asks for a Sas subscription business. Is there a way to send people to pay on my site and bypass Apple’s 30%? Absolutely so again, as we discussed, you know, you can use stripe. You know, Ariel runs his business outside of the App Store and can tell you all the challenges of managing all that stripe has made it way easier. You know, there’s other payment providers, Braintree and others. You know, there’s whole other, you know, webinars we’ve done and blog posts about this. Apple does have very specific rules around what, you know, who you can send off the App Store. So it’s possible and revenue. Again, we actually provide SDKs to do that with Stripe and we have other payment providers coming upcoming. But for all the reasons we discussed and I know I’m like, you know, I think I’m super biased being from revenue, but with Apple managing the taxes, the withholdings, the compliance and everything else, and then also it being so easy for them to just use their face to pay. I think people really underestimate just how much of a conversion rate drop you’re really going to have pushing people to web payments. And even if it was inside the app with a credit card, it’s just a different ballgame. But I will say stripe is actually getting going deeper and deeper down this rabbit hole. They acquired a company that does tax reporting. They don’t yet collect and remit payments, but I can imagine that might not be too far off. So I think over time, this is going to get easier. And easier. And one of the things I’m kind of dreading on at this point, but it’s just such an important topic. But, you know, as Ariel was talking about just a few minutes ago when he started in 2029, you think, oh, it’s so easy. Like you just collect payments and just, you know, stripe on their website. It’s just like two lines of code to collect the payment. It’s so easy. Even to this day, you know, stripe makes things so much easier. Braintree makes so much easier, but they don’t solve everything end to end. And they even don’t solve some of the accounting things in the end the way, Apple and Google do. And again, Apple probably better than Google these days. But if you are going to collect on the web, just be prepared to either be knowingly, you know, breaking local laws in some regions or, you know, fines. So you didn’t hear this from us. Yeah Yeah. I mean, as you say, you know, it’s up to you to talk to a lawyer or talk to an accountant. And if you’re collecting on the web, you know, use something like Stripe and then use there are tools in stripe that you can use to help make some of this more simple as well. But it is a big, hairy mess. Do you have anything to add, ariel? I mean, we can talk about this for days. This I know. And we just added an integration with strobe for the exact same reason, because we see more developers are trying now this and with everything that’s been happening with Apple over the last almost a year, it’s inevitable that Apple will open up the stripe. But now it’s nearly impossible. Only a few different apps can do it in under like really crazy conditions. And I’ve cover that on my various livestreams of the potential that really doesn’t exist in my opinion, with that. But it has to change. I give it 12 to 18 months and we’ll see a big shift and then it will become possible. Hopefully by then stripe will have some solution that is a little bit more tailored for these kind of use cases, which I know that they’re working on now. All right. Rachel asks for sub transaction data sent by Apple. Do they have the practice of revising data retroactively? Yes, go ahead. Absolutely the thing is, so we look at a lot of data from a lot of developers, small, big and everything in between. And for the most part, they don’t change the data retroactively. But once in a while, we’ll find something that makes absolutely no sense, triggers all the alarms on our end, as far as data, data stability. And we’ll talk to developers. We think this makes no sense. I didn’t do anything and I see this massive increase or massive drop. And that happened. I want to say in the beginning of February, there was a day that was just a huge dip for everyone. And we talked to Apple about it and they got to fixed. So it doesn’t happen too often. And when it does, Apple is really good about fixing it, but it does happen from time to time. This is what I’m curious about. So, so like revenue cat, since we are dealing with the transaction level data and we’re refreshing receipts, you know, if a transaction had gone into a grace period and then actually failed, you know, 10 days later or whatever it is, that transaction gets updated in our database and it has the entire chain from starting a free trial to the apple, trying to convert that free trial to going into the grace period to everything in Apple’s daily reports. And then in this subscription data, they do give you what happens when somebody is an active subscriber for 10 days while that transaction is pending and then they actually aren’t a subscriber anymore. Does Apple so and maybe this is part of this question is does Apple retroactively consider them no longer a subscriber, never having been a subscriber or do they are they a subscriber for those 10 days and then they like is almost like a cancellation. Do you know how that works? Yeah so that gets extremely complicated, but actually it works kind of well. So Apple under the hood has all these different classifications for where an active subscriber is in that long kind of flowchart that you had before, except for subscriptions, it gets even more complicated. We’re tracking, I want to say at this point, 70 or 80 different of those labels, and that’s all the ones that Apple has. Some of those are not at all documented. So we have to figure out what they all mean. And one of those labels or a few of those labels have to do with the specific state when a credit card declined or when a transaction wasn’t possible. And so they will go into a billing retry, and then from there they’ll go into grace and then from there they’ll kind of walk through a whole process. So you can see on our side all these different numbers and which how much of your user base is actually in a, in a retry period or as in a grace period? And you can see if they moved into grace from a trial. So if a trial was supposed to upgrade and it didn’t, so you have all this data, it just so much that most people don’t care enough about it because it’s usually a tiny percentage. So we have what we call calculated metrics that lump all of them. So we’ll lump people who we know are in this process of getting retried. And we know that they’re still technically active. So they’re getting access from the point of view. And so those will remain active. And then when that changes, when that clock hits, they’ll become a cancellation. Guys and then they’ll get out of the calculated metrics. So under the hood it’s broken down to a bazillion pieces on top. You only see what is easy. And you can see both on our side. We just most of our users don’t. Yeah as for reasons and then again on the revenue cat side because we have that at a per user level where we have it both server side with the user ID but then also client side, you can actually with our SDK pull the state they’re in and if they are in a grace period or if they’re in a trial, you can put a little flag up there saying, you know, hey, there is trouble with your payment and explain how to fix it. You can send a push notification, you know, saying, hey, your trial is going to expire because your transaction is In the grace period. So you can actually in near real time be able to kind of trigger these wind backs at an individual user basis. You know, a lot of people use email for that as well. And so with a tool like iterable, you can take that, that grace period webhook and then fire off some kind of went back on that since we do have that customer level data. So I think we’ve like answered this question pretty well. So Google pays in 30 days. That’s one of the questions Google pays. We’re in 15 days, correct? Yeah so they’ll pay within that area, I would say. So in less than 30 days would probably be a very safe bet. Gotcha in their docs, they say they pay on the 15th after the end of each calendar month, so the 15th of every month. So it’s just so much more simple like we showed in that calendar. But you’re saying that sometimes it’s the 17 sometimes it’s the $0.18 I they ever pay the 13th. 14th it just kind of. I don’t think so. OK it usually is a little bit later, but you can expect it around the 15th. From what I’ve seen, one of the things I’ve been surprised at with Apple is that they always pay exactly 33 days after the end of the fiscal month. And because I have the data and because I so I actually went back and looked at all my bank transactions and I have a blog post where I give the specific dates where this happened. But I believe there’s only been five times in the history of the App Store where Apple didn’t pay exactly on the 33 days. I think two or three of them were due to that day landing on a holiday. And then a couple of them, I swear, I think Apple does a little bit of financial engineering here and there where they push the payment into the next fiscal year to bump their services revenue in the next fiscal quarter instead of the current fiscal quarter. And so it just blows my mind that in 14 years of payments now there’s only been like four or five times, just a handful of times that Apple hasn’t paid exactly 33 days after the end of the fiscal month. Apple does a lot of financial engineering. Yeah, well, it’s so clever. It’s so clever. One of the things I actually tweeted about this recently, and you and I had a chat on Twitter, so I published our blog post in the fall about Apple’s 2022 fiscal year. And then in January, somebody pings me on Twitter and they’re like, hey, your fiscal calendar is wrong. I think it’s not like, you know, I’ve done this multiple years. I’ve watched the fiscal calendar for a decade now. Like it was, right? Like, no, no, no, it’s wrong. And so I think somehow you got tagged in the conversation or I asked you about it. And turns out in December, Apple updated their fiscal calendar. So what was going to happen? Apple’s fiscal year only has like 364 days or 360 days or something like that because of the way they do 28 day and 35 day fiscal months. And so every 5 to six years they have to add a whole week to realign the calendar. So like the end of fiscal 2022 is September 24th, which is really awkward. And so to realign the fiscal calendar to the monthly calendar, Apple has to add a week every five or six years. It’s just bizarre. So the original 20 to 22 fiscal calendar had an extra week in the December fiscal month. And my guess and is that it was financial engineering because they had such a strong quarter and they knew they were going to have such a good quarter that they pulled that fiscal month out of December and they’re going to add it back to next December. So the fiscal 2023 December will likely have five fiscal we five weeks in the fiscal month instead of four. And you know, I’m going to follow up on this in 2023 because it’s going to be interesting to see what their services revenue does like year over year. It’s something a lot of financial analysts even pay close attention to of how Apple can shift revenue around with these fiscal weeks and the fiscal months and the payment dates and things like that. I don’t know if that was what they did this year because there’s an actual pattern if you look at it over years, and that’s how we discovered that. So they had a calendar, an app Store Connect that was just wrong. And when we discovered it, we won. We asked a bunch of different people at Apple about it, but at the same time, we put out our own with the dates. We knew what we thought were right, and they have a pattern for when they add that extra week and that pattern matched to next year, not to this year. So, yeah, I don’t know. It’s maybe it’s like commodified financial engineering or like templated financial engineer. Like something was, I don’t know. But instead a template from a calendar standpoint sense from a calendar standpoint actually makes sense to do in 2023 as well because it lands perfectly on January 1st starting the 2023 Q2. So it does make sense calendar wise, but it was just weird how that all went down. Like, like how does Apple post the wrong fiscal calendar? And funny thing is, I talked to Nick. I don’t know. It’s one of those places they pay less attention to, I think maybe. Yeah anyways, we can. I don’t think anybody wants to hear US debate the financial engineering. Let’s move on to questions. So I’ll, I’ll invite you to my Livestream to do that. Well, OK, we should be fine Simon asks revenue cabcharge don’t handle VAT well. Will that be fixed? I know it’s something we’re looking into. And if you take the context of this entire conversation, you probably understand why it is actually very challenging to handle these things well. So you’re absolutely correct. We don’t handle VAT well and it’s something we’re trying to solve. But given all these complexities, it is a challenge. So I can’t promise when it will be solved. But we’re aware and wish it were easier to handle this better. Dylan, we’re running a paywall A/B test with amplitude. However, we can’t compare the refund rate because revenue capped does not send the refund event to amplitude, right? We do, actually. So why don’t you get with me or our support team offline and we can talk? I don’t know all the details of exactly how it does, but it does. So let’s. Email me directly or jump on our community and tag me and we’ll get this answered for you. Next one, we’re getting a lot of revenue questions today, but I mean, this is part of why we’re doing this webinar is that it is really confusing all the different financial aspects of what we handle versus what gets paid. What is some revenue cat users ordering, doing what the price of 0 does it mean they have a subscription for free? I never offered this description at that price. That’s another question for our community. I’m not sure. I’m pretty sure there’s a reason, but I don’t have the answer off the top of my head. Glen asks, can you actually see the currency conversion that Apple uses? As far as I see, you just get the transactions in the local currency and the payment reports. So we covered that one earlier. Apple does eventually. It’s just that since they don’t convert it until the payment date, they can’t give you that data until they actually have data and have actually converted the revenue price. Asks with this report that you are showing, where can I see the detail? This is still showing the net revenue. Where do they see the gross amount? So so again, if we get to this later, I think is that the payment report is where you get the transaction level data for the entire penny accurate. And again, it just doesn’t come out for until the 33 days after the end of the fiscal month. Daniel asks. There seems to be a catch up every three months for actual revenue on the App Store. What drives that? This is the fiscal month and this is why it’s so confusing. And when I was solely reliant on App Store revenue for paying the Bills. I love Apple’s 35 day fiscal months because you make more money. You know, what’s the I don’t know. Off the top of my head, the exact percentage difference between 35 days and 28 days. But you get a whole extra week of revenue in those months. And so it’s not a catch up. It’s just that their payments are for a 35 day month instead of a 28 day month. And again, if you check into if you happen to use app figures, you see that data in the payment report and then you can use our calendar or Ariel’s calendar to kind of match up where those payments are coming from. I should add that the payments report has a calendar built in. So when you ask for the May report, for example, you get the actual fiscal me report. You don’t have to do any of that kind of ninja thing around that. We also give you the ability to look at the financial reports by the month that Apple has, which is a regular calendar month for those financial reports in the sales reports that you can do that too and then align them, which is what happens in payments by default. If you want to go really crazy, you can really download those reports directly from the archive, which will give you what you would get if you had to go into app store, connect and then drop them into Excel and start having fun. But I don’t know who wants to have fun on Excel on a Friday evening, so if you do, it’s possible. Is it possible to get payment in euro instead of pounds? Do you know that area? not off the top of my head, but I think that’s more of what Apple decides based on your bank, right? Yeah, I think it’s that you would need to set up a bank in the eurozone to be able to accept euros instead of pounds. Yeah Yeah. And like, I set up a US account and I’ve always been paid in dollars and so. Yeah, it depends. And this may get complicated though, because if you’re registered as a UK entity and pay taxes as a UK entity, they might not actually allow you to set up a euro denominated bank account. But that would actually be a good question for apples. And, you know, one thing a lot of people don’t realize is that Apple’s support on this kind of stuff, it can take a while to get here from them, but they actually do have decent support. When you if you ask these kind of questions and say, hey, I’m in, I’m in the UK, but I want to get paid in euros, is that possible? You will likely get a good answer of how to actually do that. But my guess is that it’s going to be tricky if you’re a UK entity. Doug asks, does detailed financial reports show every transaction, as you said, or is it consolidated? It does show every transaction. The nice thing is it shows every transaction. But you do have a column for skew so that you can as at figures does actually tabulate individual SKU level totals and then total all the SKUs up for the app totals. Kelly who jumped around. Kelly asks, why don’t why doesn’t Apple enable individual transaction ideas that would allow transaction level reconciliation? There is no solution for this issue. And I mean, I have talked to Apple directly about this, and the answer was privacy. I it doesn’t make sense to me because, you know, revenue, we have all this data at a user level, like if you’re running a business and you have customers, you need to. That customer and like, you know, when, when, when I buy something online and I give them my home address and my credit card, they have my home address and credit card. That’s not a privacy invasion that’s necessary to transact and do business with a business. And so safely revenue cat we have because we manage the transactions inside the app. We have we facilitate that and have the transaction level data. And then by updating those receipts server side, we have every single thing that’s happened. So we know, you know, again, if it’s gone into grace period, we at an individual user basis. So so when your support team is talking to somebody who says, hey, why am I not getting access? They can actually pull up by email or we can also use anonymous IDs and there’s a little hack because I like to keep things anonymous and I don’t collect email, although I should start collecting email. But there’s a little hack you can put in your app in the settings where using the roving account SDK, you can actually grab that anonymous ID so when they start a support request, you can grab that anonymous ID and then you can search that anonymous ID and revenue cat and actually get the transaction level data and see, oh, they went into billing grace period and then it failed and they just need to go back into the App Store and renew it. So it’s like and this is not like massive privacy invasion. This is like you’re doing business with a company that needs to know whether you’ve paid or not and needs to know the status of your transaction and needs to know that on a user level basis. So that they can grant you permission to use it. So that’s another thing revenue does as well as that we handle. We have what we call an entitlement engine. And so when somebody pays, you can use a revenue SDK to determine what level of access they get. You know, in some of my apps, I have multiple in-app purchases in addition to the subscription. And so with the revenue SDK, you can grant those individual features individually when they’ve paid on those. And then when they get refunded, you can take them away. When they’re a subscriber, they get access to this. When they’re a lifetime user, they get access to that. And so it’s like, this is data you need to have. It’s not some massive privacy invasion. And so I just I guess the only thing that I can the only thing I can think is that, you know, if somebody is using a VPN because they want like absolute privacy, the payment report will give you their state. So like you could know the state they live in. And so yeah, it is definitely a source of frustration both for aerial obviously, and then especially for us that revenue cap, because we would love to be able to tie our transactions to the payment data directly. But apple, for privacy reasons, doesn’t allow that to happen. Well, like a tiny thing to add on top of it is all the way up until subscriptions. It wasn’t that necessary. Like you’d want it, because that’s how you make better decisions. And that’s I understand the lifecycle a little bit better, but with subscription C absolutely need it, it’s no longer a matter of just how would be nice to have. So I think eventually me will get a little bit more from Apple. They’re a little bit slow when it comes to these sort of things, so give it some time. But they’ve really upgraded and updated a lot of the infrastructure related to subscriptions a ton over the last like two or three years. The types of data that they’ve been giving us have really expanded. We started with maybe 10 or 15 different those labels that I was talking about before those metrics, and now we’re up to 70 or 80. It’s possible. It’s even more so. I imagine we’ll see more of this in the future. Yeah, I don’t know when I’m looking forward to it. Then someday, hopefully 14 years in, we’re still like crossing our fingers, hoping Apple like, gets their stuff together. I don’t know. I’m super excited about the last couple of years in the App Store. So much so. It really has changed. Yeah, Yeah. It’s kind of like a Renaissance in a way of things, so who knows? Yeah so then Carlos asks, and this is a valid point as well. So revenue cap data is, is 2% to 3% off from the payment report. If it’s primarily us based, if you have more VAT customers, again, it’s because we aren’t properly in revenue handling VAT and again, something we’re working on. So the answer is yes, we’re aware and we will. We’ll we’re working on it. Camilla, what happens with payments when Apple decides to terminate your developer account? Do you have any experience with this area? Have you worked with any customers who do correctly? I’ve heard from a few. It’s never good, though. Yeah, never get. It depends why they terminated the account. It’s always a matter of why Apple doesn’t really do anything shady. It all has to apply according. It all has to go according to some sort of rule that they have in the developer agreement. So it really depends if they decided that you were defrauding them in some way or doing something that goes against the terms and all of those downloads technically go against the terms. So you’re never going to see that money. In most cases, you don’t see that money. But again, it really depends on why it was terminated. Yeah, that makes sense. I’ve always been very curious, like all these apps that get pulled from the App Store for fraud and stuff. Anecdotally, I’ve heard they don’t automatically like refund do a lot of refunds. And that’s tricky because a lot of it has already been paid been paid out. But if they terminate an account and don’t make the final payment. I would hope they at least refund that. Apple doesn’t just keep it as part of some kind of a slush fund. From what I know, they really operate the same way across the board. So when an app is pulled. Yeah that’s where it ends. Well, that’s what I think. And it’s another one where I guess we need to find somebody who’s had there. And I guess if anybody here knows somebody, put them in touch with me or Ariel. I would love to know. Yeah, I would love to talk to somebody who’s had this been through this experience and find out, you know, if there’s refunds done or. And if you get a final payment, those kind of things. And like Ariel said, that it’s probably different depending on why you’re terminated. So if you know somebody who’s been terminated for cause, that would be especially interesting. Ariel, if you need to jump. I mean, I want to try. And, you know, I’m still with you. I got a few more minutes. All right. With do accrual accounting here, I was wondering, does Apple charge the card on time of transaction and pay us later or do they actually charge the card later after the transaction date and that kind of. Well, it was a. Is if it’s a very frustrating answer that we talk through in multiple ways during the presentation, but the answer is that it’s indeterminate from the transaction happening and when actually charges the credit card and for, you know, dozens of reasons that things can get delayed, Jonathan asks, it sounds like most smaller app companies are using cash basis accounting. Is that correct? If so, is there a revenue threshold at which service companies will crossover to accrual accounting? Is it hard to make the switch from cash basis to accrual basis? I’ve always operated cash basis. I’ve recommended to everybody I talked to again, I’m not an accountant, I’m not a lawyer. I shouldn’t give this advice publicly. But it is just simpler. And so how do you know, like what are the specific reasons? A larger, I guess, you know, publicly traded companies are pretty much forced to do accrual based accounting. So a company that’s headed toward being coming public, a company that needs their accounting to be that way for specific reasons. Yeah can you speak to that more? Yeah so I’ll preface with I’m not an accountant or a lawyer or anything of that nature, but you don’t have to be a public company to go accrual. I think most companies that are slightly more than individuals, most companies that are actual companies that have a lot of expenses or have expenses. And have a team and have payroll and have taxes and have all of that, they’ll usually use that rule. We I think we use that rule like almost right in the beginning because it makes everything. It is a little bit more complicated. So you would need to have an accountant and you don’t want to do that by hand because that becomes a mess. But if you have an accountant, it shouldn’t be that difficult if you don’t have that many transactions. But the benefits are one, you get to have a much better, more flexibility with your taxes, which hopefully none of you have to worry about it. But if you do have to worry about it, you want to have that sort of flexibility, especially when you make a lot of payments. If you have a team and you’re paying payroll, payroll taxes. If you have an office space or you buy buying a building, or are you doing any of those things that require big, larger amounts of cash, you want to be able to recognize them when they make the most sense for your books as opposed to recognize them when they happen, because it doesn’t always align. If you, for example, get paid by someone who isn’t or is not directly from the app stores, if you have accounts that pay you, let’s say, for a year in advance, so an annual subscription even can be broken up. And if your fiscal year is not exactly the calendar year for that particular subscription, you don’t have to pay taxes on that entire subscription. So on $100, you may only need to pay taxes in the current year on $50. And as you grow, that becomes a lot more relevant. I don’t even remember the days of doing cash basis, so I would say don’t have to be big to do it paid. It’s so much easier. The other benefit too of accrual based accounting is if you use your accounting data to run your business. So like if, you know, if you’re trying to figure out, you know, your ad spend in January was x and your revenue was y, and you’re trying to understand that at a, you know, to the penny level, then doing accrual based accounting, you can use your books to better understand the ins and outs of the flow of money. And again and doing it in a way that’s convenient to you versus just waiting until things get paid to register. And so that is one thing about cash based accounting. That is a downside. So for all the hassle of accrual based accounting, you get more insight into what’s actually going on with your business. So like when, when it says that in March, I was paid x in my accounting software, I know that money was not actually made in March. It’s just that I was paid in March and I don’t use my books to analyze my business in that way. But if you’re spending in January and you want to know how much you actually revenue you actually generate in January, yeah, it does make sense. Because it’s such a big hassle, it’s like you need to at least be at the level where you can either hire an accountant or have somebody dedicate real time to it. Because it’s a lot of work. A lot of work. Absolutely and then and then for all the reasons we just discussed, trying to align Apple’s fiscal months to calendar months to do accrual based accounting is a lot of work. Yeah, you need a bookkeeper probably too. If you’re in that boat and you want to do it right. I have to leave. But I think the next question. I think I can answer the next question. OK go to. Yeah, Yeah. So is it possible to get Apple to recharge a user after they have given the user a refund for a service they actually used? And the answer is no. I don’t think anyone can make Apple do anything when it comes to subscriptions or in-app purchases or anything like that, which is why the new APIs that now Apple is starting to acquire. So you can enable people to do more about your subscription from within your app. Why that’s so exciting. You’re kind of cutting out the whole. Can Apple do this? Can Apple issue a refund? Can they undo a refund? And the answer is no to all of those. But now there is a little bit more access to users on this app. You know, I think my time is up. Is there anything else I can answer quickly before I leave? No, Thank you so much. I’ll go through these questions and then, yeah, we’ll have to do this again some time, too, and I’ll have to. I’ll absolutely. I’d love to see you on my side. Yeah, absolutely. But Thank you so much for your time, Mario, and Thank you for going 30 minutes over having me on this. A big topic. So yeah, a lot going on. Absolutely Thank you. And if anyone has phones that I can answer, you can find me on Twitter fairly easily. And a lot of people have my email this point because I send a ton of newsletters. So if you want to ask me a question and I’ll be on Twitter, ask away. I’m pretty chatty, as you might imagine, at this point. Me, too. All right. Thanks a lot. All right. Bye, everyone. All right. Well, he’s leaving. I’m going to I’ll stick around and just try and get through all the questions Glenn asks. I’ve read that some countries are requiring annual subscriptions to be printed on a per annum basis. How is this going to affect pricing versus monthly versus annual subscriptions now? This is a fascinating topic. The answer is. It depends, and we don’t know. It seems as though Apple is intentionally making it a little harder to get the pro-rated refund. And so then it just depends on, you know, how many consumers actually jump through the hoops to get that pro-rated refund. And then I think it’s going to matter to kind of how much churn you have, how dependent you are on the annual subscriptions. And so I think the answer to this is going to vary depending on retention. I think if you look at a company like Netflix where, you know, probably a majority of their customer base just stays subscribed and, you know, like to me, it’s just like, you know, I don’t have cable anymore. I just subscribe to like three or four streaming services. I’m going to stay subscribed. I have no intention of ever canceling. And I’m not the kind of person that’s going to cancel for a month and then get back on and then cancel. And get back on, you know, to save $10 here, $10 there. So I think, you know, companies at that level are going to be much less impacted. And this is a part you know, Netflix doesn’t even offer an annual subscription anyway. But, you know, a lot of developers will charge, you know, 40% to 60% less on the annual subscription to make the pricing look very attractive compared to the monthly to get that money upfront, which is nice from a revenue standpoint that you can pull that revenue forward. And then there is typically more monthly churn. So if you charge on a monthly basis, you know, the we’re going to get some benchmarks out in the next few months. But, you know, by the end of a year, you generally have less than 50% on a monthly subscription, but you’ll have in the ballpark of 50% on an annual subscription on the renewals. And so I think, you know, there’s a lot of reasons why that is. You know, people who are willing to pay the annual subscription probably have a little more dedication. People who are using the monthly subscription are maybe just wanting to try it out and, you know, pay the $5 or $10 or whatever your monthly subscription price is. So each app is going to have to figure out that balance and they’re going to have to look at, you know, how much better conversion are they getting by making the pricing look attractive for the annual you know, how important is having that revenue all at once versus over the months? And then look at, you know, once these things start to happen, you know, our customers are actually using it in mass. So if it’s, you know, 5% of your annual subscriptions end up getting refunded, that’s probably small enough that whatever was working for you on your annual versus monthly pricing is going to continue to work. So I kind of think it’s not going to be a big deal. And not going to change strategy very much. But again, there will be some apps like if the app is heavily European focused versus the US. Yeah if if, you know, like a lot of apps are like 60, 70% US revenue. And so then if it’s 5% of subscriptions get refunded in that 5% is of 40% of your business. And it actually is just a few countries. It’s not even all countries in Europe and then globally. So, you know, it may be 5% of 20% of your revenue. And so I kind of think, you know, we’ll see what happens. But I don’t think it’s kind of Earth shattering and get to make, you know, big dramatic changes. Consumers are going to have to, like, learn about it. They’re going to have to jump through hoops to get the refunds. But ultimately, I think things like this are fantastic for the subscription economy broadly because the more comfortable people are in the subscription model, the better off we all are. So yeah, we’re going to, you know, take a little bit of a hit when people do get that refund and Apple does pull the money out of your next payment. And for everything we were just discussing, it’s going to be another kind of accounting nightmare actually having to, you know, go into the payment reports and figure out these pro-rated refund amounts. So it is going to be a hassle. But ultimately, I think it’s fantastic for consumers to feel comfortable about signing up for an annual subscription. So broadly, I’m in favor. Yes, it’s going to potentially change some tactics in some countries depending on how much. It gets. Jonathan says. So from our point of view, chargebacks and refunds look the same and effect on cash flow timing would be equivalent, whether they take tracking chargeback or refund. Yes, that is correct. So they’re essentially the same thing. And and, you know, as with refunds, whenever the chargeback does happen in the fiscal month, that it happens is when they deduct the revenue. So, you know, if something was a three or four-month-old transaction, an Apple will go back pretty far and offer a refund. As Ariel said, they fight chargebacks pretty hard. But if it’s a refund from three, four months ago, it’s going to come out of your next fiscal months payment. Hope that answers that. Peter asks how can a how can a Sas company recognize an Apple user initial subscription on a Google device or vice versa? So this is where revenue comes in. You know, our platform is specifically designed to simplify the cross-platform Subscription Management. And so there’s a couple of layers here. As I discussed earlier, we have the identity managed, we have the entitlement management of we’re kind of the source of truth for who has access to what. And then we have what is now version three, because we’ve learned so much. And as we’ve scaled and seen more kind of edge cases at scale, we’ve been able to tackle all known edge cases at this point, but by using revenue, carrot and creating some form of customer ID. So if you collect an email on the web and then force them to log in on the device, if on Android you collect an email and a log in or something like that, that’s the most straightforward way to do it. If you don’t want to force a login for the subscription, there’s some kind of hacky ways around it, where you could have them from the Android device, push their anonymous ID and get access on an Apple device. And with the forthcoming revenue cap product that we’re working on to make it easier to take web payments, we are working toward having a solution where you don’t have to force a login, where they can pay on the web and be redirected to the app with that user ID intact. And then once that web payment is attached to that App Store account, then it stays with that account. So that kind of stuff does get really tricky. But again, it’s, it’s, you know, why revenue exists is to help you manage those. And again, forcing a login is the easiest way to share subscriptions across platforms, but there are ways around it. Andrew asks, can you explain the anonymous user an alias in revenue cap? Better for us, we have trouble keeping track of actual subscriber counts compared to the app platforms. Who this is. You know, this is probably one better for the community or support. It’s a long answer. The aliases and anonymous while you can and I do this in my apps using anonymous ideas does create some level of confusion in. And this is where you’re kind of following on the last question of where our identity solution comes into play is that there’s even stuff, even if you have a login where people share Apple ideas. So for a long time, like my wife and I shared an Apple ID so I could pay for and log in with my email address into calm and then. My wife gets into calm and she has my App Store receipt because she’s logged in to my App Store account. So calm sees her as a valid subscriber, even though she’s not logged in to my account. And so those things get really, really tricky, especially because people do like to share Apple IDs too, so that they can get access to the paid versions. I mean, there’s like, like, you know, friend groups that will share an Apple ID so they can all get access. So, so with revenue cap, we do have a solution. Now in our identity management where when you see multiple Apple ids, when you see different log n versus user ID, where you can decide to grant or revoke access and try and kind of prevent some of that. But when, when an Apple idea is shared and you’re not require a login, so you have an anonymous user ID and you’re relying 100% on the App Store receipt, you can end up with 10 or 20 people sharing the same subscription across multiple devices. And again, we have some tools in revenue, you know, check our docs, talk to support. I’m not sure if this is answering your question specifically, but this is a better question for probably the revenue cap community or TRICARE and support to get a little more detailed answer. But the broad answer is know, it is a tough thing because people do try and work the system like that. Thomas asks, why do we some days get so many billing issues, mostly in australia? That is a great question. And it’s actually something I’ve been meaning to write a blog post on, just to force myself to ask the right people and get more detail on this. I know that there are specific countries that have higher billing issue rates. There are specific days that have higher billing issue rates. So, for example, a lot of people get paid on Friday. And so if you have a debit card attached to their App Store account and, you know, Thursday, they’ve they’ve, you know, hit a few dollars in their account and your subscription is 10. They’re going to hit the billing issue if you’re renewing on a Thursday. And then that’s part of why Apple has the grace period now. So then if they get paid on a Friday, you know, they have the money. They want your subscription. I mean, ideally, that’s the case. I mean, you know, and so then on Friday, Apple retail dies and then the money’s there and then there’s, you know, you can use apps, app, prepaid cards. Some people use prepaid cards to make sure that they don’t spend too much. And so those prepaid cards can run out. There’s a ton of different reasons why these billing issues happen. And at some point I want to do a deep dive on why. But that might actually answer your question is that I would bet that if you are seeing an increase in the US and Australia of billing issues on specific days, I would bet it’s either like a Thursday or Friday and it’s because that’s payday. And the billing issues are happening to people who don’t have the money in the account. All right, Leonard asks. We have a lot of seven day trial users whose trials don’t cover after seven days, although they didn’t opt out. Do you know why it sometimes takes longer for these trials to occur? So that’s exactly. Well, part of what I was discussing earlier. And part of what we discuss in the webinar is there a certain percentage. And again, we should do benchmarks on this at some point on our web site, on the blog. We’re working toward doing an annual report on these kind of benchmarks. But a surprising percentage of transactions. And again, I’m, you know, don’t quote me on these numbers, but but it’s in the ballpark of 20%, probably somewhere between 10% and 30% And then it depends on the app. It depends on the geography, depends on, like, so many different factors. And these are things that I would love to actually break down in a blog post. But those. For not having funds in a debit card, for not having funds in a prepaid card for expiration dates on a credit card for fraud, mistaken fraud prevention. You know, there’s a ton of reasons why the initial transaction the Apple tries wouldn’t go through. And so then that’s why Apple has this grace period. And these retry and that’s why you see a delay in those trial conversions is that Apple’s trying to collect. And they actually Apple does a pretty incredible job this is called dining. You can look it up in the kind of Sas industry who’s had to handle this on their own for years in as an app developer. I didn’t even learn the word until a couple of years ago. But Dunning is trying to collect payment, and so Apple has a pretty incredible process for continuing to retry those payments, entering into the grace period, continuing in that grace period to try payments. And they even do smart things like, you know, trying on Fridays and Saturdays after payday and things like that. So that’s why you have a lot of users who actually don’t convert on that seventh day is if the transaction enters into that grace period. All right, last question. I can’t believe how many people are still here. Almost two hours in. But this has been so fun. And there’s I mean, there’s a reason this ended up being such a popular webinar is that it’s just there’s so much to talk about. The next question, can you talk in detail about cross-platform payment and how to manage it? I kind of went over that a little bit ago, you know, kind of talking about, you know, billing on Stripe. And Android. Again, we support the Amazon App Store. We’re adding more web payments soon. You know, again, this is really why revenue cap was built, was to manage this cross-platform payment. So the best place to read up on now I think we have at least one blog post and then we do talk about it quite a bit in the docs. So again, ideally you would have a forced logging for anybody who is going to pay and then revenue cap becomes that single source of truth across all the different platforms of who paid on the web, but is logging in. And on an Apple device, who paid on Android and is logging in on the web. And so that is why revenue can exist to help simplify managing those cross-platform payments. And our identity solution can handle it, you know, most seamlessly if you force some kind of log in. But then we have ways to manage it through anonymous ideas and otherwise, if that’s a route you go. All right. Now we have one more question. Come in. Hannah asks, where can I find? Read more about the workflow for cross-platform payments, kind of similar to what I just answered on the blog. And I feel like this webinar itself has asked a lot of questions that each individual issue should be blog post. So we will do our best to be publishing more content in our talks in the blog. As Ariel said, he’ll probably have me on his he does weekly Tech Talk kind of things. And so I guess the best thing for now is to follow me and Ariel on Twitter. And as we produce more content around this, will be sharing it. Subscribe to the revenue Kate newsletter. Subscribe to the app figures newsletter. And as we are able to both produce more content on understanding these things and then also, you know, provide more solutions. I was shocked to learn today. And I don’t know if you’d want me to say publicly, but at figures is a lot smaller than I thought it was for. For as much as they’ve tackle that, as much as they do, you know, there are relatively small company and bootstrap. They’ve never taken funding. And so what say the exact number of employees in case Ariel didn’t want me to say and the revenue, you know, we’re 45 people now will be probably, you know, close to 100 in the next 12 months. But there’s a lot of stuff that we still are in the process of building out to make these things easier and easier. And so we will continue working that direction. So follow me and Ariel for updates on on, you know, better, better and better solutions for this. Again, you know, for cross-platform payments specifically, we do have a lot of great tools with Stripe and android, Amazon App Store and Apple’s App Store. And then feel free to hit me up, too, on Twitter as well. Whoo! that was almost two hours. Thank you for the people who stuck around all the way to the end and for asking so many interesting questions. And yeah, we’ll have to do this again soon. All