Billing & Collections Engine
A Billing and Collections Engine is a class of software that is prevalent in service provider industries, such as telecommunications, IaaS/SaaS, cable, satellite, utilities, and digital media providers. This is often referred to as Service Provider Billing, which is separate from ERP-based Invoicing and Payment engines.
Over the years, this class of billing engines has been called, among other things, telco billers, cloud billers, service provider billers, and subscription billers.
As companies evolve the product offerings to include more dynamic relationships with their customers, service provider billing is necessary to support Usage, Recurring, and Non-Recurring charges that are common to these business models.
The Billing & Collection Engine sits in the center of the Monetization Ecosystem. As with most service-provider enterprises, billing touches more system domains and requires more application and data interfaces than any other. A strong billing system is the backbone of an effective monetization architecture, while a weak or incorrectly implemented billing system can be the bane of a company and cause serious issues both up- and downstream.
The Billing & Collections function is separated in three distinct areas:
These databases house critical data schema.
These provide more detailed processing within the engine.
Tools such as API, ETL, and Workflow to process data into and out of the engine. These are dealt with as a separate domain.
Billing & Collection Engine Components
Billing Product Catalog Database
The Product Catalog, within the Billing and Collections Engine, documents the various products, pricing, discounting, and promotions that are needed to support the business.
The billing product catalog should demonstrate the billing view as it relates to product monetization strategies for a company. The billing product catalog typically works in coordination with ‘selling’ and ‘provisioning’ product catalogs to ensure products and services are sold properly, activated correctly, and billed accordingly. Coordination of these catalogs is a complex effort, but it is a cornerstone to a successful monetization architecture.
Billing & Rating Catalog Integrations
Information needs to be captured at order time to be delivered to the billing system(s). Typically requires integration of the selling & billing product catalogs.
The billing and rating product catalog(s) Information required
to be in sync between the billing system and network systems to ensure usage is properly accounted for and associated with the appropriate customer account.
All products/services billed at what they were quoted/ordered. All active services being billed appropriately. All usage has an identified owner. Credit adjustments are minimized. Trouble tickets are minimized.
Customer Billing Profile (Hierarchy) Database
If the product catalog supports the billing component of a company’s monetization strategy, it is the Customer Billing Profile where it truly comes to life. This is where the customer data resides. Minimally, this includes key objects such as Customer, Account, and Service Instance. In addition, the Customer Hierarchy will hold information such as bill format preference, several contacts, payment information, taxable status, and geographic information.
A customer may be Bob Jones, who has two accounts: one for his household, and one for his daughter in college. Each of the accounts has one or more active services.
Billing charges to Bob Jones tie to the product catalog and reside as Usage, Recurring, or Non-Recurring charges associated with these service instances.
The flexibility of the database to support the number and type of customer, account, and service combinations is key to ensure billing will be accurate and easy to understand for the customer. In addition, a strong yet flexible database provides scalability to the monetization ecosystem.
Simplified Billing Customer Hierarchy
Order Entry is the process for creating a new service for a customer. Often, this is the first and only service for a customer. In Business to Business (B2B) models, it is very common for customers to have multiple services and accounts, each requiring effective order entry to capture the necessary information to provision and bill for the service effectively.
It is important to capture the information in an efficient manner that provides a positive customer experience while gathering all the appropriate data at one time.
Order entry can be direct with a customer, performed by the customer, or it can be a ‘swivel chair’ exercise where the sales employee is entering the order from a previously generated quote or contract without direct interaction with the customer.
Here, the focus is on quality and completeness. The customer is not waiting on the line but is relying on the information being complete and correct to ensure accurate activation/provisioning and billing of the service.
A Subscription involves paying on a periodic basis for an ongoing product or service. In reality, it is a monetization strategy that encourages, by its structure, a customer purchasing the same product or service over and over for some period of time, or with no specified end date.
In the past, many people subscribed to a newspaper and had it delivered on a daily basis to their home. The delivery person collected directly from the subscriber by going door-to-door, and the subscription continued until the customer cancelled. The product was a bundle of printed paper, the delivery method was a kid on a bicycle, and the payment was made in cash when the consumer happened to be at home.
Today, a more common subscription would be an entertainment streaming service (Netflix, Spotify, etc.) with a digital network delivery method and payment made automatically via credit card on a specified day of the month with absolutely no human intervention involved.
This lack of human intervention enables a service provider to increase the value of the service often by simply increasing capacity. As you can imagine, the lack of human intervention also requires a great deal of automation and integration between the customer acquisition, ordering, provisioning, entitlement, billing, and collection systems. In the case of a newspaper boy, he performed all those functions. In the case of Netflix there are complex, typically independent systems that must be kept in sync to provide the level of service that a customer now demands – humans only get involved when there are problems that can’t be fixed automatically.
The beauty of the subscription model is that it is based on recurring charges that are essentially “set it and forget it.” The service can start as a free trial that automatically converts to a paid subscription if no action is taken. Once the consumer is accustomed to seeing a charge on a credit card statement, they may subscribe for long periods of time – whether or not they utilize the product or service. Since cancelling the service requires action on the part of the subscriber, the recurring revenue often continues long-term.
Subscription-based products or services can be a valuable part of a company’s monetization strategy when offered alone or as part of a blended product set that includes one-time purchases and usage-based services.
Usage processing tracks the consumption of something that can be measured. This can cover tracking or counting the consumption of something that may or may not have an associated billable component.
When the monetization strategy includes usage as a billable entity, usage processing determines when and how much to charge a customer for any individual unit being measured. There are often situations where services might include a charge for every unit used. Other situations include a certain number of units and then charge for any additional units based on a pricing structure or other variable factors related to a service or an individual account.
Units that come into the usage processing system should have some defined unit of measure or the unit type being charged for, such as hours, kilowatts, megabytes, minutes, units, tickets, etc. Having a proper unit of measure can be used for determining rates or just be labels that are used in invoices, reports, or presentations to the customer.
Usage processing is completed by one or more supporting systems depending on the complexity of the business case and the capability of the supporting systems. All usage processing will have at a minimum the ability to load usage and assign a currency rate. The actual rating of the usage records may be handled by a rating system, ERP, or billing system.
Usage processing systems can generally handle a wide variety of granularity between usage records being processed. In many cases, each discreet usage event will need to be tracked individually for analytical or rating purposes, but in other cases, usage may be aggregated and only sent to rating after the usage has been grouped together based on type, date, or some other factor.
Having the ability to monetize services based on usage allows customers to pay for the exact amount of consumption that was used and drives the customer closer to the intersection between the value received from a service and the amount of money spent to use a service.
In addition, heavy-use customers can be charged for the additional amount of resources being consumed.
Closely related to Billing, an Invoice represents the charges due, description of charges, method of payment, and terms of payment. Invoice, Bill, and Statement are terms that are often used incorrectly in the context of service provider billing.
Invoice – official accounting term, defined above
Statement – semi-official accounting term, which is typically provided monthly or quarterly, that represents all of the activity for a given period, including previous balance due, payments, adjustments against previous invoices, new charges, and a new balance due. The typical cell phone or cable bill is technically a monthly statement, which includes information from one or more invoices.
Bill – informal term that can be used to describe an Invoice, Statement, or a guy named William.
Billing is the crucial process of evaluating a customer’s billing profile, and identifying the new charges that should be generated. These charges will be aggregated to generate an Invoice.
For many service providers, the billing output is a Statement in addition to an Invoice that aggregates all of the financial activity since a previous period. In these environments, Billing includes evaluation of payments and adjustments from previous Invoice/Statements to produce a comprehensive Statement, which includes a new invoice and an updated Balance due.
The billing process can be done on-demand, at customer inception, or at periodic intervals – most commonly monthly, but often quarterly or annually.
Entitlement is relatively new to the billing domain. Entitlement, in a billing context, is where the billing system is responsible for being a source of record for communicating whether a customer is entitled to use the service in the manner they are attempting – and whether there is a billable impact to what they are trying to do.
For example, if a monetization strategy is to allow a customer up to 10 downloads of a ringtone before they are charged $.50 per download, then the billing system may be invoked to quickly process a ringtone request and let the customer know that there may be a billing impact to this activity. This is a relatively new requirement, and the billing engine is not the only component that can deliver it, but it is becoming an important part of maintaining a positive customer experience in usage based monetization models.
The Prepaid model for billing is used in many industries – from telecom to health care. It is a monetization strategy built on the premise that it reduces risk to the provider, often in exchange for some incentive to the customer.
Implementation methodologies of the prepaid billing system are as varied as the industries that use them. Providers view prepaid products as everything from a customer paying in advance for a normal periodic service to complex entitlement for products that are dependent on time-of-day, day of the week, quality of service, or some other combination of factors.
In the simplest case, payment is taken to offset future products or services that will be delivered. The challenge to this model is how the cash be will handled and how the revenue will be recognized – typically either upon payment or upon provision/delivery of the services paid for.
In the prepaid entitlements world, the first item to consider is what system is tracking the entitlements and use of the product or service to which the customer is entitled. Complex entitlements are often managed by a combination of an entitlements engine and a real-time rating engine – one to track what has been used and one to track what is due. These implementations typically manage what happens when a customer consumes their prepaid amount and may have integrations with ordering and payment systems to increase the entitlement when it is nearing exhaustion. The other side of that interaction is what happens to unused capacity? The ability to rollover an entitlement to another period is often desirable to retain customers.
Another factor to consider in prepaid billing is what happens when the customer cancels the service. Prepaid agreements are often linked to a contract with some provision for cancellation fees and/or refunds. The billing system may need to respond by prorating charges or adding penalties.
The prepaid model can be a valuable monetization tool for the service provider, but it is not without extra cost and some risk.
Payments represent customers paying for the invoice or services that they received from a service provider. They can be one-time, upfront payments for a physical good, or they can occur on a periodic basis for a recurring or subscription based service. Recurring or subscription payments occur most often monthly; however, quarterly or annually are other common practices, and subsequently payment intervals.
Payments come in a variety of forms, most commonly:
Tax regulations vary greatly by jurisdiction, country, industry, and service type. Successful organizations often build revenues on more than one product offering or service line that take place in more than one region/tax jurisdiction. Bundled products, each potentially with unique tax regulations, can be a nightmare for tax managers to account for in a subscription revenue model. Companies unable to accurately calculate and bill for tax risk revenue leakage, face strong punishment and regulatory scrutiny.
Savvy tax engines enable companies to calculate the correct tax for the correct customers and services, which can be presented cleanly on a customer statement. Such offerings can be packaged inside the billing engine, or provided by a third party, relying on API integration to quickly and securely pass customer and tax information from one system to another.
Adjustments are changes to a customer’s accounts receivable, or balance. Adjustments that are in the customer’s favor end up being a credit to the A/R. Such adjustments are known as credit adjustments, credits, or, on occasion, credit memos.
In a billing context, billing engines often must handle pre- and post-billing adjustments. Post-billing adjustments are typical, but many business models require pre-billing adjustments against a charge that has not yet been applied. For example, if a cable customer experiences a problem with an on demand movie, they may call and complain and get a ‘pre-billing adjustment’ that will negate the charge that is placed on the invoice at the end of the month.
Another form of Credit adjustment is not an A/R transaction at all, but provides the customer with a service credit against future time periods or usage buckets.
Occasionally, an adjustment is made that is not in the customer’s favor. Known as a debit adjustment, this adds to the customer’s balance. Debit adjustments are pretty rare in most cases, but they can be used to correct erroneous bills or to handle instances such as a penalty for not returning a set-top box to a cable company. Some service providers have a concept of a dispute, which is simply a higher order object creating a case to be investigated that could lead to a credit adjustment.
Billing Operations is the process of managing the various billing processes that are core to a billing system. The tasks and functions within billing operations includes managing billing runs, posting records to financial systems, monitoring and loading usage records, and managing other billing functions such as bill cycles.
The Billing Operations functions are typically performed by the billing administration team and will require a level of intervention based on the systems used to manage billing and billing functions.
ATG maintains a complete Billing Operations Map, which spans all tasks and responsibilities in managing a billing system and assigns those to the likely enterprise organizations that should be both responsible and accountable. Please contact an ATG consultant for more information by clicking here.
Credit Card Optimization
Credit Card Optimization can achieve the following goals:
- Reduce credit card processing costs
- Reduce risk of internal fraud
- Increase security of customer PCI data
- Update credit card information automatically
Cost reductions can be achieved by sending additional customer and transaction information with the credit card transactions to the credit card processor. Sending extra data may be referred to as enhanced data or Level # processing, where # corresponds to the level number.
There are three levels. With each increased level, the amount of additional transactional data is increased. While the specific data may vary slightly between credit card processors, a sample of possible data that may be requested by a processor for each level might include the following:
When additional credit card data is passed to the processor, the cost per transaction is generally reduced because the risk of fraud is also lessened and the likelihood of recovery is increased. Additional internal optimizations can be made to increase the security and limit the ability for internal fraud to take place. Credit card data should follow practices outlined in the Payment Card Data Security Standard (PCI DSS) to ensure controls are in place to reduce risk.
Additional optimizations can be made to reduce the sensitivity of the actual credit card data that is being stored in various systems. One such step is to tokenize credit card numbers so anyone viewing the token would have no value in actually stealing the token. The process of tokenization must be supported by the internal systems as well as the payment processor. When a credit card is submitted to the payment processor, a token is returned and is the actual value stored on file, instead of the credit card, for ongoing or future payments.
Account Updater is a feature supported by some systems – and most credit card processors – which allows credit card numbers and expiration dates to be updated automatically when a customer gets a new card issued. This can be extremely useful to maintain a low level of credit card failures and increase the overall customer experience as service continues uninterrupted, and the customer does not have to call with updated credit card information. Account updater even supports credit cards re-issued as a lost or stolen card.
Collection activities are undergone when a customer’s payment date is past due, and warrants effort from the business to collect cash. It is up to the business to define thresholds to begin collection activities, as not every customer payment may be worth pursuing the moment it is considered late. Metrics to trigger collection attempts are varied, including; time, account type, outstanding amount, age of outstanding charges, etc.
Collection activities aim to increase cash by collecting past due payments, and decrease the need for bad debt and allowance for doubtful account expenses. Quality collection software shortens the length of time needed to collect remaining balances owed. As delinquent balances are recovered, the FMS must be able to process and account for changes to the appropriate GL accounts quickly, allowing collections to move on to the next high value balance and accounting users to have current financial data.
Revenue Recognition (Rev Rec) is defined in many ways by many different governing bodies with a seemingly endless list of considerations, rules, exceptions, and headaches. Put simply, revenue recognition principles exist to provide guidance to business owners on sustainable ways to manage money from business operations, and for investors to be able to have transparency to the financial health of a company.
At the core of revenue recognition law is the matching principle, an accrual based accounting principle mandating companies to associate expenses with related revenues consistent with the time periods each is incurred. Pairing revenues with expenses enables companies to more accurately understand their current financial health, whereas recording revenues without regard to expenses (or vice versa) does not paint a clear picture for business owners or investors.
Under US GAAP (Generally Accepted Accounting Principles, created by the FASB), revenue is recognizable when four criteria are met:
Service providers often provide recurring services billed either in advance or arrears. Quality financial management systems must be able to accurately decipher between earned and deferred revenue, the related expenses, and then amortize the necessary values as service delivery occurs. With Rev Rec being a constantly evolving principle, systems and their users must remain nimble in order to comply with regulations, provide accurate information to business users, and fairly represent a company’s financial standing to stakeholders.
The rules for revenue recognition, and the how billing engines support them, are in flux. Specifically, service provider customers are currently tackling complicated ASC 605-25 Multi-Element Arrangement requirements and ASC 606 Contracts with Customers requirements. The role of the billing engine in the overall revenue recognition process is changing as well, with the introduction of pure Revenue Recognition engines. The billing engine, Revenue Recognition engine, Financial Management System/GL, and often Excel, are components necessary to support the full requirements of service provider revenue recognition.
Customer Accounts Receivable (AR)
Receivables represent cash owed to a company for goods/services provided; thus, they have the potential to be a very large asset account. Maintained at the sub-ledger level, Customer AR is increased as goods and services are delivered, and decreased as payment is received for those services.
AR is a generic term used for receivables, and can be broken down into two flavors: billed and unbilled. Billed AR represents the dollar amount a customer has been billed for, whereas unbilled AR represents receivables which have not been billed to the customer. Though this distinction may or may not be relevant for a company, both billed and unbilled amounts represent an asset.
Accurate customer AR relies on billing and financial management systems to be in sync since bills generated from the billing engine directly impact receivables. Without harmony between the two, companies risk overstating/understating how much their customers owe them, jeopardizing both asset and revenue quality.
Key Vendor AlertThe Billing & Collection Driver domain Key Vendors is divided into three software category types, which are segmented below.
Cloud Billing Key Vendors
HQ: San Francisco, CA
Company Type: Privately held
HQ: Austin, TX
Company Type: Privately held
HQ: Belmont, CA
Company Type: Privately held
SFDC-Native Key Vendors
HQ: Palo Alto, CA
Company Type: Public
HQ: San Jose, CA
Company Type: Privately held
On-Premise Key Vendors
HQ: Chesterfield, MO
Company Type: Public
HQ: Rensselaer, NY
Company Type: Privately held
HQ: Stockholm, Sweden
Company Type: Public
HQ: Waltham, MA
Company Type: Public
HQ: Boca Raton, FL
Company Type: Public