Demystify the Balance Dimension in Profitability and Cost Management

Management Ledger models, whether Hyperion Profitability and Cost Management (HPCM) or Profitability and Cost Management Cloud Service (PCMCS), have been around for a few years, but I still receive emails asking for help with figuring out where the results are coming from. This request is often related to a 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.

Before we have a look at each member within this dimension, let’s go over some basic rules that govern the creation of an HPCM or PCMCS Management Ledger (ML) application:

  1. All HPCM or PCMCS ML applications must contain just one dimension named Balance
  2. Members and their properties cannot be edited or removed.
  3. 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.
  4. You can choose to rename the Balance dimension (translate it into another language, for example) when you first set up the application in PCMCS.

For the most part, the Balance dimension members are quite easy to follow and understand, but familiarity with usage guidelines helps to avoid issues during development and supports troubleshooting.

Demystifying the Balance Dimension in PCM - Image 1

  • 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.

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:

Demystifying the Balance Dimension in PCM - Image 2

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.

Demystifying the Balance Dimension in PCM - Image 3

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 “Same As Source” (SAS) 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:

Demystifying the Balance Dimension in PCM - Image 4

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 results below; 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.

  1. The first step behind the scenes is for the allocation to correctly distribute the data to the target intersections.
  2. The second step is to perform the offset on the intersection specified by the user, if different from the source intersection.
  3. 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.

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 that you have not fully utilized your pool data. If the Remainder member has a negative value, then you have overutilized your pool data which may be, in some cases, intentional.

Demystifying the Balance Dimension in PCM - Image 5

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, the usage of alternate offsets throughout your allocation flow might be helpful.

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.

If you need further help with figuring out the purpose and usage of the Balance dimension within PCMCS, email us at Our PCM Center of Excellence team is ready to share leading practices and industry-specific solutions that accelerate your ROI and expand the capabilities of your chosen profitability software.

Security configuration in TaskFlows (EPMA 11.1.2) – Cookbook style

TaskFlows in Enterprise Performance Management Architect (EPMA) can be used to sequence any number of EPMA operations such as dimension updates, application deployments, and data synchronisations.  They are also able to execute batch jobs and send emails, all of which makes them potentially useful for automation and integration of EPMA applications.

TaskFlows can be scheduled by a built-in scheduler in TaskFlow Management, but there is also the option to run task flows ‘interactively’ (i.e. on-demand). For one particular client application, this was an attractive approach to delivering a capability to kick-off processes in-day on an ad-hoc basis, but we needed to ensure that some kind of security could be applied to the different task flows so that ‘run’ permissions could be assigned to the correct people for the correct TaskFlow.

Our client system was based on 11.1.2, and the procedure below is based on  I could not find much documentation around doing this on 11.1.2, and it appears that the controls around TaskFlow security have changed since  Therefore I decided to set up a simple PoC as described below.

The summary approach is as follows:

  • Set up several simple TaskFlows
  • Set up security roles (Create the aggregated HSS roles)
  • Modify the Access Control to the TaskFlows
  • Set up several users & provision them to have access to different roles
  • Demonstrate the effect of these different levels of access

Set up some simple TaskFlows

TaskFlows can be created to run many different EPM processes such as cube deployment, data import/export, but for our example we are just going to get the TaskFlows to execute a simple batch file, which will write to an output file, which indicates that our TaskFlow has successfully run.

The administrator should have, as a minimum, the following roles provisioned in Shared Services, to be able to create TaskFlows:

TaskFlow administration is then accessed in EPMA, via ‘Navigate’ > ‘Application Library’, and then choose menu ‘Administration’  > ‘Manage Task Flows’, which will bring up the following screen:

From here, new TaskFlows can be created, and existing ones can be edited, deleted, scheduled and executed.

Below I have set up TaskFlow TF_1 to execute a batch job in Stage1.

This is done by selecting the processing tab & choosing ‘Hub’ from the ‘Application’ drop-down, ‘Execute’ from the ‘Action’ drop-down, and specifying the name of the batch file to execute.

(by default batch files are located in %HYPERION_HOME%\Common\Utilities, and output is routed to Oracle\Middleware\user_projects\domains\EPMSystem folder).

(Note, the example has Stage2 in it – TaskFlows can contain any number of Stages – this example has 2 stages purely as a result of experimentation – each stage simply executes a basic batch file to create an output file)

For the purposes of  testing access control, I created the following 4 TaskFlows (by using the ‘Save As’ control) :

Now that we have set up several TaskFlows, we will set up some users to demonstrate access control.  The first step is to create ‘aggregated roles’ in Shared Services (HSS) to allow each TaskFlow to have a different level of access, by associating it with different roles.

Set up security roles (Create the aggregated HSS roles)

The pre-defined HSS Administrator roles of ‘Manage TaskFlows’ & ‘Run TaskFlows’ will give default access to a user to run manage / run a new TaskFlow, until the access control of that TaskFlow is edited.

To satisfy our requirement to have differing levels of access we create different  ‘aggregated’ roles in HSS, with different access levels.  There are 2 access levels for TaskFlows

  • ‘Manage’ access allows the user to create, delete, schedule & run TaskFlows
  • ‘Run’ access allows the user to only run TaskFlows.

(Having no access, simply means that a user will only be able to ‘View’ TaskFlow status.)

For our example, we want to achieve the following access to TaskFlows TF_1 -> TF_4:

This requires us to create the following aggregated roles, which will eventually be associated with the specific TaskFlows :

Creation of aggregated  roles is simple.

1.   Log into HSS as admin, expand the ‘User Directories’, ‘Native Directories’ tree in the explorer and right-mouse-click on ‘Roles, and choose ‘New’:

2.   This brings up the ‘Create Role’ dialog – we enter a Role name, and choose ‘HUB-11.1.2’ as the product group (each product group has its own list of relevant ‘Available Roles’, but TaskFlow related roles exist in the ‘HUB…’ group):

3.   Select ‘Next’ and from the left hand list, select ‘Manage TaskFlows, and move it to the right hand list, and ‘Save’ :

4.   For the Roles which will have Run access, we simply choose the ‘Run TaskFlows’ role from the left-hand list instead.

5.   When we have finished creating all the new aggregated  roles we should have a list in HSS like this:

The next task is to edit our TaskFlows to utilise these new roles.

Modify the Access Control to the TaskFlows

As admin, log into EPMA & navigate to the ‘Manage TaskFlows’ screen.

Select the TaskFlow TF_1 & choose ‘Access Control’:

Each TaskFlow has the option to set the role allowed for ‘Manage’ access and the role allowed for ‘Run’ access:

The drop-down for the ‘Manage Permission Role’ displays all roles (pre-defined and aggregated) that have ‘Manage TaskFlow’ level access:

The drop-down for the ‘Execute Permission Role’ displays all roles (predefined and aggregated) that have ‘Run TaskFlow’ level access:

You can see the Aggregated roles that we created earlier are available.  The ‘Administrator…….Taskflow’ roles correspond to the predefined ‘Manage..’ and ‘Run..’ roles directly under the Administrator node in HSS:

So we can now associate our task flows with the different aggregated roles available, for both the ‘Manage’ & the ‘Run’ access level.

So for TaskFlow TF_1, we set the roles as follows:

The TaskFlows TF_2, 3 & 4 are configured as per the following table:

Now we need to provision our users to give then the correct level of access.

Set up several users & provision them to have access to different roles

Set up the example users (User1 -> User5) in HSS & provision them in the usual way as follows :

I have found that a user must be provisioned with ‘Create Integrations’ role as well as the ‘Manage’ or “Run’ roles, in order to get access to the ‘Manage TaskFlows’ screen.

(These are the roles required for each user in order to achieve the required access to the TaskFlows – it will be necessary to assign users to additional roles to achieve access rights to other parts of the product !)

Running a ‘Provisioning Report’ from HSS on the 5 users for Shared Services applications, we can see what their provisioning is:

Now we can login to EPMA for each of the 5 users and we can see the combined effect of the role creation, user provisioning & ‘Access  Control’ configuration:






Additional Information

The pre-defined Shared Services roles ‘Manage TaskFlows’ and ‘Run TaskFlows’ apply by default to any new TaskFlows that are created, because new TaskFlows have the access control roles of ‘Administrator Manage Taskflow’ and ‘Administrator Execute Taskflow’ set by default.  Any new TaskFlows with these default access control settings will only be available to users provisioned with the pre-defined Shared Services roles ‘Manage TaskFlows’ and ‘Run TaskFlows’.  Conversely, any users provisioned only with these pre-defined Shared Services roles, would have access only to TaskFlows with these default access control settings

The ‘Create Integrations’ role that is required to give any user access to the ‘Manage Taskflows’ screen can be embedded into the aggregated roles, rather than provision the role to the user separately:

I found that If a user has roles with ‘Manage TaskFlow’ access to TaskFlow A, and ‘Run TaskFlow’ to TaskFlow B, when the user logs in they appear to have ‘Manage TaskFlow’ access to both TaskFlow A & B. This means that that user can delete TaskFlows that they were not intended to have ‘Manage TaskFlow’ rights to , so it would be best to avoid this scenario.

Finally I found that logging out of one user session and logging back in as another user, without closing down the browser session,  had the effect that the second user’s privileges appeared to be the same as the first, even if their access was lower.  I worked around this by exiting all browser sessions & clearing the browser cache in between logins.  This could have been a local environment issue.


The Oracle library has the following guidance on TaskFlows and security relating to them: chapter 6 – Managing Roles, chapter 8 -Managing TaskFlows part IV, Using Task Automation