Tag: Oracle Financials

  • Why OTBI Isn’t Showing Your Chart of Accounts (And How to Fix It Fast)

    Why OTBI Isn’t Showing Your Chart of Accounts (And How to Fix It Fast)

    Introduction

    If Oracle Transactional Business Intelligence (OTBI) is not displaying your Chart of Accounts correctly, the issue is usually tied to flexfield deployment, metadata refresh timing, security configuration, or subject area design. These problems are common during implementations and reporting redesign efforts.

    This article explains the most common causes, how to troubleshoot them, and what implementation teams should validate before promoting reporting changes into production.

    One of the most common frustrations in OTBI reporting occurs when Chart of Accounts segments fail to appear correctly within subject areas. Organizations often expect all configured segments to appear automatically, only to discover that OTBI displays only limited dimensions or incomplete hierarchy information.

    Fortunately, this issue is usually caused by missing configuration steps related to hierarchy flattening, BI-enabled segments, flexfield deployment, or BI metadata synchronization.

    This guide walks through the key OTBI configuration steps required to correctly expose Chart of Accounts segments and hierarchies within OTBI subject areas.

    Watch the Webinar

    This webinar walks through common Oracle Fusion OTBI reporting issues and practical troubleshooting approaches used during implementations.

    Understanding OTBI Subject Areas

    Out of the box, OTBI subject areas typically display three mandatory Chart of Accounts segments:

    • Balancing Segment
    • Cost Center Segment
    • Natural Account Segment

    These dimensions are required within Oracle General Ledger.

    Additional Chart of Accounts segments may appear automatically if organizations used Rapid Implementation during initial setup. However, manually configured environments often require additional OTBI configuration steps before custom segments become visible.

    Step 1: Flatten Your Account Hierarchies

    One of the most important configuration steps is hierarchy flattening.

    For each Chart of Accounts segment:

    1. Ensure one hierarchy version is active
    2. Navigate to Actions
    3. Select Flatten
    4. Select Column Flattening

    This process denormalizes hierarchy relationships so OTBI can query parent-child relationships more efficiently.

    Hierarchy flattening should be rerun whenever hierarchy maintenance occurs.

    Without flattening:

    • hierarchy rollups may fail
    • reporting structures may appear incomplete
    • OTBI performance may degrade

    Step 2: Publish Account Hierarchies

    After flattening hierarchies, organizations must publish hierarchy data.

    Publishing makes hierarchy metadata available to embedded tools including:

    • OTBI
    • SmartView
    • Financial Reporting Studio
    • Allocations
    • Cross Validation Rules
    • Segment Security

    Failing to publish hierarchies often prevents reporting dimensions from appearing correctly.

    Step 3: Create Segment Labels

    For non-qualified Chart of Accounts segments, organizations must create segment labels.

    This configuration step maps Oracle flexfield segments into BI reporting structures.

    A critical requirement is the BI Object Name format.

    For General Ledger segments, BI Object Names must follow this exact naming convention:

    • Dim – GL Segment1
    • Dim – GL Segment2 through Dim – GL Segment10

    This naming syntax is extremely sensitive.

    One common issue occurs when Microsoft Word or PowerPoint automatically converts:

    • en dash (-)

    into:

    • em dash (—)

    Oracle requires the standard en dash format.

    Incorrect character formatting can prevent OTBI configurations from functioning correctly.

    Budgetary Control Differences

    Budgetary Control configurations differ from General Ledger configurations.

    Unlike General Ledger:

    • Budgetary Control has no mandatory segments
    • only 10 BI dimensions are available
    • naming conventions use XCC instead of GL

    Budgetary Control BI Object Names must use:

    • Dim – XCC Segment through Dim – XCC Segment10

    Organizations should carefully plan Budgetary Control segment usage because only 10 dimensions are available.

    Step 4: Assign Labels to CoA Segments

    Once labels are created:

    1. Navigate to Manage Structures
    2. Edit the Chart of Accounts structure
    3. Assign newly created labels to the appropriate segments

    This connects Oracle flexfield structures to BI reporting metadata.

    Step 5: Enable BI and Attach Hierarchies

    Next, organizations must verify that each segment is:

    • BI Enabled
    • associated with a hierarchy

    Navigate to:

    Manage Structure Instances

    Then:

    1. Edit the structure instance
    2. Verify BI Enabled is checked
    3. Attach the appropriate hierarchy

    Without these settings, segments may fail to appear inside OTBI subject areas.

    Step 6: Deploy the Flexfield

    After configuration changes are completed:

    1. Navigate to Manage Chart of Accounts Structures
    2. Select Deploy Flexfield

    Deploying the flexfield pushes configuration changes into metadata structures.

    Organizations frequently miss this step, causing reporting configurations to remain unavailable.

    Step 7: Run Required Scheduled Processes

    Two critical scheduled processes must be executed after configuration changes.

    Create Rules XML File for BI Extender Automation

    Navigate to:

    Scheduled Processes → Schedule New Process

    Run:

    Create Rules XML File for BI Extender Automation

    Parameter:

    • Essbase Application = your Chart of Accounts

    Wait for this process to complete fully before proceeding.

    Import Oracle Fusion Data Extensions for Transactional Business Intelligence

    Next run:

    Import Oracle Fusion Data Extensions for Transactional Business Intelligence

    Parameter:

    • ERP
    • Financial Reporting

    This process may take significant time to complete depending on environment size.

    Even empty environments may require approximately one hour for this process to complete.

    Subject Areas Affected

    Once configurations are completed successfully, additional segments become available across multiple Oracle Fusion subject areas.

    Affected Financials subject areas include:

    • General Ledger – Journals Real Time
    • General Ledger – Transactional Balances Real Time
    • Payables Invoices – Transactions Real Time
    • Receivables – Transactions Real Time
    • Receivables – Receipts Details Real Time

    Additional Procurement and Projects subject areas may also expose new dimensions.

    Fixed Assets Configuration Differences

    Fixed Assets configurations behave differently from General Ledger configurations.

    Key Asset Flexfields include:

    • CAT# for Asset Category
    • LOC# for Asset Location
    • KEY# for Asset Key

    Unlike General Ledger:

    • hierarchy flattening is not required
    • hierarchy publishing is not required

    Organizations should understand these differences before attempting to troubleshoot Fixed Assets OTBI issues.

    Common Reasons OTBI is Missing Chart of Accounts Segments

    Common OTBI configuration issues include:

    • hierarchy flattening not completed
    • hierarchy publishing skipped
    • BI Enabled not checked
    • incorrect BI Object Name formatting
    • flexfields not deployed
    • scheduled processes not executed
    • incorrect segment label assignment

    Most OTBI reporting visibility issues trace back to one or more of these configuration gaps.

    Final Thoughts

    OTBI reporting relies heavily on proper Chart of Accounts configuration, hierarchy management, flexfield deployment, and BI synchronization.

    When configurations are performed correctly, organizations gain significantly improved reporting flexibility across:

    • General Ledger
    • Payables
    • Receivables
    • Procurement
    • Projects
    • Budgetary Control

    Understanding the relationship between Oracle flexfields, hierarchies, BI metadata, and scheduled processes is critical for building scalable Oracle Fusion reporting environments.

    Related Oracle Topic Hubs

    About Afternoons With ACEs

    Afternoons With ACEs provides practical Oracle Fusion implementation expertise from Oracle ACE Professionals Lee Briggs and Thomas Simkiss.

    Sessions focus on:

    • enterprise ERP best practices
    • Oracle Fusion implementation strategy
    • reporting and analytics
    • SmartView
    • OTBI
    • testing and governance
    Return to Blog Page
  • Oracle Fusion Chart of Accounts Design Best Practices

    Oracle Fusion Chart of Accounts Design Best Practices

    Why Chart of Accounts Design Matters

    One of the most important decisions in any Oracle Fusion implementation happens long before users begin entering transactions.

    Chart of Accounts (COA) design impacts:

    • financial reporting
    • operational visibility
    • scalability
    • governance
    • analytics
    • implementation complexity
    • long-term maintainability

    Poor Chart of Accounts design creates reporting limitations, unnecessary complexity, and expensive redesign efforts later in the implementation lifecycle.

    A well-designed Chart of Accounts creates a scalable financial foundation that supports enterprise reporting, operational analysis, governance, and future growth.

    In this Afternoons With ACEs session, Oracle ACE Professionals Lee Briggs and Thomas Simkiss discuss practical Oracle Fusion Chart of Accounts design guidance based on decades of real-world Oracle implementation experience.

    Watch the Webinar

    Start with Reporting Requirements

    One of the most important principles discussed during the session is:

    If you need a financial report by something, that “something” must exist in your Chart of Accounts.

    This is one of the most common mistakes organizations make during Oracle Fusion implementations.

    Teams often design a Chart of Accounts around:

    • current organizational structure
    • legacy ERP design
    • transactional workflows
    • departmental politics

    instead of designing around:

    If the business needs:

    • Profit & Loss by Product
    • Balance Sheet by Location
    • Reporting by Project
    • Cost analysis by Department

    those reporting dimensions must be intentionally designed into the Chart of Accounts structure.

    Trying to retrofit reporting requirements later usually creates:

    • custom reporting complexity
    • reconciliation issues
    • manual workarounds
    • inconsistent analytics
    • governance challenges

    Oracle Fusion reporting strategy should begin with the reporting outcomes the business expects to achieve.

    Understanding Oracle Fusion Chart of Accounts Structure

    Oracle Fusion Chart of Accounts design begins with two core components:

    Value Sets

    Value Sets define:

    • format
    • length
    • validation rules
    • allowable structure

    They act as the containers that control how segment values behave.

    Examples include:

    • company
    • cost center
    • natural account
    • intercompany
    • project
    • future use segments

    Value Set Values

    Value Set Values are the actual members of the Chart of Accounts.

    Examples:

    • Company 100
    • Cost Center 010
    • Natural Account 4000

    Together, these structures define the financial architecture of the ERP.

    Oracle Fusion Value Set Best Practices

    The webinar outlines several practical recommendations for Oracle Fusion value set design.

    Use Clear Naming Conventions

    A consistent naming convention dramatically improves administration and maintainability.

    Example:

    XXX_GL_COA_US_COMPANY
XXX_GL_COA_US_COST_CENTER

    Recommended naming structure includes:

    • company short name
    • application/module
    • purpose
    • country identifier (when applicable)

    This makes searching, maintenance, and governance significantly easier over time.

    Allow for Future Growth

    One of the biggest implementation mistakes is designing only for current requirements.

    Organizations evolve.

    New:

    • legal entities
    • reporting structures
    • acquisitions
    • operating models
    • geographic expansions

    can quickly expose limitations in an overly rigid Chart of Accounts.

    Design should always include:

    • scalability
    • future flexibility
    • expansion planning
    • reporting growth considerations

    Use Alphanumeric Parent Values

    The session recommends using alphanumeric parent values for hierarchy clarity.

    Examples include:

    ASSET
LIABS
OWNER

    This improves:

    • readability
    • hierarchy management
    • reporting organization
    • financial statement structure

    At the same time, child values should remain simple and consistent.

    Include an Intercompany Segment

    Even organizations with relatively simple structures should strongly consider implementing an intercompany segment.

    Why?

    Because intercompany requirements almost always increase over time.

    A dedicated intercompany segment supports:

    • balancing
    • future expansion
    • consolidations
    • legal entity growth
    • cleaner financial management

    The presenters recommend using a separate value set for intercompany rather than reusing the company segment value set.

    Thick Ledger vs Thin Ledger

    One of the most valuable sections of the webinar discusses the concept of:

    • Thick Ledger
    • Thin Ledger

    This is a foundational Oracle ERP architecture discussion that many implementation teams overlook.

    Thick Ledger Approach

    A Thick Ledger design uses:

    • many segments
    • extensive detail
    • long natural account lists
    • detailed cost centers
    • detailed asset/liability tracking
    • highly granular posting

    Advantages include:

    • detailed GL analysis
    • rich reporting directly from General Ledger
    • extensive financial segmentation

    However, this approach also creates:

    • heavier reporting structures
    • more complex maintenance
    • larger account combinations
    • increased administration
    • potentially slower reporting

    The webinar describes this approach as increasingly antiquated for many modern Oracle Fusion environments.

    Thin Ledger Approach

    A Thin Ledger design focuses on:

    • fewer segments
    • simplified structures
    • leaner General Ledger architecture
    • operational analysis in subledgers
    • reporting through attributes and analytics tools

    Advantages include:

    • simplified COA management
    • scalability
    • cleaner structures
    • improved maintainability
    • reduced complexity

    This model assumes organizations will leverage:

    • subledger analysis
    • Oracle reporting tools
    • EPM
    • SmartView
    • OTBI
    • analytics platforms

    instead of embedding every reporting requirement directly into the General Ledger.

    For organizations processing high transaction volumes, the presenters strongly favor a thinner ledger approach.

    Key Oracle Fusion GL Segments

    The webinar also discusses several core General Ledger segment recommendations.

    Balancing Segment

    The balancing segment ensures journals balance correctly across organizational structures.

    Oracle Fusion supports:

    • primary balancing segment
    • second balancing segment
    • third balancing segment

    The primary balancing segment is required.

    Cost Center Segment

    Cost centers support:

    • expense tracking
    • operational reporting
    • workforce analysis
    • departmental visibility

    While technically optional, the presenters strongly recommend including cost center structures from the beginning.

    This becomes especially important for:

    • Assets
    • Expenses
    • Procurement reporting
    • business intelligence
    • approval routing

    Natural Account Segment

    The natural account segment defines:

    • assets
    • liabilities
    • expenses
    • revenue
    • equity

    This is a required segment and serves as one of the foundational reporting structures within Oracle Fusion Financials.

    Future Use Segments

    One of the practical recommendations from the session is including future-use segments.

    Even if they are not immediately required.

    Why?

    Because redesigning a Chart of Accounts after go-live can become extremely expensive and operationally disruptive.

    Future-use segments create flexibility that organizations often appreciate years later.

    Oracle Fusion Reporting and Essbase Mapping

    The webinar also discusses how Oracle Fusion General Ledger structures map into Essbase and enterprise reporting environments.

    Examples include:

    Oracle Fusion StructureEssbase Mapping
    Chart of Accounts NameCube Name
    Segment NameDimension Name
    Segment ValueDimension Member
    Value DescriptionAlias
    Ledger NameLedger Dimension

    This is an important consideration because poor Chart of Accounts design frequently creates downstream reporting complexity in:

    • EPM
    • SmartView
    • Financial Reporting Studio
    • analytics environments
    • enterprise reporting cubes

    Reporting architecture should always be considered during COA design.

    Common Chart of Accounts Design Mistakes

    The session highlights several common implementation mistakes.

    Overengineering the COA

    Adding too many segments often creates:

    • maintenance complexity
    • user confusion
    • reporting challenges
    • governance overhead

    More detail is not always better.

    Embedding Excessive Logic

    Too much embedded business logic can make the Chart of Accounts:

    • rigid
    • difficult to scale
    • difficult to maintain

    Good design balances:

    • reporting needs
    • operational flexibility
    • maintainability

    Ignoring Reporting Strategy

    Many implementations focus heavily on transactions and configuration while underestimating:

    • reporting
    • analytics
    • financial visibility
    • executive reporting

    This almost always creates downstream issues.

    Reporting strategy should be one of the first discussions in any Oracle Fusion implementation.

    Practical Oracle Fusion COA Recommendations

    Based on the webinar discussion, several practical recommendations stand out.

    Recommended Practices

    • Start with reporting requirements
    • Design for future growth
    • Keep structures scalable
    • Use consistent naming conventions
    • Include intercompany functionality
    • Consider long-term governance
    • Align COA design with reporting architecture
    • Avoid unnecessary complexity

    Avoid

    • Overly thick ledgers
    • Excessive segmentation
    • Embedded business logic everywhere
    • Inconsistent naming
    • Designing only for current-state requirements

    Final Thoughts

    Chart of Accounts design is not simply an accounting exercise.

    It is:

    • an enterprise architecture decision
    • a reporting strategy decision
    • a governance decision
    • a scalability decision

    Strong Oracle Fusion implementations begin with strong financial structures.

    Organizations that invest time in thoughtful COA design typically experience:

    • cleaner reporting
    • simpler governance
    • better scalability
    • easier analytics
    • improved operational visibility

    Long-term ERP success depends heavily on getting this foundation right.

    Related Oracle Topic Hubs

    About Afternoons With ACEs

    Afternoons With ACEs provides practical Oracle Fusion implementation expertise from Oracle ACE Professionals Lee Briggs and Thomas Simkiss.

    Sessions focus on:

    • enterprise ERP best practices
    • Oracle Fusion implementation strategy
    • reporting and analytics
    • SmartView
    • OTBI
    • testing and governance
    Return to Blog Page