For years, government organizations using Oracle Fusion Cloud ERP have faced a persistent challenge: how to handle enterprise funds that operate on full accrual accounting when their primary ledger uses modified accrual accounting. The traditional approach forced these transactions into both ledgers, creating unnecessary data bloat and processing overhead in the primary ledger where they served no meaningful purpose.

Oracle’s Accounting Hub 25D release changes everything with a deceptively simple but powerful new feature: the ability to exclude specific subledger transactions from accounting in selected ledgers. Combined with separate journal line rules that leverage conditions, this capability finally provides the surgical precision government entities need to route transactions exactly where they belong.

The Problem: When Full Accrual Meets Modified Accrual

Government accounting presents a unique challenge. While governmental funds (like the General Fund) use modified accrual accounting that focuses on near-term inflows and outflows of spendable resources, enterprise funds operate more like businesses, using full accrual accounting that recognizes all revenues when earned and expenses when incurred, regardless of cash timing.

Previously, if you wanted enterprise fund transactions to flow into a secondary ledger with full accrual accounting, you had no choice but to also process them through your primary modified accrual ledger—even though these entries were meaningless in that context. This created:

  • Unnecessary data volume in your primary ledger
  • Processing overhead for transactions that provided no value
  • Complexity in reporting and reconciliation
  • Confusion for users trying to understand why certain entries existed in the primary ledger

The Solution: Conditional Rules Plus Selective Exclusion

The breakthrough comes from combining two powerful capabilities:

1. Separate Journal Line Rules with Conditions: By creating distinct journal line rules for each ledger and using conditions to control when each rule fires, you can define completely different accounting treatments for the same subledger event. For example, you might have one rule set for enterprise fund transactions that creates full accrual entries, and a different rule set (or no rule at all) for those same transactions in your modified accrual primary ledger.

2. The New “Exclude” Column: The new “Exclude” column in the Journal Entry Rule Set Assignments section of the Accounting Method page is the key that makes it all work. Once you’ve set up your conditional journal line rules, you can use this checkbox to explicitly exclude specific event types from accounting in particular ledgers.

Together, these capabilities enable true Transaction Routing Flexibility: You can now configure your accounting methods so that enterprise fund transactions from subledgers (like Accounts Receivable, Accounts Payable, or Assets) skip accounting in your modified accrual primary ledger entirely and flow directly—and exclusively—to your full accrual secondary ledger, where separate journal line rules tailored to that ledger’s requirements take over.

How Conditional Rules Make It Work

The magic happens at the journal line rule level. Here’s the typical setup pattern:

Primary Ledger Rules: Create journal line rules with conditions that identify governmental fund transactions. These rules only fire when the transaction meets modified accrual criteria (perhaps based on fund code, department, or other transaction attributes). Enterprise fund transactions simply don’t match these conditions.

Secondary Ledger Rules: Create separate journal line rules specifically for your enterprise fund secondary ledger. These rules use conditions to identify enterprise fund transactions and apply full accrual accounting logic—capitalizing assets, recognizing depreciation, accruing revenues and expenses based on delivery rather than cash flow.

Exclusion Configuration: In your accounting method setup, check the “Exclude” box for enterprise fund event types in the primary ledger. This prevents Create Accounting from even attempting to generate entries there, since your conditional rules wouldn’t fire anyway.

Delta Ledger Configuration in Practice

Oracle calls this approach “Delta Ledger” configuration, and the conditional rules are what make it practical:

  • Shared Transactions: When a transaction needs the same accounting treatment across all ledgers, your journal line rules (without fund-specific conditions) generate entries in the primary ledger, which then automatically flows to secondary ledgers
  • Different Treatments: When you need different accounting for different ledgers, separate conditional rules handle each ledger’s requirements independently
  • Secondary-Only Transactions: Enterprise fund transactions use conditional rules that only exist in the secondary ledger accounting method, with the primary ledger excluding these events entirely

Real-World Impact for Government Entities

Consider a water utility enterprise fund within a city government:

Before 25D: Revenue accruals, depreciation entries, and capital asset transactions all had to be processed through both ledgers. Even though you might have tried using conditional rules to prevent entries in the primary ledger, the Create Accounting process still had to evaluate those transactions, creating processing overhead.

After 25D: You create separate journal line rules in your enterprise fund secondary ledger that use conditions like “Fund equals 510” to identify utility transactions. These rules apply full accrual logic—capitalizing improvements, accruing unbilled revenues, recognizing depreciation. Meanwhile, you exclude these same event types from your primary ledger’s accounting method entirely. The transactions never even get evaluated against your modified accrual rules.

Your modified accrual primary ledger stays clean and focused on governmental fund activities, processed by its own set of conditional rules that target governmental fund attributes. Your enterprise fund maintains its proper full accrual accounting through separate, purpose-built journal line rules.

Why This Matters

The combination of conditional journal line rules and selective exclusion isn’t just about cleaner data—though that alone would be valuable. This approach fundamentally reduces complexity in several ways:

  1. Reduced Processing Time: Excluding entire event types from ledgers where they don’t belong means fewer rules to evaluate and faster Create Accounting processes
  2. Rule Clarity: Separate journal line rules for each ledger, controlled by clear conditions, make your accounting logic transparent and maintainable
  3. Simplified Reconciliation: When your primary ledger only contains transactions that actually belong there (filtered by conditional rules), reconciling to external reports becomes straightforward
  4. Improved Performance: Less data volume and fewer rule evaluations mean better system performance across queries, reports, and processes
  5. Flexible Architecture: Conditional rules give you the flexibility to handle edge cases where the same transaction might need different treatment based on context—something the exclude feature alone couldn’t accomplish
  6. Cost Efficiency: Reduced data storage, fewer rule evaluations, and faster processing translate to lower cloud infrastructure costs

Implementation Considerations

While this combination of features is powerful, Oracle provides important guidance for government organizations:

  • Rule Design First: Start by designing your conditional journal line rules for each ledger. Make sure your conditions properly segregate governmental fund transactions from enterprise fund transactions. Test thoroughly to ensure transactions route correctly.
  • Downstream Impacts: Exercise caution when excluding events that have downstream dependencies. Your conditional rules for downstream events (like payments) may need to be designed to work independently if you’re excluding the upstream event (like the invoice) from a particular ledger.
  • Business Flows: When journal line rules use business flows to derive attributes from upstream events, and you’re excluding those upstream events from certain ledgers, you’ll need to modify your conditional rules so the downstream event can generate entries independently in each ledger.
  • Condition Testing: The interplay between conditional rules and the exclude feature means thorough testing is essential. Verify that transactions are landing in the right ledgers with the right accounting treatment—or being properly excluded.
  • Timing: Setup changes can take up to an hour to reflect in online accounting processes, though you can use batch Create Accounting during this period.

Getting Started

This feature requires opt-in through Oracle’s feature adoption interface and will become mandatory starting in Update 26C. Here’s a recommended implementation approach for government organizations:

  1. Map Transaction Flows: Document which subledger transactions should go to which ledgers and what accounting treatment each needs
  2. Design Conditional Rules: Create separate journal line rules for primary and secondary ledgers, using conditions based on fund codes, departments, or other attributes to control when each rule fires
  3. Test Rule Logic: Before implementing exclusions, verify your conditional rules are working correctly in a development environment
  4. Configure Exclusions: Once your conditional rules are solid, add the exclude configuration for event types that should bypass specific ledgers entirely
  5. Validate End-to-End: Test the complete flow from subledger transaction through Create Accounting to final journal entries in each ledger

Start with enterprise funds, where the benefit is clearest and most immediate. The combination of conditional rules and selective exclusion provides the most value where accounting treatment diverges most significantly between ledgers.

The Bottom Line

Oracle Fusion Cloud Accounting Hub 25D, combined with well-designed conditional journal line rules, delivers something government organizations have needed for years: the ability to route subledger transactions intelligently based on their relevance to each ledger and apply the appropriate accounting treatment in each.

The conditional rules provide the “how”—defining exactly what accounting entries should be created in each ledger based on transaction characteristics. The exclude feature provides the “where”—ensuring transactions only flow to ledgers where those conditional rules exist and should fire.

For enterprise funds, this means escaping the wasteful practice of creating accounting entries in a modified accrual primary ledger where they serve no purpose. By leveraging conditions to segregate governmental from enterprise fund transactions, and then excluding enterprise fund events from your primary ledger entirely, you gain a cleaner, faster, more efficient financial system that better reflects the true nature of your operations.

This isn’t just about configuration—it’s about architectural design. The days of one-size-fits-all transaction processing are over. Welcome to selective, intelligent, conditionally-driven ledger accounting.

Let's set up a call?

Send over your name and email and we can coordinate to do call over coffee!

We'll get in touch

Let's set up a call

Send over your name and email and we can coordinate to do call over coffee!

We'll get in touch

Let's get on a call!

Send over your name and email and we can coordinate to do call over coffee!

We'll get in touch

Subscribe To Keep Up To Date

Subscribe To Keep Up To Date

Join our mailing list to receive the latest news and updates.

You have Successfully Subscribed!