Oracle GL 2026 (1Z0-1054-26) common mistakes
Oracle GL 2026 (1Z0-1054-26) · Understand the traps and how to avoid them.
Treating the Chart of Accounts structure as freely editable after go-live - trying to add, reorder, or delete a segment in an existing chart - and then designing account combinations assuming segments can be reordered later.
Candidates carry over habits from systems where the account key is a flat string and assume the COA is just configuration. In Oracle Fusion Cloud GL the chart of accounts structure and its value sets are effectively fixed once accounting has occurred; changing the structure requires a new chart and a migration, so design decisions made up front are near-permanent.
What to do instead
Memorise the rule that the COA structure (segments, order, value sets, and the key flexfield definition) is set at implementation and cannot be altered after balances exist. Answer design questions by choosing the correct structure and value-set properties up front, and treat 'add a segment later' as a reimplementation, not a configuration change. Domain: Chart of Accounts, Values, and Account Hierarchy Design.
Confusing the roles of ledger, legal entity, and business unit - for example assigning a primary ledger to a business unit, or expecting a ledger to be created automatically from a legal entity.
The four-C structure (Chart of Accounts, Calendar, Currency, and the ledger/legal-entity/business-unit hierarchy) is described in one place and then assumed everywhere. Candidates skim the enterprise-structure setup and answer from a generic ERP mental model where the company code is the ledger.
What to do instead
Draw the hierarchy explicitly: legal entity is the registered entity, ledger is the accounting representation (one primary ledger per legal entity in the common pattern, with secondary and reporting ledgers attached to it), and business unit is the transaction-processing unit that references a default legal entity and ledger. For each scenario question, identify which object the question is actually configuring before choosing an answer. Domain: General Ledger Configuration and Enterprise Structures.
Assuming a subledger journal entry posts straight to the GL balances, or that subledger accounting rules can be bypassed by creating a manual GL journal for a subledger transaction.
Candidates who have only seen manual GL journals underestimate Subledger Accounting (SLA) as the mandatory translation layer. They miss that every subledger transaction is accounted by SLA create-accounting rules into subledger journal entries, which are then transferred to GL and posted, and that the accounting method and rule sets determine the resulting lines.
What to do instead
Trace the full path for every transaction type: subledger transaction → SLA create accounting (draft or final) → subledger journal entry → transfer to GL → GL posting → balances. Learn where the accounting method, journal line rules, and account derivation rules sit, and remember that correcting a subledger transaction is done at the source, not with a manual GL journal. Domain: Ledger, Subledger Accounting, and Accounting Configuration.
Answering journal questions as if any journal can be posted at any time, ignoring the journal source, category, batch, and the approval and posting options that govern whether a journal is posted individually or in a batch.
Manual journals in GL have a source and category that drive behaviour, and posting can be immediate or batched depending on the journal's posting options and the ledger's setup. Candidates who only remember 'create journal, post journal' miss the status model (unposted, posted, error) and the controls around reversal and approval.
What to do instead
Learn the journal lifecycle and the attributes that control it: source, category, conversion rate type for foreign currency journals, reversal method and reversal period, and whether the journal is posted automatically or must be posted through a batch. When a question describes a journal that will not post, check status, period open/closed state, and suspense or error handling before assuming a security problem. Domain: Journals, Allocations, and Recurring Transactions.
Designing an allocation or recurring journal without specifying the basis, target, offset, and generation pattern, then expecting it to calculate on demand rather than being generated and posted through the normal journal process.
Allocations and recurring journals are often treated as reports. They are journal generators: an allocation definition includes a basis (source balances), a target, and an offset, and recurring journals use a formula or fixed amounts with a generation schedule. Candidates miss that the generated journal still flows through the standard journal approval and posting path.
What to do instead
For allocation questions, identify the four pieces: basis, target, offset, and the run/generation step. For recurring journals, distinguish the template from the generated journal and confirm the formula, currency, and reversal settings. Remember that a generated journal inherits the source and category of its definition and must still be posted to affect balances. Domain: Journals, Allocations, and Recurring Transactions.
Treating period close as a single 'close the period' action and forgetting the sequence - subledger close and transfer, GL posting, revaluation, translation, consolidation, and the final period status change - or assuming a closed period can be reopened freely.
The close is a chain of dependent steps with statuses (Never Opened, Open, Closed, Permanently Closed) and controls such as the close monitor and exception reporting. Candidates who have not run a close mentally compress it into one step and then pick answers that skip transfer or posting.
What to do instead
Memorise the close sequence and the status model, including that reopening a closed period is a controlled action and Permanently Closed cannot be reversed. For each close question, ask where in the chain the described activity sits: subledger accounting, transfer to GL, posting, revaluation, translation, consolidation, or period status. Domain: Period Close, Consolidation, and Revaluation.
Confusing revaluation with translation - expecting revaluation to restate all balances into a reporting currency, or expecting translation to revalue individual foreign-currency balances using a daily rate.
Both processes touch currency and both run at period end, so candidates collapse them. Revaluation restates selected foreign-currency-denominated balances using a revaluation rate and generates unrealised gain/loss entries; translation converts an entire ledger's balances into another currency using period-end, average, and historical rates for different account types.
What to do instead
Separate the two by purpose and scope: revaluation is balance-level, rate-type-driven, and posts adjustment journals in the ledger's own currency; translation is ledger-level, uses a rate type with different rates per account type, and produces balances in the target currency for reporting or consolidation. Match each scenario to the process that changes which number: the balance amount (revaluation) versus the reporting currency (translation). Domain: Period Close, Consolidation, and Revaluation.
Assuming Financial Reporting reports live GL balances directly, or that a report will show data for a period the user has access to regardless of the ledger and security context in which it was run.
Oracle Financial Reporting (and the broader reporting and analytics stack) queries balances through a governed data model with its own currency, ledger, and security context. Candidates who expect a live transactional view misjudge why a report shows different numbers from a GL inquiry or why a user sees no rows.
What to do instead
Learn that reports run against balances with an explicit ledger, currency, and period context, and that row-level security follows the user's data access. When a report is empty or mismatched, check the report's ledger and currency parameters, the period selected, and the user's data access set before suspecting the report definition. Domain: Financial Reporting, Budgetary Control, and Analytics.
Answering budgetary control questions as if budget checking is always on, or as if a failed budget check simply warns and lets the transaction proceed - without distinguishing control levels (absolute, advisory, track) and where the check occurs.
Budgetary control is configured per ledger and per budget, with a control level and exception behaviour, and checking happens at the point of transaction entry in the relevant subledger or GL. Candidates who have not configured it assume one global behaviour and pick the wrong outcome for a given control level.
What to do instead
Memorise the control levels and their effects: absolute blocks the transaction, advisory warns but allows it, and track records without blocking. Also fix where the check fires and what happens when no budget exists for the account and period. For each scenario, identify the configured control level before predicting the result. Domain: Financial Reporting, Budgetary Control, and Analytics.
Treating intercompany accounting as a manual balancing exercise - posting one-sided journals between legal entities - instead of relying on intercompany balancing rules and the automatic balancing that creates the due-to/due-from entries.
Candidates think of intercompany as a reconciliation task performed after the fact. In Fusion Cloud GL, intercompany balancing rules and the intercompany system generate balancing lines when a journal crosses legal entities, and the intercompany reconciliation process matches those balances; manual entries break the automatic control.
What to do instead
Learn how intercompany balancing rules are defined (by ledger, legal entity, journal source and category) and how the system adds balancing lines automatically. Then learn the reconciliation workflow that matches due-to and due-from across entities. When a question describes an unbalanced cross-entity journal, the answer is the balancing rule or the missing rule, not a manual plug. Domain: Intercompany Accounting and Multi-Ledger Processing.
Assuming a user who can see a ledger can also post to it, or that data access and action privileges are the same thing - leading to wrong answers when a user can view balances but cannot enter or approve journals.
Fusion Cloud separates data access (which ledgers, legal entities, and business units a user can see, via data access sets and roles) from function privileges (create, post, approve, close). Candidates who have only seen role-based menus conflate the two and misdiagnose 'user cannot post' as a data access problem.
What to do instead
For every security question, split it into two checks: does the user's data access set include the ledger and period, and does the user's role grant the specific privilege (create journal, post, approve, close period)? Diagnose visibility problems with data access and action problems with role privileges, and remember that approval workflows are driven by the journal's approval rules, not by data access. Domain: Data Access, Security, and Approval Workflows.