Skip to main content

Deal and Asset Level Allocation Changes - Product Advisory

May 2021

Business Summary

Accounting for reallocation entries was introduced with the 20R3 Accounting release in August 2020. With 21R2, customers will now see updates in the reallocation entries for deal level and asset level allocation changes. The update in 21R2 is the next step in updating reporting to reflect deal level and asset level allocation changes. Additional improvements will be forthcoming in future releases.

Important items to note based on the 21R2 updates:

Customers may see changes to historical accounting entries:

  1. You may see changes to GL segment coding, for historical journal entries.

  2. You may see what appears to be new reallocation entries in closed periods.

GL Segment Coding

This means that if you had a historical change to a deal level participant or an asset level participant (not allocation level participant), that was recorded subsequent to 20R2.2 (deployed to Production on July 18, 2020), when the audit trailing started for these participants, then a reallocation entry would have been generated as a placeholder at that time.

These placeholder entries for deal level and asset level participant changes were not reflected in schedule-level and portfolio-level reporting for the 11 GL segments in the Ledger Export and all other reports. These entries were not reflected in reports because the debits and credits for the GL segments were identical and netted to a zero change in segment codes and amounts. Therefore, these placeholder entries were suppressed by the application for schedule-level and portfolio-level reporting. They would, however, have appeared on Ledger Exports run at asset-level, assuming accounting for the deal was recalculated after recording the participant change. Changes made to participants will automatically trigger a recalculation of accounting entries.

Note: The 11 GL segment code fields are not and have not been subject to Month End Close in the Ledger Export. This is not new behavior with the 21R2 release.

New Reallocation Entries

With 21R2, you will now see reallocation entries for changes in deal level and asset level participants that have associated GL Segments in reporting. These reallocation entries will be for balance sheet accounts only with the exception of AP Clearing.

Ledger entries after such a change will reflect the new participant after the change. Prior to the change, ledger entries will reflect the old participant. The new reallocation entry will provide the transfer of balances from old participant to the new participant.

Now, because the ledger entries reflect the different coding in the GL segments, the reallocation will be visible on schedule level and portfolio level reports. The benefit of this update is that your account balances will now be relieved from the deal level or asset level segments and transferred into the appropriate deal level or asset level segments, so if you are trying to move an asset from BU 123 to BU 456, that will now work, and the balances will be transferred effective the date you establish.

In some cases, the historical reallocation entry existed at asset level before but may not have been reportable. It would not have been reportable if the GL segment coding was unchanged from before to after the change, because the system was not applying the segment code differentiation based on the deal level participant change.

Please note if you had multiple historical deal level or asset level participant changes, that you should expect to see reallocation entries for each of the changes, effective the date of the change. If you made multiple changes in one day with the same effective date, you will only have one reallocation entry; if you have changes across multiple days, you will have multiple reallocation entries.

Currently, the application does not allow recording of a backdated participant change. The application will prompt the user to change the effective date to the first day of the first open period.

If there is a historical backdated participant change, the reallocation entry will be posted in the first open period when the change was recorded. But it will be the reallocation entry, based on the effective date of change. And the GL segment coding for journal entries after that date will be changed, even if those entries are in closed periods. The only catch-up entry is the entry needed to transfer the balances.

  • If the deal has been recalculated since the participant change was made and audit trailed, then the reallocation entry was already created for the effective date (or the first open date when the recalculation occurred if the effective date happened to be in a closed period). The only scenario in which you will get a new catch-up reallocation entry is if you have a participant change recorded in what is now a closed period and the deal has not been recalculated since that change was recorded.

Please note that these allocation entries are not subject to AsAt rules and if you have historical deal level or asset level participant changes that cause reallocation entries in prior closed periods, that you will be unable recreate historical reports by running reports with a backdated AsAt date.

The following changes will NOT generate reallocation entries:

  • Changes made to segment values through Contact Management will always be from lease inception, as there is no effective date on these changes. This type of change will change historical data, even in closed periods.

  • Changes made to an account code within the ledger configuration will always be from lease inception, as there is no effective date on these changes. This type of change will change historical data, even in closed periods.

Please refer to the section at the end of the document covering existing scenarios that will not be corrected with this update since the code deployment is prospective.

Reminder on How to Record Participant Changes

Deal level participant changes can be made within Deal Summary under the Participants tile. The Make Changes Effective date selection must be entered and can only be a date in an open period. After changing the selected deal level participant, click on the Summary tile, scroll down, and click Save. The system will not save the changes if any of the participant fields are red, indicating an invalid selection.

Note: Vendor and Ship To appear on both the Deal level and Asset level workspaces. Updating either in one workspace does NOT update the fields in the other workspace. This is very important if you use either of these attributes as a GL segment.

Example: If your ledger configuration lists Vendor with a Deal level scope, then you must make changes to the Vendor in the Deal Summary Participant workspace (above). If your ledger configuration lists Vendor with an Asset level scope, then you must make changes to the Vendor in the Asset Management workspace and the Asset Level Attributes section.

Asset level attribute changes can be made within Asset Management. After selecting the asset(s) to be updated, populate the Make Changes Effective date selection. The selected date must be in an open period. Expand the Asset Level Attributes section and update the selected asset level attributes. Click Save.

Asset allocation level changes are also made within Asset Management. Like the asset level attribute changes, you must select the asset(s) that will be changed and enter a valid effective date. Expand the Allocation Level Attributes section. Click the edit icon for the allocation item that will be updated. It is important to make sure that ALL allocation attributes that are in effect on the selected effective date be updated at this time. After updating the allocation attributes, click on Update and then Save.


Reallocation Entry Examples

To aid in understanding how these new reallocation entries will appear with the 21R2 release update, we are sharing the following examples:

Single asset with a 60/40 allocation split with changes based on the following effective dates:

  • 2/1/2020 - Entity, Geo, and Area changed

  • 4/1/2020 - Lessee, Funder, Vendor (deal-level), Property Tax Authority, and Vendor (asset-level) changed

  • 6/1/2020 - Business Unit, Order Administrator, Ship To (deal-level), Project, Cost Center, and GL Coding Convention changed

  • 9/1/2020 - Asset Owner, Asset User, and Ship To (asset-level) changed

    Note: During testing, changes were made over multiple system dates. The Project field was changed first with an effective date of 9/1/2020. The next day, Cost Center was changed (without making additional changes to Project) with an effective date of 6/1/2020. Since the Cost Center change was the most recent – and included the updated Project value – the Project change now reflects a 6/1/2020 effective date.

Deal History:

Below is an example of a Ledger Export using a ledger created with predominately deal level participant ledger segments (the ledger attribute is included in orange at the top). Note that while the Operating Asset account entries are highlighted, all of the balance sheet accounts – with the exception of Accounts Payable Clearing – has been transferred to the new GL string.

Below is an example of a Ledger Export using a ledger created with predominately asset level attribute ledger segments (the ledger attribute is included in orange at the top).

The following scenarios will not reflect corrected entries:

Due to the ongoing progression of audit-trailing capabilities for deal and asset level participants as well as the generation of reallocation entries, updates made prior to 20R4 may not reflect reallocation entries.

Reallocation entries that included the new segment values for both the debit and credit entry resulting in the old segment values carrying balance sheet balances. For terminated schedules in this scenario, there will still be a positive balance reflecting the original segment value(s) and a negative balance for the new segment value(s).

If cost center (or other allocation level participant) was changed multiple times in the same day where the latest change was an older date, this resulted in duplicate rows on the ledger export. Usually this occurred when a user entered a cost center change without changing the effective date which previously defaulted to the current system date. User would subsequently make the change again but with an earlier effective date. UI enhancement now defaults to a blank date which forces the user to select a date.]  21R1.1 introduced the ability for users to make multiple allocation level changes on the same day without the worry of double rows of data on the ledger export. This change was prospective only.

Reminder: All scenarios outlined above that are represented in the ledger export would also be reflected in all accounting reports.

For the BI Accounting Balance Reports:

Rows representing both the original GL segment values and the new GL segment values may appear on the reports. Balance sheet accounts balances for the original GL segment values will be zero (in transactional currency). Income statement accounts with the original GL segment values will carry balances incurred up through the effective date of change. Income statement accounts with the new GL segment values will reflect balances from the effective date forward. Income statement balances for the original GL segment values will clear at the beginning of the next fiscal year.

Fiscal Month End after reallocation:

First Fiscal Month in New Fiscal Year:

(Expense accounts for original segment values have reversed to produce a zero balance)

Accounting reports run with a Functional or Reporting currency setting may not provide zero balances for transferred GL segments due to known issues related to the FX date setting for adjusting entries. This is being addressed in a future release.

Was this article helpful?

We're sorry to hear that.