Book: Billing for Business Networks (Sample Chapters): Understanding Billing Basics

Copyright
© Copyright 2012, 2013 by Stephen Jones
All Rights Reserved.
This material may not be reproduced, displayed, modiﬁed or distributed without the
express prior written permission of the copyright holder.
Published by www.purebill.com (through which Stephen Jones can be contacted).
Book Version: Final (1.0 - September 2013)
ISBN:
978-0-9874350-0-2! (PDF)
978-0-9874350-1-9! (epub)
978-0-9874350-2-6! (mobi)
Billing for Business Networks
________________________________________________________________________
________________________________________________________________________
www.purebill.com - Final Page 2

Dedication
To my son Xander, who changed my life for the better
________________________________________________________________________
________________________________________________________________________

Table of Contents
Chapter 1: What is Billing?! 10
Billing as a primary ‘Customer Contact’ point! 10
Billing Systems that are ‘Fit for Purpose’! 11
The Billing Process! 12
What is a Network ?! 13
Non-network Commercial Situations! 15
Chapter 2: Billing Within The Business! 16
Ordering! 17
Provisioning! 18
Service Assurance! 19
Data Analysis! 20
Why Multiple Billing Platforms Are Used! 21
Chapter 3: The Key Functions of Billing! 26
Activation / Service Provisioning! 27
Transaction Collection / Mediation! 27
Transaction-level pricing (Rating)! 28
Bill Generation / Bill-level Pricing! 29
Bill Presentation / Distribution! 30
Downstream Reporting / Business Support! 30
Account Maintenance / Inquiries! 31
Chapter 4: The Core Data Concepts Of Billing! 33
Customer! 34
Account! 35
________________________________________________________________________
________________________________________________________________________

Service! 35
Product! 36
Hierarchy! 37
Chapter 5: Common Network Businesses! 40
Utility Billing! 40
Tollway Billing! 41
Telecommunication Networks! 43
Government Rates / Taxes! 44
The Wholesale Model! 45
Chapter 6: Charge Types! 47
Non-Recurring Charges! 48
Charges Billed By Installment! 48
Recurring Charges! 50
Charging for Network Usage / Consumption! 52
Common Billing Processing Protocols! 53
Chapter 7: Individual Charges! 58
Differentiating Charges! 58
Moderating Pricing Complexity! 60
Recurring and Non-Recurring Charges! 61
Usage! 62
Building Charges From Their Parts! 63
Chapter 8: Bundled Charges! 65
What is a Bundle?! 65
Why Bundle Products?! 65
Constructing a Product Bundle! 67
________________________________________________________________________
________________________________________________________________________

Chapter 9: Contracts! 70
Commitments Over Time! 70
Contract Examples! 71
Chapter 10: Service Provisioning / Activation! 74
Customer Orders! 74
Order Management! 75
Operational Structures for Billing! 76
Bundle Provisioning! 79
Automatic Network Activation! 81
Provisioning Latency! 82
Chapter 11: Transaction Collection / Mediation! 85
Historical Comparison: Fixed phone versus Utility! 85
Network Collection! 87
Collection: Operational Considerations! 89
Error Management! 90
Data Mediation! 91
Chapter 12: Transaction-level Pricing (Rating)! 96
How Much Does A Charge Cost?! 96
The Key Steps of Rating! 98
What are Rate Plans?! 102
Rating Algorithms! 105
Additional Rating Mechanisms! 111
Rating’s Operational Workload! 119
Chapter 13: Bill Generation / Bill-level Pricing! 122
Bill Generation! 122
________________________________________________________________________
________________________________________________________________________

Triggering the Billing Cycle! 124
Customer Details Extracted For Billing! 128
Bill-level Pricing! 133
Bill Format Options! 139
Bill Validation! 144
Chapter 14: Bill Distribution! 148
Distribution Channels! 148
Notiﬁcation Channels! 152
Bills and Other Documents! 153
Distribution Operations! 154
Chapter 15: Customer Inquiry / Maintenance! 156
Customer Identiﬁcation! 156
Wholesale Customers: Inquiries and Maintenance! 158
Contact Channels! 160
Maintenance Lifecycle! 165
Capturing Customer Details! 166
Chapter 16: Reporting / Business Support! 170
Auditing Reports! 170
Exception Reports! 171
Adhoc Reports! 172
Size, Timeliness, Distribution and Access! 173
Chapter 17: Customer! 177
What is a Customer?! 177
Customer Lifecycle! 178
Consolidating ‘Customer’ Databases! 180
________________________________________________________________________
________________________________________________________________________

Chapter 18: Accounts! 183
Account Lifecycle! 183
Structural Combinations! 184
Account Complexity by Customer Segment! 185
Account Information! 186
Financial Totals! 188
Chapter 19: Service! 189
Network Services! 189
Non-Network Services! 190
Derived Services! 191
Service Segmentation! 192
Chapter 20: Product! 194
What is a Product?! 194
Building Up A Product Offering! 194
Product Catalogs! 197
Chapter 21: Hierarchy! 200
What is a Billing Hierarchy?! 200
Beneﬁts of Billing Hierarchies (at Scale)! 200
Hierarchy Complexity! 202
Chapter 22: Other Important Data Concepts! 204
Bill Details! 204
Post Bill Disputes! 205
Billing Notes and Contact History! 206
Taxation Details! 207
Addresses! 208
________________________________________________________________________
________________________________________________________________________

Chapter 23: Aspects of Pricing! 210
Pricing Complexity! 210
Bundled Pricing! 215
Differential Pricing! 216
Chapter 24: Disputed Charges! 220
The Dispute Lifecycle! 220
Operational Support! 227
Disputes: An Example of ‘Case Management’! 230
Chapter 25: Payments! 231
Forms of Payment (Payment Channels)! 231
Timeliness! 234
Chapter 26: Settlements! 236
Methods of Settlement Payments! 237
Chapter 27: Revenue Assurance! 239
What is Revenue Assurance (RA) ?! 239
Documentation and Data Discovery! 241
Iterative Testing! 242
About the Author! 244
About the Book! 245
________________________________________________________________________
________________________________________________________________________

Chapter 1: What is Billing?
Looking through a pile of bills will reveal that more than one is from a network business.
Many of the services we purchase are based on access to, and use of, networks that
either provide the necessities of a comfortable environment (e.g. electricity and water) or
allow us to communicate with others (e.g. telephone and internet).
Depending on where you live these network businesses may be publicly held corporations
run for profit or arms of government providing services to residents - either way, the basics
of the process by which you are billed is very similar.
Billing for Business Networks explores a network’s billing process by separating the act of
billing from the multifaceted operations of that network. Networks are usually large
complex creatures that are difficult to develop, and require considerable money, staff and
ongoing focused effort to maintain. They can be limited to a specific locality or provided on
a country-wide or international basis. In contrast, billing is usually provided in a centralised
manner and is based upon what has been done upon the network (of whatever size or
type). By separating the complexities of the ‘physical’ network and the billing for that
network, the billing process can be understood.
This is not to say that all billing is the same or equivalent. Billing for a telecommunications
company is considerably more difficult than the billing for basic water consumption. The
telecommunications industry seems to delight in building highly complex networks and
then reflecting them in its billing systems. The water and electricity industries have not
(yet) developed this level of complexity, but this may happen in the future with the
increasing focus on reducing water and energy consumption.
Billing for Business Networks will explain the billing process using examples familiar (or at
least understandable) to most people based on the bills they receive in their everyday
lives. Examples describe how telecommunications billing can be generalised from its
complexity and explain how simple billing for water and electricity can be made customer
specific (and more complex).
The similarities in the billing process across different industries are illustrated using
examples taken from telecommunications, road tollways, utilities (gas, electricity, water),
and local government (rates and garbage collection). Billing for Business Networks is not
intended to be technology or industry specific, nor based around a specific billing vendor.
Instead it is designed to enable readers to use what they will learn to evaluate and
understand their own business’s systems, or those of a candidate billing vendor.
Billing as a primary ‘Customer Contact’ point
In today’s business environment with its focus on cost-effective customer contacts, there is
a movement away from person-to-person communication and towards arms-length
electronic processing. This means that there are fewer customer touchpoints aside from
________________________________________________________________________
________________________________________________________________________

when (say) a new service is connected for a telecommunications company, the utilities are
connected when moving into a new house, or there is a problem with the biller’s services.
This reduction of ‘customer contact’ between the network biller and its customers puts
pressure on the primary point of contact - the bill.
Naturally this reduction is most applicable in the consumer mass market where customers
number in the thousands or millions. Corporate customers are generally managed with a
closer relationship since their needs are usually more complex, and their bills are generally
worth more!
Thus, the bill a customer receives needs to perform many functions. These can include
clearly articulating how the amount payable was arrived at (a core requirement not always
achieved), highlighting details of future billing changes (e.g. price rises or specials),
possibly marketing new offers to customers and, most importantly, informing them as to
how they can pay their bill.
If the bill performs these services well, the customer is more likely to be positive about the
biller’s network and its services and feel less need to call the biller’s customer service staff
with questions, complaints or disputes (or change service providers). Importantly, the bill
is more likely to be paid promptly.
Billing Systems that are ‘Fit for Purpose’
Billing for Business Networks highlights the billing similarities between different networks.
Not all billers require the same sophistication to operate their business. Billers require
systems that both meet present requirements, and are adaptable to future (perhaps
unknown) needs. Some of the questions billers may ask themselves when thinking about
their billing systems’ ‘fitness’ can include:
What is the complexity of my billing needs? If a business is primarily based on monthly
recurring charges, its billing needs are less complex than those of a business having high-
volume daily transactions with tailored rates for different customer segments.
What is the cost of the billing systems? Cost includes the purchase price of new
systems, and the operational costs of existing and possible new environments. The
system, business and human costs of any transition from an old to a new environment
must be taken into account. Depending on the required complexity, the cost of a network
operator’s billing can be material to its ‘cost of doing business’.
What is the cost of modifying the billing system? New features and transaction sets
are often developed to enhance the biller’s market offerings. What are the system
development or configuration costs required to deploy new transactions and interfaces?
How does the billing systems process information? This involves the speed and
latency with which events and business updates are reflected into and through the billing
systems. This processing speed impacts the functionality provided to a customer, and the
speed with which network access and events can be converted into money.
________________________________________________________________________
________________________________________________________________________

How quickly can bills be modified to reflect new market offerings? A biller needs to
be able to develop and bring new offerings to market quickly (lead time) and to anticipate
or address a competitor’s offerings (responsiveness). Their bills must reflect these
changes.
Are the billing systems transparent? Billing is not performed in isolation. The biller’s
management and outside parties (e.g. regulators) often require access to billing
information in a timely manner. Is the required information available in the required format
within the required timeframe?
These questions highlight the many different and inter-related tradeoffs in billing between
‘complexity’ (with its benefits of adaptability), and the ‘cost’ of providing and supporting that
complexity. The billing solution a biller selects must align with the functions to be
performed today, provide suitable adaptability for the future (as the biller’s vision sees it)
and operate within the biller’s available funding envelope (for development and ongoing
support).
Transaction and customer volumes are a factor here, since increased size generates more
complex product combinations, system scaling issues and exaggerates the impact of any
billing problem or defect.
Once a biller has chosen a set of tradeoffs, they can move them over time as their
network, operating environment and competitors (if any) change around them. Yesterday’s
solutions may be inadequate today and obsolete tomorrow. But decisions must be made,
and wise decisions will confer a competitive advantage, or at least lowered costs to a
network.
The Billing Process
Once the network business has defined who its customers are, the services it is willing to
provide to those customers, it needs systems to charge those same customers for the
services rendered. The collection of the resulting charges and subsequent request for
payment is what billing is all about.
Viewed as an end-to-end process, billing:
- Captures the billable events, i.e. the details of access and services provided
- Calculates specific charges against the billable events
- Aggregates the charges for a ‘customer’
- Deducts charges against a pre-paid balance, or asks for payment
- Determines the ongoing entitlement to network access
Captures billable events This is the touchpoint between the network and the billing
process. The richness, timeliness and accuracy of the data captured here drives the
subsequent billing processes. Billable events can include charges for access as well as for
the actual consumption or use of the biller’s network.
________________________________________________________________________
________________________________________________________________________

Calculates specific charges Once the billable events have been captured, a financial
value must be placed against them. The precise value can depend on the customer’s
details (e.g. business, residential), special features of the event (e.g. a ‘reverse charge’
phone call), captured event details (e.g. call duration, call destination, quantity of
electricity, gigabytes downloaded) - in short, all the information available about the specific
customer, her demographic segment’s characteristics, and any special and standard
pricing arrangements.
Aggregates the charges After charges have been given a financial value, they are
periodically collected and formed into a bill. The bill may allow discounts on aggregate
totals and taxes applicable to the nett charge. If charges are prepaid, the customer’s
balance may be reduced by the charge’s total.
Seeks payment The (post-paid) bill, representing the consolidated, discounted and taxed
charges, is sent to the customer for payment using the biller’s approved methods.
Determines the ongoing entitlement to network access A prepaid customer may have
her access to the network terminated when the prepaid balance is consumed or her
balance may be recharged via (say) a credit card to enable continuing access. For
postpaid customers, if the requested payment is not made, ongoing access may be denied
or financial penalties applied.
What is a Network ?
The establishment and maintenance of a network’s billing system can best be understood
by first reviewing characteristics typically found in networks.
A ‘network’ typically has the following characteristics:
- A specific infrastructure or a finite geography across which the network business is
conducted
- The ability to permit or refuse access or service to customers based on pre-payment or a
promise to pay
- The ability to measure a customer’s access or consumption if required
- An ongoing relationship across time with its customers
- A charge is made for use of the network
Specific Infrastructure or Geography A network has a finite, though possibly large,
boundary within which its business takes place. Examples include the national phone
network, pipes of a water distribution network, roadway associated with a tollway, and the
geographic limits of a city that levies rates for local government services and waste
collection.
Permit or refuse access or service A threshold associated with ‘signing up’ to access or
use the network is placed upon the customer. This can be quite low, as in the case of a
prepaid calling card, or substantial, such as a requirement that the customer pass a credit
________________________________________________________________________
________________________________________________________________________

check. By signing up, the customer’s details becomes known to the business and access
can be granted to the network. Even in the case of a pre-paid calling card, despite the
customer remaining anonymous (whilst making phone calls), there is still some measure of
‘enabling’ the card before commencing its use.
Measure a customer’s access or consumption Complementing ‘permission of access’,
measurement allows the network business to provide a specific quantity of access or
service, or if not limited, measure the amount consumed and later bill for it. Examples
include tollway journeys billed later or a preset number of domestic phone call minutes on
a calling-card. Alternatively, a customer who purchases an all-day tollway pass is billed
based on a measured period of access (time) rather than the quantity of journeys made
(use).
An ongoing relationship Access and use of a network are associated to the same
customer across a measure of time and can be ‘billed’ or ‘charged for’ collectively.
Examples include calls deducted from a single (even if anonymous) calling card balance,
and international calls collected and charged to a home phone bill.
A charge is made for use The charge drives the need for billing, but does not
necessarily mean that a paper bill needs to be generated. Indeed, there is a definite trend
away from paper-based billing towards online (internet) based presentation of the bill’s
details.
The degree and manner to which each characteristic is employed in a particular network
will be specific to each individual business, will be industry specific and will be influenced
by the regulatory framework within which it operates.
For example, tollways usually cannot refuse access to specific vehicles (absent weight,
etc. restrictions). However, the owner of a vehicle that uses a tollway without payment
may be subject to fines and penalties.
Two additional points about network characteristics are worth noting:
Ownership of the network assets A network business need not own the network assets
it uses. It can rent the assets of another business at one rate and on-sell to end users at a
higher rate. For example in the telecommunication industry, the wires into the home are
rented from the local incumbent, or in the power industry electricity may be purchased
wholesale from a generation business, carried over the wires of a transmission business,
and sold at retail into the home. In each of these cases the retail relationship with the end
customer is separate from the ownership of the end-to-end network assets.
Networks need not be physical An example of a network asset that is not physical (in
the sense of being able to touch it) is an electromagnetic spectrum (e.g. radio frequency).
Access to a wireless network for phone or other services can be supplied by the spectrum
owner in the same manner as access to a home’s phone line can be rented from an
incumbent telecommunications company.
________________________________________________________________________
________________________________________________________________________

Non-network Commercial Situations
Not all commercial transactions need a sophisticated billing system. Some examples are:
Retail shops Here the purchased goods are totaled at the register and immediate
payment is requested. There are usually few options to decline service, often the customer
remains ‘anonymous’ and there is little or no ongoing relationship with the customers once
they have left the shop.
A ‘billing’ requirement could be generated for shops where (say) there was a specialised
‘trade’ component to their sales. Examples include interior decoration shops with a
professional decorator clientele alongside their retail sales, or a large plumbing store that
sold products to professional plumbers as well as the weekend DIY population. In these
cases the shops could perform anonymous retail sales, and ask for monthly payment of
their ‘trade’ accounts based on special ‘trade’ pricing, with an expectation that non-
payment would force these professionals to pay the same rates as the public.
Cash transport tickets Tickets are obtained from a station, retail shop or vending
machine and used for anything from a single trip to (say) a week’s travel. There is little
ongoing customer relationship, no differentiated charging and usually no scope to decline
access. This, despite the transport being performed over a rail or bus network.
Transport tickets could generate a ‘billing’ requirement if a customer had an ongoing
relationship via a ‘transport-pass’. The pass could allow details of the travel performed to
be collected for later billing or deduction from a customer’s speciﬁc pre-paid balance.
There could be bonus rebates / credits based on the traveler’s use of the transport
network over time.
Tollways that only take cash payments Many tollways charge for their use only by
collecting cash from their customers. Customers pay for each use of the tollway.
Some tollways use billing to great effect, by using electronic tags to capture details of trips
taken. These trip details are then passed to the tollway’s billing systems.
________________________________________________________________________
________________________________________________________________________

Chapter 2: Billing Within The Business
Business functions normally view their own activities as central to the entire business.
While this viewpoint is always exaggerated, business functions are interdependent, and
often, the failure of any one function can cripple an otherwise sound business. This is
certainly true for billing, which interacts with nearly every business function. Yet, billing can
do more than collect cash. Properly structured, it can provide support to forecasting,
marketing, and sales efforts. Thus, it is entirely appropriate to treat billing as a central
business function, the approach taken here.
Operationally, billing businesses are complex combinations of staff and information
technology. In this book, business and billing ‘functions’ will describe ‘what’ is performed,
‘systems’ will be the collective combination of the manual and automated processes that
support ‘how’ functions are performed, and ‘applications’ will be specific deployments of
information technology.
An application may participate in one or more functions, be part of one or more processes,
and can range in size from a large, comprehensive software package to a small, specific
processing step. A business process supports one function and may utilise one or more
applications as well as including manual steps. This book is a general discussion that
includes talk of functions and systems, and discusses applications when the specifics of
how to perform a task are important.
The functional landscape around billing
No two business networks are identical. Thus, the implementation of no two billing
systems will be the same. This holds true even within a given industry where, the choices
made by individual businesses will result in different billing arrangements.
Business functions (outlined in more detail below) that interact with billing include:
- Ordering: Captures the details of a customer’s purchase
- Provisioning: Implements the customer’s order in the network and/or billing
- Service Assurance: Network monitoring and problem resolution to ensure maximum
service availability and customer satisfaction
- Data analysis: An internally focused business examination of customer data
- Fraud Detection: Identifying suspicious or fraudulent activities taking place upon the
network
- Marketing Support: Supporting the search for sales opportunities from new and existing
customers
- Other billing systems: Where multiple billing systems exists within a business, each
billing system is likely to interact with the others to share customer, reference or
transaction information.
________________________________________________________________________
________________________________________________________________________

Billers can use separate or consolidated applications to interact with each of these
functions. Provisioning and service assurance, the functions that form the touchpoints
between the IT infrastructure and the network infrastructure, will encounter the greatest
variation in their processing. Each industry’s network will require different processes to
support these functions, and the required applications will vary as a result.
Ordering
Each customer’s purchase is captured by an order. An order is the customer’s response to
a biller’s offerings, and refines them to a specific sub-set for that customer with specific
details (and potentially customised pricing).
The customer’s order can take several forms: by phone with the biller’s staff, by regular
mail using a paper purchase order, electronically through the use of an agreed B2B
interface, or perhaps executed by the customer themselves via an internet-based self-
service portal. Orders can be generated internally by the biller (e.g. in credit management -
disconnection of the customer for an unpaid invoice, by service assurance - credit rebates
when the biller does not maintain contracted service levels).
Each order is unique and must be differentiated from similar orders from the same
customer for the same products. Similar orders must have unique identifiers reflecting the
different phone numbers, meter or internet connections against which they are to be
applied. In subsequent processing, one of the order’s key validations is to confirm that the
same order has not already been processed. Thus, it is essential that each order have, or
be assigned, at the outset, a unique order number.
Orders may be simple and standardised, or exceedingly complex, customised requests.
An order’s complexity is limited only by the ordering system’s ability to capture its details,
and the biller’s other systems’ ability to process them. The likely complexity of an order will
vary depending on the complexity of the network receiving the order. An order for a new
tollway transponder is likely to be simpler than an order for modifications to an
international telecommunications link.
Complex orders can take several days to define, and may require the biller to have or
acquire detailed information on a customer’s preferences, specialised knowledge of the
biller’s network, and service identifiers (e.g. phone or meter numbers) to ensure the billing
and network arrangements are applied correctly.
To ensure that a biller can fill a customer’s order, new network connections may need to
be pre-tested (qualified). This pre-testing may involve evaluation of the order’s details
against a customer’s existing product sets and the network itself. For example, evaluation
tests may include product eligibility based on the customer’s market segment, availability
of network equipment at the customer’s location, and technical compatibility (sociability)
between the intended and existing network configurations.
When a customer orders a new product or service, or modifies an existing one, she has an
expectation that its bill details will align with what it ordered. The price, description and
________________________________________________________________________
________________________________________________________________________

date range of services provided must not vary, without an explanation, from what the
customer ordered. Hidden from view, the network response supporting the customer’s
order may be implemented in a variety of ways, but it must achieve the desired external
effect. Absent such alignment the biller will, at a minimum, incur additional costs through
responding to the customer’s inquiries and complaints. Optimally, the biller provides what
was ordered without requiring the customer to understand how it was delivered.
Once an order’s details have been captured and validated, it is sent onward (as
appropriate) to the network for provisioning, and then on to billing. An order that varies
only a customer’s billing arrangements (e.g. billing address, pricing plan) is unlikely to
require processing by the network. Any network change, however, should be passed to
billing since it may change a customer’s billing arrangements or the basis upon which it is
charged. e.g. a change in the speed of a communications line, or configuring ‘call waiting’
on a phone line.
A specialised form of ordering is referred to as churn. It is the process whereby a customer
can move (often in an automated way) between retail network providers whilst retaining
their existing service details. e.g. a customer may change phone providers and retain her
existing phone number or change electricity retailers whilst remaining connected to and
continuing to use the same meter.
Provisioning
Provisioning describes the range of network interfacing actions that add new network
connections (e.g. connect a new phone), modify an existing network connection (e.g.
change the allowed programs in a subscriber’s premium cable TV package), and
disconnect connections (e.g. change a meter’s status as part of its final meter reading).
This function isolates the network’s intricacies from the central business functions and their
IT applications. The specific technical details required for configuring, reading and
otherwise communicating with a network can be effected within the provisioning function.
This function is especially important where the network is a heterogeneous collection of
vendors and equipment, and each has its own approach to performing common tasks.
Ideally, provisioning interactions within a network are highly automated. This is especially
important when network connections are numbered in the millions.
Complex orders, especially for high-end telecommunications, may require an expert
design step that reserves equipment, implements and then tests the proposed solution.
Standard, simple orders using existing infrastructure (e.g. water or phone connections) are
unlikely to require a design step unless the customer’s premises had not previously been
connected to the network (e.g. new housing) necessitating manual intervention. Otherwise
the existing equipment would be (re)configured to reflect the order.
Complex installations or network modification may require ‘time and materials’ charges be
applied. These charges, on an original or a subsequent order, are directed to billing for
subsequent inclusion on the customer’s invoice. They may be reflected in the initial
invoice, or held for inclusion on a subsequent invoice.
________________________________________________________________________
________________________________________________________________________

Order validation should be performed before processing to ensure that the network is not
impacted by inappropriate requests. Validation will cause some orders to error and manual
intervention will be required. Errored orders may be rejected outright, or modified to correct
the problem and resubmitted.
Contractual or regulatory provisions may require orders to be filled within a certain time
period (i.e. service level agreements (SLA)). To meet these requirements, the provisioning
process should be actively monitored (jeopardy management) to identify those orders in
danger of breaching their mandated service levels. Automated or human judgment can
then be applied on whether they should have their priority raised to meet their SLAs.
Where shared infrastructure is used for different retail providers, churn may require
provisioning alter network settings. The network settings can indicate which retail provider
currently ‘owns’ the retail relationship, or provide data security to prevent unauthorised
access to the network settings by a competing retail provider’s staff.
Service Assurance
Service assurance, like provisioning, is a network interfacing function. When network-
related problems are identified, assurance sees that they are managed until fixed.
Assurance should also include the proactive identification of otherwise unreported
problems and their management on to resolution.
When problems occur, the biller’s staff capture the problem details provided by the
customer. Problems are logged and prioritised based on the staff available and the
expertise required. Once allocated to staff, a problem’s cause is identified and the
appropriate fix applied. Some problems can be fixed remotely, whilst others may require
the dispatch of network staff to the customer’s location.
Any shared use of network staff between provisioning and assurance requires that the
competing priorities of new orders and network problems be carefully managed (work
force management). The different skill levels between staff, and dedicated teams for
specific tasks (e.g. new connections) can cause complications. New connections can be
relatively standard; problem resolution usually requires more experienced staff. More
complex network technologies (e.g. telecommunications) may require a detailed
understanding of a range of technology platforms.
Different industries (based on their networks) will require different levels of assurance
activities. Billing of government charges based on a residential address’s details may have
assurance issues concerning the postal address for documents, who owns a property and
its current value. These can be addressed from a central office location during business
hours. Water networks will require registered plumbers with access to underground pipe
information, equipment to replace faulty pipes, and details of where to turn the water off.
These details must be available to a large, distributed workforce operating 24 hours a day
from trucks and vans.
________________________________________________________________________
________________________________________________________________________

When multiple problems occur, assurance must identify whether there is a common cause.
The identification of a common cause can sometimes reduce the overall resolution effort
by targeting the underlying fault rather than each individual problem. However in other
cases, each individual problem may still need to be tested and closed. Identifying an
underlying fault can also identify the broader scope of an outage / issue and allow the
identification of unreported impacts. Proactive resolution and notification can then provide
a higher level of customer service.
Even more than ordering, assurance uses service level monitoring to identify when
outstanding problems are in jeopardy of breaching service level agreements. The time
allowed to resolve problems will normally be included in commercial contracts, or, in non-
commercial circumstances, by minimum regulatory standards.
A premier level of ‘service restoration’ may be offered to customers as a ‘value-add’
product. Alternatively, essential service providers (e.g. hospital, doctor’s surgery or police
station), or emergency situations may require a premier service. Additional information on
such situations can be retrieved from the billing system so that it can influence the priority
with which a specific problem is addressed.
When service levels are breached, rebates and contractual credits may apply. When a
problem is a customer’s fault there may be ‘time and materials’ charges applied to recover
the biller’s costs. These internally generated, non-network charges are forwarded to billing
for inclusion on the customer’s bill.
Data Analysis
Data analysis combines data from different sources, validates its accuracy, transforms its
format to one suitable for high-performance analysis processing (rather than transaction
processing), and assembles it ready for use. For billers, data analysis can provide insights
into customer, transaction and network information that are not easily obtained using
regular database queries.
For example, data warehouses can consolidate information from across the biller’s
systems to enable integrated dissection of the biller’s data. Queries can be performed by
business staff to identify new sales opportunities, regional performance differences, clarify
the effectiveness of different marketing campaigns and track long-term purchasing trends.
By analysing behaviour over a sufficiently long time period and for a large customer
sample, a biller can construct predictive models of customers’ propensity to perform future
activities. Examples include the customers’ likelihood to purchase (e.g. useful for sales
and marketing), or change providers at the end of their contract period (i.e. churn). It can
also be one of the data sources used in fraud detection.
Fraud Detection Fraud detection analyses data to identify fraudulent or suspicious
behaviour. The specific methods used to perform this analysis are often restricted to a
select group to ensure the ‘alarm’s tripwires’ remain hidden. Suspicious activity may or
may not be criminal. A customer’s change of behaviour may be based on a change of
________________________________________________________________________
________________________________________________________________________

circumstances, and, just like a credit card company confirming an unusual purchase, once
investigated can be dismissed from further consideration. The customer’s new
circumstances may present sales opportunities that can be passed to other business
functions.
For high-value transactions, fraud detection may need to be performed in near real-time in
order to limit the biller’s financial exposure. Lower value transactions may be analysed
after a brief delay using cheaper infrastructure than required for near real-time checking.
Marketing Support Billing can be an information source used to support the biller’s
marketing initiatives. Billing’s core databases can include information such as contact
details, market segmentation information, and details of recent purchases. Billing’s
accurate information is important where regulator-mandated codes-of-conduct limit the
frequency with which a customer can be contacted. Candidate targets for marketing
campaigns may be identified by the data analysis function.
Why Multiple Billing Platforms Are Used
A network business may have multiple billing instances because of strategic policy
decisions, corporate mergers, and/or separately conceived product or service
development. Complex billing environments can use different billing platforms to support
solutions and cost structures for different market segments. The causes of multiple billing
instances include:
Time pressures New products or services introduced quickly are given a separate (new)
billing instance where the use of an existing billing platform would delay introduction or
subsequent modifications.
Product Maturity Mature products are likely to have stable billing requirements that can
use a less sophisticated billing platform whilst new products and services may undergo
frequent marketing changes and so will need a billing platform that can be changed quickly
and easily.
Market segmentation Different market segments may need to be billed on separate
billing platforms in order to support their different configurations and independent
development needs. e.g. wholesale / retail, residential / small business / corporate
Product segmentation A business with different networks may have silo billing systems
aligned with each network. e.g. internet / fixed phone / mobile phone, gas / electricity
Geography A business operating in different regions may operate regional billing
instances. Foreign currency processing may also require separate billing.
Capacity The same billing platform may need to be replicated because of performance or
size limitations.
________________________________________________________________________
________________________________________________________________________

Business Continuity The same billing platform may be replicated to maintain business
continuity. This can be done by operating multiple live systems, or by having a ‘mirror’ site
that can be brought online if required. Operating redundant systems can be expensive, but
may be less expensive than the lack of a business continuity plan.
Regulation Regulators may require that product or market segments use separate billing
systems.
Transition This can occur where an older billing system is migrating into a newer system,
or several billing systems are being consolidated into one.
Capability Speciﬁc billing systems (or sub-systems) may be tuned or designed to operate
for a limited function set. For example, such systems might be employed for real-time
transaction pricing, high-volume batch rating, or pre-paid balance management.
Role Rather than having one billing system do everything, different billing systems may
be tasked with different scope responsibilities. This approach can allow a biller to provide
customised solutions for their hardware, software and service level agreements. e.g.
content settlement, interconnect billing and reconciliation, retail billing.
Security Regulatory or marketing considerations may require a biller to provide separate
billing repositories enabling data environments to be demonstrably ‘secure’ by being
physically rather than logically isolated within the one database.
Buy versus Build Historically, many billing system were developed in-house, but may be
replaced in the future by vendor software packages. A biller may choose to deploy a
software package for new products whilst retaining its in-house billing system for existing
products.
The most effective number of billing instances will, of course, vary from biller to biller, and
depend on the biller’s historical position, available opportunities, and goals. The best
billing solution will proceed from a clear statement of a biller’s strategic direction, rather
than simply be a result of historical decisions.
From an operational point of view, it is essential to ensure that the chosen solution can do
the jobs required of it. A reduction of billing instances based solely on ﬁnancial
considerations or an arbitrarily determined environment number can limit a biller’s ability to
respond to market changes if the jobs that need doing can’t be supported. For complex
networks, it is likely that several billing instances will be required, particularly where there
are competing business priorities.
Nevertheless, multiple billing instances pose risks and issues that need to be addressed,
such as:
Potentially increased costs Multiple billing environments can generate some dis-
economies of scale with each environment requiring its own suite of staff, hardware,
________________________________________________________________________
________________________________________________________________________

software, and license fees. When separate instances operate the same software and/or
hardware (operating environment), some costs can be reduced by resource sharing or
negotiated volume discounts.
Staffing contention Separate billing environments with a development program reflecting
new business initiatives may be limited in their ability to share their staffing expertise. Busy
staff working at capacity may have limited scope to leverage their skills across other billing
platforms. Separate, vendor-specific development teams operating at capacity may
moderate cost arguments associated with separately staffed billing systems (since the
same number of staff are busy doing the same volume of work).
Where billing platforms are provided by different software vendors, staff may be able to
leverage functional knowledge but not vendor-specific implementation experiences. Billers
with a wholesale division may be required by regulators to provide some separation
between their wholesale and retail billing staff.
Internal environmental complexity Billing changes can require a more careful design
when many separate applications are impacted. Whilst some initiatives may be specific to
a market segment, corporate-wide initiatives may need to be developed and separately
applied to each billing environment.
External environmental complexity External applications interfacing with billing must
handle multiple billing systems to perform their job. e.g. corporate GL receiving feeds from
different billing systems.
Speed of Change Where multiple systems must be updated to implement a change, the
deployment rate may be reduced due to the coordination overhead. This can be
moderated where changes are limited to one billing environment’s market segment.
Functional limitations Locating a customer’s products on many billing systems can
restrict the billing options that a customer can be provided. e.g. when multiple systems are
involved the biller may be unable to discount across the products’ billing silos.
Vendor Choice
The most complex networks generally have multiple billing systems provided, at least in
part, by outside vendors. Billing systems from multiple vendors can reduce a biller’s
business risk by avoiding a software monoculture, by providing competitive vendor choice,
and by reducing the business impact of a defective system. Smaller networks or
government agencies may be able to address their needs with a single system, often
developed in-house.
A software monoculture generates business risk if the outside vendor is unable to meet the
biller’s subsequent development needs. Without development alternatives, a biller’s ability
to respond to market or regulatory change is dependent on the efforts of a single outside
vendor, which may go out of business, or be acquired, leaving the purchased software
unsupported. The use of (software) code escrow will only limit damage here.
________________________________________________________________________
________________________________________________________________________

Where a biller uses several vendors, competitive pressures are likely to produce better
platforms at a lower cost. If different vendors construct the several billing platforms of a
network, there will be integration issues. However, careful management can normally
resolve these issues.
If a network’s single billing environment fails, the biller’s cash needs will be dependent on
service restoration. With multiple billing environments, part of the biller’s network can
continue to operate. Where multiple billing environments use different vendors, cross
system comparisons over time can provide supporting data for the biller’s future platform
choices.
There is no ‘correct’ solution for all billing situations. Each network must find its own
balance of marketing, regulatory, performance, staffing, and financial requirements to
achieve the best possible outcome. Practical considerations may place limitations on what
is possible. Any future solution’s starting point will be the biller’s present systems, and this
may limit what can be cost effectively achieved. As well, historical technical (e.g. preferred
vendor), political (e.g. management political capital) and strategic business choices (e.g.
billing consolidation) may be too entrenched to support some recommended ‘green field’
solutions.
‘Billing’ As A Marketable Offering
Once a network biller develops billing expertise it can offer to provide managed billing
services to third parties. These services can be offered on a wholesale or retail basis.
A network biller offering its billing services on a wholesale basis (‘billing on behalf of...’)
does so as a ‘value-added’ service (for a charge) avoiding the need for wholesale
purchasers to develop their own capabilities. These purchasers are then free to focus on
their own marketing and customer-facing tasks. Typically, the scope of the billing provided
would be limited to the network biller’s products that the purchaser is reselling, but a more
sophisticated wholesale purchaser may require that third party products also be included.
Billing can be a business’s core product offering. Such a ‘billing bureau’ processes and
bills for the products and services of other parties, and provides an alternative to
purchasing billing on a wholesale basis from a network provider.
Modern billing platforms can operate logically separate billing instances within one
software and hardware platform without the need to deploy several physically separate
billing systems. This approach allows the biller’s existing infrastructure to be leveraged
(reused) without the need to deploy separate billing instances for each sale of ‘billing’ to a
new customer.
Convergence
Traditionally, the billing function was performed by specialised, smaller applications that
each delivered part of the billing solution, but with limited additional functionality. As
________________________________________________________________________
________________________________________________________________________

information technology has matured, software vendors have consolidated functionality and
capabilities into their core software packages so that now fewer applications need to be
deployed to achieve a more capable result.
Modern billing software can perform more of the end-to-end billing tasks (functional
scope), operate across a biller’s more diverse market offerings (product scope), and
process the larger and more complex billing required by today’s billers (performance). A
biller can choose to operate multiple environments based on strategic criteria (e.g. by
customer segment), rather than be forced into that situation to achieve sufﬁcient coverage
of their business requirements.
Billing is converging from many directions including:
Payment methods One platform offering pre-paid and post-paid billing for the same
products using the same infrastructure. The same billing options can be offered
consistently across the biller’s entire customer base. However the network requirement to
terminate pre-paid access when the pre-paid balance is exhausted still remains.
Consolidated (single) invoice Historically, a customer received separate invoices for
each product suite (e.g. ﬁxed phone, mobile phone, internet). Billing platforms now provide
the ability to consolidate all this information onto one customer invoice supporting a biller’s
cost reduction and customer service goals.
Credit management The use of a single whole-of-customer debt balance, rather than
multiple debt balances by product silo, supports consolidated credit management
processing. The biller can use this better view of the customer’s debt and payment history
to reduce their bad debt risk by identifying non-payment across all of a customer’s
services, and supports the full disconnection of a customer for non-payment rather than
isolated services.
Real-time versus batch This supports the biller’s ability to market the same rating and
pricing plans across their entire product suite. Customers can be offered the same
marketing message regardless of the underlying technology.
Cross product pricing Using one billing system that contains all of a customer’s product
information enables pricing across products to be performed. Marketing can use this to
support sales of new or less popular products, or use bundles to attract and retain more of
a customer’s expenditure.
________________________________________________________________________
________________________________________________________________________

Chapter 3: The Key Functions of Billing
Five Core Functions
Billing’s core functions activate the network for a customer, collect details of network
transactions, determine the appropriate chargeable amounts, apply applicable discounts,
format the bill, and send the bill to the customer. There are also supporting functions that
transmit the billing details to the biller’s internal and external systems, and provide access
and maintenance of customer details for resolution of customer issues.
These core functions also provide the raw data for secondary, though still important, billing
functions. For example, a bill must have been generated and remain unpaid before credit
management can act. Without the core billing processes that form and distribute the bill,
there is no record of a debt to pursue. Of course, the credit management function is not
involved in generating the bill. This chapter is intended to provide an initial context for
those readers with little or no work history in billing.
Activation / Service Provisioning Interacts with the network to enable new customers,
and modify details for existing customers. (Chapter 10)
Transaction Collection / Mediation Collects and standardised details of customers’s
network activity. (Chapter 11)
Transaction-level pricing (Rating) Individually prices both network and non-network
charges. (Chapter 12)
Bill Generation / Bill-level pricing Periodically collates a customer’s charges and
prepares a bill, applying discounts based on the customer’s collective transaction volume,
value or other criteria. (Chapter 13)
Bill Presentation / Distribution Prepares the raw bill information into customer friendly
formats that can be sent on paper, viewed across the internet, or sent via ﬁle. (Chapter 14)
Two Supporting Functions
These two functions enable other parties, both internal and external, to access details of
the billing process and the customer’s billing arrangements. The account maintenance
function is an online, interactive function that enables staff (and possibly customers) to
inquire and update details of individual customers and transactions. The reporting /
business support function uses consolidated, batch interfaces to supply details for all
customers.
Downstream Reporting / Business Support Supplies bill and customer details to
ﬁnancial and reporting systems (e.g. the corporate data warehouse) for further processing.
________________________________________________________________________
________________________________________________________________________

Account Maintenance / Inquiries Supports inquiries from customers and staff about a
customer’s billing arrangements (e.g. orders, payments, bills). Customers may also be
able to view their own information and self-serve themselves for a limited range of
purchase / update transactions.
Activation / Service Provisioning
A customer order can be understood as a checklist that drives change in the network,
which is later reflected in billing. This change may include the inventory reservation of
specific equipment (e.g. telecommunication lines, electronic tollway tags) and its
association with a specific customer. Such reservations ensure that future orders do not
double-book the same piece of equipment.
It is almost always cost-effective to automate the network modification (activation) process.
Automation will both reduce the staff required to maintain network connections (particularly
as the network or customer base grows), and provide the customer with more prompt
network connections and updates.
Despite validation in the ordering process, an order can error during network provisioning
and require human intervention. Errors can be caused by a misalignment of validation
processes between ordering and network provisioning, or can be due to a misalignment
between the customer’s details activated on the network and those already held elsewhere
(e.g. billing, ordering).
Some orders will not affect the network itself, but instead will change the customer’s billing
arrangements. For example, a telecommunications customer may select a new pricing
plan with cheaper long-distance phone calls but a higher monthly subscription. This update
does not affect the customer’s network connection or where they can call, but when calls
are made the new pricing plan will affect the amount the customer is charged. Orders not
requiring network manipulation can be passed directly to the billing system for processing.
Due to the diversity of possible networks, Billing for Business Networks will focus on the
billing impact of different provisioning approaches, rather than the networks themselves.
Transaction Collection / Mediation
Two important considerations drive this billing function. First, it is difficult to communicate
with complex and diverse networks. Second, the raw information collected from a network
may be insufficient (or unreadable) for billing and require manipulation before it becomes
useable.
A large biller (especially in the telecommunications industry) may operate a network with
different equipment vendors using various software programs across geographically
diverse areas. To collect network information, the mismatches among the various network
systems need to be systematically (and transparently) rationalised. The specific
commands in one vendor’s program are likely to be unique to its hardware. Even the same
________________________________________________________________________
________________________________________________________________________

vendor may modify commands on new versions of its equipment’s software causing
subtle, but important, changes in the network’s operations.
The collection process must address these differences and isolate them from the rest of
the billing process. Downstream billing processes must receive transaction records without
worrying about how they were obtained. By doing this, the integrity of the billing process is
preserved, even when new network equipment is installed.
The raw information collected from the network may omit information required by billing.
This can be because the network doesn’t need it to deliver network services. Also, some
network information may be in error (e.g. transposed phone number digits), require
enhancement (e.g. additional field values based on the transaction), or require
modification (e.g. time zone standardisation) before it is passed to billing. Data mediation
thus serves to isolate the idiosyncrasies of the network from the billing process.
The centralised transaction correction and standardisation performed in mediation reduces
the maintenance effort expended downstream to pass existing transactions to billing, and
the integration effort required when new transactions (and networks) are introduced. The
standardised transaction format(s) generated by the collection / mediation function can be
reused by other business functions. e.g. fraud detection, regulator reporting, network load
analysis
Transaction-level pricing (Rating)
Rating performs the heavy lifting for billing. Rating combines network information,
customer details and marketing (rate) information to determine the specific amount a
customer is to be charged for a given transaction or transaction sets. The initial
determination may be modified by later bill processing to reflect discounts and taxes.
Where a biller operates in a competitive market (assuming no changes in the network), it
will reflect any (re)packaging of existing offerings in rating. Marketing imperatives may
dictate frequent repackaging with short lead times. The speed with which changes can be
made, and the versatility of the available rating methods determine the level of support
billing can provide to marketing. A biller which does not compete for customers will still
require accurate rating for its mass markets, and possibly customised offerings for its
larger corporate customers.
The more detailed the information passed from the network, the more options there are for
rating differentiation. For example, if a transaction’s date is known then day-of-week rating
can be applied; a transaction’s time can support peak and off-peak price offerings.
Rating may be applied uniformly across a large customer segment (e.g. consumer), or be
tailored for high-value customers (e.g. large corporates). Each transaction must have the
appropriate rating approach determined. Different transactions for the same customer are
likely to be charged differently. Subsequent transactions may be rated differently based on
the totals of transactions to date. To enable timely transaction processing, billers with high-
transaction volumes usually require substantial infrastructure (i.e. IT hardware).
________________________________________________________________________
________________________________________________________________________

Rating may be performed after the fact (e.g. charging for water) or in real-time (e.g.
prepaid phone calls). There is a substantial difference in complexity between these two
approaches. Achieving real-time processing requires high-availability, high-speed
infrastructure to ensure that the correct price can be supplied quickly at all times. Rating
for ‘after the fact’ transactions can be performed with some latitude as the rated price of
(say) phone calls is not required to execute the network events (i.e. connect the phone
calls).
Bill Generation / Bill-level Pricing
This function aggregates and forms bills to customers for transactions and/or activity
performed within a given time period. The billing frequency may be at the customer’s
choice, be driven by industry norms, or be based on negotiated terms. Interim bills may be
prepared when a need to convert unbilled charges into debt is identified. Final billing may
be performed when a customer’s network connection is terminated. Operationally, the bills
for thousands of customers are usually prepared at the same time.
It is advisable to perform validation within a billing cycle to review the correctness and
reasonableness of the customers’ bills. Validation asks whether bill totals are reasonable,
taking into account a given customer’s market segment, and their historical activity.
Bills that fall outside of industry and business specific ‘correct and reasonable’ tests may
be held for review by the biller’s staff before their release. Bills for sensitive or important
customers may be held and reviewed to minimise the impact of any errors.
Bill-level discounting may be performed using the customer’s aggregated purchase
information. This discounting provides a customer (marketing) benefit by rewarding high-
spending. A deduction (discount) is made from the amount calculated in transaction-level
pricing (rating) and the nett amount is presented on the customer’s bill.
Some bill-level discounts may require a repricing of individual transactions during the bill
generation process. This generates a high and immediate processing load. Repricing
performed during bill-generation is less common though the full range of pricing methods
can be made available. The initial pricing performed in rating is performed gradually
(through the month) and operates with a lower (average) peak load. The time-critical
repricing performed within the bill generation process necessitates a more expensive
infrastructure (i.e. IT hardware) to supply the additional processing capacity.
Once all charges for the period have been finalised, rounding is performed to transform
high-precision amounts (four or more decimal places) into charges that can be presented
to, and paid by, the customer in an understandable format (e.g. two decimal places). This
can also include the rounding of the bill to support easy payment by the customer. For
example, in Australia, due to the lack of one and two cent coins, bills may be rounded
legally to the nearest five cent multiple. The rounded amount could also be carried forward
and applied to the next bill.
________________________________________________________________________
________________________________________________________________________

At the completion of this step, the amounts to be charged have been calculated, and the
information to be presented on the bill sourced (e.g. marketing messages, prior payment
details). The next function formats these details for presentation to the customer.
Bill Presentation / Distribution
Bill presentation deals with the bill’s physical appearance. The charges, supporting
information and any marketing messages, as determined in the preceding function, must
be formed into an effective format for presentation to the customer. Distribution involves
getting the bill to other parties, principally, but not only, the customer. Thus, distribution is
concerned with both media and mechanisms.
A bill’s physical appearance is influenced by the biller’s marketing function. Beyond the
need to present a request for payment, in a format that explains why the customer is
charged the billed amounts, a bill can differentiate the biller from its competitors. Since the
bill is a core communication channel to the customer, the clarity and breadth of the
information must be carefully considered, and may include information unrelated to what
has been billed. For example, energy companies may want to show customers the
quantity of carbon released to the atmosphere. Other information may be required by
regulation or tax law (i.e. due to the bill’s status as a financial document).
The bill’s details may be distributed through many different channels. Many of these
channels are directed at the customer, but at least one of them will be for the biller’s
internal staff. External channels include paper, email, internet based self-service portals,
and optical media (e.g. DVDs). The channels used for different customer segments will
depend on cost and usability trade-offs. Paper is relatively expensive compared to delivery
via the internet, and does not support the data analysis desired by corporate customers.
On the other hand, the usability of paper and internet-delivered consumer bills for mass-
market customers is high, but corporate bills composed of thousands of pages and
delivered by courier truck are more of a challenge.
The same bill information may be delivered to multiple destinations. For example a
summarised format may be delivered to a corporate customer’s head office on paper,
while a detailed statement may be delivered by DVD to the customer’s data analysis
department, and location specific reports may be manually downloaded from an internet
portal by the customer’s regional offices. In this case the same information is utilised, but
the views are tailored for different needs within the customer’s business functions.
A bill not only requests payment from a customer, but also provides support for the
revenue the biller receives. Bills invariably need to be retained for a variety of legal, tax
and regulatory reasons, and therefore effective storage and retrieval mechanisms are
required to address these concerns.
Downstream Reporting / Business Support
Billing generates a high-volume of information that can be used, or is required, by a biller’s
other business applications. The needs of some of these recipients will be more urgent
________________________________________________________________________
________________________________________________________________________

than others. For example, the identification of possible fraud will require prompt delivery
(and indeed may require specific information directly from the network), whilst a profitability
analysis of the biller’s business can perhaps be addressed with a short delay.
Large corporate customer, industry regulators, and other outside parties may also receive
billing reports. In these circumstance, strict segmentation of the report information is
required to avoid exposure of private customer details and competitive intelligence.
Some downstream functions, such as financial postings, will require most of the billing
detail. Each bill must be traceable to a summarised financial posting, and each
summarised financial posting must be related to its constituent sources. Other reporting
will be performed on an exception basis. That is, criteria will be applied to identify a small
subset of transactions, customers or situations that need individual review.
The information provided by billing to other functions may be raw data that is subjected to
further processing. For example, the prices charged to customers for the music they
download can be supplied to a biller’s content settlement system (Chapter 26). The
specific settlement arrangements between the biller and each music provider are then
combined with the ‘billed’ details to determine the individual financial settlements to be
paid.
Account Maintenance / Inquiries
When databases are maintained and stored in multiple locations (copies), one of those
locations must be nominated as being the point-of-truth (i.e. the database of record). When
two locations disagree on a database entry, the value held by the database of record is
deemed to be correct. This role as the data ‘master’ means that the maintenance,
replication and back-up processes for the database of record must have integrity.
A billing system contains many databases of record. These hold details of the customer
and their billing arrangements captured during the ordering and provisioning processes,
and bill and financial transactions generated by billing. Some reference information (e.g.
rates) may also be mastered from the billing system.
Some billers may choose to ‘master’ their customers’ details in other functional areas (e.g.
a CRM platform). In these cases, the data is supplied to the billing systems by either
replication between databases as it is maintained, or only as and when required for the
billing process.
Whichever database of record approach a biller takes, the data within the billing systems
must be accessible to address internal staff and customer inquiries. Some data
maintenance will also be required to update customer details and reflect changes
performed by staff (e.g. notes against a customer’s account). Historically, batch orders
were processed daily. This approach is still performed, but increasingly the direction taken
is to perform maintenance in real-time, or near real-time (i.e. with a delay of minutes). This
allows any errors to be addressed immediately with the customer rather than the next day.
________________________________________________________________________
________________________________________________________________________

Customers ringing the biller with an inquiry will be assisted by the biller’s staff using an
online system that retrieves and updates information held on the billing databases. The
online system may be a billing-only interface, or a specialised CRM package that
aggregates non-billing details in order to provide richer information about the customer.
Where provided, customers can use a self-service portal using internet technologies to
examine their own account details, possibly performing limited updates (e.g. purchases)
without the intervention of the biller’s staff. The biller’s staff may use a version of the same
internet portal with additional maintenance and inquiry functionality enabled. This
additional functionality would perform internal functions not suitable or desirable for
customers to operate (e.g. dispute resolution, credit checking).
By volume, most maintenance of the customer database will be sourced from the ordering
systems (e.g. CRM application). However, there will be some complex maintenance that is
best done manually to allow immediate validation of the correctness of actions performed.
For example, if a corporate customer wishes to modify their large organisational hierarchy,
manipulation using a GUI screen with its immediate feedback is likely to generate a more
accurate result than a batch maintenance order submitted overnight.
________________________________________________________________________
________________________________________________________________________

Chapter 4: The Core Data Concepts Of Billing
Five Core Data Concepts
The billing process operates on data collected from customers, networks, marketing and
other sources. Billing applications contain a range of customer, network and marketing
concepts, but a core set forms the basic framework that anchors bill processing. This basic
framework is then supplemented by vendor, industry and biller specific extensions.
A data concept is implemented as a structured grouping of related fields into one or more
related ‘databases’ that billing processes can reference during bill processing. A
customer’s database entries will be updated over time reflecting their ongoing interaction
with the biller and its network(s).
Core data concepts are often shared across different functional areas within the biller, but
each functional area focuses on the specifics relevant to its local operational needs. For
example, a network function (e.g. activation) will focus on the network-specific data (fields)
representing a telephone service whilst billing will focus on different billing-centric data
(fields).
In this example, the data concept of a network ‘telephone service’ is ‘shared’ across
functional domains through the use of a common and unique identifier, the telephone
number. Identifiers such as these allow databases to be reconciled and other cross-
domain processing to be performed without the forcing the replication, and much worse,
maintenance of all data fields across a biller’s entire operational environment.
These five core data concepts will be explained later in more detail. This chapter provides
an initial context for those readers without a work history in billing.
- Customer identifies each external person or business entity involved in or responsible for
billing or subsequent bill payment. (Chapter 17)
- Accounts are the structural entity at which the billable charges incurred against a
customer’s network services are aggregated to form bills, and the entity against which
(pre-paid) credit / (post-paid) debt amounts are often stored. (Chapter 18)
- Service entities differ the most between industries and network technologies as they
represent the network delivery point for the biller’s market offerings. (Chapter 19)
- Products represent what the biller sells to its customers including network (e.g.
consumption) and non-network (e.g. pricing plans) offerings. (Chapter 20)
- Billing Hierarchies are a relationship structure that associates customers, their accounts
and related services. In more complex (corporate) billing, hierarchies can link network
services into sub-groupings for use in bill presentation and pricing. (Chapter 21)
Important second-level data concepts are either generated by the billing act, or extend /
support the billing relationship and include:
________________________________________________________________________
________________________________________________________________________

- Taxation
- Address
- Contact History
- Notes
- Bill Details
- Disputes
- Financial Postings
Databases of Record
The core data concepts listed above represent key information that must be shared
accurately and consistently across multiple functional domains within the biller (e.g.
products), and therefore the databases that hold these concepts are often classified as
databases of record. Databases of record (DBoR) are the referential ‘points-of-truth’ used
when determining an accurate and definitive value for a data value or record.
DBoRs are updated in one ‘location’ using a consistent update process, even when copies
of the database are stored in multiple locations around the biller. The ‘primary’ or ‘master’
database is deemed to be the ‘truth’, with all databases being ‘secondary’ or ‘slave’ copies
of this information. Additional processing costs and complexity may be incurred associated
with database replication and alignment to maintain the ‘primary’ database’s status as a
DBoR reference point.
Customer
You, the reader, are a customer, as is the company you work for. The customer data
concept helps billing differentiate between you, your company and other similar customers.
Details stored against each customer entry enable a specific customer to be identified. For
an individual these details might include their full name, date of birth and drivers license
number. For a business entity these details might include the business’s registered
corporate name, registration jurisdiction, company officer(s) and business registration
number.
The customer concept associates customer’s details across the biller’s entire operations.
Data extracts from the biller’s different applications (including billing) can be brought
together in one location (e.g. a data warehouse) and associated using a customer
identifier to form a consolidated ‘customer’ view. To ensure the customer identifier is
allocated consistently, the ‘customer’ database is often treated as a database of record.
Identifying customers is important to billers as it enables them to permit or deny access to
their network’s activities. For example, a biller may record information against a customer
to highlight historical bad debt or an existing poor payment history. When such a customer
seeks to connect a new or expensive network service, the biller may ask that the bad debt
be repaid or request a security deposit is taken before the service is established. When
corporate customers declare bankruptcy, the courts can require the biller determine their
total financial exposure to the (now) bankrupt customer if the biller is to get the maximum
possible distribution. The (corporate) customer’s identifier allows the information from
________________________________________________________________________
________________________________________________________________________

multiple billing systems to be extracted separately and aggregated to form a consolidated
total. The customer can then be flagged as ‘bankrupt’ limiting their future activities within
the biller, with any ‘related’ corporate entities placed on a watch-list for tighter monitoring.
Account
An account is the point to which a customer’s purchases and / or liabilities are aggregated
before being billed. A customer may have only one account or request that their charges
are aggregated and billed across multiple accounts. For example, a residential customer
may choose to have separate billing for their family home and their holiday house. All
charges for the family home are formed up and sent via one bill aggregated against one
account, and similar processing is done for the holiday house’s charges against a second
account. A separate account might also divide the billing incurred by a ‘home office’ from
the billing associated with domestic ‘personal use’. For a corporate customer, accounts
can represent offices, regions or any other sub-groupings that supports the customer’s
business operations and/or accounting.
The account is also the entity against which debt is stored. Whilst customers may be held
accountable for payments, all financial transactions including bill debt, payments and other
adjustments are processed at the account level. Credit management of outstanding debts
can be performed at the account level, or all the debt across a customer’s collective
accounts can be aggregated and used to perform customer-level credit management.
Depending on the biller and their industry, the customer and account entities may be
treated as equivalent. This approach is more likely where customers within a network
commonly have only one account. For example, governments that levy rates / taxes on
property may find that relatively few customers own more than one property within their
jurisdiction, and hence the government may make little distinction between the customer
and account concepts.
Service
The service concept represents customer’s network access within the billing domain.
Since each network uses a different approach to describe access and network
consumption, this data concept differs the most amongst industries. Examples of services
on different networks include electronic tags attached to vehicles (tollways), meter
numbers (utilities), phone numbers (telecommunications), and property references
(governments). Aside from generic data fields, the characteristics of each network will
influence which additional network-specific data fields are required against each service.
Unique identifiers specify each network service so that the consumption at or access to
each service can be monitored, measured and controlled. Some networks support sub-
divided access to a network service with each sub-division qualified, possibly using a
separate identifier. For example, electricity meters may use separate ‘service’ identifiers
aligned with separate physical measurements performed for ‘peak’ and ‘off-peak’ power
consumption, or fixed-line phone networks may separate voice call charges from those
________________________________________________________________________
________________________________________________________________________

charges incurred by DSL broadband operated across the same copper ‘twisted pair’
network connection.
This differentiated measurement of the network service allows each ‘sub-division’ to be
charged for differently in billing. The separate qualifications used to identify service’s sub-
divisions must be included in the data passed from the network to the billing process to
support the charging of different rates (e.g. indicators of peak / off-peak).
Some network infrastructure (e.g. fixed phone lines) can support a (logical) division of their
services to generate offerings (and their associated billing arrangements) with multiple
billers. For example, a phone service may be provided by two businesses with one a long-
distance phone provider and the other operated by a local phone provider. A phone call’s
destination will determine which network it is carried upon, and how it will be billed.
Similarly, a residential fixed line voice service may be delivered by one provider, with a
DSL internet service, using the same physical infrastructure, provided by a separate ISP
business.
Separate (pre-paid) financial balances can also be stored against a customer’s services.
This is used in pre-paid billing where a customer tops up / recharges a service’s pre-paid
balance to control spending or budget expenses. For example, a parent might limit their
monthly outlay on their children’s pre-paid mobile phones by providing regular but fixed
amounts. When their children’s pre-paid balances are consumed, the children will be
unable to use their phones until their parent’s next (pre-) ‘payment’. The children can fund
expenditure in excess of their parent’s minimum outlay by pre-paying with their own
money.
Product
Products are what customers purchase from a biller. The product data concept must
support a biller’s entire suite of market offerings, with product complexity varying by
industry. For example, the telecommunications industry generates complex product
entities that can combine multiple network types into bundled offerings, charging different
amounts for network access and usage. A government entity generating rate notices
employs a limited, simpler product suite that changes only slowly.
The product concept captures all recurring, one-time and network usage charges that a
customer may purchase or incur, including all miscellaneous non-network charges, credits
and adjustments. Product definitions must also include details about which transactions /
access features to charge for, and the methods and rates to be used when calculating the
product offering’s price. For example, a phone service’s recurring access charge can be
charged at different levels and bundled with phone calls - bundles can offer cheaper phone
calls with a higher network access charge, or vice versa, with each arrangement
generating a separate instance of a billable ‘product’. The same network connection and
phone calls will be billed for different amounts depending on which ‘product’ offering the
customer has purchased from the biller.
________________________________________________________________________
________________________________________________________________________

Products need to be distributed throughout a biller’s operational systems to ensure they
can be ordered, activated in the network, have their problems fixed, and generate
appropriate financial postings. This need provides a distribution and synchronisation
challenge to ensure that all operational systems are using the same product view. For this
reason, the product database is best treated as a ‘database of record’.
Hierarchy
Hierarchies are a relationship structure that associate customers, their accounts and
related services. Their use in billing enables:
Whole-of-customer views A consolidated view of different parts of a customer’s billing
can assist a biller’s staff as they address customer’s inquiries and purchase requests. A
billing hierarchy allows views below the ‘customer’ level to be created.
Bill presentation For more complex (business) customers, billers can use hierarchies to
provide ‘value add’ presentation grouping of services on the customer’s bill. Different
levels of the billing hierarchy can represent levels of the customer’s business translated
through to the customer’s bill presentation. For example, a customer’s services can be
grouped together into ‘offices’, which are then grouped into ‘regions’, and then ‘states’,
before aggregating to a grand total at the ‘corporate’ level. Value-add subtotaling at each
level allows customers to assess their spending quickly at different levels of their business.
Pricing plans Rather than specify each service’s pricing plan, the biller can use a billing
hierarchy to attach a single pricing plan at a ‘high’ point in the hierarchy and ‘inherit’ its
pricing influence down through to the customer’s services lower in the hierarchy. This can
ensure pricing is applied consistently, and avoids the maintenance difficulties of aligning
pricing plans across a hierarchy of hundreds or thousands of services.
In billing, the benefits that a complex hierarchy delivers must be balanced against the
complexity, maintenance and processing costs it generates. Residential billing may use a
simple customer hierarchy structure to associate a customer’s few services together under
a single account. A large corporate hierarchy may include thousands of services grouped
in a customer-specified arrangement of variable hierarchy depth. A wholesale customer
may be billed for tens of thousands of services structured in a ‘shallow’ and very wide
hierarchy.
In these examples, the residential customer has little with which to form a hierarchy, the
corporate hierarchy can offset its maintenance costs against pricing and bill presentation
benefits, and the wholesale hierarchy is kept simple to minimise the maintenance costs in
a low margin customer relationship.
Seven Important Second-level Data Concepts
Aside from the data captured and stored for the core data concepts, billers will also
capture customer data generated by billing operations, interactions with customers, and
________________________________________________________________________
________________________________________________________________________

external reference repositories subsequently used in billing. These important second level
data concepts include:
Taxation These details describe the relationship between a biller’s products, tax
jurisdictions, and the methods used to calculate the correct tax amounts. Taxation details
are required in multiple places within the biller’s organisation including front-of-house sales
(providing the correct ‘total’ price), revenue assurance (validating system processing), and
billing. Billing systems are an important user of tax information since calculations are
usually based on the actual (final) amounts billed to customers. The financial and
corporate consequences of miscalculating tax means that details are often maintained
centrally and monitored closely as a corporate database of record.
Address Accurate descriptions of ‘location’ are important in billing, not just for creating a
bill. Different address types are employed depending on the situation. For example,
addresses can indicate the service location for a utility meter, the mailing address for bills,
website addresses (e.g. IP numbers, URL) may be used to calculate charges, or the
latitude and longitude may describe the location of equipment (e.g. pipes, communication
cables, electricity poles). Addresses are complex and often prone to inaccuracies when
entered manually by staff or customers.
Contact History Each time a customer and biller make contact, details of their interaction
can be stored to assist the biller in future contacts. Capturing details of historical contacts
avoids the need for customers to restate their problem / inquiry, and reduces the chances
of inconsistent messages supplied by the biller to the customer. The types and frequencies
of customer contacts can be analysed for patterns and trends that may indicate problems
(e.g. customers can’t understand their bill), and opportunities (e.g. proactively contact
customers if they are unhappy and at risk of changing providers).
Notes Notes complement the contact history and provide detailed information for
subsequent staff interactions with the customer. They can be generated internally by staff
during problem investigation, or automatically by billing processes. Details captured in
notes might include credit management activities (service suspension, disconnection),
special customer details (disability (deafness, blindness), doctor / hospital, relatives of the
CEO), internal contacts within the biller (sales representatives, account managers) and
customer-specific details (authorised representatives, restrictions on communication to
address identified stalkers).
Bill Details Whilst the debt and due date of a bill can be stored easily, to address all
customer inquiries additional information must be stored. These details can be used by
staff and customers alike to (re)view bills, and support follow-on processing such as
disputes.
Disputes Disputes are the formal recognition of bill details challenged by customers.
Dispute details drive the investigation of a customer’s challenge, but can also identify
systemic problems when excessive disputes are raised against (say) specific call
destinations, charges levied on a specific day or product families. By capturing details of a
customer’s disputes and holding them against a customer’s bill details, the generation of
________________________________________________________________________
________________________________________________________________________

duplicate disputes and subsequent financial adjustments against the same charges can be
avoided.
Financial Postings After bills have been generated, billers must store accurate financial
postings that reflect the charges levied against each customer. Individually, these postings
reflect the revenue, debt and payments attributable to each customer. In aggregate, the
postings form the foundation of a biller’s corporate financial ledger (e.g. revenue and
debt). Revenue analysis can be performed against customer’s purchases using additional
segmentation dimensions (e.g. market segment, geographical location, business unit,
product ‘family’). Customers must step through their bills, payments, dispute credits and
other miscellaneous financial postings and agree that their billed and outstanding amounts
are accurate. The biller’s auditors must do the same across all bills to sign-off the biller’s
corporate ‘books’.
________________________________________________________________________
________________________________________________________________________

Book: Billing for Business Networks (Sample Chapters): Understanding Billing Basics

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (15)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Book: Billing for Business Networks (Sample Chapters): Understanding Billing Basics