4 Usage-to-Payment Business Process

Learn about the Usage-to-Payment business process and its features available in the Oracle Communications Digital Business Experience Reference Solution package.

Overview of the Usage-to-Payment Business Process

The Usage-to-Payment business process is a foundational component of the Oracle Communications Digital Business Experience Reference Solution (Reference Solution), enabling telecom operators to convert customer service usage into revenue. This process begins when service consumption events, such as voice calls, data sessions, and messaging are captured from network elements and mediation systems. These usage records are then normalized, validated, and rated based on predefined tariffs and business rules to determine the corresponding charges.

The calculated charges are aggregated along with recurring fees and any applicable discounts or adjustments to produce comprehensive customer invoices within defined billing cycles. The Reference Solution supports a variety of payment methods, allowing customers to settle their invoices through channels, such as credit/debit card, bank transfer, or electronic payment gateways.

Throughout the process, the Reference Solution enforces compliance, data integrity, and auditability, supporting timely payment collection and enabling efficient revenue management. This end-to-end automation streamlines the operator’s revenue assurance activities, minimizes revenue leakage, and improves the overall customer billing experience.

This business process includes the following features:

  • Manage Customer Billing
  • Payment and Receivables
  • Charging and Call Control
  • Manage Collections

The sections that follow briefly describe each of the above features.

About Manage Customer Billing Process

This process supports telecom operators in accurately calculating, generating, and administering customer invoices for a wide range of telecommunication services. This process encompasses the consolidation of all customer account data, including service usage records, recurring charges, one-time fees, applied discounts, and applicable taxation.

At the conclusion of each billing cycle, this process compiles and verifies all relevant financial information for individual customers or accounts. Using configurable rules and billing schedules, the system produces detailed invoices that reflect every component of a customer's subscription and consumption profile. These invoices are then distributed through multiple channels, such as electronic delivery, customer self-service portals, or print, conforming to regulatory and contractual obligations.

This process ensures data integrity, compliance, and transparency throughout the billing lifecycle, supporting customer inquiries, adjustments, and dispute management as needed. By automating billing operations and integrating with downstream payment and finance systems, this process significantly enhances billing accuracy, reduces operational overhead, and strengthens customer trust in the operator’s billing practices.

Implementing Billing

This feature enables telecom operators to generate comprehensive bill content objects from unbilled charges. This feature ensures each bill is accurate, compliant with local market regulations, and suitable for Business-to-Business (B2B) and Business-to-Customer (B2C) customer presentation. Bill runs are scheduled and performed as part of regular billing operations, based on predefined cycles, billing segments, or billing profile specifications.

The billing execution process consists of the following:

  1. Bill Run Scheduling
    • Frequency: Bills are run one or several times per month, according to customer billing segments or Billing Date of Month (BDOM) specified in the Billing Profile.
    • Billing windows: Execution occurs on predefined days of the month.
    • Applicable customers:
      • B2B and B2C postpaid customers on monthly billing cycles.
      • B2B customers with quarterly or annual billing cycles when the billing cycle completes.
    • Initiation: Business Operation Center (BOC) schedules bill runs, potentially executing in multiple phases to account for delayed events (such as those from offline charging).
  2. Bill Generation Logic
    • Account processing:
      • Service accounts are processed sequentially, respecting the billing hierarchy or other grouping dependencies.
      • Billing accounts aggregate accumulated service account charges for the cycle.
    • Each generated bill includes:
      • Bill Number: Consists of a fixed or dynamic prefix.
      • Due Date: Calculated based on payment terms, adjusted for calendar dates and any configured public holidays.
      • Total Amount: Rounded to the local currency precision.
      • Cyclic Charges and Rollovers: Cyclic fees, counter replenishments, and rollovers may be applied for the current and/or next bill/accounting period, with proration rules as per the configuration.
      • Balance Forward: Optionally includes previous unpaid bill amounts (Balance Forward configuration). When Balance Forward is enabled, previous unpaid totals are carried into the new bill’s total due.
      • Volume Tier Discounts: Applied if volume-based discounting is enabled.
      • Charge Breakdown: Detailed charges by service and type (Non-Recurring Charges [NRC], Monthly Recurring Charges [MRC], and Usage).
      • Bill Status: Set to Open; once finalized, no additional charges can be added. Upon successful bill creation, subsequent invoicing and PDF rendering are implemented via Oracle Communications Billing and Revenue Management (BRM) bulk utilities.

Note:

If a subscriber is eligible and requests termination of the contract, the system must issue a final bill before contract termination.

Exception management

Bills that fail during the process are reported by BOC. These must be investigated, corrected, and reprocessed to ensure billing integrity. Re-invoicing scenarios are supported as per the configuration, and trial billing is available for non-posting invoice validation.

About Generate Bill Invoice

The Generate Bill Invoice feature transforms previously generated bill objects into finalized, customer-ready invoices. This process applies to bills created through scheduled bill runs or corrective billing operations and ensures that invoices comply with formatting, legal, and regulatory requirements.

The invoice generation process involves the following steps:

  1. Standard Payload Generation
    • The system creates an XML payload that represents the final invoice layout.
    • The pin_inv_accts script handles this step in bulk for efficiency and selects the appropriate invoice template key (for example, B2C, B2B, Credit Note, Re-billing, and so on) based on customer data and document reason.
    • The XML payload is enriched with customer and bill-specific data, including template selection based on customer type (for example, B2B, B2C, credit note), tax breakdowns, rate codes, and itemization aligned with invoice structure rules.
  2. PDF Rendering
    • The pin_inv_doc_gen script converts the structured XML payloads into human-readable PDF invoices.
    • The Oracle Analytics Publisher (OAP) formatting system applies predefined templates and further enriches the output as required (for example, logos, contact numbers, payment instructions, optional marketing banners, and region-specific text).

The invoice contains the following sections, rendered to comply with local regulations and business requirements:

  • Summary
    • Customer name and billing address
    • Invoice date and bill run date
    • Bill number
    • Due date (ensuring legal minimum delay between delivery and due date)
    • Total due amount
    • Payment method
  • Charge Aggregation
    • Itemized periodic, one-time, and discount charges
    • Grouped by type of service
    • Rounded to local currency precision
  • Usage Details
    • Optional and configurable by a billing preference flag
    • Details per usage type and service, with corresponding dates and tax information

The following additional formatting is done to the invoices:

  • Application of logo, contact details, payment instructions, and optional marketing messages.
  • Insertion of QR codes or barcodes for manual payment facilitation (using bill number and URI).
  • Generation of QR codes for specific local regulatory requirements (for example, tax declarations), if applicable and supported.

Operational considerations

  • Scheduling
    • Invoicing processes are triggered by the Business Operation Center (BOC) after successful bill execution for postpaid and hybrid customers.
    • The system ensures invoice delivery dates comply with legal requirements, typically enforcing a minimum notice period (for example, two weeks) before the due date.
  • Distribution
    • Upon successful generation, invoice metadata is published to a queuing system for downstream processing and delivery.
    • Failed or incomplete invoice batches are monitored and retried through the BOC user interface.
  • Re-invoicing
    • Re-invoicing occurs for various scenarios:
      • Address/contact changes: Regenerate the invoice PDF using the same bill object (no financial change).
      • Credit/Debit Notes: Issued as separate bill objects with dedicated prefix/series and templates; not a modification of the original invoice.
      • Other financial alterations require issuing a new corrective document

Exception management

  • Any failures in the bulk invoicing process are reported and can be resolved by regenerating invoices using BOC tools.
  • All invoice format changes or customer-driven alterations require the generation and delivery of an updated invoice.

About Invoice Template Customization

The Invoice Template Customization feature enables organizations to define and manage a range of invoice render templates tailored to various business scenarios and customer segments. This feature supports compliance, operational efficiency, and customer communication requirements by allowing flexible and precise control over invoice formatting and presentation.

Invoice designers utilize the Oracle Analytics Publisher (OAP) rendering system to organize and maintain XSL/XSD-based templates, which format invoice XML payloads into final PDF documents. These templates accommodate different business purposes while ensuring information consistency and adherence to presentation standards, including dedicated templates for corrective documents (for example, Credit Notes).

Templates are specialized based on the following criteria:

  • Product type
  • Invoice reason (for example, final, hot, credit note, bill shock, and so on)
  • Customer segment (for example, Business-to-Business (B2B), Business-to-Customer (B2C), and so on)
  • Static messages (specific to business or regulatory needs)

Supported invoice render templates include, but are not limited to:

  • Regular B2C invoice
  • Regular B2B invoice
  • Bill Now invoice
  • Bill Threshold invoice
  • Credit Note
  • Re-billing (for B2B)

Note:

  • Select or modify templates according to business requirements and regulatory obligations.
  • Incorporate static messaging and required invoice sections based on segment and context.
  • Validate template output to ensure accuracy and compliance before mass deployment.
  • Ensure numbering schemes and prefixes (for example, CN-xxxxx for Credit Notes) are configured before template.
  • QR/barcode elements for manual payments may be included (bill number plus payment URI).
  • Archive rendered PDFs to the designated Document Management System (DMS) upon successful generation.

About Trial Billing

The Trial Billing feature allows operators to validate the invoice output for newly introduced business products prior to full production rollout. This process enables targeted testing of invoice formats and billing calculations using a subset of customer accounts, without affecting production balances or financial ledger entries.

This feature:

  • Enables operators to test and review invoice output for new product launches.
  • Facilitates assessment of invoice structure and charge calculations for selected accounts in the production environment.
  • Prevents any impact on current account balances or general ledger data during the trial process.

The Trial Billing process involves the following steps:

Note:

Before starting the Trial Billing process, you must provide a list of customer accounts to be included in the trial billing run.
  1. Trial Bill Generation
    • Launch the batch trial billing job using Business Operation Center (BOC) or a command-line interface (CLI).
    • Invoke the pin_trial_bill_accts script to create trial bill objects for specified accounts.
    • Trial bills include cycle fees and total amounts but do not alter existing account balances or General Ledger (GL) feeds.
  2. Trial Invoice Generation
    • Run the pin_trial_inv_accts script to generate trial invoice files in XML format.
    • XML invoice files are generated for review and are not persisted in the database.
  3. Validation and Output
    • The XML files can be further processed manually using the Oracle Analytics Publisher (OAP) system for invoice render and format validation.

Limitations

  • Trial Billing is not intended for comprehensive billing simulation following major migrations or as a replacement for B2B proforma or pre-billing scenarios.
  • Trial invoice output is for validation purposes only and does not trigger any operational or financial processing, no notifications, no queuing, no Document Management System (DMS) archiving, no tax commit.

Exception management

In case of processing failures for specific accounts, operators must re-run the utilities for failed account list; investigate configuration/data issues surfaced in logs.

About Correct Bill Invoice

The Correct Bill Invoice feature supports the issuance of credit notes to address adjustments on previously issued bills or bill items. This capability ensures compliance with legal and tax accounting requirements for Business-to-Business (B2B) and Business-to-Customer (B2C) customers by providing transparent and auditable corrective billing statements.

This process is triggered following the resolution of a bill inquiry, resulting in an approved adjustment on a prior bill.

A Customer Service Representative (CSR) initiates the corrective billing action by specifying the adjustment in the Siebel CRM, which triggers credit note generation within the billing system. The request is submitted to Billing and references the original bill/item adjustment.

This feature:

  • Facilitates the generation of credit notes or corrective invoices resulting from bill inquiries and adjustments.
  • Maintains alignment with legal, regulatory, and customer tax accounting standards, including General Ledger (GL) postings and adjustment.

This process involves the following steps:

  1. Credit Note Generation
    • The system creates a new bill object for the affected billing account, using a predefined prefix series (for example, CN-XXXXX).
    • The credit note documents the amount credited or debited with explicit reference to the original bill number.
  2. Invoicing and Formatting
    • The system applies a dedicated invoice template for credit notes to ensure clear differentiation from standard invoices.
    • Credit note is displayed as the heading on the invoice.
  3. Archiving and Distribution
    • Invoicing, formatting, archiving, and distribution processes are invoked asynchronously after the credit note is generated, following standard operational procedures.
  4. Bill Now Execution
    • After the item adjustment, the Bill Now process is used to immediately generate and issue the credit note, ensuring the update is reflected without waiting for the next regular billing cycle.

Note:

  • Only authorized and approved adjustments can trigger credit note issuance.
  • Each credit note references the original bill and carries a transaction/reference id for reconciliation.
  • All corrective actions are subject to existing audit trails and legal accounting requirements.

About Upload Invoice to DMS System

The Upload Invoice to DMS System feature manages the secure upload, archiving, and controlled retrieval of finalized invoice documents. This process ensures that all rendered invoices are stored in a Document Management System (DMS), supporting both compliance and operational access requirements across billing and customer service channels.

The upload process starts automatically after successful completion of the Generate Bill Invoice operation.

This feature:

  • Provides secure, long-term storage for finalized invoices.
  • Enables direct invoice access from Siebel CRM and self-care (unassisted) channels.
  • Ensures systematic invoice indexing and archiving for regulatory compliance and operational needs.

This process involves the following steps:

  1. Event Creation
    • Upon invoice rendering completion, an event containing bill metadata for content indexing is generated by the system.
    • This event is published into a queuing system for downstream processing.
  2. Acquisition and Upload
    • An integration process (using AIA or OSB) consumes the event, retrieves the invoice from the Oracle Analytics Publisher (OAP) system, and uploads it to the designated DMS repository.
  3. Archiving and Access Control
    • The DMS applies security and archiving policies.
    • Uploaded invoices are indexed for direct access via customer service applications and unassisted self-care portals.

Note:

  • DMS configuration is a field implementation and needs to be configured to upload invoices.
  • Ensure that integration endpoints between OAP, queuing, and DMS are monitored for reliability.
  • Verify that bill metadata content is complete and accurate for content indexing to enable effective search and retrieval.

Exception management

  • In the event of upload failures or process interruptions, the system supports resumption of the upload process.
  • Logic is in place to avoid gaps or duplicate entries during recovery or retries.

About Configure Billing

The Configure Billing feature allows Oracle Communications Billing and Revenue Management (BRM) specialists to define and manage key billing parameters and behaviors to meet specific business requirements. Configuration occurs during the design phase and is a prerequisite for achieving the expected operational outcomes from the billing system.

This feature:

  • Establishes system-wide billing behavior aligned with organizational policies and business goals.
  • Enables flexible control over billing cycles, accounting methods, customer segmentation, and integration points, including corrective billing and invoicing.

The system supports configuration of the following global parameters and extensions for billing:

  • Primary Currency: Define the operational currency for all billing processes.
  • Delayed Billing: Set rules for deferred bill runs or invoice generation.
  • Open Item Accounting: Enable or disable open item accounting practices within the system.
  • Item Assignment: Control itemization and groupings of charges.
  • Customer Segment (Bill Suppression): Configure rules for bill suppression based on customer segment and minimal threshold amounts.
  • Billing Segments: Organize billing cycles and groupings by segment.
  • Journal and General Ledger (GL): Integrate billing events with accounting systems for revenue posting and reconciliation, and maintain GL Segments, GL Codes, and GLIDs.
  • Rollover: Manage rollover logic for usage, balances, or charges across billing periods.
  • Rating Engine and Pricing Designer: Specify engines for usage charging and pricing rule application.
  • Tax Configuration: Set up tax rules, codes, and calculation parameters for compliance.
  • Bill Number and Corrective Bill Prefix: Define numbering schemes for regular and corrective bills (for example, CN-xxxxx for Credit Notes and DN-xxxx for Debit Notes).
  • Billing Event Notifications: Configure systems for notifying stakeholders of billing events and statuses.
  • Invoice Template Configuration: Manage Oracle Analytics Publisher (OAP) templates (Business-to-Customer (B2C), Business-to-Business (B2B), Bill Now, Threshold, Credit Note, and Re-billing).
  • Collections Configuration: Define profiles, entry/exit thresholds, grace days, and action scenarios.

Out-of-the-Box (OOTB) Validations

  • The default system configuration supports Bill Day of Month (BDOM) values from 1 to 28.
  • For customers configured with BDOM as 29, 30, or 31, the billing system automatically assigns a billing date of the 1st of the following month.

Note:

  • All configuration settings should be reviewed and managed by designated BRM specialists.
  • Validate global parameter changes in a controlled environment prior to production deployment.
  • Ensure all business and compliance requirements are captured in billing configuration before go-live.

About Payments and Receivables Process

This process governs the management of subscriber payments, application of those payments to outstanding invoices, and the tracking of receivable balances throughout the billing lifecycle. This process ensures the secure and accurate collection of amounts due from subscribers through various payment channels, including electronic, manual, and third-party gateways.

The system records each payment transaction, automatically reconciles received funds with open invoices, and updates the subscriber’s account status accordingly. It also monitors one-time payments (must carry distinct General Ledger IDs (GLIDs)), receivable balances, manages overpayments and underpayments, and supports adjustments, reversals, and chargebacks as required for both operational and regulatory compliance.

Additionally, this process enables timely cash application, supports financial reporting obligations, and provides the foundation for collections management by identifying overdue accounts and escalating outstanding amounts in accordance with organizational policies and market regulations. This process plays a critical role in maintaining the accuracy of financial records and ensuring the ongoing integrity of the revenue cycle with General Ledger (GL) segment/code/GLID mappings maintained in PDC/BRM for Accounts Receivable (A/R) and tax postings; adjustment reasons use LOVs mapped to GLIDs and apply proportional tax reversal when itemized tax is enabled.

Placing an Adjustment

This feature enables Customer Service Representatives (CSRs) and back-end support teams to process financial corrections to bills or bill items resulting from customer inquiries or disputes. The process upholds rigorous approval controls, ensures tax integrity, and maintains detailed audit trails in accordance with financial and regulatory requirements.

Adjustments are initiated following the resolution or approval of a bill inquiry or dispute through the ticketing system.

Only authorized personnel, such as CSRs or billing support staff, may process adjustments using the Siebel CRM UI or Billing Care UI.

The adjustment process works as follows:

  • The user selects the billed item(s) requiring adjustment.
  • The amount to adjust is specified in the transaction currency and must include all applicable taxes.
  • A justification is required for each adjustment, selected from a predefined list of values (LOV).
  • The system references configured GLID tracks for financial tracking.

Depending on the account and situation, adjustment posting can lead to the following:

  • Application to next bill: The adjustment amount is carried forward and reflected on the subscriber’s subsequent bill by default.
  • Credit note generation: In cases requiring formal correction, a credit note is issued in accordance with credit note processes.
  • Refund issuance: If the adjustment results in a negative subscriber balance and the contract is terminated, a refund process will be initiated.

Financial and Tax Handling

  • The system automatically applies proportional tax reversals based on the adjusted itemization, ensuring tax reporting accuracy.
  • For Business-to-Business (B2B) customers, adjustments are journalized, capturing all tax credit impacts and associating the reason (LOV) with the corresponding general ledger (GL) record for further financial analysis.

Note:

  • Currently, GLIDs are supported only for B2B customers.
  • All adjustments are recorded with reference to their reason code, approval chain, and financial impact.
  • Adjustment activities are available for finance teams to review and analyze through the configured GL identifiers.

About General Ledger Requirements

This feature ensures that all financial transactions impacting the organization's position are accurately reflected in the general ledger (GL). This capability enables consistent financial tracking, auditing, and reporting by associating every relevant transaction, such as charges, payments, bills, adjustments, and asset changes with dedicated GL codes and segments.

This feature:

  • Guarantees complete and auditable representation of company financial activities in the GL.
  • Supports detailed financial analysis for each product, service, or business activity.
  • Complies with finance department and regulatory reporting requirements.

Configuration and Setup

  • GL segments: Segments, such as Consumer and Business, are defined in a configuration file before upload to the Oracle Communications Billing and Revenue Management (BRM) system.
  • GL codes:
    • Assigned based on the Communications Service Provider's (CSPs) chart of accounts.
    • Each transaction type (usage, payment, bill, adjustment, purchase, asset change) is mapped to appropriate GL codes.
  • GL IDs: Unique identifiers are assigned for each Accounts Receivable (A/R) transaction and uploaded to the BRM system.
  • Code association:
    • Each product, package, service, or discount is associated with the relevant GLID codes to ensure correct reporting.
    • Code-to-product associations and percentages for bundled offerings are defined and configured in the Oracle Communications Pricing Design Center (PDC) during product creation or amendment.

Financial Posting Process

  • All transactions affecting the company’s balances are allocated to the appropriate GL segment and code at the time of event/rating, billing, payment, or adjustment.
  • These allocations accumulate as transaction activity occurs and are periodically posted or exported to the GL system for consolidated financial reporting.

Usage and Audit

  • Finance administrators and reporting teams can access detailed breakdowns of all GL-mapped transactions, including charges, credits, adjustments, and bills.
  • This traceability supports the accurate reflection of financial performance for each service, product, or business activity in compliance with accounting standards.

Note:

  • Currently, this feature is applicable only for the Business-to-Business (B2B) customer segment.
  • Ensure all required GL codes and segments are loaded into the system before product or transaction configuration.
  • Maintain alignment between the chart of accounts and GL mappings in the billing platform.
  • Update GL assignments promptly when creating or modifying products, packages, or discounts in PDC.

About One-Time Payments

This feature provides the capability to process individual, unprompted subscriber payments from various internal and external sources. This includes payments for initial orders, settlements of open bills, and non-automated recurring payments, ensuring flexible and accurate revenue collection through multiple payment channels (assisted via Siebel; unassisted via digital; manual reconciliation for bank transfers).

The following are the supported payment scenarios:

  • Acceptance of payments for single or multiple open bills.
  • Handling of payments not set up as automatic or recurring debits.
  • Processing of payments for both initial orders and outstanding invoices.

Payments may originate from the following channels and payment methods:

  • Assisted channels (Siebel UI/Call Center/POS):
    • Credit card payments
    • Cash payments at point of sale (POS)
    • Manual check processing
    • Wire transfer reconciliations completed by back office staff
  • Unassisted digital channels:
    • Online credit card processing
    • Third-party payment services integration
  • Bank wire transfer:
    • Bank-to-bank account transfers, recorded and reconciled subsequently by finance personnel using Billing Care UI or Siebel CRM UI.

This process involves the following steps:

  1. Payment details submission: Required details (payment type, bill reference, billing account, amount, payer name, date, method-specific data, such as check number) are submitted to the Oracle Communications Billing and Revenue Management (BRM) system.
  2. Accounting requirements: Each payment method or configuration is associated with a distinct General Ledger Identifier (GLID), to ensure correct financial posting and reconciliation.
  3. Payment allocation: BRM allocates the payment to the associated bill(s) or billing account according to business rules and configuration.
  4. Customer notification: BRM generates and dispatches payment confirmation notifications to the subscriber upon successful processing, in accordance with notification guidelines.

The following are the integration interfaces available:

  • Online processing: Credit card transactions and interactions with clearing houses.
  • Manual reconciliation: Bank file uploads and wire transfer records managed by finance support teams.

Note:

  • Ensure all payment sources and types are mapped to the designated GLIDs for accurate accounting.
  • Maintain secure handling of sensitive payment data, especially for credit card transactions.
  • Coordinate with finance and customer support teams for effective management of manual and assisted channel payments.
  • Payment events should update collections status where applicable (for example, exit criteria and unbar triggers).

About Charging and Call Control

The Charging and Call Control process is essential for managing real-time rating, authorization, and control of customer telecommunications services. This process coordinates the assessment and enforcement of subscriber account balances and service entitlements at the time of service invocation, ensuring accurate charging and preventing unauthorized or over-quota usage.

During service usage, such as voice calls, data sessions, or value-added interactions, the process interacts with network and charging systems to verify subscriber balances, determine applicable tariffs, and authorize the requested usage based on business policies, product definitions, and usage quotas. For prepaid scenarios, the system performs real-time deduction from subscriber balances, while in postpaid environments, it accumulates charges for later billing by configuring service tariff plans in PDC and applied per Rating Group (RG).

The process is tightly integrated with policy management, rating engines, and network elements to enforce thresholds, apply discounts, and perform call barring or session termination when limits are reached. Comprehensive event logging and audit capabilities are maintained for revenue assurance and regulatory compliance. Ultimately, this process provides the foundation for reliable, secure, and transparent monetization of telecommunications services, supporting both customer experience and operator revenue objectives.

Performing Online Rating

This feature enables the real-time calculation and application of charges for subscriber service usage events. This feature determines the usage quantity, relevant zone, and correct rate based on the subscriber's provisioned product and tariff plan, then applies the calculated charges to the appropriate account balances. The process supports both event-based and cumulative session-based rating scenarios, ensuring accurate and compliant monetization of telecommunications services.

Prerequisites:

  • Subscriber is provisioned with an offer that includes an associated tariff plan.
  • Zone definitions and service tariff plans are configured in the Oracle Communications Pricing Design Center (PDC).

The rating workflow involves the following processes:

  • Subscriber identification
    • The subscriber is identified in the system.
    • The system receives a service usage request for rating via the defined network/charging interface.
  • Event-based rating
    • The system rates quantities grouped by Rating Group (RG) according to the service rate plan.
    • If applicable, the relevant zoning group for the service event is identified.
    • Both currency and non-currency balances are updated and discounts are applied.
    • Real-time taxation and general ledger (GL) impacts may be triggered, based on configuration.
    • The system generates and persists a rated event.
  • Session-based rating
    • Update request
      • Receives Used-Service-Units (USU) with RG for accumulation in an ongoing charging session.
      • If sufficient balance exists, a new grant (GSU) is reserved and deducted. If not, and credit limits are enforced, the request is rejected and service redirection may occur.
      • Upon specific mid-trigger events, aggregated usage is attached to a bill item and persisted.
    • Terminate request
      • Upon session termination, final USUs and RG quantities are rated and charges are applied according to the subscriber’s rate plan.
      • Taxation and GL impacts are determined as configured.
      • The system persists a final rated event and closes the charging session.

Applying Usage Discounts

This feature enables the automated application of usage-based discounts during the final stage of the service rating process. This feature ensures that eligible subscribers receive contractually defined rebates, such as recurring or one-time allowances, directly impacting their rated usage charges and account balances.

Prerequisites

  • The subscriber has purchased an offer that includes a cyclic (recurring) or one-time (top-up) usage allowance.
  • The usage event being rated is eligible for discounting according to the terms of the subscriber’s offer.
  • There is a non-zero allowance balance available at the time of rating.

The discount application logic is as follows:

  • Upon completion of the initial rating, the system checks for eligible usage units that qualify for allowance discounts.
  • The Oracle Communications Elastic Charging Engine (ECE) evaluates the Convergent Usage Discount Filter to determine applicable discount rules.
  • If conditions are met:
    • The monetary charge (in currency units) for eligible usage is partially or fully offset by the available allowance.
    • The corresponding allowance balance is reduced by the discounted usage units.
    • A detailed record of the discount application, including the allowance consumption and resulting balance, is recorded within the event data for audit and reference.

Note:

  • The discounting process is performed as the concluding step in the rating flow to accurately reflect any usage-based rebates.
  • If multiple discounts exist, their precedence/order is applied as per the configuration.
  • If the relevant bill item does not exist, the system auto-creates it so that the discounted event can be attached.
  • All adjustments to balances and event records are performed consistently to maintain financial integrity and support downstream billing and reporting activities.

Applying Events to Bill Items

This feature enables the association of rated service event records with appropriate bill items for each subscriber. This process ensures that all chargeable usage events are accurately reflected in the subscriber's invoice, supporting transparent and itemized billing.

During the rating process, the Online Charging System (OCS) generates and persists service event records according to predefined configuration rules.

Each event record contains usage-specific details required for billing and compliance.

Association with Bill Items

  • Every rated event is linked to an existing bill item on the subscriber’s account to enable invoicing.
  • The system selects the applicable bill item based on configuration rules, ensuring alignment with the expected invoice structure.
  • If a suitable bill item does not exist, the Oracle Communications Elastic Charging Engine (ECE) automatically creates a new bill item for the event.

Service event records capture the following usage attributes:

  • Start and end time (local timestamp)
  • Origin zoning information (for example, MCCMNC) to identify roaming activity
  • B-Number (called number)
  • Zoning destination for Voice or SMS
  • User Equipment (UE) IP address (PDN)
  • Serving Gateway (SGW), Mobility Management Entity (MME), Roaming Indicators, or Access and Mobility Management Function (AMF) address

Note:

  • Event-to-bill item assignment must be carefully configured to ensure the invoice structure remains accurate and compliant.
  • Automated creation of bill items streamlines billing operations and supports complete, auditable invoice records.

About Manage Collections Process

This process encompasses the systematic identification, monitoring, and resolution of overdue receivables resulting from unpaid subscriber invoices. This process begins when a subscriber’s account becomes delinquent (meets entry criteria for its collection profile/scenario after grace days) and continues through a series of structured actions designed to recover outstanding balances while maintaining compliance with internal policies and external regulations.

Throughout the collections lifecycle, the system tracks aging receivables, evaluates account risk, and prioritizes actions based on configurable criteria, such as amount overdue, customer segment, and historical payment behavior. Automated notifications, reminders, and escalation procedures are generated to inform subscribers of their obligations and prompt timely payment. If necessary, additional measures, such as dunning, temporary service suspension, or referral to external collection agencies may be initiated in accordance with company policy.

By providing comprehensive oversight and control of collection activities, the Manage Collections process supports revenue assurance objectives, reduces bad debt exposure, and upholds the financial integrity of the organization with the following entry/exit rules:

  • Entry: Move an account into collections when due amount exceeds the scenario’s entry threshold and grace days have passed.
  • Execution: On each action due date, if no or insufficient payment is received, Siebel executes automated steps (for example, send text, barring order) and posts status back to Oracle Communications Billing and Revenue Management (BRM).
  • Exit: Upon sufficient payment or a valid Promise-to-Pay (PTP), cancel pending actions, unbar/restore services to pre-collections state, and update Siebel to remove workflows.
  • Aging and reporting: Maintain aging buckets.

Qualifying Invoices for Collections

This feature automates the identification and initiation of collections treatment for accounts with overdue balances. This process is scheduled to run periodically, typically on a daily basis, following payment and billing cycles. It ensures timely escalation of delinquent accounts, enabling effective risk management and minimization of outstanding balances, debtor days, and bad debt exposure.

This feature:

  • Automatically detects accounts with overdue amounts exceeding thresholds.
  • Initiates structured collections scenarios to recover outstanding balances.
  • Supports dynamic assignment and update of collection profiles based on account payment behavior.

Accounts are assigned a collections profile upon creation, reflecting risk and payment history. The profile is adjustable over time (for example, relaxed criteria after sustained good payment behavior).

Each profile is linked to a collection path, specifying treatment steps and timing (for example, send SMS, initiate outbound call, restrict service).

Accounts are evaluated for collections entry using the following logic:

  • The collections profile class for the billing account is valid.
  • There is an associated collection scenario (treatment plan) for the profile.
  • The account is not currently in collection status.
  • The account’s bill due amount exceeds the collection scenario’s entry threshold.
  • The designated grace period has elapsed (considering weekends/holidays as well).

Upon meeting the above criteria:

  • The account’s status is updated to In collections.
  • The linked collection scenario is assigned.
  • All predefined collections actions in the scenario are created and scheduled for implementation.
  • Collections actions are synchronized with Siebel for further processing.
If an account is already in collection status:
  • The process evaluates whether the overdue amount remains above the exit criteria value.
  • If the overdue amount exceeds the threshold, the account remains in collections status without exiting the collections cycle, else exit processing is handled by the Exit Collections flow.

Implementing Collections B2B

This feature manages and automates the collections process for Business-to-Business (B2B) accounts identified as delinquent. Each account is associated with a defined collections path, which sequences the treatment steps and the intervals between them. The feature ensures prompt and systematic handling of overdue receivables, escalation of collection actions, and alignment between the Siebel and Oracle Communications Billing and Revenue Management (BRM) systems.

Each delinquent B2B account is linked to a specific collections path that prescribes:

  • The sequence of actions to be performed.
  • The duration between each action step.

Scheduling and Implementing an Action

Note:

On each due date, actions are implemented only if no or insufficient payment has been received and exit criteria is not met.
  • Actions are triggered on scheduled dates, calculated from the date the bill unit enters collections status.
  • Example of an action schedule:
    • Action 1: Day 2
    • Action 2: Day 5
    • Action 3: Day 10
  • Scheduled actions are mapped to calendar dates. For example, if a bill enters collections on May 1:
    • Action 1: May 3
    • Action 2: May 6
    • Action 3: May 11

Commonly implemented collections actions include:

  • Sending reminder texts/emails
  • Sending reminder letters
  • Initiating outbound calls
  • Barring or throttling services
  • Terminating agreements and cancelling services
  • Writing off debt (manual finance action)
  • Sending debt to external collections agencies
  • Notifying the legal department

The process flow is as follows:

  • On the scheduled date, if no payment or an insufficient payment has been received:
    • Siebel automatically implements the next required action (for example, sending reminders, barring services).
    • For actions requiring manual involvement (such as outbound calling or management interventions), Siebel initiates the appropriate workflow.
    • Automated processes are triggered where possible, reducing manual effort for repetitive actions.
  • Each action is recorded, and completion is communicated back to BRM for consolidated collections management and audit purposes.
  • When sufficient payment or a valid Promise-to-Pay is recorded, remaining actions are cancelled and unbar/restore activities are initiated; credit profile and credit limit are reassessed as per the exit process.

Note:

  • Collections actions are synchronized from BRM to Siebel.
  • Siebel is responsible for implementing or initiating all required activities in accordance with the collections path.
  • Status and completion updates are sent back to BRM to maintain system alignment and data integrity.

Configuring Collections B2B

This feature defines the run-time parameters and workflow settings required to support automated and manual collections management for Business-to-Business (B2B) subscriber accounts. These configurations establish the credit risk framework, treatment paths, and operational processes necessary for effective and compliant handling of overdue receivables in the enterprise segment.

Credit limits are assigned to business accounts based on business rules, such as account tenure, product value, and payment history. For example:

  • New business accounts with products valued at $500: credit limit of $1,000
  • Accounts older than one year with good payment history: credit limit of $1,500
  • Accounts averaging $750 per month: credit limit of $1,500

Collections paths are defined that detail the sequence and timing of actions performed during the collections process. For example:

  • Path C1:
    • Action 1: Day 2
    • Action 2: Day 5
    • Action 3: Day 10
  • Path C2:
    • Action 1: Day 2
    • Action 4: Day 3
    • Action 3: Day 15

Note:

On each due date, actions are implemented only if no or insufficient payment has been received and exit criteria (including Promise-to-Pay) is not met.

Actions are configured that represent operational steps taken in each path. For example:

  • Action 1: SMS notification/email (using format 'format1')
  • Action 2: Letter dispatch
  • Action 3: Barring order request to Siebel
  • Action 4: Configurable additional actions as required

Credit profiles are set, which segment subscribers to guide risk and collection approaches. For example:

  • Profile 1: New subscriber, value below threshold, no deposit required
  • Profile 2: New subscriber, value above threshold, deposit required
  • Profile 3: Established subscriber (more than 1 year), value below threshold, direct debit payer

Aging buckets are defined that categorize overdue balances based on the number of debtor days to support risk monitoring and reporting. Standard groups are as follows:

  • 0 to 15 days
  • 16 to 30 days
  • 31 to 50 days
  • Over 50 days

Implementing Collections B2C

This feature automates the collections lifecycle for Business-to-Customer (B2C) subscriber accounts identified as delinquent due to unpaid postpaid bills. The system applies standardized collections treatment paths tailored to customer segment, outstanding balance, product type, and delinquency age. Automation ensures efficient recovery, minimizes bad debt exposure, and maintains a consistent customer experience with entry and exit criteria enforced as per the configuration.

Each delinquent B2C subscriber account is automatically assigned a collections treatment path based on:

  • Customer risk segment (low, medium, or high risk)
  • Outstanding debt amount
  • Days past due (DPD)/grace days elapsed from bill due
  • Product type (for example, mobile, broadband, DTH)

Each treatment path specifies:

  • The sequence of actions
  • The interval between actions
  • Escalation logic for non-payment (advance to next step only when no or insufficient payment and no valid Promise-to-Pay (PTP))

The following table provides example action schedules for collection treatment.

Table 4-1 Example Action Schedule

Action Day from Bill Due
SMS reminder/emails Day 2
IVR auto call Day 5
Outgoing call center attempt Day 8
Outgoing service restriction Day 12
Incoming + Outgoing restriction Day 18
Permanent disconnection Day 30

Typical collection actions are as follows:

  • Automated SMS/email payment reminders
  • IVR auto-dial reminders
  • Agent-assisted outbound calls
  • Outgoing call/SMS bar
  • Full service suspension
  • Permanent account disconnection
  • Write-off for low-value debt
  • Transfer to external recovery agency
  • Blacklist/KYC tagging
  • Service reactivation upon payment

The workflow of this feature is as follows:

  • Treatment actions for delinquent subscribers are synchronized from Oracle Communications Billing and Revenue Management (BRM) to Siebel.
  • Payment status is updated in near real-time through digital channels (cards, apps) and via batch for offline/bank transfers.
  • On reaching the scheduled action date, if payment remains insufficient or absent:
    • Siebel implements the required collection step.
    • For manual steps, Siebel triggers appropriate workflows (for example, outbound calls, management escalation).
    • Automated actions (for example, SMS, service barring) are system-initiated.
  • Siebel communicates step completion and status updates back to BRM.

Upon receipt of full payment:

  • All service restrictions (bars) are removed.
  • Any future scheduled collections actions are cancelled.
  • Full service is restored within the service-level agreement (SLA).
  • Subscriber credit behavior profile is updated.

The integration for this feature happens as follows:

  • BRM to Siebel: Synchronization of treatment actions.
  • Siebel to BRM: Reporting of action status and step completion.
  • Siebel to OSM: Fulfillment of service orders (bar/unbar/disconnect).
  • Siebel to SMSC: Dispatch of messaging notifications (for example, SMS reminders).

Configuring Collections B2C

This feature establishes the parameter-driven controls and workflow definitions necessary to support automated and manual collection activities for Business-to-Customer (B2C) customers. This configuration enables operators to efficiently manage overdue accounts, enforce credit policies, and tailor collections strategies to subscriber profiles and payment behaviors.

Credit limits are assigned to subscriber accounts based on predefined rules reflecting account tenure, product value, and payment history. For example:

  • New subscriber accounts with products valued at $100: credit limit of $200
  • Accounts older than one year with good payment history: credit limit of $300
  • Accounts with average monthly value of $150+: credit limit of $300

Collections paths are defined, which specify the sequence and timing of actions based on delinquency duration. For example:

  • Path C1
    • Action 1: Day 2
    • Action 2: Day 5
    • Action 3: Day 10
  • Path C2
    • Action 1: Day 2
    • Action 4: Day 3
    • Action 3: Day 15

Note:

On each due date, actions are implemented only if no or insufficient payment has been received and exit criteria (including Promise-to-Pay) is not met.

Actions within each collection path are explicitly defined. For example:

  • Action 1: SMS notification/email (using format 'format1')
  • Action 2: Letter dispatch
  • Action 3: Initiation of barring order request to Siebel
  • Action 4: Configurable additional actions as required
  • Termination: Generate customer notice; submit cancel/tear-down order

Credit Profiles are set that enable tailored collections and credit strategies based on subscriber status and payment characteristics. For example:

  • Profile 1: New subscriber, value below threshold, no deposit required
  • Profile 2: New subscriber, value above threshold, deposit taken
  • Profile 3: Established subscriber (more than 1 year), value below threshold, pays via direct debit

Aging buckets are defined that segment debtor balances by the length of time past due for reporting and prioritization purposes. For example:

  • 0 to 15 days
  • 16 to 30 days
  • 31 to 50 days
  • Over 50 days

Note:

  • Maintain a systematic approach to defining and updating rules, actions, and profiles to align collections activities with evolving business policies.
  • Ensure collections configurations are consistent with regulatory and customer experience requirements.

About Analysis of Siebel Collections Processing

This feature details the Siebel system’s role in performing collection activities initiated from the Oracle Communications Billing and Revenue Management (BRM) application. This integration ensures comprehensive handling of overdue accounts, customer communication, service management, and escalation actions throughout the collections lifecycle.

The following actions are triggered in Siebel as part of the collections process, either via synchronized requests from BRM or manual initiation:

  • Email or SMS Notification:
    • Siebel sends an email or SMS reminder to subscribers regarding outstanding bills.
    • Example Email Content: This is a reminder that your communications bill of $nn on account nnnnnn is now due. Please pay as soon as possible to avoid service disruption. If you have already paid, please ignore this message.
    • Failed or bounced messages are flagged on the collections event.
    • All communication details are stored and accessible via the Customer 360 interface.
  • Physical Mail Generation:
    • Siebel generates a formal letter for mailing using the Siebel document server or Oracle Analytics Publisher (OAP) system, as appropriate. The letter includes:
      • Account number
      • Debt amount
      • Due date
      • Payment instructions
      • Notice regarding consequences of non-payment and available support channels
    • All letters are stored for retrieval and displayed in Customer 360.
  • Call Initiation:
    • Siebel schedules or triggers an outbound call, delivered through a Customer Service Representative (CSR) or automated recording.
    • Call metadata, recordings, and summaries are stored for CSR review within Customer 360.
  • Bar or Throttle Service:
    • When sufficient payment or a valid Promise-to-Pay is recorded, Siebel generates the unbar/restore Modify order and submits it to OSM.
    • Upon a bar or throttle action, Siebel generates and submits orders to restrict service (outbound, total, or bandwidth throttling) for all products on the corresponding billing account.
    • Orders are automatically processed for provisioning via OSM.
  • Terminate Agreement and Cancel Services:
    • Siebel produces and sends a termination notice to the subscriber (detailing account, debt, date, and affected services).
    • Generates orders to cancel (tear down) all services, quarantining resources for reuse.
    • Flags account as Terminated for debt and adds it to the bad debt register. This status syncs back to BRM.
  • Debt Write-off: Manual action performed by finance personnel using Siebel or Billing Care, referencing the appropriate policy.
  • Send to Collections Agency: Activity is either processed by internal collection agents or forwarded to finance for external collection action.
  • Legal Escalation:
    • A service request or activity is generated for the legal department.
    • Account is flagged as Legal, ensuring any subscriber contact is routed appropriately.

Note:

  • All collections activities, communications, and escalations are recorded for retrieval and review within Customer 360.
  • SMS, Call, and Email are field configurations and not part of the reference solution. Hence, sending messages is subject to integration with underlying SMSC and email server.
  • Status changes and service actions are synchronized between Siebel and BRM to maintain data consistency and auditability.
  • Execution failures are not advanced unless policy allows.

About Collections Siebel Sends Message

This feature automates the process of notifying subscribers regarding overdue bills through electronic and physical communication channels. This feature leverages Siebel to implement message delivery actions triggered by the collections workflow synchronized from the Oracle Communications Billing and Revenue Management (BRM) system.

Siebel performs the following actions as part of the collections process:

  • Send reminder text (Email/SMS)
  • Send reminder letter (Physical Mail)

Electronic Messaging

Note:

SMSC and Email are field configurations and not part of the reference solution. Hence, sending messages is subject to integration with underlying SMSC and email server.
  • Siebel sends a reminder message to the customer via email or SMS.
  • The message communicates the outstanding bill amount and account reference, for example:

    This is a reminder that your communications bill of $nn on account nnnnnn is now due. Please pay as soon as possible to avoid service disruption. If you have already paid, please ignore this message.

  • If a message fails to deliver or is returned as undelivered (for example, incorrect email address), Siebel flags the event on the collections record for further review.
  • All message details are recorded and made available for display and historical reference via the Customer 360 view.

Note:

  • Ensure message templates, addresses, and configurations are maintained for accuracy and compliance.
  • Regularly review flagged undelivered messages and update contact information as required.

About Collections Siebel Creates SR or Activity

This feature manages the initiation of manual activities and service requests (SRs) as part of the collections process. These actions are triggered by collections events synchronized from Oracle Communications Billing and Revenue Management (BRM) and are implemented within Siebel to ensure proper escalation and tracking of non-automated collections steps.

Siebel supports the following manual actions within the collections workflow:

  • Outbound call
    • Siebel initiates an outbound call activity, which can be conducted by a Customer Service Representative (CSR) or as an automated recorded message. Both outbound calls and automated recorded messages are handled via approved dialer/IVR integrations as configured.
    • Each outbound call activity is assigned to a designated user or position in the system.
    • Details captured include the date and time of the call, call recording, and call summary.
    • All call activity data is stored and available for review within the Customer 360 view.
  • Write-off debt
    • Write-off is a manual Accounts Receivables (A/R) adjustment performed by a finance department employee.
    • This action can be completed via Siebel or Billing Care.
    • The task is assigned to a finance team member or role responsible for debt adjustments.
  • Notify Legal department
    • Siebel creates an SR or activity directed to the Legal department for accounts requiring escalation.
    • The account is flagged as Legal, ensuring that any future customer contact is directed appropriately.
    • The SR or activity is assigned to the Legal department or appropriate user/position for follow-up.

Note:

  • SR or Activities are field configurations and not part of the reference solution. Hence, sending messages or SR is subject to integration with underlying required systems.
  • Each manual activity or SR is explicitly assigned an owner (user or functional role) for clear responsibility and follow-through.
  • All activities and their status are tracked within Siebel and visible for operational oversight.

About Collections Automated Disconnect, Barring, and Unbarring

This feature orchestrates the execution of service restrictions and restorations in response to collections actions initiated in the Oracle Communications Billing and Revenue Management (BRM) system. Integration with Siebel ensures that all necessary provisioning and customer communication actions are automated, consistent, and auditable.

Bar, Unbar, or Throttle Service

  • Upon receipt of a collections action from BRM, Siebel automatically generates an order to apply the designated service restriction to all or selected services/products linked to the billing account. Actions may include:
    • Outgoing bar (restrict outbound service)
    • Total service bar (restrict both inbound and outbound)
    • Bandwidth throttle (for applicable products)
  • The order is automatically submitted for provisioning through the Oracle Communications Order and Service Management (OSM).

Note:

Credit alert based throttling initiation from Siebel is considered as field configuration (based on Policy Control Function (PCF) or Policy and Charging Rules Function (PCRF) integration) and not part of the reference solution.

Integration and Synchronization

  • All collections-generated service actions initiated in BRM are communicated to Siebel for fulfillment and status update.
  • Siebel automates order generation, submission, and customer notification processes (for example, SMS/email notices for barring/termination as required), ensuring alignment with collections policies and provisioning requirements.
  • Updates to account statuses and service orders are reflected back to BRM, maintaining consistent financial and operational records.

Note:

  • Ensure all actions and status changes are logged for compliance and auditability.
  • Maintain clear communication protocols between BRM, Siebel, and OSM to prevent service recovery or restriction errors.

About Exit Collections

This feature manages the process of removing subscriber accounts from collections treatment when designated exit conditions are met. Its primary objective is to allow timely restoration of services and update account credit status, thereby balancing revenue recovery with a reduction in bad debt exposure.

This feature:

  • Facilitates the rapid reinstatement of services for subscribers who have resolved their outstanding balances or made acceptable payment arrangements.
  • Ensures accurate updating of credit limits, collections profiles, and service statuses in accordance with company policy.

The Exit criteria is as follows:

  • Full Payment: The account is eligible for collections exit when full payment of outstanding debt is received. Exit criteria can be configured to accept partial payments above a defined limit/threshold.
  • Promise-to-Pay (PtP) Arrangement: Accounts with actively maintained PtP agreements may also qualify for collections exit, depending on configuration.

Depending on the mode of payment, the account exits collections as follows:

  • Online Payment
    • When an online payment meeting or exceeding the exit threshold is received, the account is immediately removed from collections status.
    • No further collections actions or treatments are scheduled.
    • The account’s collections profile and credit limit are reassessed and may be updated.
    • Any service restrictions imposed by collections activities are lifted, and service is restored to its pre-collections state (including any previously active voluntary suspensions).
    • Siebel is updated to cancel associated collections workflows and actions.
  • Offline (Batch) Payment
    • When a batch-processed offline payment meets the exit threshold, the collections exit execution process identifies eligible accounts.
    • The account is taken out of collections status, and no further treatment actions are initiated.
    • The account’s collections profile and credit limit are reassessed and updated as needed.
    • Service restrictions are addressed, with restoration to the prior status before collections actions.
    • Siebel is correspondingly updated to remove collections workflows or actions.

This feature uses Oracle Communications Billing and Revenue Management (BRM) to Siebel interfaces to ensure synchronization for cancellation of collections actions and restoration of account status (weekends/holidays are considered).