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.
