1 About Collecting General Ledger Data

This chapter describes how to collect general ledger (G/L) data from your Oracle Communications Billing and Revenue Management (BRM) system.

Before reading this chapter, you should be familiar with the BRM price list, and with BRM billing and accounting cycles. See the following documents:

BRM Pricing and Rating
BRM Configuring and Running Billing

To set up G/L reporting, you must be familiar with accounting terms, systems, and data. You need to work with your accountants to find out how your company handles G/L data.

About General Ledger (G/L) Data

Your company's general ledger is the total list of all accounts used by your accountants to track revenue and expenses. For example, a company might use the following general ledger accounts:

Cash
Wages
Accounts receivable

A service-based business typically has general ledger accounts to track revenue from different sources. For example, a company might track revenue in the following general ledger accounts:

Monthly fees
Usage fees
Cancelation fees

When you set up G/L reporting in BRM, your goal is to make sure that data generated in the BRM system is reported to the correct general ledger account; for example, that revenue from monthly fees is recorded in the monthly fees account.

Note:

General ledger accounts are not BRM accounts, such as those assigned to customers. A general ledger account is the name of an account used by your company accountants to track revenue.

How BRM Collects G/L Data

To collect G/L data, you assign a G/L code to each type of balance impact for which you need to track revenue, for example:

The balance impact for a monthly subscription fee.
The balance impact of a GPRS usage event.

You run a report to collect the G/L data, typically once a month. When you run the report, BRM looks at the /journal objects that contain summaries of revenue from the events for the last month and finds the G/L impact for each event that has a balance impact. The report summarizes the revenue for each type of balance impact.

Figure 1-1 shows a small portion of a G/L report. The account that collects revenue data about monthly fees is called monthly; the account for dialup usage fees is called dialup.

Figure 1-1 G/L Report Portion

Description of ''Figure 1-1 G/L Report Portion''

About A/R and Offset Accounts

Each general ledger account has two parts, A/R and offset, each divided into debit and credit columns. This organization is used for double-entry accounting and is automatically tracked by BRM.

In a G/L report:

The entries in the column labeled DEBIT ACCOUNT represent the A/R accounts and the ones in the column labeled CREDIT ACCOUNT represent the Offset accounts.
The DEBIT ACCOUNT entries are always listed first and the CREDIT ACCOUNT entries are listed second.
The G/L Report program always impacts the A/R account (Debit Account in G/L reports) by the impact of an event (same sign as balance impact) and always impacts the Offset account (Credit Account in G/L reports) by the exact opposite (negate the sign) of the balance impact.
A positive number (+) is always a debit, and a negative number (-) is always a credit. There are no exceptions, no matter what kind of account it is.

For example:

A customer purchases a product for $10:
- The customer account balance has +$10 impact.
- The A/R Account gets +$10 = $10 debit.
- The Revenue Account gets -$10 = $10 credit.
A customer credit card gets charged $10:
- The customer account balance has -$10 impact.
- A/R Account gets -$10 = $10 credit.
- The Cash Account gets +$10 = $10 debit.
A customer account gets a $10 credit adjustment:
- The customer account balance has -$10 impact.
- The A/R Account gets -$10 = $10 credit.
- The Revenue Account gets +$10 = $10 debit.

About Setting Up G/L Reporting

To set up G/L reporting, you do the following:

(Optional) Create a chart of accounts (COA) in BRM to verify that G/L accounts in BRM match the G/L accounts in your external G/L tracking system. See "Creating a Chart of Accounts" for more information.
Create General Ledger IDs. These IDs assign G/L codes to BRM balance impacts. For example, you might assign the G/L ID 1000111 to telephone call usage balance impacts. You create G/L IDs by editing and loading the pin_glid file. See "Creating General Ledger IDs" for more information.

Some balance impacts, such as payments and adjustments, are generated from nonrated events; that is, the balance impact is not created by rating billable events. You assign G/L IDs to those balance impacts by editing the reasons.locale file. You can assign a G/L ID to any event that has a balance impact. See "Assigning G/L IDs to Nonrated Events" for more information.

In addition to assigning G/L IDs to balance impacts from different events, you can create G/L segments to track revenue by brand or by any arbitrary category, for example, by geographic region. See "Creating General Ledger IDs" for more information.
When you create products in the Pricing Center, assign a G/L ID to each balance impact.

Within Pricing Center, you choose from a list of G/L IDs to define rates for cycle fees, one-time fees, and usage fees. BRM assigns at least one G/L ID per rate. Within each rate, you can have more than one fee. For example, a total monthly rate can be split into email and IP fees. In this case, you can assign a separate G/L ID for the email fee and IP fee.

Figure 1-2 shows G/L assignments in Pricing Center.

Figure 1-2 Pricing Center G/L Assignments

Description of ''Figure 1-2 Pricing Center G/L Assignments''

As events occur in the BRM system, intermediate G/L results, which are summaries of the revenue, are stored in /journal objects in the BRM database. When you run the pin_ledger_report utility to create a G/L report, BRM reads the journal object for G/L activity, creates a sum of the balance impacts associated with each type of G/L ID, and records the revenue amount in the corresponding G/L account.

In the example shown in Figure 1-3, BRM finds events, totals the balance impacts for each G/L ID, and compiles the balance impacts in a G/L report.

Figure 1-3 Event G/L Assignments for G/L Report

Description of ''Figure 1-3 Event G/L Assignments for G/L Report''

How BRM Stores General Ledger Reports

The pin_ledger_report utility uses PCM_OP_GL_LEDGER_REPORT to store general ledger reports in the BRM database. This opcode calls PCM_OP_CREATE_OBJ to create a /ledger_report storable object.

When the PCM_OPFLG_READ_RESULT flag is set, the opcode returns the entire contents of the /ledger_report storable object.

About G/L IDs

BRM stores the balance impact of events in the BRM database. To track G/L data, you create a general ledger ID (G/L ID) for each type of balance impact, for example, balance impacts for usage fees.

To create G/L IDs, you edit the pin_glid file and use the load_pin_glid utility to load the G/L IDs into the BRM database.

Important:

If you use Pipeline Manager to rate events, you need to use the same G/L IDs in your price list and in the Pipeline Manager pricing configuration.

Each G/L ID definition contains the following information:

An identification number.
A description, which is displayed in Pricing Center.
(Optional) The tax code used by your tax calculation software.
The G/L account that collects the revenue data, including the revenue type, for example billed, unbilled, and unearned. (See "About Revenue Recognition".) In addition, you define the following account pair attributes:
- gross – reports the total of net and discounted revenue.
- disc – reports the balance impacts of discounted revenue.
- net – reports the amount of revenue that remains after applying discounts.
- tax – reports the amount of taxes calculated. This data is used for collecting G/L data based on tax codes.

Usually, you post G/L for gross and discount revenue, or you post for net revenue.

For example, if you provide a $5 discount on a $30 cycle forward fee:

The gross amount is $30
The discounted amount is $5
The net amount is $25

This example shows the G/L ID definition for a purchase fee:

#============================================================================
# G/L ID for purchase rate 
#============================================================================
glid 
id            10123222
taxcode       PURCHASE_TAXCODE
descr         Purchase Fees
gl_acct       billed         gross       purchase.debit        purchase.credit
gl_acct       billed         net         purchase.debit        purchase.credit
gl_acct       billed         disc        purchase.credit       purchase.debit
gl_acct       unbilled       gross       purchase.debit        purchase.credit
gl_acct       unbilled       net         purchase.debit        purchase.credit
gl_acct       unbilled       disc        purchase.credit       purchase.debit

Note:

This organization is used for double-entry accounting, and is tracked by BRM automatically.

How G/L IDs Affect Storage and Reporting of G/L Data

The G/L ID assigned to a balance impact determines whether the balance impact is stored in a /journal object and whether it is included in a G/L report as shown in Table 1-1:

Table 1-1 G/L IDs

G/L ID	Description	Stored in Journal Object?	Included in G/L Report?
0	Default G/L ID. If you forget to assign a G/L ID to a balance impact type, BRM automatically assigns G/L ID 0 to it. You should reassign such balance impact types to an appropriate G/L ID.	Yes	No
1 through 99	Assigned to balance impact types that are not included in G/L reports.	No	No
100 and above	Assigned to balance impact types that are included in G/L reports.	Yes	Yes

G/L ID

Description

Stored in Journal Object?

Included in G/L Report?

Default G/L ID.

If you forget to assign a G/L ID to a balance impact type, BRM automatically assigns G/L ID 0 to it. You should reassign such balance impact types to an appropriate G/L ID.

Yes

1 through 99

Assigned to balance impact types that are not included in G/L reports.

100 and above

Assigned to balance impact types that are included in G/L reports.

Yes

For information on how to control the creation of /journal objects for non-currency resources, see "Disabling /journal Objects for Non-Currency Resources".

Planning Your G/L IDs

When planning G/L IDs, you need to know the following information:

The balance impacts that need revenue reporting, for example, if you need to report revenue from monthly fees, usage fees, and payments.
The names of G/L accounts used in your company's accounting system. You use these names when assigning G/L IDs to G/L accounts. See "About the Chart of Accounts".
The nonrated events for which you want to track revenue, for example, payments. See "Assigning G/L IDs to Nonrated Events" for more information.
The method your company follows when reporting earned and unearned income. See "About Revenue Recognition" for more information.
Whether your company offers services that require G/L data to be separated by G/L segment. See "About Collecting G/L Data for Brands or Selected Accounts".

Important:
When you create products for each brand, you use the brand-specific G/L IDs. Pricing Center displays G/L IDs for all brands. To make sure you know which G/L ID to use for each brand's price list, include the brand name in the G/L ID description.
If you need to track tax codes. You can modify the pin_glid file to assign unique G/L IDs per tax code.

About Collecting G/L Data for Brands or Selected Accounts

You can use G/L segments to create G/L reports that include data for specific brands, or arbitrary sets of customers. For example, G/L reports for different geographic regions.

You specify the segment to run the report on when you run the pin_ledger_report.

For information about creating segments, see "Creating General Ledger IDs" for more information.

Using Multiple pin_glid Files for Multiple Segments

You can use one pin_glid file for multiple segments, or you can load multiple pin_glid files, one for each G/L segment.

If you use one pin_glid file for multiple segments, all segments use the same G/L IDs.
If you use a different pin_glid file for each segment, you can create different G/L IDs for each segment. This is the typical method.

How Customer Accounts are Assigned to Segments

To collect G/L data about a specific brand or a group of accounts, BRM needs to know which brand or G/L segment applies to each customer account.

Accounts that are assigned to a brand are automatically assigned a G/L segment.
Your BRM system uses a default root segment, which is defined in the Connection Manager pin.conf file. By default, all accounts use the root segment. To change the default segment, see "Changing the Default G/L Segment" for more information.
To assign G/L segments without branding, you must define the G/L segments by editing policy source code. See the PCM_OP_CUST_POL_PREP_BILLINFO opcode for more information.

Creating Nested Segments

You can create nested G/L segments. For example, you can create the following segments:

northwest
northwest.washington
northwest.oregon

This allows you to run reports on all of your Northwest region, including Oregon and Washington, or just on Oregon and Washington specifically.

You can define unlimited levels of nesting.

You can specify if the data for a segment should be included when you run a report against the parent segment. To do so, you use the no_rollup entry in the pin_glid file to specify that the segment should not be included in the parent report.

gl_segment  .
gl_segment  .northwest
gl_segment  .northwest.washington
gl_segment  .northwest.oregon  no_rollup
gl_segment  .southwest     no_rollup
gl_segment  .Central

As seen in Table 1-2, .northwest, .northwest.washington, and .central are included in parent reports, but .northwest.oregon and .southwest are not.

Table 1-2 Data Included for Example Reports

Report for This Segment	Includes Data for These Segments
. (root segment)	.northwest, .northwest.washington, and .central
.northwest	.northwest and .northwest.washington
.northwest.washington	.northwest.washington
.northwest.oregon	.northwest.oregon
.southwest	.southwest
.central	.central

Important:

Be sure to specify the parent segment in the report or you will get an error message like the following:

E 05/26/03 15:39:54  -  load_pin_glid:1960.2460  load_pin_glid.c:1477
Root Segment .NSL_REGIONAL is missing. Define the root before the child (.NSL_REGIONAL.BB)

Setting up G/L IDs for Brands

To create G/L IDs for separate brands, you create multiple G/L segments and multiple pin_glid files.

Create a pin_glid file for the root segment.
Define a separate pin_glid file for each brand. Use the brand name as the segment name.
After defining the G/L IDs for each brand, prepare a list of G/L ID numbers that are used across all brands.
In the pin_glid file for the root segment, define all the common G/L IDs. If you do not require ledger reports for the root segment, the general ledger accounts you specify here can be dummy accounts. However, if you need to track revenue for the root segment, define the appropriate general ledger accounts for the G/L IDs you require. For any G/L IDs you do not require, specify dummy general ledger accounts.

Important:
When you create products for each brand, you use the brand-specific G/L IDs. Pricing Center displays G/L IDs for all brands. To make sure you know which G/L ID to use for each brand's price list, include the brand name in the G/L ID description.
Load the pin_glid files, including the pin_glid file for the root segment, by using the load_pin_glid utility.

Note:
The G/L IDs for nonrated events are the same for all brands.

About the Chart of Accounts

You can load a chart of accounts (COA) into the BRM database. The COA verifies that the G/L accounts you enter in the G/L IDs are valid. The COA is optional.

You load the COA before loading G/L IDs. When you load the G/L IDs, the load_pin_glid utility reads the COA to verify that the G/L accounts exist. If the utility finds a nonvalid G/L account, it reports an error.

If you use multiple G/L segments, you can load multiple COAs and assign a different COA to each segment.

See "Creating a Chart of Accounts" for information on loading a COA.

The COA includes the following fields:

coa_id: Defines the identification number for the chart of accounts. You use this ID in the pin_glid file to specify which COA to use for the G/L IDs in that file.
coa_name: Represents a short name that describes the COA.
gl_coa_accts: Lists the G/L accounts that are part of the COA. Each entry includes a description of each G/L account, such as the account number, name, type, and status of the account.

Shown below is a sample pin_glchartaccts file. The sample also indicates the type of the account: asset, revenue, expense, or liability. It also indicates that all the accounts are active.

gl_chartaccts (
    coa_id         1000
    coa_name       Primary COA
    gl_coa_acct    0         undefined       revenue    active
    gl_coa_acct    1         undefined       asset      active
    gl_coa_acct    49400     prepaid.off     revenue    active
    gl_coa_acct    49300     monthly.A/R     asset      active
    gl_coa_acct    49200     uncollect.A/R   asset      active
    gl_coa_acct    40800     uncollect.off   revenue    active
    gl_coa_acct    40700     cancel.A/R      asset      active
    gl_coa_acct    40500     prepaid.A/R     asset      active
    gl_coa_acct    40000     purchase.off    revenue    active
    gl_coa_acct    20160     monthly.off     revenue    active
    gl_coa_acct    20150     cancel.off      revenue    active
    gl_coa_acct    11000     purchase.A/R    asset      active
    gl_coa_acct    10600     daily.A/R       asset      active
)

About Running G/L Reports

Use the pin_ledger_report utility to extract data from BRM and create G/L reports. This utility searches the BRM database for /journal objects containing G/L activity and summaries of revenues and either displays the data or writes it to the BRM database. You can also use the pin_ledger_report utility to export G/L reports to XML files so they are available to an external G/L system. See "Exporting General Ledger Reports to XML Files" for more information.

Note:

/journal objects are created and updated by Rated Event (RE) Loader.

Writing the data to the database is called posting the G/L report. You typically post G/L reports once a month. When you post a G/L report, you prevent backdating adjustments, write-offs, subscription transactions, or other transactions, prior to the last date you posted the G/L report. This maintains general ledger data integrity. After they are posted, the G/L report updates the /data/ledger_report object. This object records the date of the latest posted G/L report and controls transaction backdating.

You can run G/L reports at any time without posting data. When you do not post data, backdating is not affected.

Note:

Exporting G/L reports automatically creates them; this is part of the export operation. You do not need to create them first.

About Revenue Recognition

To report general ledger data consistently, you run G/L reports on a regular basis, for example, on the last day of the month. However, customer accounts can be billed on any day of the month. Therefore, at the time the G/L report is run, some accounts have been billed and some have not, so some revenue is recognized as billed and some as unbilled.

Also, you might run a G/L report that includes revenue from a cycle forward fee that is partially earned and partially unearned. For example, if a customer is charged for one month in advance, if you run a G/L report in the middle of the month, the revenue for the first two weeks has been earned, but the revenue for the last two weeks has not been earned yet, even if it has been billed.

BRM recognizes seven revenue types:

Billed
Unbilled
Billed earned
Unbilled earned
Billed unearned
Unbilled unearned
Previously billed earned

Whereas most companies generate G/L reports for billed and unbilled revenue, it is less common to recognize the difference between earned and unearned revenue. You need to find out if your company uses immediate revenue recognition or accrual-based revenue recognition:

Immediate revenue recognition reports all charges as earned as soon as they are applied. For example, a monthly cycle forward fee is considered earned even if the customer has not used the entire month of service. All revenue is recognized and reported as either billed or unbilled.

In this case, billed and unbilled revenue include earned and unearned revenue:
- Billed = billed earned + billed unearned + previously billed earned
- Unbilled = unbilled earned + unbilled unearned
See "About Immediate Revenue Recognition".
Accrual–based revenue recognition reports all charges as earned based on when the services are rendered. For example, a monthly cycle forward fee is considered only partially earned if the customer has not used the entire month of service. All revenue is recognized and reported as earned or unearned. See "About Accrual–Based Revenue Recognition".

About Reversing G/L Entries

An amount reported as unbilled should be reversed in your company's general ledger in the period following the one in which it was reported. For example, an entry made for unbilled revenue in the month of January should be reversed if it is billed in February. BRM automatically reverses its general ledger data when it changes from unbilled to billed; however, you might need to reverse the data in your company's accounting software.

About Immediate Revenue Recognition

If your company recognizes immediate revenue, you need to customize BRM to report billed and unbilled revenue for all G/L accounts.

About Billed and Unbilled Revenue

Billed revenue is revenue that was already billed at the time that the G/L report is generated. This includes revenue from charges that have been included in a bill, but not necessarily earned.

Unbilled revenue is revenue that includes charges not included in a bill. For example, usage fees that have accrued after the last bill, but have not been billed. Unbilled items become billed at the end of the customer's billing cycle.

Note:

Unbilled is not the same as uncollected. For example, if a customer uses a credit card to pay a cycle forward fee for the first month of service at registration time, the money is collected from the credit card company almost immediately. The cycle forward fee remains unbilled, however, until you run the BRM billing applications.

The following examples show how different types of rates and events can be billed or unbilled depending on the billing date and the G/L reporting date.

Billed and Unbilled Usage Fees

In the example shown in Figure 1-4, the last billing date for the customer was 2/15, and the G/L report was run on 2/28. Usage fees occurring between 2/15 and 2/28 are reported as unbilled.

Figure 1-4 Billed and Unbilled Usage Fees

Description of ''Figure 1-4 Billed and Unbilled Usage Fees''

Billed and Unbilled Purchase and Cancellation Fees

If a purchase or cancel event occurs after the billing date but before the G/L reporting date, BRM G/L reports the revenue as unbilled.

In the example shown in Figure 1-5, a purchase fee made on 1/20 was billed during the scheduled billing cycle that ran on 2/15. Another purchase fee was made on 2/20. Since the scheduled billing date (2/15) has passed, the revenue for the second purchase fee is recorded as unbilled.

Figure 1-5 Billed and Unbilled Purchase and Cancellation Fees

Description of ''Figure 1-5 Billed and Unbilled Purchase and Cancellation Fees''

Billed Cycle Arrears Fees

Cycle arrears fees are always billed. In the example shown in Figure 1-6, the cycle arrears fee billed on 2/15 is included in the 2/28 report as billed.

Figure 1-6 Billed Cycle Arrears Fees

Description of ''Figure 1-6 Billed Cycle Arrears Fees''

Billed and Unbilled Cycle Forward Arrears Fees

Cycle forward arrears fees can be reported as billed or unbilled, depending on when the G/L report is run. In the example shown in Figure 1-7, the last billing date for the customer was 2/15, and the G/L report was run on 2/28. Cycle forward arrears fees occurring between 2/15 and 2/28 are reported as unbilled:

Figure 1-7 Billed and Unbilled Cycle Forward Arrears Fees

Description of ''Figure 1-7 Billed and Unbilled Cycle Forward Arrears Fees''

Billed and Unbilled Nonrated Events

Revenue from nonrated events that are not included in bill items, such as payments and refunds, is always recorded as billed if the event occurs before the G/L report. The billing date has no affect on whether a payment or refund is reported as billed. If a payment or refund event occurs after a G/L reporting date, it is not included in the report.

In the example shown in Figure 1-8, the payments made on 1/31 and 2/20 are included as billed revenue in the 2/28 G/L report. The payment made on 3/20 is not included in the 2/28 G/L report.

Figure 1-8 Billed and Unbilled Nonrated Events

Description of ''Figure 1-8 Billed and Unbilled Nonrated Events''

Billed and Unbilled Cycle Forward Fees

Cycle forward fees are always billed except when the cycle forward fee is for a new account. In the example shown in Figure 1-9, the cycle forward fee billed on 2/28 is reported as billed in the G/L report on 3/15.

Figure 1-9 Billed and Unbilled Cycle Forward Fees

Description of ''Figure 1-9 Billed and Unbilled Cycle Forward Fees''

Note:

Because cycle forward fees pay for services in advance, the G/L report can include revenue for services that have not yet been earned.

About Unbilled Cycle Forward Fees

Cycle forward fees can be unbilled when the fee is for a new account.

In the example shown in Figure 1-10, the cycle forward fee charged when the account is created is not billed until 2/28. Therefore, the G/L report run on 2/15 reports the revenue as unbilled.

Figure 1-10 Unbilled Cycle Forward Fees

Description of ''Figure 1-10 Unbilled Cycle Forward Fees''

About Accrual–Based Revenue Recognition

When your company recognizes accrual–based revenue, you need to configure your BRM G/L system to report earned and unearned revenue.

Revenue that is earned at the time that a G/L report is run is called earned revenue. Fees applied to usage, purchase, and cancellation of items are always accounted for as earned revenue.

Unearned revenue is revenue that is not earned at the time the G/L report is run. Unearned revenue only applies to revenue from cycle forward fees and cycle forward arrear fees.

See "How BRM Calculates Earned and Unearned Revenue" for more information on earned and unearned revenue.

About Earned and Unearned Cycle Forward Arrears Fees

Cycle forward arrears fees can be reported as earned or unearned depending on when the G/L report is run. In the example shown in Figure 1-11, the customer's billing date is 3/31. When the G/L report is run on 3/15, BRM accounts for G/L revenue from cycle forward arrears fees as follows:

The cycle forward arrears fee from 3/1 - 3/15 is unbilled/earned.
The cycle forward arrears fee from 3/16 - 3/31 is unbilled/unearned.

Figure 1-11 Earned and Unearned Cycle Forward Arrears Fees

Description of ''Figure 1-11 Earned and Unearned Cycle Forward Arrears Fees''

See "How BRM Calculates Earned and Unearned Revenue" for information on how earned and unearned revenue is calculated.

About Unbilled/Unearned Cycle Forward Fees

The first cycle forward fee for a new account can be unbilled and unearned. In the example shown in Figure 1-12, the first cycle forward fee for the new account is not billed until 2/28. When the G/L report is run on 2/15, BRM accounts for G/L revenue from cycle forward fees as follows:

The cycle forward fee from 2/1 - 2/15 is unbilled/earned.
The cycle forward fee from 2/16 - 2/28 is unbilled/unearned.

Figure 1-12 Unbilled/Unearned Cycle Forward Fees

Description of ''Figure 1-12 Unbilled/Unearned Cycle Forward Fees''

About Previously Billed Earned Revenue

Previously–billed revenue is revenue that was billed in the previous billing cycle, but recognized in the current G/L cycle. For example, if a portion of a cycle event, such as a cycle fee, is earned across two G/L cycles, then BRM reports the earned portion of this revenue as previously–billed earned revenue. See "Calculating Previously Billed Earned Revenue" for more information.

About Adjustments and G/L Reporting

By default, adjustments made to an open bill item or a pending bill item are always considered billed. The BRM system creates an /event/billing/adjustment/event storable object and records the adjustment amount as billed in the adjustment item (/item/adjustment). The adjusted amount is reported in the billed G/L report.

In addition, when adjustments are made to a pending bill item, the original amount in the bill item is considered unbilled and is reported in the unbilled G/L report, and the adjustment amount in the adjustment item (item/adjustment) is considered billed and reported in the billed G/L report. When the pending bill items are eventually billed, the billed amount is reported in the billed G/L report.

You can change this behavior to create shadow event objects instead of adjustment event objects. Creating shadow event objects has the following advantages:

For pending bill item adjustments, both the original amount and the adjustment amount are associated with the same bill item and are recorded in the unbilled G/L report until billing is run.
Adjustment amounts do not show up in customers' bills as line items that modify the total due because the events have already been adjusted. You can specify whether shadow event adjustment details are displayed in invoices. See the discussion on customizing information included in invoices in BRM Configuring and Running Billing.

Note:
Shadow events are created for event-level adjustments only. BRM creates shadow events only for events that are adjusted before they are billed.

To specify whether to generate a shadow event or adjustment event, you modify the input flist of the PCM_OP_AR_EVENT_ADJUSTMENT opcode. For more information, see the discussion of unbilled event-level adjustments in G/L reports in BRM Managing Accounts Receivable.

About Rounding and G/L Reports

To round event balance impacts for billing and G/L reports, you specify a rounding rule for A/R processes in the balance element ID (BEID) configuration file (BRM_Home/sys/data/pricing/example/pin_beid). You then run the load_pin_beid utility to load the contents of the pin_beid file into the /config/beid object in the BRM database. For more information, see the discussion on rounding in BRM Setting up Pricing and Rating.

The balance impacts of events are totaled and rounded separately for billing and G/L reports:

When generating a bill, the event balance impacts in the items are totaled, then the items are rounded, summed, and added to the bill.
When generating a G/L report, the balance impacts of all events with the same G/L ID are totaled in journal entries, then the journal entries are rounded and posted.

Note:
Balance impacts are intermittently sub-totaled in G/L journal entries prior to posting, but are not rounded until a report is generated. For more information about journal entries, see /journal.

For information about setting up BRM to record rounding differences, see the discussion on resource rounding in BRM Setting up Pricing and Rating.

Rounding G/L Report Data After Billing

Events that belong to an item can belong to different journal entries. When there are a great number of items, this can cause minor rounding differences between the billing totals and the G/L report totals.

Figure 1-13 is a simplified example of how billing and G/L totals for the same balance impacts can differ when the balance impacts in an item belong to different journal entries. In this example, the precision is 3 for rating and 2 for A/R, and the mode is round to the nearest:

Figure 1-13 Rounding G/L Report Data after Billing

Description of ''Figure 1-13 Rounding G/L Report Data after Billing''

When you run billing, this rounding difference is recorded in the bill item, and included in G/L reports. A G/L ID is defined for rounding difference so that the G/L report can be accurately reconciled. See "How BRM Records the Difference Between Rounded and Unrounded Items" for more information.

Rounding G/L Report Data Prior to Billing

Because items are not rounded prior to billing, they might have a high precision such as six significant digits. However, journal entries are rounded when G/L reports are run. This can create small rounding discrepancies because rounding differences are not recorded until billing is run. For example, if the sum of all billing items is 100.53009, the pre-billing G/L report will display the rounded amount of 100.53, leaving a difference of 0.00009 undocumented.

How BRM Records the Difference Between Rounded and Unrounded Items

The difference between rounded and unrounded item totals is typically a very small amount referred to as the delta. This delta is recorded and included in G/L reports so that they can be accurately reconciled. The delta rounding difference is recorded in the following ways:

When billing is run and pending items are rounded, the delta rounding difference is recorded in the /item object.
A corresponding /journal entry object is created for each pending item. The delta rounding difference is stored as a credit or debit in the /journal object to balance the G/L:
- If the rounding difference is negative, the balance needs to be credited, so the amount is stored in the PIN_FLD_CR_AR_NET_AMT field.
- If the rounding difference is positive, the balance needs to be debited, so the amount is stored in the PIN_FLD_DB_AR_NET_AMT field.
When a G/L report is generated, the journal entry containing the delta rounding difference is included in the report.

The delta rounding difference is calculated as the difference between a rounded pending item total and the sum of the rounded journal entries associated with the pending item:

    round(unrounded pending items) 
 -  sum(round(journal entries)
-------------------------------------------
 =  rounding difference

For example, if a rounded pending item total is 11.72 and the sum of rounded journal entries is 11.73, the delta rounding difference is 11.72 - 11.73, or -.01.

G/L Report Example

This example shows how revenue is reported for three customer accounts over several months. The following diagrams show the billing cycles relative to monthly G/L reports for each account. Arrows represent billing cycles. G/L reporting periods begin on the first day of each month and end on the last day of each month.

Note:

To make these examples clearer, the calculated amounts are approximations. For example, a value of $15.00 might actually be $16.45, if the BRM calculations are used. See "How BRM Calculates Earned and Unearned Revenue" for more information.

G/L results for January 31

Account A has a monthly billing cycle that starts on 01/01.
Account B has a quarterly billing cycle that starts on 01/01.
Account C has a monthly billing cycle that starts on 01/15.

Figure 1-14 shows the G/L results for January 31.

Figure 1-14 Billing Cycles Relative to Monthly G/L Reports for January 31

Description of ''Figure 1-14 Billing Cycles Relative to Monthly G/L Reports for January 31''

Account A incurs a one-time $5 purchase fee for account creation and a recurring $30 monthly cycle forward fee.
Account B incurs a one-time $5 purchase fee for account creation and a recurring $90 quarterly cycle forward fee.
Account C incurs a one-time $5 purchase fee for account creation and a recurring $30 monthly cycle forward fee.

Table 1-3 G/L Results as of January 31

January 31G/L report	A/R Billed	A/R Billed	A/R UnBilled	A/R UnBilled	Billed Earned	Billed Earned	Billed Unearned	Billed Unearned	Previous Billed Earned	Previous Billed Earned	Unbilled Earned	Unbilled Earned	Unbilled Un earned	Unbilled Un earned
Account A	NA	NA	35	NA	NA	NA	NA	NA	NA	NA	NA	35	NA	NA
Account B	NA	NA	95	NA	NA	NA	NA	NA	NA	NA	NA	35	NA	60
Account C	NA	NA	35	NA	NA	NA	NA	NA	NA	NA	NA	20	NA	15
Total period	NA	NA	165	NA	NA	NA	NA	NA	NA	NA	NA	90	NA	75
Total cumulative	NA	NA	165	NA	NA	NA	NA	NA	NA	NA	NA	90	NA	75

Table 1-3 shows as of January 31:

Revenue from Account A is unbilled because the billing utilities have not yet been run. This revenue appears as a $35 debit to the AR Unbilled T-account. In addition, the revenue is earned because service has been rendered for that revenue. Because it is earned as well as unbilled, it appears as a $35 credit to the Unbilled Earned T-account.
Revenue from Account B is also unbilled because the billing utilities have not yet been run. The entire $95 appears as a debit to the AR Unbilled T-account. In addition, $35 of the revenue is earned because service has been rendered (account creation and one-third of the quarter.) This $35 appears as a credit to the Unbilled Earned T-account. The remaining $60 is unearned because no service has yet been rendered for it. It appears as a $60 credit to the Unbilled Unearned T-account.
Revenue from Account C is unbilled because the billing utilities have not yet been run. It appears as a $35 debit to the AR Unbilled T-account. Of Account C's revenue, $20 of it is earned because some service has been rendered (account creation and one-half of the month.) So, this portion appears as a $20 credit to the Unbilled Earned T-account. The unearned portion appears as a $15 credit to the Unbilled Unearned T-account.

G/L results for February 28

Account A has been through a complete G/L reporting cycle and a complete billing cycle, and has another monthly billing cycle that starts 02/01.
Account B has been through a complete G/L reporting cycle, but has not reached the end of its billing cycle.
Account C has been through the end of both a G/L reporting and a billing cycle, and has a monthly billing cycle starting on 02/15.

Figure 1-15 illustrates the G/L results for February 28.

Figure 1-15 Billing Cycles Relative to Monthly G/L Reports for February 28

Description of ''Figure 1-15 Billing Cycles Relative to Monthly G/L Reports for February 28''

Account A incurs a $30 monthly cycle forward fee on 02/01.
Account C incurs a $30 monthly cycle forward fee on 02/15.

Table 1-4 G/L Results as of February 28

February 28G/L report	A/R Billed	A/R Billed	A/R UnBilled	A/R UnBilled	Billed Earned	Billed Earned	Billed Unearned	Billed Unearned	Previous Billed Earned	Previous Billed Earned	Unbilled Earned	Unbilled Earned	Unbilled Un earned	Unbilled Un earned
Account A	65	NA	NA	35	NA	65	NA	NA	NA	NA	35	NA	NA	NA
Account B	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	30	30	NA
Account C	65	NA	NA	35	NA	50	NA	15	NA	NA	20	NA	15	NA
Total period	130	NA	NA	70	NA	115	NA	15	NA	NA	25	NA	45	NA
Total cumulative	130	NA	95	NA	NA	115	NA	15	NA	NA	NA	65	NA	30

Table 1-4 shows as of February 28:

All revenue from Account A is billed. The $35 that appeared in the AR Unbilled T-account on January 31 now appears as a credit to the AR Unbilled account and a debit to the AR Billed account. New revenue generated by the $30 cycle forward fee during February also appears as a debit to the AR Billed T-account. Also, the $35 that appeared as a credit to the Unbilled Earned T-account on January 31 is offset by a $35 debit. In addition, a total of $65 ($35 from January and $30 from February) appears as a credit to the Billed Earned T-account.
Revenue from Account B is unbilled because the billing cycle is not over yet. The only change to Account B's T-accounts is a $30 credit to the Unbilled Earned T-account and a matching debit to the Unbilled Unearned T-account because another one-third of the quarter has elapsed.
All revenue from Account C is billed. The $35 that appeared in the AR Unbilled T-account on January 31 now appears as a credit to the AR Unbilled account and as a debit to the AR Billed account. New revenue generated by the $30 cycle forward fee during February also appears as a debit to the AR Billed T-account. Also, the $20 that appeared as a credit to the Unbilled Earned T-account on January 31 is offset by a $20 debit. In addition, a total of $50 ($35 from January and $15 from February) appears as a credit to the Billed Earned T-account and $15 appears as a credit to the Billed Unearned T-account.

G/L results for March 31

Account A has a billing cycle that ends 04/01.
Account B has a billing cycle that ends 04/01.
Account C has a billing cycle that ends 03/15 and another begins 03/16.

Figure 1-16 illustrates the G/L results for March 31.

Figure 1-16 Billing Cycles Relative to Monthly G/L Reports for March 31

Description of ''Figure 1-16 Billing Cycles Relative to Monthly G/L Reports for March 31''

Account A incurs a $30 monthly cycle forward fee on 03/01.
Account C incurs a $30 monthly cycle forward fee on 03/15.

Table 1-5 G/L Results as of March 31

March 31G/L report	A/R Billed	A/R Billed	A/R UnBilled	A/R UnBilled	Billed Earned	Billed Earned	Billed Unearned	Billed Unearned	Previous Billed Earned	Previous Billed Earned	Unbilled Earned	Unbilled Earned	Unbilled Un earned	Unbilled Un earned
Account A	30	NA	NA	NA	NA	30	NA	NA	NA	NA	NA	NA	NA	NA
Account B	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	30	30	NA
Account C	30	NA	NA	NA	NA	15	15	15	NA	15	NA	NA	NA	NA
Total period	60	NA	NA	NA	NA	45	NA	0	NA	15	NA	30	30	NA
Total cumulative	190	NA	95	NA	NA	160	NA	15	NA	15	NA	95	NA	0

Table 1-5 shows as of March 31:

All revenue from Account A is billed and earned. It appears as a $30 debit to the AR Billed T-account and as a $30 credit to the Billed Earned T-account.
Revenue from Account B is unbilled because the billing cycle is not over yet. The only change to Account B's T-accounts is a $30 credit to the Unbilled Earned T-account and a matching debit to the Unbilled Unearned T-account because the final third of the quarter has elapsed.
All revenue from Account C is billed. It appears as a $30 debit to the AR Billed T-account. Of the $30 billed, $15 appears as a credit to the Billed Earned T-account and the other $15 appears as a credit to the Billed Unearned T-account. Also, $15 that was considered billed in the February 28 report became earned and appears as a $15 credit to the Prev Billed Earned T-account, offset by a $15 debit to the Billed Unearned T-account.

G/L reported as of April 30

Account A has a billing cycle that ends 05/01.
Account B is in the middle of a billing cycle that ends 07/01.
Account C has a billing cycle that ends 04/15 and another that begins 04/16.

Figure 1-17 illustrates the G/L results for April 30.

Figure 1-17 Billing Cycles Relative to Monthly G/L Reports for April 30

Description of ''Figure 1-17 Billing Cycles Relative to Monthly G/L Reports for April 30''

Account A incurs a $30 monthly cycle forward fee on 04/01.
Account C incurs a $30 monthly cycle forward fee on 04/15.

Table 1-6 G/L Results as of April 30

April 30G/L report	A/R Billed	A/R Billed	A/R UnBilled	A/R UnBilled	Billed Earned	Billed Earned	Billed Unearned	Billed Unearned	Previous Billed Earned	Previous Billed Earned	Unbilled Earned	Unbilled Earned	Unbilled Un earned	Unbilled Un earned
Account A	30	NA	NA	NA	NA	30	NA	NA	NA	NA	NA	NA	NA	NA
Account B	185	NA	NA	95	NA	125	NA	60	NA	NA	95	NA	NA	NA
Account C	30	NA	NA	NA	NA	15	15	15	NA	15	NA	NA	NA	NA
Total period	245	NA	NA	95	NA	175	NA	60	NA	15	95	NA	NA	NA
Total cumulative	435	NA	NA	0	NA	330	NA	75	NA	30	NA	0	NA	NA

Table 1-6 shows as of April 30:

All revenue from Account A is billed and earned. It appears as a $30 debit to the AR Billed T-account and as a $30 credit to the Billed Earned T-account.
All revenue from Account B is billed as follows:
- $185 debit to Billed.
- $95 credit to Unbilled to offset the $95 debit made in January.
- $125 credit to Billed Earned, where $95 is for the quarter ending 03/31 and $30 is for the first third of the current billing cycle.
- $60 credit to Billed Unearned for the remaining two-thirds of the current billing cycle.
- $95 debit to Unbilled Earned to offset the $35 credit made in January and the $30 credits made in February and March.

All revenue from Account C is billed. It appears as a $30 debit to the AR Billed T-account. Of the $30 billed, $15 appears as a credit to the Billed Earned T-account and the other $15 appears as a credit to the Billed Unearned T-account. Also, $15 that was billed in the March 31 report became earned and appears as a $15 credit to the Prev Billed Earned T-account and is offset by a $15 debit to the Billed Unearned T-account.