How does ARM work with evergreen subscription term...
# arm
a
How does ARM work with evergreen subscription terms in SuiteBilling? Can ARM be configured to go off of invoices or must they work off of subscriptions when configured with SuiteBilling?
c
With evergreen SuiteBilling subscription, ARM tracks the "end date" to be the date of the charge with the max bill date, which is auto-created up to 3 years out if I recall correctly. You can ALWAYS do rev rec off of invoices, if you configure it right, even when SuiteBilling is being used. But then you don't get all the behavior around contract modifications - which may either be good or cause trouble with ASC606 depending on your specific situation.
a
thanks! sounds like i need to test rev rec on invoices with the 3 year evergreen term and then test evergreen terms that are more inline with our auto-renew terms and run it off the subscription, yes?
c
Depends. Let's break this into two sections:
1. Having ARM run off the invoice (i.e recognize as billed). This is controlled by the rev rec rule on the item, and can be used even if the item is in a subscription plan. Rev rec rule should have start/end date source as Event Date, and item should have Create Revenue Plans On of Billing.
2. Picking terms for SB/ARM
Do you want revenue to adjust when the contract is modified (i.e it's renewed or they up/downgrade)?
a
Yes, we will. Does that mean if I run rev off the subscription/contract then it will auto merge the arrangements?
c
It won't create multiple arrangements to start with. The subscription will be the revenue source instead of the SO.
a
ahh ok
c
This can get pretty complicated, but look here for an overview: https://netsuite.custhelp.com/app/answers/detail/a_id/62997/
a
so my concern was around the evergreen term because we have either monthly or annual plans so i thought if we use the three year evergreen term then that won't match up with how our business is run
c
Key note: There's a setting which controls how Revenue Elements behave when a subscription is modified. Don't play with it unless you are prepared to refresh sandbox as it is an irrevocable choice
👍 1
a
so while are plans are still evergreen they are renewed monthly or yearly.. that being said that means it makes more sense to change the terms right?
c
What are your actual contract terms? Is it 12 month term auto-renewing for 12 months?
Is the term actually different or just different billing frequencies?
a
questionable. we bill monthly for "monthly" subscribers and bill annually for annual but they are all evergreen contract terms
so i think it can be argued either way
c
when can the customer cancel?
a
whenever they want
c
anytime or only at end of billing period?
a
anytime for annual
end of the period for monthly
c
Have you looked into using renewal behavior in SB? I'm not recommending, necessarily, as it depends on exactly how you need to do rev rec. But you could have a 12-month (or 3 year, or whatever) term, which renews by extending the end date of the existing subscription at the end of the term.
a
let me rephrase: if they cancel an annual they will get a prorated refund. if they cancel a monthly they get no refund if in the middle of the period
RE: the renewals, isn't that what an evergreen subscription term is for?
so that it auto-renews?
c
No - you can also auto-renew a fixed length term, either by spinning off a new subscription, extending the existing subscription, or even creating a sales transaction if you did negotiated renewals.
a
thanks a bunch. implementing SB and ARM at the same time is going to be a lot of fun
c
or you can do evergreen
It's really my favorite thing 😄
I guess I would say that you really need a clear understanding of how you want to recognize revenue (esp what should happen when a subscription is modified with a cancellation or an upsell) in order to choose the optimal settings for the subscription plans
They are interlinked
a
so glad you mentioned that. was having trouble deciding which module should be built around which. and it sounds like SB should be built around ARM?
c
Yes, I think that's a good way to put it. The combo of the two supports a lot of variations in behavior, but it's the rev rec that will be closely scrutinized by auditors. There are likely to be more ways of getting billing right than getting rev rec right.
Make sure you test a lot of modification scenarios before you settle on an approach.
a
yes, definitely. I can tell it's going to be needed. thanks again!
c
Anytime