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.
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.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.
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.
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
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
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.
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.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:
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 |
For information on how to control the creation of /journal objects for non-currency resources, see "Disabling /journal Objects for Non-Currency Resources".
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.
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.
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.
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.
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)
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.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 )
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.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
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".
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.
If your company recognizes immediate revenue, you need to customize BRM to report billed and unbilled revenue for all G/L accounts.
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.
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
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
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.
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
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
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
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.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.
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.
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
See "How BRM Calculates Earned and Unearned Revenue" for information on how earned and unearned revenue is calculated.
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
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.
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.
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.
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
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.
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.
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.
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.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
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.
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
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.
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
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.
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
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.