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
- 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.
- Plans are setup to post against the specified deferred revenue account and use the revenue recognition template (or rev rec rule) specified.
- Coupons and discounts are represented as non-posting discount items.
- 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.
- When a refund (partial or full) is created for a invoice, the CreditMemo created against the Invoice follows the same revenue recognition schedule.
- 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 transaction (invoice, credit memo) is created it "copies" the specified rev rec schedule. Any changes to the rev rec schedule are not applied to past transactions even if revenue has not been associated with a rev rec journal entry.
- 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:
Example GL Impact
Consider this example:
- $120 Invoice is created in January with a 12 month, straight line, by period rev rec schedule
- January accounting period is closed
- February accounting period is open
- CreditMemo for the January invoice is created March 15
- Rev rec journal entry is made for Feb on March 16
- Feb accounting period is closed on March 17
Here's what the GL impact will look like over time:
|NetSuite Action||GL Impact|
|January Invoice||Debit $120 A/R
Credit $120 Deferred Revenue
|January CustomerPayment||Debit $120 Undeposited funds
Credit $120 A/R
|March CreditMemo||Credit $120 A/R
Debit $120 Deferred Revenue
|February Rev Rec||
Credit $20 Deferred Revenue
Amount is $20 because January is closed, to the earned income in January is grouped into February (the next open period) on the CreditMemo's rev rec schedule.
|March Rev Rec||
Credit $10 Deferred Revenue
April through Jan will experience the identical GL impact.
|March CustomerRefund||Credit $120 Undeposited Funds (Deposits in Transit)
Debit $120 A/R
Debit $120 Deposit in Transit
Assuming this deposit only contains the CustomerRefund associated with the CreditMemo.
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 effecting 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 effect cash accounts:
The GL entries created by these records effect the period in which the payment/refund/deposit occur. They are not effected 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:
- A customer accidentally signed up for a yearly (or other multi-period plan) and wants to switch to a monthly plan.
- 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:
- Fully refund the yearly subscription, cancel the yearly subscription, and create a new monthly subscription.
- Partially refund the yearly subscription for the prorated unused time on their subscription, cancel the yearly subscription, and create a new monthly subscription.
- 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.
- 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 effect earned revenue
When using revenue recognition, open accounting periods effect 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.