The Complete Handbook For Choosing the Right Subscription Billing Service ACTIVATIONS SIGNUPS Automate BILLING NOTIFICATIONS USAGE PROVISIONING
Customers exploring recurring billing solutions should look beyond their immediate needs to ensure they choose a platform that meets their long-term needs. This paper will help you assess the range of features required for metering, billing, and collecting. 1
Contents 1 Overview 4 2 Pricing and Packaging 5 2.1 One-Time Charges 5 2.2 Recurring Charges 5 2.3 Fixed Recurring Charges 5 2.3.1 Volume Based Recurring Charges 5 2.4 Usage-Based Charges 6 2.5 Timing of Usage Based Charges 6 2.6 Free Trials 6 2.7 Usage Processing 7 3 Rating and Billing 8 3.1.1 Creating Invoices 8 3.1.2 Adjustments 8 3.1.3 Billing Automation 8 3.1.4 Multi-Channel Delivery 9 4 Payments 10 4.1 Multiple Payment Types 10 4.2 Ad-Hoc Payments 10 4.3 Scheduled Payment Runs 10 4.4 Payment Gateway Integration 10 4.5 PCI Complance 11 4.6 Failed Payments 11 4.7 Overpayments and Credit Balance 11 4.8 Refunds and Chargebacks 11 4.9 Overview 12 4.10 Customer Account Creation 12 4.11 Free Trial Accounts 12 4.12 Customer Account Maintenance 12 4.13 Updating Credit Cards 12 4.14 Cancelling Accounts 13 2
5 Subscription Management 14 5.1 Creating a Subscription 14 5.2 Creating Multiple Subscriptions 14 5.3 Adding Products to Subscriptions 14 5.4 Removing Products from Subscriptions 14 5.5 Updating Products in Subscriptions 15 5.6 Changing Subscription Terms and Conditions 15 5.7 Suspending Subscriptions 15 5.8 Cancelling Subscriptions 15 6 Web Self-Service 16 6.1 Account Creation and Initial Purchase 16 6.2 Viewing Information 16 6.3 Updating Information 16 7 Reporting and Metrics 17 8 Accounting System Integration 18 8.1 Integration Options 18 8.2 Accounting Close Process 18 8.3 Revenue Recognition 18 1-888-519-1425 19 3
1 Overview The increasing use of subscription billing creates significant challenges for back-office systems. Billing systems and processes need to respond to a shift from one-time transactional charges, to ongoing recurring charges and subscription management. This document is intended to help you assess the range of features required in your systems, for metering, pricing, billing and collecting. 4
2 Pricing and Packaging The ability to rapidly define and introduce new price packages is key, and many companies stagnate in the market when the billing system becomes a bottleneck to creating new plans. Whether your goals are to better segment customers, improve cash flow, up-sell additional offerings, or prevent abuse, pricing and packaging is an effective strategic enabler. This section outlines a variety of pricing and packaging approaches that your billing system should support. Price plans are built from three kinds of charges: one-time, recurring and usage based charges. 2.1 One-Time Charges Most often used for a setup fee, one-time charges are also frequently used during the customer life cycle for professional services, training, access to support teams, etc Onetime charges are frequently optional. 2.2 Recurring Charges Recurring charges are charged based on a defined time interval. Different time intervals for the recurring charges, such as weekly, monthly, quarterly, or yearly, should be supported. Your system should also support additional complexities, such as when the recurring charges are calculated (e.g., 1st of the month vs. anniversary date) and what proration rules apply (e.g., for partial months). Typically, recurring charges for a time period are charged in advance. Different types of recurring charges must be supported. 2.3 Fixed Recurring Charges Recurring charges might be fixed a flat fee that gets charged each month to customers. This is commonly seen in consumer applications, for example, charging $10 per month. 2.3.1 Volume Based Recurring Charges Recurring charges might also be variable a charge calculated by multiplying units purchased (e.g., application users) by a set price, with the purchase volume determining the unit price. The unit price may also vary with volume (see below). These pricing structures are commonly seen in B2B applications in which volume pricing is negotiated when a contract is established. 5
2.4 Usage-Based Charges Usage based charges are calculated based on the use or consumption of a service, and can vary each month depending on actual usage. Generally, price plans include an allocation of included usage, with incremental charges for usage above the allocation. There are four typical variations of usage charges: 1. Standard: uses a set price per unit of usage, which does not vary with volume. 2. Tiered: the incremental unit price is set per range of usage (e.g., 1-20 = $2; 21-40 =$1) 3. Stairstep: The unit price for all usage is determined by the overall volume; typically used for volume purchases. 4. Volume: Provides a range of usage for a fixed price (e.g., up to 10 users allowed for$100). 2.5 Timing of Usage Based Charges Usage based charges are typically charged in arrears, with rating and billing at the end of the period when usage is known. Account level credit limits should be used to limit exposure to credit risk or fraud. Pay-as-you-go charging, which charges the account as usage is incurred, is commonly used to limit exposure to credit risk. To avoid small, frequent charges to a credit card, a billing threshold account setting should be used to accumulate charges until the threshold is reached. Top-Up charging models require the customer to purchase an allocation of usage in advance; the account is recharged when actual usage consumes all or most of this initial purchase. This approach avoids any credit risk. Volume plans can also be charged in advance. 2.6 Free Trials Particularly in SaaS (software-as-a-service) cloud businesses, you may offer customers a free trial to evaluate your service prior to converting to a paying account. Some configurations that your commerce system should support are: Whether a credit card or other method of payment must be provided before the free trial can begin Customization of the free trial duration Reminder notifications as the free trial is about to expire. 6
2.6.1.1 Promotions and Coupons To help convert prospects to customers, you may also choose to offer marketing promotions, which can be time-based (e.g., 50% discount for the first 3 months), volumebased (e.g., tiered pricing, whereby additional units become progressively cheaper), or both. 2.7 Usage Processing 2.7.1.1 Overview With your usage-based pricing models, your commerce system will need to be able to meter actual usage as it occurs to track what has been consumed and by whom. 2.7.1.2 Metering Your business must be able to track what has been consumed and by whom. Typically, this information can be obtained from the monitoring software of your underlying infrastructure, but you will need to structure usage records in a consistent manner for your commerce system. Each usage record should minimally have the following: Date and Time: when did this usage occur? Unique Customer ID: Who consumed the service? Unit of Measure: What was consumed? Amount: How much was used? Your commerce system must own the aggregation of all usage data across your multiple infrastructure systems, as well as the billing of customers against that data. In that way, your infrastructure stack need only measure and record the above usage data, rather than being burdened with additional commerce complexity as well. 2.7.1.3 Usage Collection and Integration Your commerce system will need to integrate with your infrastructure layer to pull the underlying usage data. Initially, and at small scale a manual integration process can be used but later automation is key to avoid errors and bottlenecks. 7
3 Rating and Billing Rating refers to the process of translating metering data into invoice items for a customer, based upon the chosen pricing plan. Your system will need to provide a rating engine that can calculate these charges based upon usage data over time. In some instances, you may need your system to be configurable as to how the rating calculations are performed. Billing is the process of creating an invoice for customers on a recurring basis according to the pricing plan they have selected, their usage during that time period, and any discounts that may apply. This section outlines the key requirements for a cloud-based billing system. 3.1.1 Creating Invoices Your commerce system will need to generate invoices for customers, indicating the payment that is due. Invoices should be itemized to show one-time charges, recurring charges, and line-by-line usage-based charges. In some situations, you may decide not to present an invoice to certain customers, particularly ones that are billed automatically each month via credit card. Even for such customers, it is important to create an invoice for your records, for presentment to customers if requested, and for legal requirements in some countries. 3.1.2 Adjustments Your system should permit you to make adjustments to invoices. There are two types of adjustments that you will typically make: Invoice-level adjustments: allow you to credit (e.g., for customer service reasons) or debit (e.g., for added late fees) an invoice after it has been created. Line item-level adjustments: allow you to credit or debit against a specific line item charge on an invoice (e.g., to reverse out a charge that was not really incurred). 3.1.3 Billing Automation Revenue leakage occurs in manual systems when recurring charges get missed for example, when an annual service charge is not applied properly. Automating invoicing and billing makes this an always on process which automates account charging, communication and collections on a pre-determined cycle. 8
3.1.4 Multi-Channel Delivery Invoices need to be delivered to customers by email, and posted to a web self-service portal. They also need to be readily available to support agents who deal with customer inquiries Note that some clients that are automatically charged by credit card may not need to receive invoices. 9
4 Payments This section outlines the key items your commerce system will need to accommodate in order to process payments and accelerate your cash collection. 4.1 Multiple Payment Types Your customers will likely request to pay in different ways, so it is important that your commerce system support the key payment types: Electronic: These payments are typically electronic bank transfers (e.g., ACH) or credit card transactions that are made with a direct connection between your billing system and the electronic payment processor. External: These payments, such as paper checks or wire transfers, are processed outside of your commerce engine and must be recorded against an invoice back in the billing system. 4.2 Ad-Hoc Payments Generally customers remit an invoiced amount on a regular basis. However, your system should still support the processing of ad-hoc payments that customers may make. For example, if a customer did not pay you the full invoice amount in a previous statement period, you may need to process an ad-hoc payment to cover the outstanding balance. 4.3 Scheduled Payment Runs For customers that pay electronically, your system should accommodate the scheduling of automated payment runs that charge their accounts or credit cards at a regular, recurring time interval. 4.4 Payment Gateway Integration In order to accept credit cards and electronic checks, you will need a relationship with a payment gateway (e.g., PayPal, Authorize.net, Moneris) to authorize transactions. Your commerce system must be able to integrate with the payment gateway you have selected in order to automatically charge the credit cards of your customers on a recurring basis. Your commerce system should also allow you to change gateways seamlessly, so your end customers do not need to re-enter their credit card information when you add or change a gateway contract. 10
4.5 PCI Compliance If you intend to process credit cards as a method of payment, best practices will dictate that your commerce system be PCI compliant, thereby achieving a level of security that meets the standards of the Payment Card Industry (PCI) and giving your customers comfort that their credit card information is protected. PCI compliance involves network and system security approaches, as well as rigorous adherence to process. 4.6 Failed Payments When you schedule automated payment runs, your system should allow you to define how many times you want to retry failed transactions on a specific credit card. For example, you may define up to three additional attempts, and designate that a specific amount of time (e.g., 12 or 24 hours) must pass between retry attempts. In addition, your system should provide you and your customer with automated notifications should all retry attempts ultimately fail. 4.7 Overpayments and Credit Balance Customers will sometimes overpay the amount due, for example, by rounding up a check or erroneously paying more than the current invoice amount. In these situations, your commerce system should allow you to accept these overpayments and hold them as credits for the customer that can be automatically applied against future usage of your service. With support for credit balances, your business can avoid many time consuming refund processes. 4.8 Refunds and Chargebacks Customer refunds are needed for example, for overpayments or perhaps for unmet service level agreements. In addition, your system should be able to support chargebacks, which are funds needing to be returned to customers for contested charges. Customers typically request chargebacks for fraudulent purchases made on their credit cards, clerical errors (e.g., duplicate billing), or services purchased but never received. Account Management 11
4.9 Overview This section discusses key system requirements regarding the creation and maintenance of customer accounts. 4.10 Customer Account Creation When creating a new customer account, your system should only collect information you absolutely need, to keep the process short and minimize customer abandonment. Information typically required will be: name, password, key contact and billing information, and payment information. 4.11 Free Trial Accounts If your business offers a free trial period, you will need to decide whether your system will collect credit card information prior to starting the free trial. Prior collection of credit card information will likely lower your free trial customer acquisition rate but increase your conversion rate from free to paying customers downstream. Testing both approaches is a good way to measure which approach works best for your business, and so your system should accommodate such experimentation 4.12 Customer Account Maintenance Your system should allow your service agents and customers to access a customer account and modify its details. In addition to the information entered during account creation, your system should also likely allow for the editing of the following customer account details: Locale: information about the customer s time zone and date format preferences Currency: the currency that is used to charge the customer Tax Exemption: a customer s tax exemption status (typically not editable directly by a customer) Payment Terms: you may want flexibility to offer both net 15 or net 30 terms (typically not editable directly by a customer) Payment Methods: your system should ideally support entry of multiple payment methods, in addition to selection of one default payment method Additional Contacts: for example, you may want to store different bill to and sold to contacts for a particular customer. 12
4.13 Updating Credit Cards Subscription charges typically require that a credit card be maintained on file for the duration of a subscription. Once a credit card is on file, there is the possibility that the credit card will expire or the cardholder will cancel her credit card. Proactive notifications to customers via e-mail and alerts on your web portal are needed when their credit cards are about to expire. This proactive, automated approach will reduce the number of failed payments and ultimately improve your cash flow. 4.14 Cancelling Accounts Your system will need to support cancellation of customer accounts. Customers should be able to cancel accounts in a self-service manner, and your support representatives should also be able to cancel accounts, either at a customer s request or for other business reasons such as non-payment or fraudulent use. To reduce revenue leakage you should ensure: Before canceling an account, your system should cancel all of the customer s subscriptions and verify that all due invoices have been paid or adjusted. The system should prohibit further subscriptions from being added to a canceled account. The system must ensure that any remaining usage prior to account cancellation gets billed to the customer in the next billing cycle. Optionally, you may consider having your system cancel all of a customer s subscriptions but keep the customer account active, so the customer can reengage without friction at a later date, with her existing account information still intact. 13
5 Subscription Management When a customer purchases one of your cloud offerings, your system will need to create a subscription for that customer, defining what has been purchased, by whom, over what time horizon, and at what pricing rate. This section outlines the various requirements your commerce system will need to support both in creating subscriptions and in managing changes against it throughout a customer s lifecycle with you. 5.1 Creating a Subscription Your commerce system should create a subscription when a customer makes a purchase from you. Some key information that should be captured in a subscription includes: Customer Name and ID: identifying the customer who made the purchase Initial Term: the duration for the subscription Start Date: the date that the subscription begins Auto Renew: whether the subscription should automatically renew at the end of the term Renewal Term: the duration for a subscription renewal Products Purchased: the products that comprise the subscription Product Pricing: the amount to be charged for each product purchased, which can include one-time fees, recurring fees, and usage-based fees Billing Interval: the interval (e.g., monthly, quarterly, etc.) over which recurring charges are billed. 5.2 Creating Multiple Subscriptions As your business grows, you may want to offer an additional product line to your existing customers. It is important that your commerce system allows you to create multiple subscriptions for an account so you can, for example, allow your customers to try out the new offering without impacting their existing service. 5.3 Adding Products to Subscriptions To upsell more products or services to a customer later, your system should support the addition of those items to an existing customer subscription. 5.4 Removing Products from Subscriptions If a customer decides to downgrade from what he originally purchased (e.g., remove a promotional product after its teaser rate has expired), your system should support the removal of specific products from that customer s subscription. 14
5.5 Updating Products in Subscriptions Your system should allow you to make changes to a product within a subscription if you wish to alter the price charged to the customer for that product. 5.6 Changing Subscription Terms and Conditions In some cases, your system may need to support the ability to change the terms and conditions outlined in a customer s original contract. For example, rather than issuing a refund to a customer, you may both agree to simply provide that customer with a credit extending the length of her contract by three months. 5.7 Suspending Subscriptions Your commerce system may need to permit a customer to suspend his subscription to your service for a certain period of time; this is common for seasonal businesses and services. 5.8 Cancelling Subscriptions Your system must allow customers to cancel subscriptions to services that are no longer needed. For example, a customer may cancel the trial subscription at the end of the free promotional period, without converting into a paying customer. Since a customer can have more than one subscription, your system must allow a customer to cancel one subscription while keeping others active. 15
6 Web Self-Service A web presence allows customers to place initial orders, and reduces your lifecycle costs by providing self-service capability to customers. 6.1 Account Creation and Initial Purchase Your web storefront should allow a new customer to create an account and make an initial purchase online. The storefront should be: Configurable, to rapidly add new price packages and offerings without coding; Brandable, to match the rest of your website; Secure and PCI Compliant. 6.2 Viewing Information Returning customers should be provided with a login and password to access your web selfservice portal. From the web, a customer should be able to view the following information: Account Profile: typically a customer s contact and billing information Payment Method: the payment method used for any recurring billing. For credit card details, only the last four digits and the expiration date should be displayed for security purposes. Subscription Details: information related to the products and services that a customer has purchased from you, along with their corresponding rate plans Invoices: a record of the invoices you ve generated for that customer Payments and Adjustments: the history of payments that a customer has made and any billing adjustments you have made for the account 6.3 Updating Information Your system should also allow customers to make changes to their accounts from your web self-service portal, thereby saving you from significant customer support costs. Common self-service updates that your system should support are: Changing account user name and password Changing contact information for that account Updating the payment information for an account (e.g., adding a different credit card or changing a card s expiration date) Adding, removing, or updating products in a subscription Creating, suspending, or cancelling a subscription 16
7 Reporting and Metrics Your system should provide you with real time access to reports and subscription metrics. appropriate for the cloud. Some important metrics to consider include: Total Customer Value (TCV) Monthly Recurring Revenue (MRR) Cash Flow Churn CustomerLifetime value Customer acquisition rates Product / Subscription sales Earned Revenues Reports should be readily exportable. 17
8 Accounting System Integration 8.1 Integration Options Your commerce system will need to integrate with an accounting system to create your company s financial statements. There are two common approaches to integrating billing data: GL Integration: The benefit of this approach is to unburden the accounting system. Customer accounts, usage, invoices, and A/R are managed in the commerce system, and a summarization of this data by GL accounting code is loaded into the accounting system as journal entries. Invoice Integration: This approach passes customer information, invoice line details, payments, and adjustments to the accounting system. The accounting system then aggregates the information into the General Ledger. 8.2 Accounting Close Process Regardless of the accounting integration approach, your commerce system should have the ability to lock down the data therein as part of an accounting close process. Your commerce system should allow for extensive flexibility to create invoices, payments, and other financial transactions during the month. When the accounting books are closed, however, there should be no ability to change transactions or create new ones in the closed period. 8.3 Revenue Recognition The driving force behind revenue recognition is that you can only earn revenue as the service is delivered. With arrears-based usage models where you invoice after the service is used, revenue recognition is not a challenge. However, if your pricing model includes cycleforward billing where you bill ahead for a specified period of time (e.g., a quarter or a year), you will need to need to recognize this revenue as it is earned. Your commerce system should have the ability to invoice charges and trigger revenue recognition at a different time. For instance, you may want to invoice a one-time setup fee as soon as the contract is signed, but not start revenue recognition until the service is activated. Another common complication for cloud businesses is in recognizing a one-time charge over the length of a contract, or even the average customer lifetime. The commerce system will need to be able to invoice for these one-time charges, but enable revenue to be recognized over these longer service periods. Taxation Applied taxes vary depending on geography (yours, and the customer s) and type of product or service. 18
Each charge in your bundle of pricing may have different tax rules. For instance, some states charge taxes on professional services but not on internet access, so your commerce system will need the ability to apply taxes differently for each type of product that you offer. Federal and state level taxes may apply, with variations for European Value Added Tax and Canadian Provincial taxes. Some of your customers, such as charities or churches, will be exempt from taxes. These customers will need to provide proof of their tax exemption, and your commerce system will need the ability to not apply taxes on a customer-by-customer basis. About Fusebill Fusebill automates invoicing, billing and collections for subscription based companies. Ideal for both B2B and B2C businesses, our customers span many industry sectors, including software as a service, digital media, and communications. Our customers rely on Fusebill to reduce their costs, speed their cash collections, and extend their customer lifecycles. 1-888-519-1425 Email: Info@ Twitter: @fusebill 19