Portfolio-level financial rollups in investment currency – Multi-Currency Support in SPM

[kriti012]

Hi Community,

We are implementing ServiceNow SPM with multi-currency enabled and have a requirement to view portfolio-level financials in the investment/portfolio currency.

Currently, the Portfolio Financials view appears to aggregate and display financial information only in the functional currency. 

Could anyone please confirm:

1. Is there any OOB capability or configuration to display/aggregate portfolio financials in the investment/portfolio currency?
2. If not, is this a known product limitation or planned enhancement in upcoming ServiceNow releases?
3. Has anyone implemented a custom solution to achieve portfolio-level financial rollups in investment currency? If yes, what approach did you use?
4. Are there any specific considerations around currency conversion rates, portfolio planning, cost plans, and budget rollups when implementing such a customization?

Any documentation, KB articles, product documentation, or implementation examples would be greatly appreciated.

Thanks!
#servicenow #spm #localcurrency #portfolio

[musislam]

Hi @kriti012 

In ServiceNow Strategic Portfolio Management (SPM), handling multi-currency across portfolios involves specific system behaviors regarding Functional Currency versus Project/Demand Currency.

1. Out-of-the-Box (OOB) Capability
There is currently no OOB configuration to aggregate and display portfolio-level financials directly in a custom portfolio/investment currency when child projects/demands use different local currencies.
Portfolio Level Behavior: At the portfolio level (in Classic Portfolio Management, Portfolio Workbench, Investment Portal, and Next Experience Portfolio Financials in Strategic Planning Workspace), financial rollups (Planned Cost, Actual Cost, Budget, EAC, Variance) are aggregated and rendered in the system’s Functional Currency (reporting currency defined via glide.system.locale or system properties).
Entity Level Behavior: Multi-currency features (via the com.snc.ppm_multicurrency plugin) allow individual Demands (Demand Currency) and Projects (Project Currency) to manage cost plans, benefit plans, time cards, and expense lines in local currencies.
Sub-Project to Parent Rollup: If parent and sub-projects have different project currencies, ServiceNow uses the system property com.snc.project.multicurrency.rollup_if_different = true to convert sub-project costs to the parent project's currency using Budget Reference Rates (itfm_fx_rate). However, at the top portfolio level, all financial summary grids and widgets convert and sum child items into the single Functional Currency.
2. Known Limitation & Product Context
This is a known platform architectural design limitation:
Heterogeneous Currency Aggregation: Because a portfolio can contain demands and projects spanning multiple geographic regions and currencies, ServiceNow standardizes rollups into the single functional currency to maintain mathematical integrity across heterogeneous investments.
Next Experience Baseline & Migration Limitations:

In Next Experience (SPW/PPW), ServiceNow explicitly notes that financial baseline migration is not supported for demands or projects with multi-currency.
Portfolio Financials Scope: Portfolio Financials views currently support Demands, Projects, and Epics mapped to Fiscal Calendars in Functional Currency.
3. Common Implementation Approaches for Custom Solutions
Organizations requiring portfolio views in a specific Investment/Portfolio currency typically implement one of three approaches:
Approach A: Scripted Investment Widgets (UI / View Layer)
Mechanism: Both classic Investment Portal and Next Experience financial widgets support Scripted Widgets (Scripted = true).
How It Works: Rather than altering underlying database rollups, developers write custom server-side scripts (using GlideAggregate on pm_project or cost_plan_breakdown combined with PPMCurrencyHelper and itfm_fx_rate). The script queries the child project cost plans, converts amounts on the fly using the portfolio's target currency exchange rate, and formats the output string for display.
Advantage: Leaves core database calculations and standard rollups untouched while providing executive stakeholders with converted currency metrics.

Approach B: Custom Summary Currency Fields & Business Rules
Mechanism: Add custom currency or decimal fields to the Portfolio table (pm_portfolio or sn_align_core_portfolio) such as u_portfolio_currency, u_planned_cost_portfolio_curr, and u_actual_cost_portfolio_curr.
How It Works: A scheduled job or business rule executes on cost plan/expense line changes, querying child project cost_plan_breakdown records, fetching the period-effective Budget Reference Rate from itfm_fx_rate, converting the amounts to the portfolio's selected currency, and writing the sum to the custom portfolio fields.
Approach C: Platform Analytics / Reporting Layer Conversion
Mechanism: Leverage ServiceNow Platform Analytics or Performance Analytics.
How It Works: Create formula indicators or calculated report fields that multiply functional currency amounts by conversion rate lookup tables (itfm_fx_rate / fx_rate) based on the reporting period. This isolates currency customization entirely to analytics dashboards.
4. Key Implementation Considerations & Pitfalls
If you proceed with a custom rollup or view, keep the following considerations in mind:
Use Budget Reference Rates (itfm_fx_rate), Not System FX Rates (fx_rate):
ServiceNow SPM uses Budget Reference Rates stored in the itfm_fx_rate table for financial planning and budgeting, controlled by the property com.snc.resource_management.use_budget_reference_rates.
Ensure your conversion scripts reference itfm_fx_rate matching the first date of each fiscal period (Exchange rate date) rather than daily spot rates (fx_rate) to stay aligned with OOB cost plan breakdown logic.
Convert at the Breakdown Level (cost_plan_breakdown), Not the Header:
Exchange rates vary across fiscal periods. Converting a top-level project total using a single exchange rate will cause inaccuracies. Conversions must occur at the Cost Plan Breakdown (cost_plan_breakdown) and Benefit Plan Breakdown (benefit_plan_breakdown) level per fiscal period.
Respect Currency Field Locking:
Once a cost plan, cost plan breakdown, benefit plan, or expense line is created against a project or demand, the Project Currency and Demand Currency fields become read-only and locked. Custom scripts should not attempt to modify primary currency fields on active financial records.

Compatibility with Strategic Planning Workspace (SPW):
SPW / Next Experience uses a new lean budgeting data model (sn_invst_pln_invst_budget). If you plan to migrate to Strategic Planning Workspace, custom fields added to classic forms will not automatically appear in SPW's grid views without custom Table Maps (sn_align_cmn_int_table_map) and field mappingsA small request from my end, If you like this opinion and your problem is resolved after reviewing and applying it.                                              

Please kindly mark this your best answer‌🌠‌ OR  mark it  Helpful ‌⛑‌ if you think that you get some insight from this content relevant to your problem and help me to contribute more to this community