Differences between Financial Reporting and Reports

When you migrate a report artifact from Financial Reporting to Reports, the system will convert as many elements of the original report artifact into the Reports equivalent as possible. However, there are differences between Financial Reporting and Reports, and not all elements exist in both. You should consider the migrated report artifact as a starting point for converting a Financial Reporting to Reports, but it is likely that you will have to modify certain elements after the report artifact has been migrated in order to produce a report that is equivalent to the original report artifact. This topic will help you understand the differences between Financial Reporting and Reports so that you can modify the migrated report artifact as necessary.

Financial Reporting Functions and their Reports Equivalents

The following section describes the functions that are available in Financial Reporting and their Reports equivalents where available.


The syntax for text functions differs between the two products. Financial Reporting requires << and >> brackets around functions (for example, <<MemberName()>>). Reports does not require the brackets.

Table B-1 Financial Reporting Functions and Reports Equivalents

Financial Reporting Function Reports Equivalent
CellText CellText
Data source  
Date DateTime
GetCell CellValue
GetHeading HeadingValue
MemberName MemberName
MemberAlias MemberAlias
MemberDescription MemberProperty
MemberProperty MemberProperty
MemberQualifiedName MemberName
Page PageNumber
PageIndex PageNumber
PageCount PageCount
ReportAuthor ReportAuthor
ReportCreated ReportCreateOn
ReportDesc ReportDescription
ReportFolder ReportLocation
ReportModified ReportModifiedOn
ReportModifiedBy ReportModifiedBy
ReportName ReportName
ReportRunBy ReportRunBy


The Reports text function "DateTime" has two parameters, one for date and one for time, the Financial Reporting "Date" function only has one parameter format string. When migrating Financial Reporting reports using the "Date" function, where the time is also specified, the migrated function in Reports needs to be modified to include an extra parameter of "none", otherwise the time result is repeated. For example, a migrated text function as follows: DateTime("dd-MMM-yy h:mm:ss a") needs to be manually modified to the following: DateTime("dd-MMM-yy h:mm:ss a", none)

In Financial Reporting, the text functions allowed for the use of cur, curr or current to indicate the current row, column, or grid. Reports does not support curr. Instead, the functions allow for optional parameters where curr was used.

For example, in the Financial Reporting function <<MemberName("curr", "curr", "Product", "curr")>>, where the "curr" elements stand for grid name, row, column, or page, the "curr" elements are not necessary in Reports. The Reports equivalent would be MemberName("Product"). The "grid" defaults to the grid that contains the function (or the only grid if the text function was in a text object and there was a single grid). If there are more than one grid, and the text function occurs in a text object, then the gridname parameter is required.

Differences in the Point of View (POV)

There are differences between the way that Financial Reporting and Reports manage the POV:

  • In Financial Reporting, by default a grid POV has a value of "User Point of View". In Reports, the default value is "Default".

  • In Financial Reporting, both the grid and user POV are able to have choice lists. In Reports, the list is called a "Suggested List". See Setting Up the Point of View.

  • In Financial Reporting, a report designer can select an initial member to be used on the Grid POV. If a dimension on the Grid POV has a selection, this acts as the initial member for that dimension on the Grid POV every time the report is run. In Reports, a report designer cannot select an initial member to be used in the Local POV when the report is run. If a Suggested List is defined, the local POV uses the last selected Global POV member for the dimension as an initial member when the report is run. However, if the suggested list is defined as a single member selection, then the POV Dimension uses that member as the initial member when the report is run, even when display suggestions only option is not selected.

  • Financial Reporting Grid POV dimensions that have "User Point of View" selected will be migrated to use the Global POV in Reports. If the report has multiple data sources, only the first data source’s dimension will be migrated to the Global POV. All other Financial Reporting Grid POV dimensions will be migrated to the Local POV in Reports.

  • In Financial Reporting, grids can have page axes. In Reports, the page axis functionality is supported through the 'Print All Selections' option on a dimension in the POV. If the member selection contains a Prompt it will be migrated as a Global POV dimension in Reports.

  • In Financial Reporting, in the grid editor a user sees the values of the user POV for dimensions on the grid POV. In Reports, the user sees only 'Default', or the 'Suggested List' members.

Grid Object Differences

When working with grid objects, consider the following:

  • In Reports grid headers are frozen by default.

  • The heading type 'Entity Short Name' is not supported in Reports.

  • Reports does not have a Hide Grid property; all hidden grids are managed in the Hidden Sheet. Hidden grids in Financial Reporting are moved to the Hidden Sheet in Reports, where they can be edited and managed. Any grids that are in the Hidden Sheet will not be displayed in the report output.

  • The Row/Column property for ‘Page Break Before = Position at Top’ is not supported in Reports. Row/Column page breaks will always appear in the same position on the following page.

  • In Financial Reporting, the 'Show Supporting Detail' unary operator is set at the row level. In Reports, it is set at the grid level. If the Financial Reporting report contains different property values for 'Show Supporting Detail' for different rows, the system displays a migration error.

  • If the grid object has a page axis member selection set to 'Current Point of View', the system will replace the selection with the dimension-name-member. This condition is not valid in Reports, since the page axis member selection is migrated to a suggested list on a grid POV dimension. In the log for the migration, the system will display :" In grid object 'Grid1', the page axis member selection has a 'Current-Point-of-View' reference, which is not valid."

  • If the Financial Reporting page axis member selection contains multiple prompts, the member selection will be migrated to a single prompt in Reports.

  • A single grid cannot reference multiple data sources in Reports. If a Financial Reporting grid references multiple data sources, the system displays a migration error.

  • Since a Reports grid does not have a page axis, if a Financial Reporting grid contains sorting on the page axis, the system displays a migration error in the migration log.

  • For migrated Financial Reporting reports where the cell shading is set to white (FFFFFF) by default, you must set the report cell shading to "Transparent" in order to use the grid property for row banding. Otherwise, the system will recognize the cell shading as having an existing format applied and row banding will not be applied.

  • In Reports the Financial Reporting Conditional Format of Format Cells then Alignment then Indent Increases For Each Generation By: is not supported. Indent by Generation can be applied as a cell property after import.

  • If a user has merged heading and data cells in Financial Reporting and imports the report to Reports, the import splits the merged cells into merged heading cells and merged data cells. This will change how the report looks and works and the user will need to modify the report.

  • Reports does not support empty formula rows or columns in a grid, when importing Financial Reporting (FR) reports with empty formula rows or columns, a warning message is displayed. The report designer will need to edit the Reports grid formula to either set up a formula and enter "0" or replace the formula row or column with a separator row or column, if nothing is needed to display.

  • The floating heading cell values into adjacent heading cell is not supported. All the manual adjustments such as merging cells, may be required for the look and feel from the Financial Reporting report's point of view.

  • In Financial Reporting, the grid-level property sheet allowed a user to enabled "Suppress Missing/Error/Zero". However, enabling this property at the grid level just enabled the property for every row and column in the grid.

    The enabling of the property did not get applied to the grid, it was just a short-cut to selecting all the rows and enabling the property and then selecting all the columns and enabling the property.

  • In Reports, the grid-level property allows a user to enable "Suppress NoData/Error/Zero" properties, and these properties are set and stored at the grid level. You can also select one or more rows/columns and enable/disable the suppression properties for those rows/columns instead of defaulting to the grid-level settings. This is why at the row/column level, the Suppression properties have three options: "Grid Setting", True, and False. The Grid Setting property value will defer to the property setting at the grid level.Financial Reporting did not have this ability.

    Because of these differences, when an Financial Reporting (FR) report is migrated to Reports, only the row and column level properties of the Financial Reporting (FR) report are migrated to Reports, unless every row and column in the Financial Reporting (FR) report has the given Suppression property enabled. The grid level properties remain at their default (False), if all the rows and columns do not have the same Suppression property enabled.

    In addition, Financial Reporting (FR) always uses the rounded/scaled value for basic and conditional suppression, Reports does not by default. There is a Grid General property, under Conditional Expression, Use rounded/scaled value, which by default is set to False. If you are seeing differences in suppression applied between Financial Reporting (FR) and Reports, then you can set this property to True.

  • In Financial Reporting, the "Indent by relative generation" was calculated on a segment-by-segment basis, so that the relative generation would be for all member combinations resulting from a single design time row. In Reports, the "Indent by relative generation" is calculated on an entire axis basis, meaning that the relative generations of all row member combinations is used when calculating the relative indent.

    To achieve the results in Reports that were previously available in Financial Reporting, you can set up conditional formatting expressions for a specific generation (e.g. Generation 3), and the formatting is to indent by a certain amount amount; then define a different conditional format for another specific generation (e.g. Generation 4), and the formatting is to indent by a different amount.

  • In Reports, the Repeated Heading grid, row and column property, when set to Hide, any adjacent row or column cells which have the same value are considered for repeated values. In Financial Reporting, the inner-most layer in the row and column headings is not considered with regards to repeated values. This will result in different processing and rendering of repeated values between Reports and Financial Reporting for the inner-most layer in rows and columns.

Image Object Differences

Financial Reporting supports a stretch option for images. Reports does not support stretching or cropping; instead, the image will be sized to the correct aspect ratio.

Text Object Differences

In Financial Reporting, the text object has an 'AutoSize' property. In Reports, the size options for height are:

  • Fixed (equivalent to AutoSize=Off)

  • Fit (equivalent to AutoSize=On)

  • Minimum

Chart Object Differences

The following Financial Reporting chart properties are not supported in Reports charts:


After importing a Financial Reporting report with Combo charts, the chart line colors in Reports do not match the colors in Financial Reporting.

  • Font Angles: Font angles for all font settings for text in the Format Chart dialog box

  • Format Chart:

    • Appearance:

      • Title Box Color

      • Title Box Border Color, Type, and Width

      • Grid Depth

    • Legend:

      • Suppress Repeating Labels

      • Background Border Type and Width

    • Axes:

      • X-axis Background Color

      • X-axis Border Color, Type, and Width

      • Y-axis Background Color

      • Y-axis Border Color, Type, and Width

      • Y-axis Override Number Format

      • Y2-axis Title Box

      • Y2-axis Override Number Format

    • Pie Options:

      • Pie Label Position

      • Pie Slice Angle

Alignment and Layout Differences

  • In Financial Reporting, an object can be top/left/bottom and left/right/center aligned. However, the object is aligned with the appropriate edge of the page (taking into account the margins and header/footer height). In Reports, the same alignment options are supported. However, the object can be aligned a certain distance from the appropriate edge. This is supported via the ‘Indent’ alignment property.

  • Financial Reporting does not perform validation on object sizing and positioning compared to the page and margin sizes. Reports performs layout-related validations. If you receive a validation error, regarding an object overlapping or not fitting after opening an imported Financial Reporting report in Reports, manually resize or move the object to remove the error.

Member Selection Differences

When working with grid objects, consider the following:

  • Duplicate members in the same segment are not allowed and are removed.

  • The Financial Reporting advanced member selection operators such as AND, UNION, OR and NOT are converted to the Reports member selection functions Intersect (which combines multiple members and functions, previously the AND operator in Financial Reporting) and Except (excludes a member or function from another function, previously the NOT operator in Financial Reporting). The Financial Reporting OR and UNION operators performed the same operation and are the default for any member selections, therefore there is no need to specify anything additional in Reports for these two operators. There are two migration differences for the NOT operator:

    • Reports member selections do not support migrating nested 'Not' statements. For example, "member-selection1 and not member-selection2" is migrated, while "member-selection1 and not not member-selection2" is not.

    • Reports member selections do not support migrating a 'Not' statement on the first member selection. For example, "member-selection1 and not member-selection2" is migrated, while "not member-selection1 and member-selection2" is not.

  • In Financial Reporting, member selection supports SuppressSharedMembers. In Reports, suppress shared members is supported as an option on an existing member selection (added via a member selection menu).

  • Reports does not support a user-defined 'User member list', as Financial Reporting does.

  • The following Financial Reporting member selection functions are not supported in Reports:

    • MatchEX

    • TopOfHierarchy

    • LSiblings

    • RSiblings

    • Top

    • AllMembers

  • In Financial Reporting, a system-member-list is either a named level or a named generation. The underlying data source provides these names, which take the form of 'Lev<n>,<dimension name>' or 'Gen<n>,<dimension name>' by default. However, a data source administrator can also give a user-specified name to a level or generation (for example, SKU or Country). If the system-member-list is one of the default names, it gets converted to the 'LevelMembers' or 'GenerationMembers' member selection functions. If the system-member-list has a non-default name, the system cannot determine what the available list of names is without connecting to the data source. Therefore, the system displays a migration error and the member selection is converted to the dimension parent member.

  • When migrating members, any member name in Financial Reporting that is prefixed with a "$" (meaning it is a substitution variable ) is converted to a substitution variable and prefixed with an "&" in Reports.

  • In Financial Reporting Web Studio, duplicate prompt labels in a grid are permitted. In Reports , duplicate prompt labels are not permitted. If the reuse of prompt definitions in multiple locations is required, a Saved Selection should be created for the prompt and select the Saved Selection from the multiple locations. If the Financial Reporting Web Studio report contains duplicate prompt labels, where one prompt definition allows selection of multiple members and another prompt definition, with the same label, is used as a single selection in a member selection function (for example, Children (Prompt), upon migration to Reports, the report designer will need to manually adjust the duplicate prompt labels where validation errors occur.
  • In Financial Reporting Web Studio, the Property member selection function works with member names and aliases, attribute members as well as UDAs. In Reports, the use of member names and aliases is not supported
  • In Reports, the Dynamic Time Series member selection only supports selecting a single member or CurrentPOV. Member selection functions are not supported as parameters for the Dynamic Time Series function. Financial Reporting supported the RelativeMember function with Dynamic Time Series.

Conditional Format and Suppression Differences

In Financial Reporting Web Studio, conditional formatting and suppression conditions evaluate #missing data values as if they were zero.

For example, with the conditional expression ‘value == 0’ this would be true for both a zero value and a #missing value.

In Reports, conditions evaluate #missing data values as no data only.

For example, with a conditional expression ‘value == 0’ this would be true for only a zero value and NOT a #missing value.

Therefore, in Reports, separate conditions would need to define when checking for either zero or #missing.

Grouping and Auto Calculation Differences

Auto Calculations (Auto-Calcs) in Financial Reporting will be migrated to the equivalent report grouping, with the following considerations and differences:

  • In Financial Reporting, the Auto-Calc formulas were fixed and defined in a dialog box. We migrate them to equivalent formula rows or columns.

  • In Financial Reporting, the dimension layer on which an Auto-Calc was specified is different than the Reports grouping the dimension layer.

    • Layer 0 in Financial Reporting was considered a "Grand Total" type of calculation. This adds no real value since it is simply the summation of all the Auto-Calc dimension combinations. In Reports, this would be equivalent to a non-grouped formula rows/column referencing the grouped row or column. This is how a layer 0 Auto-Calc is migrated.

    • Layer 1+ Auto-Calcs are migrated to a grouping on Financial Reporting Layer – 1 in Reports. So an Auto-Calc on layer 1 will be a grouping layer 0, and so on.

  • In Financial Reporting, the Allow Page Break After Auto Calculation property is migrated to a grid-level Group Page Break property on the appropriate dimension. However, in Financial Reporting, this property could be specified on each Auto-Calc and change within a grid. This is a grid-level property in Reports and applies to all the groupings on the given dimension in a grid.

  • In Financial Reporting, the Allow Page Breaks Within property is migrated to a grid-level No Page Breaks in Group property. This is also a grid-level property in Reports and applies to all the groupings on a given dimension in a grid.

  • In Financial Reporting, formatting on non-data segments in an Auto-Calc was done via conditional formatting. This is not necessary in Reports since the non-data segment in a group are part of a grid and can be formatted directly. The conditional formatting in the Financial Reporting report is migrated to the equivalent segment in Reports.

Features Not Available in Reports

The following Financial Reporting features are not supported in Reports:

  • Planning Unit Annotations

  • Annotations

    The Notes feature in Narrative Reporting utilizes a different underlying framework and features than Financial Reporting Annotations, therefore Annotations are not migrated to Narrative Reporting Notes.

  • Row/Column templates

  • Microsoft Word documents in Books Using FRExecute to Embed Financial Reporting Reports into Microsoft Word

Font Differences

The following default fonts from Financial Reporting will be converted to the equivalent Reports fonts, unless the Financial Reporting fonts have been uploaded as custom fonts.

Table B-2 Financial Reporting Fonts and Reports Equivalents

Default Financial Reporting Fonts Equivalent Reports Fonts

Microsoft Sans Serif

Liberation Serif


Liberation Sans

Times New Roman

Liberation Serif


Liberation Mono


Financial Reporting Web Studio will contain additional locale-specific fonts that were not exposed in Reports.

To upload fonts in Narrative Reporting, see Uploading Additional Fonts in Administering Narrative Reporting.

To upload fonts in the EPM Cloud Platform:

Other Differences

Keep in mind the following considerations when migrating reports:

  • Drill to content cannot be used to drill to a cell file attachment sourced from an Oracle Essbase Linked Reporting Object or Narrative Reporting cell file attachment.

  • Linked and local objects, which are report objects such as grids or charts, that are saved to the repository and inserted in the report, are not supported in Reports. If a linked object is found in a Financial Reporting report that is being migrated, the system will display a migration error.

  • If you migrate an EPM Cloud report (for example, Planning Modules) with conditional formatting or suppression by Account Type (for example, suppressing rows with an account type of Revenue), you may have to update the conditional expression in order for it to be applied correctly. This is because in Financial Reporting, the conditional expressions for Account Type check only if the type is Expense or NonExpense, while in Reports, the expression checks if the account type is an Asset, Liability, Equity, Revenue, Expense, or NonExpense type. As a result, you should update the conditional expression to check for the true account type. For example, expressions that suppress a Revenue account type (which is considered NonExpense in Financial Reporting) must be updated to suppress the true account type of Revenue after the report is migrated.

  • Reports does not support a 'Custom' paper format size. The migration will convert this size to 'Letter'.

  • Reports does not support a Super A3 paper format size. The migration will convert this size to 'Letter'.

  • In Financial Reporting users can add MemberOverride to the CellText function. In Reports this is not currently supported.

  • Related content links to library folders in Financial Reporting are removed during import to Reports
  • In Financial Reporting, if a report has two grids (For example Grid1 and Grid2): where Grid1 has a Page dimension to print the grid on different pages and Grid2 does not have a Page dimension with printable pages:

    • Financial Reporting generates the output in PDF as: Page1...Page n for Grid1 with POV members on separate pages, followed by Grid2.

    • Reports generate the output for the same scenario (with Grid1 in the POV with Print All Selections enabled) to PDF as Page1: Grid1 (1st POV member), Page2: Grid2, Page3: Grid1 (2nd POV member), Page4: Grid2, and so on.