Updated 19-Mar-2025
Introduction
In this post, we explore different ways to manage off-balance sheet accounts in Accounting Hub and General Ledger.
What are Off-balance Sheet Accounts?
Off-balance sheet (OBS) accounts are assets or liabilities that do not appear on a company’s balance sheet.
A common banking example is assets under management. Although banks manage the assets, they usually belong to individual clients directly. Hence, although regulatory filings may report them in a separate section, they do not appear on official balance sheets. We also encounter requirements for off-balance sheet accounting in other industries. More widespread examples include letters of credit or guarantee.
Off-balance Sheet Accounts Requirements
Consider the relative importance of the following business requirements.
Tracked Separately
Cloud ERP should track off-balance sheet activities and balances separately from other accounting. Financial reports should optionally include or exclude off-balance sheet accounts.
Balanced
Cloud ERP should prevent cross balancing between standard and off-balance sheet accounts. Within a journal entry, total off-balance sheet debits should equal total off-balance sheet credits.
Feature Neutral
Cloud ERP features should work in the same way for standard and off-balance sheet accounts. Examples include allocations, revaluation, reporting, extracts, etc.
Ease of Use
Off-balance sheet specific configuration, maintenance and daily usage should be simple and intuitive.
Security
Some enterprises secure off-balance sheet accounts differently from other accounts.
Cloud GL Configuration Options
Account Numbering Convention
Many enterprises identify off-balance sheet accounts using a simple convention: their numbers begin with 9. They are often referred to as “class 9 accounts”.
In some countries, off-balance sheet account numbers are governed by regulation. For example, in France, they must begin with 80.

This table represents the primary balancing segment values (BSV) and natural accounts of six account combinations used in the US Bank’s primary ledger. Natural account numbers that start with 9 identify off-balance sheet accounts.
The convention satisfies requirements for feature neutrality and ease of use but doesn’t prevent cross balancing. Since it relies on manual procedures to enforce segregation, enterprises with few off-balance sheet items or few manually entered journals tend to use it.
Account Hierarchy
Another simple approach is to use a natural account hierarchy to distinguish between off-balance sheet and other accounts.

A natural account hierarchy segregates off-balance sheet and other accounts at the highest level. In this example, natural accounts below parent 200000 in the hierarchy represent off-balance sheet accounts; those below 100000 represent other accounts. When generating financial statements which should exclude off-balance sheet accounts, users filter activities and balances using a natural account parent value.
The approach satisfies requirements for feature neutrality and ease of use. It also avoids an obligatory account numbering convention.
However, it doesn’t prevent cross balancing and could lead to mistakes. Without an account numbering convention, users entering manual journal journals or viewing reports and inquiries that display leaf node account combinations cannot distinguish between off-balance sheet and other accounts.
Primary Balancing Segment Values (BSV)
A more rigorous approach combines an account numbering convention with off-balance sheet primary BSVs.

Off-balance sheet accounts are assigned a separate primary BSV. In this example, primary BSVs that begin with 2 represent off-balance sheet accounts. Those that begin with 1, represent other accounts. Therefore each real-world Entity has two primary BSVs.
The introduction of a BSV to represent off-balance sheet accounts enforces debit / credit equality and limits cross balancing. However, to ensure consistency between BSVs and natural accounts, it should be implemented in conjunction with cross validation rules. For example, a single cross validation rule could specify that for BSVs between 2000 and 2999, only natural account numbers between 900000 and 999999 are valid.
Other aspects of this approach include:
- Security: if necessary, data access sets (DAS) can secure off-balance sheet accounting using primary BSVs.
- Chart of accounts (COA) structure: the approach doesn’t modify existing COA structure.
Consider the following implications:
- Additional BSVs: the approach relies on an additional primary BSV for each Entity that generates off-balance sheet accounting.
- Overloading: the primary BSV no longer uniquely represents the Entity.
- Reporting complexity: users must select two primary BSVs to view all accounting for a real-world Entity. A shallow hierarchy could mitigate this impact in most Cloud ERP reporting tools.
- If you adopt this approach alongside a natural account numbering convention, be aware that suspense and revaluation processing will use on-balance sheet natural accounts. In effect, this approach defines off-balance accounts as the combination of the balancing segment and natural account values.
| Note: If Your COA Doesn’t Use An Account Numbering Convention We have used the class 9 account convention in most examples to illustrate the differences between the options. Bear in mind that you can configure account combination validation features to enforce consistency between segment values irrespective of your account numbering scheme. For more details, see ERP-ACE blog post: Cross Validation Combination Sets and Other Account Combination Validation Features. |
Second Balancing Segment
An alternative approach uses a second balancing segment.

A second balancing segment (OBS, in the example) with just two values distinguishes between standard and off-balance sheet account combinations. In the above table we have used “Yes” and “No” but, “1” and “0” would serve the same purpose.
Like the primary BSV approach, a second balancing segment enforces debit / credit equality and limits cross balancing. But a second balancing segment with just two values also opens an opportunity to use related value sets (RVS). Not only would RVS ensure consistency between the BSV and natural account but, it would also filter natural account lists of values (LOVs) displayed to users in the UI. For example, when the OBS segment value is “Yes”, the natural account LOV would display only 916252, 916253 and 91700; when the OBS segment value is “No”, it displays other natural account values. For more details, see ERP-ACE blog post: Cross Validation Combination Sets and Other Account Combination Validation Features.
Other aspects of this approach include:
- Overloading: the approach avoids overloading the primary balancing segment. A single segment value represents the real-world Entity.
- Defaulting: you can configure “No” as the second balancing segment’s default value. It will be used when upstream applications send no value to the Accounting Hub or GL interface; and whenever users open an accounting flexfield in the UI.
Consider the following implications:
- COA design: you must adopt this approach before finalizing the chart of accounts structure design.
- Security: you cannot secure off-balance sheet accounting using data access sets (DAS). DAS secure accounting based solely on the ledger and primary BSV. However, you could use segment value security (SVS) instead.
- If you adopt this approach alongside a natural account numbering convention, be aware that suspense and revaluation processing will use on-balance sheet natural accounts. In effect, this approach defines off-balance accounts as the combination of the second balancing segment and natural account values.
| Note: Pass-through Accounting and the Accounting Hub Many financial institutions implement pass-through accounting in the Accounting Hub as a first step in their finance transformation. Source system pass-through journals may not include an off-balance sheet account indicator. Don’t worry! You can configure a simple accounting rule to overlay the second BSV using a formula or mapping set based on the natural account. Once derived, the Accounting Engine will validate / enforce the appropriate balancing. If you adopt the primary BSV approach, you could implement a similar solution to overlay the primary BSV with the correct value. For more details about pass-through accounting, see ERP-ACE blog post: Why Implement the Accounting Hub for Pass-through Accounting? |
Separate Ledger(s)
Finally, if your requirement is to strongly partition off-balance sheet accounting, you could consider a dedicated ledger. In this section we will discuss the limitations and possible mitigations of this approach.

A dedicated ledger stores off-balance sheet accounting. Its accounting is balanced by ledger but, on its own, a dedicated ledger is insufficient to prevent users entering accounts in the wrong ledger or cross balancing.
Other aspects of this approach include:
- A separate ledger avoids natural account contamination from suspense and revaluation processing since the corresponding accounts default from the ledger setup.
- Use automatic journal approval rules to ensure that users have entered the correct accounts into the corresponding ledger. Since the approach relies on identifying off-balance sheet accounts in the approval rules themselves, its viability depends on using an account numbering convention.
- Consider a dedicated BSV or secondary balancing segment in conjunction with the dedicated ledger.
Bear in mind other consequences of this approach.
- Close schedule: a dedicated ledger allows you to operate a different close schedule for off-balance sheet accounting.
- Legal entity ledger assignment: you can assign a legal entity to only one primary ledger. Oracle’s cost ledgers mainly use the assignment, which is optional, for local regulatory reporting.
- Balancing segment ledger assignment: you can assign a primary BSV to only one ledger. Implementing a dedicated off-balance sheet primary BSV avoids this issue.
- Secondary and reporting currency ledgers: a dedicated off-balance sheet primary ledger allows its configuration to differ from that of the standard primary ledger.
- Ledger derivation: you cannot configure Accounting Hub or GL Import to automatically derive the off-balance sheet primary ledger based on rules. It must be passed it Cloud ERP along with the transaction data.
Conclusion
Cloud ERP offers various ways to address off-balance sheet accounting requirements. Evaluate which one best suits your enterprise depending on the relative importance of your business requirements.
