HFM consolidation rules are the calculation scripts — written in a VBScript-based proprietary syntax — that define how Hyperion Financial Management (HFM) calculates and consolidates data during the group close process. The rules file (with a .rle extension) is the central calculation artefact of the HFM application: it contains the logic for currency translation (which rate type applies to which account and entity), intercompany elimination matching and posting, equity pickup calculations (recognising the parent’s share of a subsidiary’s profits), and custom consolidation adjustments. The rules file is compiled and loaded into HFM, where it executes during the Consolidate, Calculate, and Translate operations. Unlike Oracle EPM Cloud business rules — which are managed through Calculation Manager as discrete, individually deployable units — the HFM rules file is a monolithic script where every calculation coexists in a single file that must be compiled and loaded as a whole.
Key HFM Rules Sections
| Rules Section | Purpose | Execution Trigger |
|---|---|---|
| Sub Calculate() | Calculates derived account values within entity submissions | Calculate operation per entity |
| Sub Translate() | Applies currency translation rates from entity currency to parent currency | Translate operation per entity-parent relationship |
| Sub Consolidate() | Applies intercompany eliminations, minority interest, equity pickup | Consolidate operation per parent entity |
| Sub Allocate() | Distributes values from parent to children — optional allocation logic | Explicitly called from main rules sections |
| Sub Dynamic() | Calculates member values dynamically at retrieval (Dynamic Calc equivalent) | At data retrieval time, not during consolidation |
Currency Translation in HFM Rules
HFM’s currency translation is configured primarily through the application’s translation rates defined in the HFM metadata (account rate type properties: Average, Ending, Historical) and executed through the Translate rules section. The Translate sub receives the entity’s functional currency data in the Entity Currency [EC] value member and writes translated values to the Parent Currency [PC] value member, using the exchange rates stored in the application’s rate accounts. The critical detail: HFM does not translate all accounts using a single rate — the rate type assigned to each account in the metadata determines which exchange rate the Translate rules apply. An account tagged as “Ending” rate translates at the closing rate; one tagged “Average” translates at the period average rate; one tagged “Historical” uses a stored historical rate. Misconfiguring account rate types produces silent translation errors where the wrong rate is applied without any error message.
FCCS Migration: Why Rules Cannot Be Migrated
HFM rules are written in HFM’s proprietary VBScript-based language with HFM-specific API calls (HS.GetCell, HS.SetData, HS.Entity.IsDescendant) that have no direct equivalent in Oracle FCCS’s calculation framework. FCCS uses Essbase-based business rules (Calc Script and Groovy) and a built-in consolidation engine that implements intercompany elimination through dimension-based rules rather than procedural scripts. Every HFM calculation that needs to be replicated in FCCS must be re-analysed, redesigned, and reconfigured in FCCS’s native framework — the HFM rules code is documentation for requirements, not transferable logic.
What Goes Wrong in Practice
The most damaging HFM rules failure in production environments is an undocumented custom sub-routine in the Consolidate section that implements a client-specific elimination logic — added by an administrator who has since left — that produces correct consolidation results but whose logic nobody currently in the organisation understands. When a group structure change requires modification of the elimination logic, no one can safely modify the rules without risking breaking the existing eliminations. Rules written without inline documentation of the business purpose and accounting basis of each calculation section are a long-term maintenance liability that becomes critical when the original developer is no longer available.
How Loop Wise Solutions Works with HFM Rules
In every HFM engagement, we produce a rules documentation workbook — a line-by-line annotation of the rules file that explains the business purpose, accounting basis, and expected input/output of each significant calculation section. This documentation is the prerequisite for safe rules modification and the migration specification for FCCS transition. We do not begin HFM rules modification in any environment without first documenting the existing rules state.
Answers before you ask.
VBScript-based calculation logic that drives how HFM performs currency translation, intercompany elimination, equity pickup, and consolidation adjustments during the group close. The rules file encodes the group's consolidation treatments as procedural script that runs as entities consolidate, producing the group result.
Because it is the most technically complex artefact in the environment — a large body of VBScript that, if wrong, misstates the consolidated accounts, and which few people fully understand once its authors move on. Changes carry real risk, and its complexity is a major reason HFM environments are cautious about modification.
Because that VBScript logic does not map onto FCCS, which uses seeded, modular consolidation configuration rather than a monolithic script. The treatments the rules encode must be understood and re-implemented in FCCS's framework, not transferred. Underestimating this re-implementation is a common cause of migration overrun.
HFM rules are a largely monolithic VBScript file; FCCS Rules are modular, governed components built on substantial seeded logic. HFM offers open, code-heavy flexibility; FCCS is more prescriptive and configuration-driven. This architectural shift is central to why migration is a rebuild of consolidation logic rather than a copy.