The document describes the high-level billing process for a telecommunications company. It involves multiple steps to set up customer accounts, provision services, collect call detail records, validate the data, and generate bills. Key steps include verifying new and existing customer data, creating orders and accounts, collecting and editing call records, applying fraud checks, and rating calls before accounts are billed. The process aims to validate all customer and call data at various checkpoints before bills are generated each cycle.

1. Billing High-Level "To Be" Process Model (New)
Process Narrative
The following narrative supports the High-Level process diagram for a billing cycle. The process
steps are detailed below. As the billing process proceeds, various edit and validation steps are
necessary in addition to the normal processing steps. While each normal process will be identified
with the overall process name and a number (e.g., BILL N.N), the edit and validation steps are not
numbered.
There are several processes that are outside the Billing process that should be referenced here since
they are the basis for billing a customer. While these processes constitute the ‘Customer Setup’
process, These are listed and briefly explained below in more detail for continuity:
New Customer Test
For each Winstar customer, a determination must be made as to whether a new or existing
customer is to be billed.
Initiator: Customer Satisfaction. This is envisioned to be an automated function within
Winstar.
Process: Verify if the Customer exists. This process is outlined below:
IF this is a new customer,
Proceed to Step Create Customer;
ELSE,
Proceed to Step Additional Service Test.
Responsible Organizational Entity/Office: Customer Satisfaction, and Order Entry
Additional Service Test
A determination must be made as to whether an additional service is applicable.
Initiator: Customer Satisfaction. This is envisioned to be an automated function within
Winstar.
Process: Verify if the addition of an additional service is applicable for this customer. This
process is outlined below:
IF this is an Additional service,
Proceed to Step Verify Account and Credit;
ELSE,
Proceed to Step Customer Ready for Billing.
Responsible Organizational Entity/Office: Customer Satisfaction, and Order Entry

2. Create Customer
For all new customers, an instance of the Customer entity must be created before a customer
can be billed. All applicable edit/validation rules are applied at this step to ensure the
completeness and integrity of Customer data entered.
Initiator: Customer Satisfaction. This is envisioned to be an automated function within
Winstar.
Process: Create an instance of the Customer entity for the new Winstar Customer.
Responsible Organizational Entity/Office: Customer Satisfaction
Create Account
For all new customers, an instance of the Account entity must be created before a customer
can be billed. All applicable edit/validation rules are applied at this step to ensure the
completeness and integrity of Account data entered.
Initiator: Customer Satisfaction. This is envisioned to be an automated function within
Winstar.
Process: Create an instance of the Account entity for the new Winstar Customer. Finance will
be responsible for the required credit checks prior to the creation of the Account entity
instance.
Responsible Organizational Entity/Office: Customer Satisfaction, Finance
Verify Account and Credit
For all new Products or Services, the customers’ Account must be verified before an Order
can be created. If applicable for the product or service, a credit check will be an integral part
of this step. All applicable edit/validation rules are applied at this step to ensure the
completeness and integrity of Account data entered.
Initiator: Customer Satisfaction. This is envisioned to be an automated function within
Winstar.
Process: Verify the existence of an instance of the Account entity for the existing Winstar
Customer, and the credit limits associated with the account. Finance will be responsible for
the required credit checks prior to the creation of the Account entity instance.
Responsible Organizational Entity/Office: Customer Satisfaction, Finance
Create Order
For both new customers, and an additional service, an instance of the Order entity must be
created before a customer can be billed. All applicable edit/validation rules are applied at this
step to ensure the completeness and integrity of Order data entered.

3. Initiator: Order Entry. This is envisioned to be an automated function within Winstar.
Process: Create an instance of the Order entity. This step will be the same for new or existing
Winstar Customers.
Responsible Organizational Entity/Office: Order Entry
Process order
All new instances of the Order entity must be processed, and all product and service entries
will be validated against the Product Catalog (PCAT) entity. This must occur before the
billing of a new customer, or the billing of an additional service for an existing customer can
be initiated. All applicable edit/validation rules are applied at this step to ensure the
completeness and integrity of Product and/or Service data entered.
Initiator: Order Entry. This is envisioned to be an automated function within Winstar.
Process: Create an instance of the Ordered Product entity. This step will associate an Order
with one or more unique instances of the Product Offering entity. This step will be the same
for new or existing Winstar Customers.
Responsible Organizational Entity/Office: Order Entry
Provision Order
All Orders must be provisioned. All Order entries are validated against the Inventory and
Switches entities. This must occur before the billing of a new customer, or the billing of an
additional service for an existing customer can be initiated. All applicable edit/validation
rules are applied at this step to ensure the completeness and integrity of Order, Inventory, and
Switch data entered.
Initiator: Provisioning. This is envisioned to be an automated function within Winstar.
Process: This step will associate an Order with one or more unique instances of the Inventory
and Winstar Switches entities. This step will be the same for new or existing Winstar
Customers.
Responsible Organizational Entity/Office: Provisioning
Customer Ready for Billing
After all the prior process steps have been successfully performed, a Customer is considered to
be ‘Ready for Billing’. To reach this stage, the following processes must have been performed
successfully:
An instance of the Customer entity will have been created with its associated Account
entity.
All new Orders will have been fulfilled, provisioned.

4. All data entered will have been validated against the appropriate entities.
All applicable edit/validation rules will have been applied when this step is reached to
ensure the completeness and integrity of Customer, Account, Order, Inventory, and
Switch data entered.
At this point, a Customer can be considered ‘Ready for Billing’.
Responsible Organizational Entity/Office: Customer Satisfaction, Order Entry, Provisioning,
and Billing

5. When a Customer has been established, and is ‘Ready for Billing’, that customer can be included in a
billing cycle. At this point, the processes that constitute a billing cycle start.
BILL 10.0 - Verify/Validate customer/billing data
All Customer billing data must be verified/validated before the billing process can proceed. All
applicable business rules for billing a customer are verified at this checkpoint. Integrity and
consistency rules are applied to ensure completeness of customer information for billing purposes.
Initiator: Billing. This is envisioned to be an automated function within Winstar.
Process: This step will establish a portion of the Customer base to be included in the billing cycle.
The lower level steps in this process are listed below:
Determine the type of account to be billed in this cycle (e.g., Large Accounts, LECs, and
Data).
Extract a subset of the Customer base of a pre-determined volume that Customer Satisfaction
(CSAT) can reasonably support for billing inquiries.
The purpose of the two prior steps is to break out the Customer base efficiently based on
the type of account to be billed in this cycle, and the number of Customers for each
account type.
Verify the billing data for all Customers included in this cycle for completeness.
Examine Payment history and past due charges.
Responsible Organizational Entity/Office: Billing, Customer Satisfaction
Reject Customer Data Test
A determination must be made as to whether the customer billing data is valid for this cycle.
Initiator: Billing. This is envisioned to be an automated function within the billing process.
Process: Verify if the customer billing data can be passed through this billing cycle. This process is
outlined below:
IF the customer billing data is not valid,
Proceed to step BILL 20.0, Return data to Service Coordinator;
ELSE,
Proceed to Step BILL 70.0, Collect Call Detail.
Responsible Organizational Entity/Office: Billing
BILL 20.0 - Return data to Service Coordinator
All Customers billing data that cannot be verified/validated will be returned to the appropriate
responsible office for analysis and correction.
In addition, this process will trigger Step 30.0, Send Customer Data to Fraud Management.
Initiator: Billing. This is envisioned to be an automated function within Winstar.

6. Process: This step will return Customer billing data to the appropriate Service Coordinator. This is
necessary to ensure that all possible Customers are billable.
Responsible Organizational Entity/Office: Billing, Customer Satisfaction, Provisioning, and Order
Entry
BILL 30.0 – Send Customer Data to Fraud Management
All Customers billing data that could not be verified/validated will be sent to Fraud Management in
addition to being returned to the appropriate responsible office for analysis and correction.
This is necessary so the Fraud Management office can assist in determining the validity of a
customer’s data. The intent of this process step is to identify a potential source of fraud as early as
possible in the billing cycle.
Initiator: Billing. This is envisioned to be an automated function within Winstar.
Process: This step sends Customer billing data to Fraud Management for further analysis of the
Customer and the associated Account.
Responsible Organizational Entity/Office: Billing, Fraud Management
BILL 40.0 – Maintain 24/7 Switch Polling
Network Operations will maintain a 24/7 Switch Polling capability to monitor all switch traffic for
indications of possible fraudulent activity. This is needed to identify and initiate remedial action in
cases of traffic that meets or exceeds the alarm parameters established by Fraud Management.
Initiator: Network Operations, Billing. This is envisioned to be an automated function within Winstar.
Process: This step will monitor all switch traffic within the Winstar network.
Responsible Organizational Entity/Office: Network Operations, Billing, and Fraud Management
FM Alarm Test
A determination must be made as to whether a Fraud Management alarm has been generated from the
Winstar or Vendor switches during this billing cycle.
Initiator: Network Operations. This is envisioned to be an automated function within the billing
process.
Process: Verify if a Fraud Management alarm has been generated. This process is outlined below:
IF a FM alarm has been generated,
Proceed to step BILL 50.0, Generate Alarm Notice,
And then proceed to Step BILL 70.0, Collect Call Detail;

7. ELSE,
Proceed to Step BILL 70.0, Collect Call Detail.
Responsible Organizational Entity/Office: Network Operations, Fraud Management
BILL 50.0 – Generate Alarm Notice
All Switch records that meet or exceed the applicable business rules for Fraud Management Alarms
are stored in the Fraud Management database.
Initiator: Network Operations. This is envisioned to be an automated function within the billing
process.
Process: Records that meet or exceed the Fraud Management Alarm criteria will generate a Fraud
Alarm Notice to denote the applicable error condition.
All Switch records passing through this process will be passed to further stages of the billing cycle.
The Fraud Management database is used as a reference/validation database to ensure data integrity,
and adherence to the business rules currently in force. This database, and the business rules contained
therein, may be updated as needed by users in Step 60.0, Update Fraud Management Alarm
Parameters.
Responsible Organizational Entity/Office: Network Operations, Fraud Management, and Billing
BILL 60.0 – Update Fraud Management Alarm Parameters
An authorized Fraud Management user must have the capability to update the Fraud Management
Alarm Parameters database as business rules change. This change should be done on an “as-needed”
basis only.
Initiator: Fraud Management. This is envisioned to be a data entry function within the billing process.
Process: An authorized Fraud Management user will update alarm parameters as needed.
Responsible Organizational Entity/Office: Fraud Management, Network Operations
BILL 70.0 - Collect Call Detail
All Call Detail records from the Winstar and Vendor Traffic databases must be collected to initiate
further processing in the billing cycle.
The Winstar Collection and Mediation System (WCMS), also called the ‘Collector’, performs normal
daily processing for switched local and long distance data. Processing consists of three stages:
Collection, Transformation and Distribution. WCMS collects local and long distance AMA data from
each of the Winstar 5ESS switches, transforms the collected data into EMI format and distributes it to
the billing system.

8. The end-user billable products for which the Winstar 5ESS switches generate recordings are as
follows:
IntraLATA Local
Intra-LATA Toll
CLASS Features (i.e. return call)
InterLATA Long Distance (domestic and international)
InterLATA Long Distance Directory Assistance (DA) (domestic only).
In addition, the recording of account codes is supported for InterLATA Long Distance calls captured
by Winstar switches.
The access-billable products for which the Winstar 5ESS switches generate recordings are:
Inter-Exchange Carrier (IXC) carried messages - (Originating) - non Winstar Carrier
Identification Codes (CIC)
intra-LATA 800 – (Originating)
There are three (3) major steps involved in the Collector process:
Collection (Input Processing)
Transformation (EMI (Electronic Message Interface) Conversion)
Distribution (Guiding)
There is also a Maintenance process that consists of two (2) steps:
Recycle Unguided EMI Records
Recycle Errored AMA Records
Initiator: Collector. This is envisioned to be an automated function within the billing process.
Process: The traffic data is parsed to ensure completeness, and then reformatted into a common call
detail layout. This reformatting to a common format includes a field (column) that serves as the error
indicator used in Step BILL 110.0, Edit Call Detail; as well as a field (column) that indicates the
source of the call data.
The data is then passed to the Fraud Management Threshold Test for further processing.
Responsible Organizational Entity/Office: Network Operations, Traffic, and Billing
FM Threshold Test
A determination must be made as to whether the Fraud Management threshold for this billing cycle
has been met or exceeded by any of the collected call detail records.
Initiator: Billing System. This is envisioned to be an automated function within the billing process.
Process: Verify if the current call thresholds for Fraud Management have been met or exceeded. This
process is outlined below:
IF the FM threshold has been met or exceeded,
Proceed to step BILL 80.0, Generate Threshold Notice,
And then proceed to Step BILL 110.0, Edit Call Detail;
ELSE,
Proceed to Step BILL 110.0, Edit Call Detail.

9. Responsible Organizational Entity/Office: Billing, Fraud Management
BILL 80.0 – Generate Threshold Notice
All Call Detail records that meet or exceed the applicable business rules for Fraud Management
Thresholds are stored in the Fraud Management database.
Initiator: Billing System. This is envisioned to be an automated function within the billing process.
Process: Records that meet or exceed the Fraud Management Threshold criteria will generate a Fraud
Threshold Notice to denote the applicable error condition.
All Call Detail records passing through this process will be passed to further stages of the billing
cycle.
The Fraud Management database is used as a reference/validation database to ensure data integrity,
and adherence to the business rules currently in force. This database, and the business rules contained
therein, may be updated as needed by users in Step 90.0, Update Fraud Management Thresholds.
Responsible Organizational Entity/Office: Billing, Fraud Management
BILL 90.0 – Update Fraud Management Thresholds
An authorized Fraud Management user must have the capability to update the Fraud Management
Thresholds database as business rules change. This change should be done on an “as-needed” basis
only.
Initiator: Fraud Management. This is envisioned to be a data entry function within the billing process.
Process: An authorized Fraud Management user will update threshold parameters as needed.
Responsible Organizational Entity/Office: Fraud Management
BILL 100.0 – Update Call Edit Parameters
An authorized billing user must have the capability to update the call edit parameter database as
business rules change. This change should be done on an “as-needed” basis only.
Initiator: Billing. This is envisioned to be a data entry function within the billing process.
Process: An authorized Billing user will update Call Edit parameters as needed.
Responsible Organizational Entity/Office: Billing
BILL 110.0 - Edit Call Detail

10. All Call Detail records must be edited according to the applicable business rules stored in the Call Edit
Parameter database.
Initiator: Billing System. This is envisioned to be an automated function within the billing process.
Process: All Call Detail records passing through this process will be tested to determine if they should
be passed to further stages of the billing cycle.
Records that do not meet the edit criteria will have the error indicator updated to denote an error
condition. Examples of conditions that could possibly reject records are listed below:
Invalid Authorization codes
Invalid or missing time of call
Invalid dollar amounts
Invalid rate
No Vertical & Horizontal (V & H) for the phone number
The Call Edit Parameter database is used as a reference/validation database to ensure data integrity,
and adherence to the business rules currently in force. This database, and the business rules contained
therein, may be updated as needed by users in Step 100.0, Update Call Edit Parameters.
Responsible Organizational Entity/Office: Billing
Call Detail Error Test
A determination must be made as to whether the call detail is valid, or in error.
Initiator: Billing System. This is an automated function driven by the applicable business rules in
effect. Each Call Detail record will have an indicator that denotes whether or not the record is in error.
Process: Verify if the Call Detail record error indicator has been set to denote an error. This process is
outlined below:
IF the call detail is valid,
Proceed to step BILL 130.0, Apply Rating/Discounting;
ELSE,
Proceed to Step BILL 120.0, Recycle Call Records in Error.
Responsible Organizational Entity/Office: Billing, Network Operations, and Traffic
BILL 120.0 - Recycle Call Records in Error
Call records that do not pass the editing criteria must be recycled for further action. These records will
be corrected where possible, or sent back to the applicable vendor for correction. This will allow all
possible data to be passed through the billing cycle. Possible causes for recycling Call records
include, but are not limited to, switch problems, and vendor changes not passed on to Winstar.
Initiator: Billing System. This is envisioned as a process that is initiated automatically. Review will
need to be, in most cases, a manual process performed by experienced Billing Analysts in cooperation
with personnel from Settlements, Network Operations, and Traffic.

11. Process: Review, correct, and re-submit all possible records for recycling in billing. This is intended
to correct all possible errors, and enhance the revenue stream. Examples of the causes of records
being sent to the Recycle process that failed the various edits are listed below:
Reason Codes
Product Code
Rates
NPA/NXX splits that have not been conveyed to the billing system for update
Usually, an update to the system edits will correct the problem.
Responsible Organizational Entity/Office: Billing, Settlements, Network Operations, and Traffic
BILL 130.0 - Apply Rating/Discounting
The Product Catalog (PCAT) database will be used to apply any applicable rating or discounting
criteria to each Call Detail record. The PCAT database is strictly used as input for this step, and
cannot be updated at any time during the billing cycle. The Billing database will be used in an input-
output mode for this process step.
Initiator: Billing System. This is envisioned to be an automated function within the billing process.
Process: This process is initiated when all Call Detail records have passed through editing. Lower
level processes are listed below:
Call records will be rated according to the combination of Product, Call Time of Day, and
Rate plan.
Volume discounts are applied at this stage of the Billing process.
All calls that have been rated are ready for billing.
Responsible Organizational Entity/Office: Billing
Rating Errors Test
A determination must be made as to whether the rating is valid, or in error.
Initiator: Billing System. This is an automated function driven by the applicable business rules in
effect. Each rated record will have an indicator that denotes whether or not the record is in error.
Process: Verify if the rated record error indicator has been set to denote an error. This process is
outlined below:
IF the rating is valid,
Proceed to step BILL 140.0, Generate Billing Record;
ELSE,
Proceed to Step BILL 120.0, Recycle Call Records in Error.
Responsible Organizational Entity/Office: Billing

12. BILL 140.0 - Generate Billing Record
Each rated Call Detail record will be used as input to generate one or more billing records for a
customer. The Billing database will operate in an input-output mode for this process step.
Initiator: Billing System. This is envisioned to be an automated function within the billing process.
Process: All rated Call Detail records will be used to generate billing records for a Customer. At this
point in the billing cycle processes will be performed to generate a bill:
Apply Monthly Recurring Charges (MRCs)
Apply Non-Recurring Charges (NRCs). Examples of NRCs are setup and connect
charges.
Apply Rates
Apply call volumes for any applicable discounts
Calculate and apply all applicable taxes. Taxes for 911 service are a Local tax. The
Vertex tax tables are used for Federal, State, and Local tax calculations.
Responsible Organizational Entity/Office: Billing
FM Limits Exceeded Test
A determination must be made as to whether the Fraud Management limits for this billing cycle have
been exceeded by any of the generated billing records.
Initiator: Billing System. This is envisioned to be an automated function within the billing process.
Process: Verify if the current bill limits for Fraud Management has been exceeded. This process is
outlined below:
IF the FM limit has been exceeded,
Proceed to step BILL 150.0, Generate Fraud Alert,
And then proceed to Step BILL 160.0, Review Bills in Question;
ELSE,
Proceed to Step BILL 170.0, Review Samples.
Responsible Organizational Entity/Office: Billing, Fraud Management
BILL 150.0 - Generate Fraud Alert
Each Billing record that exceeds Fraud Management limits will be used as input to generate a Fraud
Alert Notice for a customer. The generated bill will be used as input to this process step.
Initiator: Billing System. This is envisioned to be an automated function within the billing process.
Process: Generate a Fraud Alert Notice that will be forwarded to Fraud Management for review and
resolution.

13. Responsible Organizational Entity/Office: Billing, Fraud Management
BILL 160.0 – Review Bills in Question
Both Billing and Fraud Management will review each Billing record that generates a Fraud Alert
Notice. A determination will then be made on the appropriate course of action to be taken.
Initiators: Billing and Fraud Management. This is envisioned to be a manual review function within
the billing process.
Process: Review the bills that generated fraud alerts to determine if fraud has occurred.
Responsible Organizational Entity/Office: Billing, Fraud Management
Proceed with These Bills Test
A determination must be made as to whether the bills in question that generated a Fraud Alert Notice
should continue being processed in this billing cycle.
Initiators: Billing and Fraud Management. This is envisioned to be a manual decision point within the
billing process.
Process: Determine whether to continue these billing records. This process is outlined below:
IF the bills in question should not continue to be processed in this billing cycle,
Then the Fraud Management database is updated and processing for these billing records
stops;
ELSE,
Proceed to Step BILL 180.0, Produce Invoices.
Responsible Organizational Entity/Office: Billing, Fraud Management
BILL 170.0 – Review Bill Samples
This is a Quality Assurance step. Sample/Control bills are used for review. The intent is to ensure that
the format and content of the generated bill, and associated invoice are correct.
Initiator: Billing System. This is envisioned to be a manual review function within the billing
process.
Process: Produce the sample/control bills. Verify that sample bills are correct. Verify the bill format.
Verify charges in rating, MRCs, and taxes.
Responsible Organizational Entity/Office: Billing

14. Accept Bill Run Test
A determination must be made as to whether the bill run should be accepted.
Initiator: Billing System. This is envisioned to be a manual decision point driven by the applicable
business rules in effect.
Process: Verify the content and accuracy of the bill run. Accept or reject the bill run, or any portion,
accordingly. This process is outlined below:
IF the bill run is to be accepted,
Proceed to step BILL 180.0, Produce Invoices;
ELSE,
Go back to Step BILL 10.0, Verify/Validate customer/billing data.
Responsible Organizational Entity/Office: Billing
BILL 180.0 - Produce Invoices
The billing records generated in the previous step are used to produce itemized invoices for customers.
Initiator: Billing System. This is envisioned to be an automated function within the billing process
driven by the applicable business rules in effect.
Process: After accepting the bill run, Billing will produce the invoices for this cycle. At this point in
the billing cycle the following processes will be performed to produce invoices:
Produce Invoice file to be sent to the outside vendor.
Produce Control reports for invoice file that list the number of customers billed, number
of invoices produced, and total amount billed.
Append the Control reports to the invoice file. The vendor will use these reports as a
checkpoint.
Responsible Organizational Entity/Office: Billing
BILL 190.0 – Send bill file to Vendor for processing
The final bill file is sent to the billing vendor for processing. All invoices will be generated from this
bill file.
Initiator: Billing System. This is envisioned to be an automated function within the billing process
driven by the applicable business rules in effect.
Process: Billing will send the invoice file to the vendor. The vendor will balance the run statistics
from the Control reports, and request permission to send bills to customers.
Responsible Organizational Entity/Office: Billing

15. BILL 200.0 – Distribute Invoices
The billing vendor will distribute invoices to customers by regular mail, or other mean as appropriate.
Initiator: Vendor (Billing System). This is envisioned to be an automated function within the billing
process driven by the applicable business rules in effect.
Process: The billing vendor distributes invoices to customers.
Responsible Organizational Entity/Office: Billing, Invoicing
BILL 210.0 – Receipt of invoice/report by Customer
The customer will receive the invoice, or in the case of large accounts, a report itemizing all invoices
sent for that account.
Initiator: Vendor (Billing System). This is envisioned to be a manual function within the billing
process driven by the applicable business rules in effect.
Process: The customer receives the invoice.
Responsible Organizational Entity/Office: Billing, Invoicing
Invoice Paid Test
A determination must be made as to whether the invoice has been paid.
Initiator: Billing System. This is envisioned to be an automated function within the billing process.
Process: Verify if the invoice has been paid. This is based on the date the invoice was sent, and the
due date of the bill. This process is outlined below:
IF the invoice has been paid,
Proceed to step BILL 230.0, Update Account;
ELSE,
Go to Step BILL 220.0, Initiate Dunning/Collections.
Responsible Organizational Entity/Office: Finance (Accounts Receivable, Accounts Payable), Billing
BILL 220.0 – Initiate Dunning/Collections
All invoices not paid in a timely, or contractually agreed upon, manner are referred to Dunning and
Collections for further action.
Initiator: Billing System. This is envisioned to be an automated function within the billing process.

16. Process: Initiate the Dunning/Collections process. This is based on the customer’s payment history.
The Accounts Receivable/Accounts Payable entity in the Financials database will be updated to reflect
this action.
After this process has been completed, proceed to step BILL 230.0, Update Account.
Responsible Organizational Entity/Office: Finance (Accounts Receivable, Accounts Payable), Billing
BILL 230.0 – Update Account
The Customer Account database must be updated at the end of the billing cycle.
Initiator: Billing System. This is envisioned to be an automated function within the billing process.
Process: Update the Customer account. If the invoice has been paid, the database will be updated to
reflect this status. If the invoice has passed through the Dunning/Collections process, the database
will be updated to reflect that the account has been referred to Collections.
Responsible Organizational Entity/Office: Finance (Accounts Receivable, Accounts Payable), Billing