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.

Billing and Collection Engine

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:

Primary Databases

These databases house critical data schema.

Sub-Functions

These provide more detailed processing within the engine.

Integration Components

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

Venn2 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.

Venn3

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.


Venn4 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.

VIEWPOINT:

The Product Catalog Problem

The product catalog is a simple concept – it is a list of a company’s products and pricing. However, the waters muddy quickly as companies grow and product data starts innocently scattering throughout a myriad of applications and databases.

Read More

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.

For example:

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
Customer Hierarchy

Order Entry

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.

Subscription

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

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.

Invoice

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.

In brief:
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

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

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.

Prepaid

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.

Payment

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:

Very typical in B2C and B2SMB industries, a credit or debit card is kept on file in a PCI compliant manner and recurring payments are processed on a periodic basis. Credit Card rejects for a variety of reasons are common and should be monitored carefully and proactively.

Still prevalent across all industries, most major service providers work with a Lockbox service provided by major banks to manage incoming check payments.

Automated Clearing House (ACH) is a form of electronic payments that are processed directly from the payer’s financial institution to the service provider’s.

Emerging payment methods including PayPal, Bitcoin, Apple Pay, Google Wallet, baseball cards, and beaver pelts.

Tax

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.

Adjustment

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

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:

Level OneLevel TwoLevel Three

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.

Collections

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

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:

PERSUASIVE EVIDENCE OF AN ARRANGE EXISTS
THE PRICE CAN BE DETERMINED
THE PROBABILITY OF COLLECTION IS HIGH
DELIVERY IS COMPLETE
 

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.

VIEWPOINT:

Selecting the Right Billing Solution

Everyone complains about their billing system, but often their actual need (and the dollar value associated with that need) do not match up with the expected costs of a new billing platform roll-out (software, implementation, conversion, roll-out, training, etc.). Billing implementations are long, often painful, and costly. Clients need to be absolutely precise and thorough in their justification for the new billing platform.

Read More

Detailed: People | Process | Technology

All enterprise organizations except the marketing team have ownership in at least one process tied to the Monetization Ecosystem’s Billing and Collection Engine domain.

Customer-Success-People-IconFinance-People-IconFinance-Billing-People-IconOps-People-IconIT-People-IconLegal-People-Icon

Key Vendor Alert
The Billing & Collection Driver domain Key Vendors is divided into three software category types, which are segmented below.

Cloud Billing Key Vendors

Aria Billing Systems

Founded: 2003
HQ: San Francisco, CA
Company Type: Privately held
Website: www.ariasystems.com
Cloud/On-Premise: Cloud

Zuora

Founded: 2007
HQ: Foster City, CA
Company Type: Privately held
Website: www.zuora.com
Cloud/On-Premise: Cloud

goTransverse

Founded: 2008
HQ: Austin, TX
Company Type: Privately held
Website: www.gotransverse.com
Cloud/On-Premise: Cloud

NetSuite Monexa

Founded: 1998
HQ: Vancouver, BC
Company Type: Privately held
Website: www.monexa.com
Cloud/On-Premise: Cloud

Vindicia

Founded: 2003
HQ: Belmont, CA
Company Type: Privately held
Website: www.vindicia.com
Cloud/On-Premise: Cloud

 

SFDC-Native Key Vendors

RevChain

Founded: 2010
HQ: Palo Alto, CA
Company Type: Public
Website: www.steelbrick.com
Cloud/On-Premise: Cloud

Apttus

Founded: 2006
HQ: San Mateo, CA
Company Type: Privately held
Website: www.apttus.com
Cloud/On-Premise: Cloud

Steelbrick

Founded: 1999
HQ: San Jose, CA
Company Type: Privately held
Website: www.intacct.com
Cloud/On-Premise: Cloud

Chikpea

Founded: 2006
HQ: San Francisco, CA
Company Type: Privately held
Website: www.chikpea.com
Cloud/On-Premise: Cloud

On-Premise Key Vendors

Amdocs

Founded: 1982
HQ: Chesterfield, MO
Company Type: Public
Website: www.amdocs.com
Cloud/On-Premise: On-Premise

Cerillion

Founded: 1999
HQ: London, UK
Company Type: Privately held
Website: www.cerillion.com
Cloud/On-Premise: On-Premise

CommSoft

Founded: 1985
HQ: Rensselaer, NY
Company Type: Privately held
Website: www.commsoft.net
Cloud/On-Premise: On-Premise

CSG International

Founded: 1994
HQ: Meridian, CO
Company Type: Public
Website: www.csgi.com
Cloud/On-Premise: On-Premise

Ericsson

Founded: 1976
HQ: Stockholm, Sweden
Company Type: Public
Website: www.ericsson.com
Cloud/On-Premise: On-Premise

Huawei

Founded: 1987
HQ: Shenzhen, Guangdong, China
Company Type: Private
Website: www.huawei.com
Cloud/On-Premise: On-Premise

NetCracker

Founded: 1993
HQ: Waltham, MA
Company Type: Public
Website: www.netcracker.com
Cloud/On-Premise: On-Premise

Oracle Financial Services

Founded: 1977
HQ: Redwood Shores, CA
Company Type: Public
Website: www.oracle.com
Cloud/On-Premise: On-Premise

RevChain

Founded: 1998
HQ: Boca Raton, FL
Company Type: Public
Website: www.revchain.com
Cloud/On-Premise: On-Premise

SAP

Founded: 1972
HQ: Walldorf, Germany
Company Type: Public
Website: www.sap.com
Cloud/On-Premise: On-Premise

VIEWPOINT:

Vendor Risk & the Salesforce Ecosystem

Twenty-seven years in CRM, CPQ, and Billing have taught me a few things. First, don’t talk about your job at a cocktail party. Trust me, they are not interested in the latest bundling strategies in the mid-market, Software-As-A-Service space.

Read More
 

FIND OUT HOW WE CAN HELP

If you’re ready to find out how ATG can help transform your company, give us a call at 1-866-805-4284, or click the button below.

CONTACT US  >