Management Ledger models, whether HPCM or PCMCS, have been around for a few years, but I still receive emails asking for help in figuring out where the results are coming from. This request is often related to the lack of understanding of the Balance dimension. Here are some key pieces of information regarding this system dimension, how it works, how it should be used when defining allocations and integration jobs and how to leverage it to troubleshoot your allocations.
Basics of Balance dimension
Before we have a look at each member within this dimension, let’s go over some basic rules that govern the creation of a HPCM or PCMCS Management Ledger (ML) application:
- All HPCM or PCMCS ML applications must contain one and only one dimension named Balance
- Members and their properties cannot be edited or removed.
- You don’t need to import a file in order to load/setup the Balance dimension; members are created automatically when deploying an application for the first time.
- You can choose to rename the Balance dimension (translate it into another language, for example) when you first setup the application in PCMCS.
For the most part the Balance dimension members are quite easy to follow and understand but familiarity with usage guidelines will help avoid issues during development and will support troubleshooting.
- Input — Used to store data input / pre-allocated data sets, whether these are pool or driver data sets. Data is generally loaded against this member in combination with the NoRule member. Input can be populated through custom calculations, but it is generally advised to keep it dedicated to valid data loads/input rather than for storing calculated or allocated results.
- Adjustment In —Adjustment In can be used for manual adjustments to the Input data, prior to running allocations. In this case, the Adjustment In data will be loaded against the NoRule member. Any manually submitted data on the Adjustment member against a Rule ID member may be eliminated during the subsequent data loads and calculations. Adjustment In can also be used during custom calculations to store intermediary values or calculated driver data.
- Adjustment Out —Same usage as for Adjustment In, but with a negative data value.
- Allocation In — This member will be populated against the Destination or Target intersection for the allocation rule.
- Allocation Out —This member will be populated against the Source intersection of the allocation rule and the corresponding Rule ID member, or against a predefined “Offset” intersection that is custom defined for a given rule.
- Allocation Offset Amount — Displays an amount that further reduces an Allocation In member, if one was used in addition to the Allocation Out. I have provided an example of how this member is populated and used in a lower section of this post.
- Net Change — represents the total change for a given intersection, regardless of alternate offset actions.
- Net Balance – sum of Input (initial data loaded) and any Net Changes made to the same intersection.
- Remainder — Displays the difference between Allocation In and Allocation Out plus Allocation Offset Amount, if any.
- Balance — The amount resulting when adjustments, allocations, and offsets are considered.
Rules assign funds to destinations based on the way you have defined the allocation logic (member selections, sequencing, concurrency, etc). “Allocations in” and “allocations out” are being generated upon executing the calculations of the Profitability model. Each pair of adjustments and allocations (the “in” and the “out”) should result in a zero sum in order to balance the transaction. The Input member is affected by each adjustment and allocation. The difference between what was taken from Input and what remains at the end of an allocation will be accounted for in the Remainder.
The Remainder member is the source of your allocations, not the Net Balance member, as most would think. Remainder takes into consideration alternate offsets and ensures we do not perform a double booking or a double allocation of the same data source, regardless of where the offset was applied.
Balance Dimension Example – Adjustment Rules
To further explain the Balance dimension usage, I have used an example from the Bikes default application BksML30, which can be deployed into PCMCS through a few clicks.
The original application had only one adjustment Rule populating the Adjustment In member. I have copied that rule and reused it to demonstrate the same usage for the Adjustment Out member. Remember the adjustment out aggregation operator is still +, so if you want to offset data sets, you must use the appropriate signage for your data, in other words, negate the result either via a multiplication with -1 or by simply adding a – to the formula.
The new ruleset contents will look like this:
Our initial data set is loaded on the Input / No Rule combination for the two accounts, Rent and Utilities, on the intersection with Corporate Entity.
The data adjustments are stored against Adjustment In and Adjustment Out.
In order to further illustrate how to correctly follow the allocation process, I split the original Reassignment rule into 2 rules, each dedicated to its own account. I also updated the metadata by adding two new Account siblings to Rent and Utilities as offsets for each account.
Alternate offsets are simply intersections of members where you would like to store the offset data point, if it should differ from the source of the allocation.
The Remainder member demonstration is connected to the usage of alternate offsets, and before we go into the details of the numerical example, I would like to list out a few rules for setting up alternate offsets:
- Alternate offsets are available for selection only in standard allocation rules. For Custom calculations, your Offset custom calc would have to be pointed to the appropriate “alternate” target.
- All dimensions, including the ones predefined in the rule context, are repeated in the Offset screen as soon as you select “Alternate Offset Location”, you must select a single base level member for at least one dimension.
- There is no SAS (Same As Source) option for offsets. The dimensions that must be offset on the Source intersections can be left blank in the Offset screen selections.
- If each source member selection has its own offset, you will have to split the rule up into as many granular rules as needed in order to cover the individual offset selection. For example, if you have 6 accounts, each with its own offset account equivalent, you will have to create 6 standard allocation rules to create the individual offset selection for each account.
Going back to the numerical example and the usage of the Offset tab, in the update rule I have selected the below member intersections:
The Source account was Rent, target is Same As Source (SAS), and the alternate offset account is FACOffset_Rent.
After the rules are executed, we will see the following results. Focus on the Allocation Offset Amount member and the Allocation Out Member.
Even though the offset was applied to an alternate account for both Rent and Utilities, the allocation engine correctly identifies the Remainder of these two accounts as being 0.
- The first step behind the scenes is for the allocation to correctly distribute the data to the target intersections.
- The second step is to perform the offset on the intersection specified by the user, if different from the source intersection.
- The third step is to copy the Allocation Out value onto the Source Intersection members, on allocation Offset Amount member. This final step is performed via a custom calculation embedded in the PCMCS generated scripts which ensures there will be no double counting of pool data.
So even though we “moved” data from the Rent account, Corporate Entity, to other Entities, on the same target Account, the offset was performed on an alternate member. This allows us to create a report with Rent (Input), Rent (Allocation In) and FACOffset_Rent (Allocation out).
This is not a typical example of how alternate offsets are used from a functional standpoint, but it helps explain the mechanics behind the scenes. This alternate offset option is mostly used in cases where a Bill Out account and a Chargeback account will differ and allows users to trace which portion of a chargeback account is coming from different source accounts.
Purpose of Remainders
The final goal of an allocation is to generate a Remainder member with a value of 0. This ensures the total allocation of a pool data set, whether this was loaded or received from prior allocation steps. If the Remainder member has a positive value, then it is indicating you have not fully utilized your pool data. If the Remainder member has a negative value, then you have over utilized your pool data, which may be, in some cases, intentional.
In situations where you will not give access to the PCMCS ML application to users who need to understand the various components of a data point flowing through the allocation steps, due to licensing costs or other considerations, consider the usage of alternate offsets throughout your allocation flow.
When talking about reporting out of PCMCS ML, our clients always emphasize simplicity, and we often get requests to remove the Rule and Balance dimensions from final reporting solutions, to cancel the noise and give finance users solely the core information. In such situations, the usage of alternate offsets has proved beneficial as these finance users can still follow the flow and components of a cost without having to deal with the rule by rule detail. If further investigation is necessary, this can be pursued within the PCMCS ML model itself rather than in the external reporting solution.