Subscription Revenue Recognition with Stripe and NetSuite

Integrate Stripe's Subscription billing system with NetSuite. Pull all sales data into NetSuite and leverage NetSuite's revenue recognition engine for recurring monthly plans.

NetSuite Revenue Recognition is especially helpful for subscription businesses looking to spread earned income over multiple accounting periods. Stripe's Subscription billing period data is pulled onto the NetSuite invoice on the line-item level.

This feature is a good fit for organizations that have purchased NetSuite's revenue recognition module, and have subscription plans in Stripe that span multiple periods. Here are the key benefits:

• Since Stripe maintains a record of the customers, invoices, line items, etc there is no additional integration work required. Integrating Stripe subscriptions is turnkey and does not require any engineering resources.
• Stripe handles plan changes, prorations, coupons, trial periods, etc. All of these subscription features are cleanly integrated into NetSuite.
• Each invoice line item in Stripe contains the period which that revenue should be earned over. This is pulled over to Stripe, fully automating the rev rec workflow in NetSuite.

Both NetSuite's Advanced Revenue Management (released in 2016) and old revenue recognition module are supported. Most of the documentation below refer to specifics in the old engine.

It is possible to import revenue recognition data (the revenue period for a specific line item) into NetSuite without purchasing NetSuite's rev rec engine and recognize revenue manually.

How revenue recognition works

1. During the integration setup process you will provide the deferred revenue account and revenue recognition template (more on this later) you'd like to use. In the new rev rec engine, you'll specify a rev rec rule on the NetSuite item.
2. Plans are setup to post against the specified deferred revenue account and use the revenue recognition template (or rev rec rule) specified.
3. Coupons and discounts are represented as non-posting discount items. A non-posting item does not post to an income account, but instead gets "bundle into" the other NetSuite item it's associated with. In the context of rev rec, when the parent product in the NetSuite invoice is calculating it's rev rec impact is subtracts the non-posting discount amount.
4. When a Stripe subscription creates a invoice, it specifies a period start and end date. These dates are copied over to the NetSuite invoice on the line item level. The revenue template or rev rec rule is configured to pull from the line item level.
5. When a refund (partial or full) is created for a invoice, the CreditMemo created against the Invoice follows the same revenue recognition schedule.
6. Each accounting period, a "revenue recognition journal entry" is manually created in NetSuite. When this occurs, revenue moves from the deferred revenue account to your earned income account.

A couple details that may be helpful:

• When a NetSuite transaction is created based on another transaction (e.g. an invoice created from a sales order, a credit memo created from an invoice), the rev rec schedule is copied directly from the original transaction. However, as this is a point-in-time copy, any subsequent changes to the rev rec schedule on the new transaction are not reflected on the original source transaction. This is true even if a rev rec journal entry has not yet been generated for this original transaction. For example, let's say there's an invoice created in your NetSuite account with a rev rec schedule of Jan 1st-June 1st. If you create a credit memo for that invoice on February 15th, and manually update the rev rec dates on the credit memo, the rev rec dates on the invoice will not be changed. Here's more information
• Each line item on a Stripe Invoice contains a period start and end date. Depending on your NetSuite configuration, these line-item level period start and end dates are copied to the NetSuite invoice line item's start and end dates. This can cause an individual line item's period to be different than the header-level invoice's period.

Here's an example of a Stripe-generated subscription invoice created with revenue recognition enabled:

How Revenue Recognition Period Start & End Dates are Calculated

Stripe and NetSuite define the revenue date range differently. Stripe defines the date range as "up to" the last day, or, End date < X. Whereas NetSuite's defines the date range as "through" the last day, that is, End date ≤ X.

Therefore the last day of the revenue period in NetSuite is one day less than the corresponding end date of the revenue period in Stripe to fit NetSuite date range definition.

Example GL Impact

Consider this example:

1. $120 Invoice is created in January with a 12 month, straight line, by period rev rec schedule
2. January accounting period is closed
3. February accounting period is open
4. CreditMemo for the January invoice is created March 15
5. Rev rec journal entry is made for Feb on March 16
6. Feb accounting period is closed on March 17

Here's what the GL impact will look like over time:

The rev rec on the credit memo retains the rev rec start and end dates from the invoice and 'attempts' to offset the revenue over the same period (thus negating the full or partial balance from the invoice). If the periods are closed, then it does 'catch up' in the first open period and then recognizes the remainder over the same period.

The records affecting your cash accounts are not split over multiple periods and do not come into play with NetSuite's rev rec functionality. Here are records which affect cash accounts:

• CustomerPayment
• CustomerRefund
• Deposit

The GL entries created by these records affect the period in which the payment/refund/deposit occur. They are not affected by the rev rec functionality.

Switching, Changing, or Refunding Subscriptions

There are many cases where a user will want to upgrade, downgrade, or add seats to the plan they are subscribed to. From a revenue recognition perspective, plan downgrades (decreasing the number of seats, or switching to a lower plan) need to be considered carefully to ensure the downgrade is properly represented in NetSuite.

How subscription changes are handled in Stripe

In addition to the explanation below, Stripe offers a great overview on how plan changes are handled in Stripe.

Plan upgrades are very straightforward: the customer is charged for the difference between the unused time proration of the current plan and the cost of the new plan.

Plan downgrades are trickier. If the new plan cost is less than the current plan, a balance is added to the customer in Stripe. The customer is not refunded the difference. The difference (essentially a credit for the unused amount of the original plan that was paid for) is applied to the user's next invoice.

When the next billing period occurs, the customer balance is used to pay for the invoice. This results in a credit memo against the invoice for the amount of the customer balance. If the customer balance is larger than the invoice amount, the customer balance will be used to pay for subsequent invoices as well.

In this flow, the Stripe and NetSuite invoice for the initial invoice is not modified. The revenue on the initial invoice will continue to be earned over the billing period specified for that invoice. The revenue for the new invoice will be earned over the new subscription period.

How subscription changes work with NetSuite

Here are two examples demonstrating the most common use cases we've seen:

1. A customer accidentally signed up for a yearly (or other multi-period plan) and wants to switch to a monthly plan.
2. At some point during their subscription, a customer decides they want to switch from a yearly to monthly plan.

Here are the three approaches to handling plan changes in Stripe:

1. Fully refund the yearly subscription, cancel the yearly subscription, and create a new monthly subscription.
2. Partially refund the yearly subscription for the prorated unused time on their subscription, cancel the yearly subscription, and create a new monthly subscription.
3. Change the yearly subscription to a monthly subscription.

Depending on how you want to recognize revenue in NetSuite, you'll want to use different approaches:

• In case #1, if you don't want any revenue recognized for the yearly plan, use approach #1.
• In case #1, if you want to partially recognize revenue on the monthly plan, use approach #2.
• In case #2, use approach #2
• In case #2, approach #3 is easiest from a development perspective but has certain restrictions/limitations. If you are interested in using this approach, contact us to talk it over in detail.

Refunds and Credit Memos

When a refund (full of partial) is created for a Stripe subscription's invoice, a CreditMemo and CustomerRefund is created (more info on this process). The CreditMemo copies the exact rev rec schedule on the invoice it was created from, regardless of revenue already earned on the Invoice.

For example:

• An Invoice for $120 was created in September with a 12 month straight line by accounting period rev rec schedule.
• September accounting period is not yet closed
• The current date is October 15
• A CreditMemo is created for the total amount of the invoice created in September

In this case, the CreditMemo's rev rec schedule is the same as the invoice's schedule despite being created in a separate month.

This means that the CreditMemo will contain a refund of $10 for September and $10 for October.

How closed accounting periods affect earned revenue

When using revenue recognition, open accounting periods affect how CreditMemos refund revenue is earned over time.

In the case of the above example, if the September accounting period was closed before the CreditMemo was created the September refund revenue would be moved to October. You would see two identical entries for October in the CreditMemos rev rec schedule.

It's important that the revenue recognition journal entries are created right before closing the period. If this is not done, any refund revenue for CreditMemos created after the last rev rec journal entry for Invoices with revenue earned in the closing period will not be accounted for. Revenue in the period about to close will not move out of the deferred revenue account and it will look like rev rec is attempting to book revenue for a month that is already closed.

Credit Memos Created by Customer Balance

Payments against an invoice by a customer balance are represented by a credit memo. The credit against the invoice will be recognized using the same schedule as the invoice since the credit memo 'copies' the invoice's rev rec schedule.