https://netsuiteprofessionals.com logo
Join Slack
Powered by
We have "subscription"-based services that are tra...
# general
l
We have "subscription"-based services that are tracked in different platforms like Recurly, etc. Every day we generate a usage report showing the hours used by the customer and the corresponding revenue. The GL impact is: Dr. Accrued Income (like Unbilled Receivable) Cr. Revenue The billing process intiated from third party platforms such as AWS, GCP, etc. usually happens in the middle of next month for prior month's usage. The GL impact is: Dr. A/R Cr. Accrued Income We do not use SuiteBilling/Contract Renewals but we have ARM. Is there a way to set this up? I'm concerned about the first GL impact. How can I post that if I do not have an invoice yet? I'm thinking of creating a custom transaction but maybe I can maximize first the standard functionalities. The second GL impact looks like it's just going to be an invoice with an item linked to accrued Income (no ARM). Or is there a way to create a revenue recognition rule based on usage without SuiteBilling or Contract Renewals?
j
This can occur based off of a custom revenue event. The item master will need to be carefully considered to ensure that we get the standard impact. When invoicing occurs does it go to a sales order? Or just straight to an invoice? Is there ever a time, where amount > usage?
k
Having ARM make is entirely special ball game. Why are you ACCRUING revenue for USED hours? you can recognized it immediately. Why not use cash sale record? Seems to be appropriate given the scenario you describe. that is USED hours should not be accrued.
usually in scenarios like that there is a Sales Order or invoice synced from a 3rd party created linked to the transaction with total hours. then as hours get used revenue is recognized on fulfillment trigger for the amount associated with the hours. Nothing to accrue really.
l
@Karina we accrue it because we're not yet paid but we already "deliver the service by them using the hours". Debit accrued revenue (like Unbilled Receivable) and credit Revenue. Is it possible to select an other current asset account on cash sale? It seems that it only lists the bank accounts (unlike Customer Payments).
@Karina I think in your example using item fulfilment, it debits deferred revenue and credits revenue in the Rev Rec JE but then you will run the reclassification process which will move the deferred revenue to the unbilled receivable (which is equivalent to the accrued revenue I am referring to). Bottomline is the same actually. But by recording it to the unbilled receivable or accrued income, it is already reflected in the correct GL but I understand that's not how NS works. It is done at the end via the reclassification process.
Unfortunately, we are not using sales orders and item fulfilments. We were thinking that it'll just result in a lot of transactions.
@Jim Merrill billing goes straight to invoice. We don't use SO. 99% of the time, billed amount = usage amount
k
@Luis - actually, it (fulfillment, all rev stuff) can be done without any human involvement. I understand your logic as well, yes. But when you deal with ARM there is pretty much only one way to deal with it - let it work its magic. When humans start interfering 🙂 things go wrong fast. If you were not using arm, it would be completed different.
and for rev rec whether you paid or not at the time of service does not matter, it is your capability to pay that is at play. in other words if you paid before assumption is you will pay again. thus, no need to delay rev rec
l
Thanks, @Karina. Very helpful insights as usual. I think understand now what would happen if we would use ARM. Do you have an idea how can this be accomplished if ARM is not utilized?
k
without ARM this is simple (but very theoretical - you cannot disable ARM once you enable it) - you essentially book invoice for the used hours and that’s that, nothing else is needed
Dr AR Cr Revenue
j
You could potentially look into using direct posting revenue items (if ARM is already enabled) I think there is a lag time associated to this consumption may differ from invoicing period. Hence the need for an accrual. Again, you could have a direct posting item that offsets the unbilled AR and just book a journal entry when the usage is consumed.
l
@Karina But usage and invoicing do not coincide. For example, usage data is available on a daily basis but billing is done every 15th of the month. Like usage from Jan 15 to Feb 14 is billed on Feb 15. At the end of Jan, we need to recognize revenue based on usage data which is from Jan 1 to Jan 31. If we will base it on invoice, then the only revenue that will be recognized is from Jan 1 to Jan 14 (billed on Jan 15). Jan 15 to Jan 31 (together with Feb 1 to Feb 14) are yet to be billed on Feb 15.
@Jim Merrill, yes that is correct. There is a lag. That is what we thought of initially. Book a JE or a custom transaction that debits unbilled AR and credit revenue. Then, upon invoice, debit AR and credit unbilled AR (direct revenue posting). I just haven't thought about the reconciliation though.
k
oh, then you definitely need ARM and that’s why you have it is. So, book your usage (say, for each day or once) using SO; then recognize revenue (rev rec journal) using fulfillment trigger (create rev plans on) setting; then invoice. the issue of course is a bit exacerbated by using multiple systems for various functions; ideally you want to create invoices in NS and then sync them into AWS/else. You need invoice to collect payment.
DO NOT book manual journal entries into ARM related accounts, it is impossible to untangle
l
@Karina that totally makes sense. When you said item fulfilment, that rang a bell. I think we are hesitant because of the volume of transactions. If we use ARM, we have SOs + Item Fulfillments + Rev Rec JEs + Reclassification JEs + Rev Rec Arrangements + Rev Rec Plans, there's too many records for something that is initiated outside of NS through different subscription, billing and payment platforms. If all of these are initiated in NS, it would be easier to accept our fate to use ARM. That's why we're leaning towards "direct revenue posting" or using a transaction (custom or JE) that debits unbilled AR and credits revenue. Then, our invoices would contain direct revenue posting items and debit AR and credit unbilled AR. Or whatever the more appropriate way if ARM is not used.
k
Well, I hear you, @Luis, it is a valid point about numerous transactions. i am not sure how you can avoid recognizing revenue though without booking an invoice if you are not using ARM. why have NS at all if do everything manually 🙂. At the same time you can set your process up to work without a human touching it, wouldn’t you like it 🙂.
l
@Karina to avoid recognizing revenue when booking an invoice but not using ARM, shouldn't we just create an item with direct revenue posting box checked and "income" account of unbilled receivable/accrued income? Even if we don't use ARM, there will be no manual intervention as well since the data would just come from the external systems via integration.
k
yes, @Luis you sure can, but then you have to clear your unbilled revenue, so that would be a journal.
l
Thanks, Karina. We'll discuss it more internally but your input related to item fulfilment was very helpful.
🙏🏻 1
Hi @Karina and @Jim Merrill, again thank you for your help above. We decided to go with the SO-IF approach. I'm just wondering with regard to migration of existing subscriptions/SOs into NS. We want to be able to keep track of the original subscription details of existing contracts that are not yet expired/closed. That being said, I guess we should migrate the SOs with the full contract amount and allowed usage (quantity). Obviously, a portion of that has been recognized as revenue and billed already (revenue may not be equal to billed amount). What is the usual approach here? Is it going to be something like this? 1. Migrate all existing SOs/subscription contracts with full amount and quantity. 2. Generate one Item Fulfillment representing the usage per SO. 3. Generate one Invoice representing the billed amount per SO. 4. Generate the Rev Rec JE as of the cutoff date. 5. Reverse the Rev Rec JE and Invoices via a JE. 6. Generate Rev Rec Reclassification JE which should reflect the correct Unbilled Receivable/Accrued Income as of the transition date. 7. Any discrepancy between the recognized revenue (manually) vs. what NS calculated using ARM as of the transition date, we can just true up via a JE.
k
Hi Luis, hurray to you guys! Steps 1 through 4 - yes. For step 5 - yes to reversal of revenue already recognized in the same period in step 4, no need to do anything about invoices since they are already booked legitimately. Step 6 should really be step 5 and step 5 should really imo. Step 7 - yes, match your subledger details balance to ledger/TB balance
l
Thanks, @Karina. But we previously booked the invoices (non-ARM). That's why I thought we would reverse the invoices as of the transition date to ARM.
k
oh, if that is the case - yes, sure, you can do that, and you will get the benefit of linked transactions by creating invoices from SOs systematically (just do not forget to disable emailing 🙂 )
l
Great! Thank you
k
you are welcome, Luis!
👍 1
l
Hi Karina, I'm sorry but I'm going to have another question related to the above. I was informed that there may be cases where a subscription contract for 1,000 hours for USD 100,000/year is not technically a fixed contract. The revenue to be recognized is no. Of used hours x current price for the month which could be 110/hr, 105, etc. as opposed to the straight line 100/hr. Is this still possible via item fulfilment? Do we have to use Quantity as dollar amount and have a rate of 1, so that we can define the any revenue amount via the quantity field? Or is this a use case for fair value pricing?
k
sure, Luis, the best part about fulfillment is you can fulfill as many hours as you want out of the contract. I have never had a predicted or even number of hours or other units ever for fulfillment.
l
As far as I know, the revenue recognized based on item fulfilment is proportional to the SO amount? Or how would NS know how much to recognize based on the number of hours only? Is it no. Of hours or quantity x rate per unit from the SO (which assumes that it's fixed)?
k
Say, you sold 100 hours at $50/hr. First month you consumed 25 hr; you fitful 25 hrs, you recognize revenue for 25 hrs (25 hrs x $50) of $1,250. Next month you fulfill 10 hours. you recognize revenue for (10 hrs x %50) of $500. etc. The fun part is when you need to make sure you fulfill all sold hours. But that is another story 🙂
every time you fulfill NS knows to create rev plan for this fulfillment. You have to book your journals to recognize revenue, but it is available if you fulfill
l
The challenge is it's not always based on a fixed rate. One month it could be USD 50, next month it could be 51, then month after that could be 52
k
oh, I see. Variable price. What does the contract/performance obligation say? If you knew the variability at the time of the contract inception you could set it a a separate line. If this is not available each fulfillment must become its own contract and a separate SO 😞
that complicates things a great deal. But honestly something is off here re: revenue recognition. what i mean is if you have a contract then the prices must be determined at that time. even if a price is variable it still needs to be determined and conditions when it is X and when it is Y. If you have it then you can set up a SO for the duration of the contract. If not then you need to be creating those SOs as the fulfillment comes in 😞
l
Hi @Karina, when a new customer signs up, there's an effective price of course but it may change in the future. We don't know when. We also don't know how many hours would be utilized because it's based on actual usage. I know you mentioned about separate SO per fulfilment. But what quantity should we use in the SO if we don't know that yet because it's based on actual usage? Do we put a dummy high quantity or no. Of hours? We can't wait until the end of the month which is when we know the actual usage to create the SO. This is because we invoice the customer in the middle of the month.
k
yes, it is a problem, @Luis Essentially ASC606 says that price must be determined to recognize revenue, and in your case you cannot “predetermine” it sounds like; thus, you have only one option - recognize revenue at the time you know the value. But that to you means you cannot preset contracts, cannot defer your revenue, etc. ARM does not accomodate this at all 😞 - sorry…
l
@Karina thank you for your inputs though. By any chance, do you know if projects, charge based billing to SuiteBilling would help?
k
well, you are saying you invoice at X date and then recognize revenue at Y date which is after X date. Assuming this you do know your rev at the time of invoicing. You may be able to use charge based projects where you bill when you know what to bill (say fixed fee) and then set your rev to recognize later for that fixed fee. I am not sure what quantity you are speaking of here, sounds like a lot, no sure if a lot of quantity translates into a lot of different set up. Imho, modifying contracts with customers to establish the price at the inception of the contract (say customer signing to consume hours in the future) would save you a lot of time and effort
l
By quantity, I mean the no. of hours used by the customer which is the basis of our revenue. No. Of hours used x effective price for the month
k
right. so the only way to do it is to create those engagements every month for the known quantity because your price changes. which still needs ARM because you book and recognize rev in different times. May I ask out of curiosity why the heck your price fluctuates??? does it relate to FX rate, for example? Cannot think of anything else, that’s why I am asking
l
Considering what you said above, it looks like we're going to create an SO at the time of billing during mid-month for new contracts with the usage as of mid-month. Then, at the end of the month, we'll add a new line to the same SO for the usage for the latter half of the month. Then, next mid-month, we'll add another line again to the same SO for the first half of next month. And so on and so forth. In short, we have one SO line every around 15 days. I probably won't need to use item fulfilment and would just use the Revenue Element Start Date and End Date to determine when we should recognize revenue. Would save us some transaction lines and step. On another note, our price increases almost once every quarter. Just your typical price change. Another example is if the fees that our billing platform charge us also increase, that might result in increased customer prices as well. "Passing on" to the customer.
k
yes, I agree, this is best solution under the circumstances.
12 Views
Open in Slack
PreviousNext
Powered by