General Ledger Revenue Recognition with Configurable Days Per Month

About G/L Revenue Calculation Using Fixed Monthly Days

By default, BRM calculates General Ledger (G/L) revenue based on the actual number of days in each month. This means the daily revenue amount can vary — for example, February has 28 days, while March has 31. While this variation does not affect full billing cycles (for instance, a $100 monthly fee always resulting in $100 G/L revenue), you may notice inconsistencies when the accounting cycle DOM and G/L cycle DOM are not the same, and the G/L cycle falls between the accounting cycle. This can occur when an account starts, ends, or modifies its subscription mid-cycle.

To address this issue, BRM lets you configure a fixed number of days per month (for example, 30) for calculating G/L revenue. When enabled, the G/L revenue is calculated using the same number of days per month, regardless of the actual calendar month. This approach ensures more consistent revenue recognition for partial, prorated, or non-standard billing cycles.

About G/L Revenue Based On Actual Days in the Month

BRM can calculate G/L revenue using the actual number of days in each month. This method ensures that revenue recognition accurately reflects the specific month’s length, such as February having 28 or 29 days, April having 30, and so on.

When applying the actual number of days per month, BRM calculates the G/L revenue for partial billing cycles as follows:

Revenue = NumberOfDaysInCycle ÷ NumberOfDaysInMonth x ChargePerMonth

For example, assume John’s subscription is $100, the G/L DOM is the 10th, and he cancels the subscription on the 18th. In this case, there are 9 days in a month’s billing period. Table 6-1 shows the G/L revenue based on which month the subscription ends.

Table 6-1 G/L Revenue Calculation Based on Actual Days per Month

Billing Period	Revenue Calculation	G/L Calculation
Feb 10 - Feb 18	(9 ÷ 28) x $100	$32.14
Mar 10 - Mar 18	(9 ÷ 31) x $100	$29.03
Apr 10 - Apr 18	(9 ÷ 30) x $100	$30.00

Hence, total revenue recognized is $300 but for each month the amount is different.

If the billing cycle spans multiple months, such as in a quarterly cycle BRM calculates the G/L revenue for the first billing period as follows:

Revenue = (NumberOfDaysInCycle ÷ NumberOfDaysInMMonth) x ChargePerMonth

For the last period, BRM calculates the G/L revenue as follows:

Revenue = BillingCycleCharge – SumOfPreviousBillingPeriods

For example, assume Mary’s subscription is $300 per quarter, the G/L DOM is the 1st, and she purchases the subscription on Feb 10. Table 6-2 shows how BRM calculates the G/L revenue for each month in the quarterly billing cycle.

Table 6-2 G/L Revenue Calculation Based on Actual Days per Month for Quarterly Billing Cycle

Billing Period	Revenue Calculation	G/L Calculation
Feb 10 - Feb 18	$ (9/89 x 100)	$64.0449438202
Mar 10 - Mar 18	$ (9/89 x 300 + 22/89 x 300)	$104.4943820225
Apr 10 - Apr 18	$ (9/89 x 300 + 21/89 x 300)	$101.1235955056
May 1 - May 9	$ (9/89 x 300)	$30.3370786517

About G/L Revenue Based On Fixed Days Per Month

To standardize revenue recognition across months of varying month lengths, BRM uses a fixed number of days per month, such as 30.4167. This value is derived by dividing the total number of days in a year by the number of months: 365 ÷ 12 = 30.4167. This standardization ensures consistency when calculating G/L revenue for partial billing cycles.

When using a fixed number of days per month, BRM calculates the G/L revenue for partial billing cycles as follows:

Revenue = (NumberOfDaysInCycle ÷ FixedDays) x ChargePerMonth

For example, assume a customer’s subscription is $100 per month, the G/L DOM is the 10th, and they start their subscription on the 18th. In this case, there are 9 days in a month’s billing period. Table 6-3 shows that the G/L revenue is the same regardless of the month the subscription starts.

Table 6-3 G/L Revenue Calculation Based on Fixed Days per Month for Partial Billing Cycle

Billing Cycle	Revenue Calculation	G/L Revenue
Feb 10 - Feb 18	(9 ÷ 30.4167) x $100	$29.59
Mar 10 - Mar 18	(9 ÷ 30.4167) x $100	$29.59
Apr 10 - Apr 18	(9 ÷ 30.4167) x $100	$29.59

If the billing cycle spans multiple months, such as in a quarterly cycle, BRM calculates the G/L revenue for the first billing period as follows:

Revenue = (NumberOfDaysInCycle ÷ FixedDays) x ChargePerMonth

BRM calculates the G/L revenue for the last period as follows:

Revenue = BillingCycleCharge – SumOfPreviousBillingPeriods

Table 6-4 shows how BRM calculates the G/L revenue for each month, assuming the subscription is purchased on Feb 10, the cost is $300 per quarter, and the G/L DOM is the 1st.

Table 6-4 G/L Revenue Calculation Based on Fixed Days per Month for Quarterly Subscription

Billing Cycle	Revenue Calculation	G/L Revenue
Feb 10 – Feb 28	(19 ÷ 30.4167) x $100	$62.46
Mar 1 – Mar 31	Full cycle	$100.00
Apr 1 – Apr 30	Full cycle	$100.00
May 1 – May 9	$300 - $262.46	$37.54

How Fixed Day G/L Revenue Recognition Impacts Journal Entries

When you enable fixed-day G/L revenue recognition, BRM divides journal entries based on the configured G/L DOM and the account’s billing DOM. For example, if the G/L DOM is the 15th, the billing DOM is the 20th, and the subscription purchase date is May 10, BRM creates three journal entries for the account’s first billing cycle:

One entry for revenue from May 10 to May 14
One entry for revenue from May 15 to May 19
One entry for revenue from May 20 to June 15

This division is done automatically during cycle event generation using the PCM_OP_BILL_UPDATE_JOURNAL opcode. If necessary, you can implement custom logic through the PCM_OP_GL_POL_PRE_UPDATE_JOURNAL policy opcode, provided that the CustomJournalUpdate business parameter is enabled. For more information, see "Customizing G/L Data Stored in /journal Objects" in BRM Opcode Guide.

Note:

The G/L DOM is read from the /config/export_gl object. You must configure the PIN_FLD_GL_SEGMENTS.PIN_FLD_CALENDAR_DOM field for journal splitting to occur.

BRM ensures that the total revenue across the journal entries matches the amount of the billing cycle’s G/L revenue. The calculation BRM uses to split the revenue for journal entries varies based on the type of billing cycle.

Example 1: Journal Splitting for a Quarterly Billing Cycle

This example illustrates how revenue is divided into multiple /journal objects for a quarterly billing cycle, using a fixed number of days to calculate monthly revenue.

The formula for calculating the G/L revenue for a quarterly billing cycle is as follows:

The amount recognized for the first period uses this formula:
```
[(FixedDays – MissingDays) ÷ FixedDays] x ChargePerMonth)
```
The amount recognized for the last period uses this formula:
```
BillingCycleCharge – SumOfPreviousBillingPeriods
```

where MissingDays is the number of days between the start of the previous G/L DOM to the purchase date.

This example assumes the following:

Subscription: $300 per quarter
Purchase date: Feb 10
Fixed-day value: 30.4167
G/L DOM: 1
Billing DOM: 10

In this case, the number of missing days for the first period is 9 (that is, the number of days from Feb 1 through Feb 9). Table 6-5 shows how BRM calculates the G/L revenue for each /journal object for this example.

Table 6-5 Journal Splitting for a Quarterly Billing Cycle

Journal Object	Period	Revenue Recognized	Description
1	Feb 10 – Feb 28	$70.41	Calculation: [(30.4167 – 9) ÷ 30.4167] x $100
2	Mar 01 – Mar 31	$100.00	Full month of revenue
3	Apr 01 – Apr 30	$100.00	Full month of revenue
4	May 01 – May 10	$29.59	Calculation: $300 - $270.41 = $29.59

Example 2: Journal Splitting for a Long Cycle

This example illustrates how revenue is divided into multiple /journal objects for a long cycle. A long cycle occurs when BRM adds a partial cycle to the next cycle rather than considering it separate. For more information about long cycles, see "Specifying How to Handle Partial Accounting Cycles" in BRM Configuring and Running Billing.

The formula for calculating the G/L revenue for a long billing cycle is as follows:

The amount recognized for the first period uses this formula:
```
LongBilllingCycleCharge – ChargePerMonth
```
The amount recognized for the second period uses this formula:
```
[(FixedDays – MissingDays) ÷ FixedDays] x ChargePerMonth)
```
The amount recognized for the last period uses this formula:
```
ChargePerMonth – SecondBillingPeriodAmount
```

This example assumes the following:

Subscription: $100 per month
Long billing cycle charge: $116.13
Purchase date: Feb 5
Fixed-day value: 30.4167
G/L DOM: 1
Billing DOM: 10

In this case, the long billing cycle goes from Feb 5 thru Mar 10. The number of missing days for the second period is 9 (that is, the number of days from Feb 1 through Feb 9). Table 6-6 shows how BRM calculates the G/L revenue for each /journal object for this example.

Table 6-6 Journal Splitting for a Long Billing Cycle

Journal Object	Period	Revenue Recognized	Description
1	Feb 05 – Feb 9	$16.13	$116.13 -- $100
2	Feb 10 – Mar 01	$70.41	Calculation: [(30.4167 – 9) ÷ 30.4167] x $100
3	Mar 01 – Mar 10	$29.59	Calculation: $100 – 70.41

The total recognized revenue is $116.13, distributed across three journal entries when the account creation date falls outside the standard billing cycle.

Example 3: Journal Splitting for a Short Cycle

This example illustrates how revenue is divided into multiple /journal objects for a short cycle, which means the billing cycle is less than a month and goes from the purchase date to the billing DOM. For more information about short cycles, see "Specifying How to Handle Partial Accounting Cycles" in BRM Configuring and Running Billing.

The formula for calculating the G/L revenue for a short cycle is as follows:

The amount recognized for the first period uses this formula:

[((FixedDays – MissingDays) ÷ FixedDays) x ChargePerMonth)] – (ChargePerMonth – ProratedCharge)

The amount recognized the last period uses this formula:

ChargePerMonth – [((FixedDays – MissingDays) ÷ FixedDays) x ChargePerMonth)]

The example assumes the following:

Subscription: $100 per month
Pro-rated billing charge: $82.14
Purchase date: Feb 15
Fixed-day value: 30.4167
G/L DOM: 1
Billing DOM: 10

In this case, the short cycle goes from Feb 15 through Mar 10. Table 6-7 shows how BRM calculates the G/L revenue for each /journal object for this example.

Table 6-7 Journal Splitting for a Short Billing Cycle

Journal Object	Period	Revenue Recognized	Description
1	Feb 15 – Mar 1	$52.55	Calculation: [((30.4167 – 9) ÷ 30.4167) x $100) – (100-82.14)] = $70.41 - $17.86 = $52.55
2	Mar 01 – Mar 10	$29.59	Calculation: ($100 – [((30.4167 – 9) ÷ 30.4167) x $100))] = $100 -- $70.41 = $29.59

The total recognized revenue is $82.14, distributed across two journal entries.

About Rounding G/L Revenue

BRM rounds G/L revenue amounts and journal entry amounts as part of the revenue calculation and journal entry generation processes.

BRM applies rounding according to the system’s currency and rounding configuration. Rounding is applied as follows:

Revenue Calculation:

When BRM calculates G/L revenue for each billing period or prorated cycle, the revenue amount is rounded based on the defined decimal precision of the account’s currency.
Journal Entry Creation:

When creating each /journal object, BRM rounds the revenue amount according to the currency settings and rounding rules. BRM ensures that the total of all journal entries for a billing cycle equals the calculated G/L revenue for that cycle. Any rounding differences are adjusted in the last journal entry for the period.

BRM uses the currency of the account to determine the decimal precision for rounding. BRM supports both zero-decimal and multi-decimal currencies.

For configuration steps and details on balance impact rounding, see "Configuring Balance Impact Rounding" in PDC Creating Product Offerings.

Enabling and Using Fixed-Day G/L Revenue Recognition

To enable and use fixed-day G/L revenue recognition in BRM, you must perform a few configuration tasks to ensure that BRM applies a consistent number of days per month when calculating G/L revenue and splits journal entries correctly for partial or non-standard billing cycles.

The process for enabling and using fixed-day G/L revenue recognition involves these high-level steps:

Set the G/L Day of Month (DOM): Define the G/L DOM values that control how journal entries are split across periods.

See "Configuring the G/L DOM".
Customize how to split journal data: Optionally, customize how to split the /journal objects. To do so, enable the CustomJournalUpdate business parameter and customize the PCM_OP_GL_POL_PRE_UPDATE_JOURNAL policy opcode.

See "Customizing G/L Data Stored in /journal Objects" in BRM Opcode Guide.
Enable fixed-day G/L revenue recognition: Update the appropriate business parameter to activate the feature.

See "Configuring Fixed-Day G/L Revenue Recognition".

Configuring the G/L DOM

To split journal entries, BRM needs to access each segment’s G/L DOM from the PIN_FLD_CALENDAR_DOM field in the /config/export_gl object. Ensure that the object contains correct G/L DOM values for each segment supported by your company.

Note:

If the G/L DOM is missing, fixed-day calculations are not applied.

If you need to add or change any segment’s G/L DOM, update the pin_config_export_gl.xml file and then load it into the /config/export_gl object using the load utility.

To configure the G/L DOM:

Open the BRM_home/sys/data/config/pin_config_export_gl.xml file in an XML editor or a text editor.
For each segment, set the <DayofMonth> tag to the appropriate value.
Save and close the file.
Use this command to load the G/L configuration information into the /config/export_gl object in the BRM database:
```
load_pin_config_export_gl pin_config_export_gl.xml 
```
For more information, see "load_pin_config_export_gl".
Validate that your G/L configuration file was loaded into the database correctly. See Validating and Troubleshooting Exported G/L Reports.

Configuring Fixed-Day G/L Revenue Recognition

The SmoothedGLReportingBasedOnFixedDays business parameter controls how revenue is recognized for G/L reporting. When enabled, it allows revenue to be calculated using a fixed number of days per month (such as 30) to ensure consistent monthly recognition, regardless of the actual calendar month length.

You can set this parameter to any fixed value, such as 29, 30, 30.5, or 30.4167. For example, you might use 30.4167 because it approximates the average number of days per month in a 365-day year (365 ÷ 12).

By default, this business parameter is set to 0.0, which means the feature is disabled and revenue is recognized based on the actual number of days in each month.

To enable fixed-day G/L revenue recognition:

Go to BRM_home/sys/data/config.
Use the following command to create an editable XML file from the Billing instance of the /config/business_params object:
```
pin_bus_params -r BusParamsBilling bus_params_billing.xml
```
This command creates an XML file named bus_params_billing.xml.out in your current directory. If you do not want this file in your current directory, specify the path as part of the file name.
In bus_params_billing.xml.out, set SmoothedGLReportingBasedOnFixedDays to the number of days in each month for calculating the G/L revenue. For example, this specifies to calculate the G/L revenue based on 30 days in each month:
```
<SmoothedGLReportingBasedOnFixedDays>30</SmoothedGLReportingBasedOnFixedDays> 
```
Caution:
BRM uses the XML in this file to overwrite the existing instance of the /config/business_params object. If you delete or modify any other parameters in the file, these changes affect the associated aspects of the BRM configuration.
Save and exit the file.
Rename the bus_params_billing.xml.out file to bus_params_billing.xml.
Use the following command to load your changes into the /config/business_params object:
```
pin_bus_params bus_params_billing.xml
```
You should run this command from the BRM_home/sys/data/config directory, which includes support files used by the utility. To run it from a different directory, see "pin_bus_params" in BRM Developer's Guide.
Read the object with the testnaputility or the Object Browser to verify that all fields are correct.

For general instructions on using testnap, see "Using the testnap Utility to Test BRM" in BRM Developer's Guide. For information on how to use Object Browser, see "Reading Objects" in BRM Developer's Guide.
Stop and restart the Connection Manager (CM).

For more information, see "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

6 General Ledger Revenue Recognition with Configurable Days Per Month