In this article:




Invoices vs. Subscriptions


Natero treats subscriptions and invoices as two separate things. Generally invoices are generated to request payment for a subscription while subscriptions tell you what plan your customers are on and what that plan is worth on an ongoing basis. In Natero, we use subscriptions to set MRR/ARR, and renewal dates.  


Invoices are typically used for reporting purposes, e.g., who has paid, who has not yet paid. As such, the recurring/non-recurring fields on invoices are purely informational and only for that invoice; and it further helps you segment your invoice data (they do typically map to subscriptions). Non-recurring revenue is typically for one time fees or items. In Natero, you may set these as you prefer. However in Natero, we do not keep a mapping between invoices and subscriptions.


While invoices don't provide a data range over which they are valid, subscriptions do. Every subscription needs a start date, and if the subscription has ended, it can have an end date.


Visual__Invoices_vs_Subscriptions.jpg



Mapping Transactional Revenue


For non-transactional businesses the mapping between invoices and subscriptions tends to be clear. For transactional businesses, the invoicing tends to be clear, but what should be included in the subscription isn't always as clear. What Natero usually recommends is one of the two approaches listed below:


Option 1


Record each month's total recurring revenue and transaction revenue as a single subscription's revenue and update that every month based on changes in transaction revenue. The advantage of this approach is that the "current MRR" value matches with the most recent month's actual revenue, which makes it easier to understand the current value of an account.


The only potential downside of this approach is that month-to-month variations in transactional revenue will likely result in account expansion and contraction virtually every month, so depending on how you want that to be reported, it might be a good thing or a bad thing.


A slight variation on this approach is to maintain two subscriptions on each account, one for the stable recurring revenue and one for the transactional revenue. Natero will show the same total current MRR from the two subscriptions, but it changes the reporting slightly when looking at per-subscription expansion/contraction numbers.


Option 2


Record only the recurring revenue in subscriptions and exclude any transactional revenue, only recording it in the invoices. This can work well when transactional revenue is a small percentage of your revenue and isn't as important to reporting and you want to avoid constant month-to-month expansion/contraction being shown on accounts.



Subscription Data via Account API


When sending subscription data using the Account API, most customers typically use the 'current' event type for subscriptions. In this mode, you just provide the current start and end date for the subscription (end date may be in future, or may not be set if open ended).  Then either nightly, or when the subscription changes, you send another current event noting the start and optionally end of the new subscription with the new amount.  


We calculate MRR by looking at the total_revenue and normalizing it to a month based on the cycle unit and cycle length (E.g., 1200 total revenue with a cycle unit of month and cycle length of 12 will give a 100 MRR value). Every time we receive a current event, we'll update the subscription history if it has changed for that account.


One thing to keep in mind is to ensure that your subscription IDs remain the same across renewals of the same subscription (so if one ends and another starts), if they are the same subscription, they should have the same subscription ID.  We use the subscription ID to build the history for that subscription and report New and Lost MRR.



Handling of Currencies


Natero supports displaying financial data in your local currency (currently there is no UI to set that, you need to contact us to set the local currency). Note that only one local currency can be selected, if you capture multiple currencies, we recommend that you normalize them to a common currency, since otherwise reporting on aggregate revenue values become wildly inaccurate.


When we are doing the sync from 3rd party systems we check the day's exchange rate and use that for the conversion only if it has changed more than 5% of the existing rate, it is recommended that you do something similar.