Skip to main content

Roll Up Group

  Roll Up Group Rollup Groups in Oracle Fusion Financials   You can't understand rollup groups without first understanding the chart of accounts hierarchy   Let me be upfront about something: rollup groups are not a standalone feature you can grasp in isolation. They live   inside the larger machinery of the chart of accounts, parent values, and account hierarchies, and if you try to   explain them without that context you end up reciting a definition nobody can actually use. So I'm going to build the   foundation first, and then the rollup group will click into place as the small but useful piece it actually is.     Start with the chart of accounts. In Oracle Fusion, your chart of accounts is a key flexfield made up of segments —   Company, Cost Center, Account, and so on, whatever your design calls for. Each segment draws its allowable values from   a value set. The Account segment's value set, for instance, holds a...

Manual Journal

 

Manual Journal

Manual Journals in Oracle Fusion General Ledger

 Where the manual journal sits in the bigger picture

 Most of the accounting that happens in Oracle Fusion is not entered by hand. It flows in automatically. A supplier

  invoice in Payables, a customer receipt in Receivables, a depreciation run in Assets, a payroll posting — all of these

  are created in their own subledgers, translated into journal entries by the subledger accounting engine, and

  transferred up into the General Ledger. That automated river of accounting is the bulk of what lands in the GL.

 

  The manual journal is the deliberate exception. It is the entry an accountant creates directly in the General Ledger,

  by hand, when there is no subledger transaction behind it or when an adjustment is needed that no subledger will

  generate on its own. Accruals, reclassifications, corrections, allocations, provisions, top-side adjustments at period

  close, opening balances during a go-live — these are the natural home of the manual journal. So while manual journals

  are a small slice of total volume, they are a disproportionately important slice, because they are where human

  judgment enters the ledger directly, and where the controls around accounting have to be tightest.

 

  Understanding manual journals well means understanding not just how to type one in, but the whole apparatus around

  them: the structure of a journal, the sources and categories that classify them, the ways to enter them, the approval

  and posting controls, and the special breeds like reversing, recurring, and statistical journals. I'll walk through

  all of that.

 

  The anatomy of a journal

 

  Before talking about how you create one, it helps to be precise about what a journal is in Fusion, because the

  terminology is layered and people use it loosely.

 

  At the top sits the journal batch. A batch is a container that can hold one or many journals. It carries information

  that applies to everything inside it — most importantly the accounting period the entries belong to, and a batch name.

  Grouping journals into a batch is convenient when several related entries should be handled together, and even a

  single journal lives inside a batch whether or not you think about it that way.

 

  Inside the batch sit one or more journals, sometimes called journal entries or headers. Each journal carries its own

  attributes: the ledger it posts to, the accounting date, the journal category, the journal source, the currency, a

  description, and optionally a balancing-segment behaviour. A single batch can hold journals for different categories,

  but a journal itself is one coherent entry.

 

  Inside each journal sit the journal lines. Each line names an account combination — built from the chart of accounts

  structure — and a debit or credit amount. The fundamental rule, the one the system enforces relentlessly, is that the

  journal must balance: total debits must equal total credits. And not just overall — they must balance within each

  balancing-segment value, because the balancing segment exists precisely to keep each company or legal entity's books

  self-balancing. If you enter a journal whose lines cross balancing-segment values without balancing, Fusion will

  either generate automatic intercompany balancing lines or stop you, depending on configuration.

 

  So the hierarchy is: batch contains journals, journals contain lines, lines name accounts and amounts, and the whole

  thing must balance. Keeping that three-level picture clear in your head removes most of the confusion people have when

  they first work with Fusion journals.

 

  Source and category: the two classifiers

 

  Two attributes on a journal deserve special attention because they govern so much downstream behaviour: the journal

  source and the journal category.

 

  The journal source tells you where the journal came from. Subledger journals carry sources like Payables, Receivables,

  or Assets, identifying the module that generated them. Manual journals carry the source Manual (or a custom source

  defined for a particular purpose, like Spreadsheet for entries loaded through the spreadsheet tool). The source is how

  you, and the system, distinguish a hand-entered adjustment from an automated subledger posting. It matters for

  reporting, for reconciliation, and for certain processing controls — for example, whether journals from a given source

  are allowed to be imported, or whether they freeze after import so they cannot be edited in the GL.

 

  The journal category tells you what kind of entry it is — Accrual, Adjustment, Reclass, Allocation, Addition (from

  Assets), and so on. The category is descriptive and is enormously useful for reporting and analysis: a controller

  reviewing period-end activity can filter to just accrual journals, or just adjustments, to understand what manual

  intervention happened during close. Categories also drive certain automated behaviours, such as which categories are

  set up to auto-reverse.

 

  Together, source and category form a two-dimensional classification — where it came from and what it is — that makes

  the ledger legible. A discipline of using meaningful, consistent categories on manual journals is one of the marks of

  a well-run close, because it turns an undifferentiated pile of adjustments into something a reviewer can actually

  navigate.

 

  The ways to create a manual journal

 

  Fusion gives you more than one path to enter a manual journal, and choosing the right one for the situation is part of

  working efficiently.

 

  The Create Journal page in the application. This is the direct, online route. You navigate to the journals area of the

  General Ledger, choose to create a journal, and you are presented with a form for the batch and journal header,

  followed by a grid for the lines. You pick the ledger, the period or accounting date, the category, the currency, and

  then you enter line after line of account combinations with their debits and credits. The page shows you running

  totals so you can watch the entry come into balance. This is the natural choice for a one-off entry of modest size,

  where typing a handful of lines online is quicker than anything else.

 

  The spreadsheet route — Create Journals in Spreadsheet. Fusion integrates with a desktop spreadsheet through an

  add-in, letting you build journals in a familiar grid in the spreadsheet application and then upload them straight

  into the GL. This is the workhorse for larger or repetitive entries. An accountant who has to enter a fifty-line

  reclassification, or who maintains a standard monthly accrual with many lines, will almost always prefer the

  spreadsheet, because copying, pasting, and formula-filling are so much faster there than typing line by line in the

  web form. The spreadsheet validates and submits the journal, and the entry shows up in the GL just as if it had been

  keyed online, typically under a Spreadsheet source so you can tell how it arrived. This route is also friendlier for

  people who are simply more comfortable working in a spreadsheet, which is most accountants.

 

  Journal import. For high-volume or system-to-system loading — converting opening balances at go-live, loading entries

  generated by an external system, or bringing in allocations computed elsewhere — data is staged into the GL interface

  and a Journal Import process turns the staged data into actual journals. This is less an everyday manual activity and

  more an integration or conversion mechanism, but it produces journals that, once imported, can behave like any other

  and is worth knowing as part of the same family.

 

  File-based data import. A related bulk mechanism uses a structured template to load journal data through a file and an

  import process, which is how many implementations handle recurring large loads or conversions in a controlled,

  repeatable way.

 

  The right choice depends on volume and repeatability: online for the small and occasional, spreadsheet for the large

  and the recurring-by-hand, import and file-based loading for the bulk and the system-driven. A good consultant teaches

  the client all of these and helps them match each kind of entry to the most efficient path, because forcing

  everything through the online page when half of it should be in a spreadsheet is a common source of close-process

  pain.

 

  The lifecycle of a manual journal

 

  A manual journal does not simply spring into existence as posted accounting. It moves through a lifecycle, and each

  stage exists for a reason — usually a control reason.

 

  It begins as unposted, sometimes thought of as a draft or saved-but-not-posted entry. At this stage the journal

  exists, it can be edited, lines can be added or corrected, and crucially it has not yet affected account balances.

  Saving without posting is how an accountant parks work in progress, or prepares an entry for review before it becomes

  real.

 

  If approval is configured, the journal then enters an approval stage. The preparer submits it, and it routes to one or

  more approvers according to the rules set up for the ledger or the organization. Until it is approved, it cannot

  post. This is the segregation-of-duties control at the heart of manual journals: the person who prepares an adjustment

  is often not the person allowed to bless it as final. More on approvals shortly, because they are central.

 

  Once approved — or immediately, if no approval is required — the journal can be posted. Posting is the decisive act.

  It is the moment the journal's debits and credits actually update account balances, the moment the entry becomes part

  of the official record of the period. Before posting, the journal is a proposal; after posting, it is accounting.

  Posting can be done manually by a user clicking post, or automatically by a scheduled AutoPost process that sweeps up

  eligible journals on a schedule and posts them in bulk, which is invaluable at a busy close when hundreds of journals

  need posting.

 

  A posted journal in an open period can still be addressed if it was wrong, but not by editing it freely — posted

  entries are largely locked to preserve the integrity of the record. The proper remedy is reversal: you create an

  offsetting journal that backs out the original, then enter a corrected one. This preserves a clean audit trail,

  showing both the mistake and its correction, rather than silently overwriting history.

 

  Finally, periods themselves move through states — open, closed, and so on — and a journal can only post into an open

  period. Once a period is closed, no more journals can post to it; entries belong to the next open period instead. This

  period-status control is what makes a close a real close: at some point the door shuts and the numbers are fixed.

 

  Posting, balancing, and what the system enforces

 

  It is worth dwelling on what the system insists upon when you post, because these enforced rules are the guardrails

  that keep the ledger trustworthy.

 

  The journal must balance, debits to credits, and balance within each balancing-segment value. If it does not, posting

  fails or balancing lines are generated, depending on setup. There is no way to post a one-sided entry; double-entry is

  not optional.

 

  The period must be open for the journal's accounting date. Post attempts into a closed period are rejected.

 

  The account combinations must be valid — they must obey cross-validation rules and must not use disabled values or

  summary accounts that disallow direct posting. An entry to a nonexistent or forbidden combination cannot post.

 

  If a suspense account is configured and a journal is somehow out of balance in a way the system is set to tolerate,

  the difference may post to suspense rather than failing — but this is a deliberately-configured safety valve, not

  normal practice, and a balance sitting in suspense is a signal that something needs investigation.

 

  These enforced rules are why manual journals, despite being hand-entered, cannot easily corrupt the ledger. The human

  supplies the judgment about what to record; the system enforces the arithmetic and structural integrity of how it is

  recorded.

 

  Approvals and controls

 

  Approvals deserve a section of their own because they are the primary control surface on manual journals and a

  frequent topic in implementations.

 

  Fusion routes journal approvals through a configurable workflow. The rules can be as simple or as elaborate as the

  organization needs. A common pattern routes journals above a certain monetary threshold to a manager, and very large

  ones to a more senior approver, while small routine entries might require only a single approval or none. Rules can

  also key off the journal category, the source, the ledger, or the balancing segment, so that, for instance,

  intercompany adjustments route differently from ordinary accruals.

 

  The reason this matters so much is segregation of duties. Manual journals are, by their nature, the place where a

  person can move money between accounts on their own say-so. Without approval controls, that is a fraud and error risk.

  With them, every significant manual entry has a second set of eyes attesting that it is appropriate before it touches

  the balances. Auditors care intensely about this control, and a consultant configuring manual journals has to design

  the approval rules to satisfy both the organization's risk appetite and its auditors' expectations.

 

  Alongside approvals sit other controls. Document sequencing can assign a gapless number to journals for legal

  jurisdictions that require it. Period close discipline ensures journals stop posting once a period is shut. Security

  and data access sets ensure a user can only create and post journals for the ledgers and balancing-segment values they

  are authorized to touch. All of these wrap around the manual journal to make it safe.

 

  The special breeds of manual journal

 

  Beyond the plain one-off entry, Fusion supports several specialized kinds of journal that automate recurring patterns

  of manual accounting. Knowing these well is part of being genuinely useful, because they save accountants enormous

  amounts of repetitive effort.

 

  Reversing journals. Many manual entries are meant to be temporary. An accrual booked at month-end for an expense not

  yet invoiced should be reversed at the start of the next month, so the eventual real invoice does not double-count.

  Rather than remembering to manually back out every such entry, you mark the original journal to reverse, specify the

  reversal period and method, and the system generates the offsetting entry for you. You can reverse manually when

  ready, or set categories to AutoReverse so that reversals are generated and even posted automatically at the start of

  the next period. This is the standard way accruals and provisions are handled, and getting clients to use it instead

  of hand-reversing everything is a real efficiency win.

 

  Recurring journals. Some manual entries repeat every period with the same or formula-driven amounts — a fixed monthly

  rent accrual, a standard allocation, an amortization that follows a formula. Recurring journals let you define the

  entry once as a template, with either fixed amounts, formula-based amounts that reference account balances, or

  skeleton entries where only the accounts are fixed and the amounts are filled in each period. You then generate the

  journal each period from the template rather than rebuilding it. This turns a recurring manual chore into a one-click

  generation, and it reduces error because the structure is defined once and reused.

 

  Allocation journals. Closely related, Fusion's allocation capability — through the Calculation Manager and allocation

  rules — lets you spread costs across cost centers or entities according to defined bases, generating the resulting

  journals automatically. While this edges beyond "manual" into automated allocation, the entries it produces are

  journals that flow into the GL and are often reviewed and posted like manual ones. Many organizations replace armies

  of hand-entered allocation journals with defined allocation rules.

 

  Statistical journals. Not every journal records money. Sometimes you need to record a quantity — headcount, square

  footage, units produced — to use as a basis for allocations or for statistical reporting. A statistical journal

  records these non-monetary amounts using a statistical unit of measure, against accounts enabled to hold statistical

  balances. You can also record statistical amounts alongside monetary ones in the same line. These are essential for

  activity-based allocations and for management metrics that live in the ledger.

 

  Clearing and intercompany journals. Manual journals are often the tool for clearing suspense or interface accounts and

  for recording intercompany transactions that the automated intercompany flows do not cover. When a journal crosses

  balancing-segment values, the automatic balancing-line mechanism keeps each entity in balance, which is exactly the

  intercompany machinery doing its job on a manual entry.

 

  Each of these breeds exists to take a recurring pattern of manual work and make it repeatable, controlled, and less

  error-prone. A consultant who only teaches the plain Create Journal page is leaving most of the value on the table.

 

  A worked example in words

 

  Let me walk a typical month-end accrual through the whole lifecycle, because seeing one entry travel end to end ties

  the concepts together.

 

  It is the last day of the month. An accountant knows the company consumed consulting services during the month but the

  supplier has not yet sent an invoice, so nothing has flowed through Payables. To state the period's expenses

  correctly, she needs to accrue the cost.

 

  She opens the Create Journal page — or, because she does this every month, she generates it from a recurring journal

  template or builds it in the spreadsheet. She enters a journal in the corporate ledger, dated the last day of the

  month, with the category Accrual and source Manual. She adds two lines: a debit to the consulting-expense account for

  the right cost center and company, and a credit to an accrued-liabilities account for the same company. The page shows

  debits equal to credits; the entry balances within the balancing segment. Because this is a temporary entry that must

  not double-count when the real invoice arrives, she marks the journal to reverse in the first period of next month.

 

  She saves it. It now exists as an unposted journal, affecting nothing yet. Because the amount exceeds the approval

  threshold, submitting it routes the journal to her manager for approval. The manager reviews the accounts and amount,

  agrees it is a reasonable accrual, and approves.

 

  Now eligible, the journal posts — either when she clicks post or when the scheduled AutoPost run sweeps it up. At that

  moment the expense account and the accrued-liability account balances update, and the period's financial statements

  reflect the consulting cost even though no invoice exists. The accrual has done its job.

 

  Early next month, the reversal she set up generates automatically — or she generates it — creating an

  equal-and-opposite entry dated in the new period that backs the accrual out. Later that month, the supplier's real

  invoice arrives, flows through Payables, and posts the genuine expense. Because the accrual was reversed, there is no

  double-count: the accrual recognized the cost in the right month, the reversal cleared it, and the real invoice

  recorded it once. The audit trail shows every step plainly — accrual, approval, posting, reversal, real invoice —

  which is exactly what an auditor wants to see.

 

  That single example exercises nearly the whole manual-journal apparatus: batch and journal and lines, category and

  source, balancing, save and approval and posting, AutoPost, reversal, and the interplay with the subledger. It is the

  kind of story worth being able to tell, because it shows you understand not just the buttons but the accounting

  purpose behind them.

 

  Common pitfalls

 

  A handful of mistakes come up repeatedly with manual journals, and naming them is more useful than abstract caution.

 

  The first is forgetting to post. A saved-but-unposted journal looks done to the person who entered it but has changed

  nothing in the balances. At close, a stack of unposted journals is a classic reason the numbers do not look right, and

  chasing them down is a standard close-troubleshooting step.

 

  The second is posting to the wrong period. The accounting date determines the period, and an entry dated in the wrong

  month lands in the wrong period's results. People sometimes carry yesterday's date into a new month, or fail to notice

  the open period has rolled. Watching the accounting date is a basic discipline.

 

  The third is hand-reversing instead of using the reversal feature. Manually keying offsetting entries works but is

  error-prone and clutters the record; the built-in reversal is cleaner, traceable, and can be automated. Teaching

  clients to mark journals for reversal rather than re-keying them is a frequent improvement.

 

  The fourth is inconsistent or lazy categorization, where every manual entry is dumped under a generic category,

  robbing reviewers and auditors of the ability to see at a glance what kinds of adjustments happened. A little

  discipline in choosing meaningful categories pays back many times over at review time.

 

  The fifth is bypassing approvals through over-broad access, where users are granted the ability to both prepare and

  post large journals without a second reviewer. This is a control weakness auditors will flag, and the fix is in the

  approval rules and the access design, not in the journals themselves.

 

  The sixth is leaving balances in suspense. If a suspense account is catching out-of-balance differences, those are not

  resolved — they are parked, and a balance sitting in suspense is a flag that something needs investigation, not a

  problem solved.

 

  The seventh is editing imported or subledger journals expecting it to flow back. Journals that originated in a

  subledger reflect subledger transactions; correcting the GL copy does not fix the subledger, and the right correction

  usually belongs upstream or in a clearly-labelled GL adjustment. Knowing which journals are safe to touch in the GL

  and which need fixing at their source is part of the craft.

 

  Explaining it to a client

 

  When you teach manual journals to a finance team, the framing that lands is purpose-first, mechanics-second. Start

  with why: manual journals are how human judgment enters the ledger directly — accruals, corrections,

  reclassifications, the things no subledger will generate on its own. Then explain the lifecycle as a series of

  controls, not obstacles: you draft, someone reviews, it posts, and if it is wrong you reverse rather than overwrite,

  because the record has to be honest about what happened and when.

 

  Show them the choices of entry method — online for the small and occasional, spreadsheet for the large and the

  repetitive, import for the bulk — and let them match their real entries to the right tool, because that alone often

  transforms how long their close takes. Introduce the special breeds — reversing accruals, recurring templates,

  statistical journals — as labour-savers for the patterns they already do by hand every month. And be candid about the

  controls: approvals and segregation of duties exist because manual journals are where risk concentrates, and the

  auditors will look here first.

 

  Walk them through one concrete entry, like the consulting accrual above, end to end. Nothing makes the abstractions

  concrete like following a single real journal from draft to reversal.

 

  Pulling it together

 

  The manual journal in Oracle Fusion General Ledger is the deliberate, hand-made entry that complements the automatic

  flood of subledger accounting. It is structured as a batch holding journals holding balanced lines, classified by

  source and category, entered online or through a spreadsheet or by import, and moved through a controlled lifecycle of

  draft, approval, and posting — with reversal as the honest remedy for mistakes and period status as the door that

  eventually closes on each month. Around it sit the special breeds — reversing, recurring, allocation, and statistical

  journals — that turn repetitive manual patterns into repeatable, controlled processes, and around all of it sit the

  controls — approvals, segregation of duties, security, document sequencing — that make hand-entered accounting safe

  enough to trust.

 

  A consultant who understands manual journals deeply does more than show a client which button to click. They help the

  organization decide what belongs in a manual journal versus upstream in a subledger, match each kind of entry to the

  most efficient entry method, automate the recurring patterns, classify entries so the close is legible, and design the

  approval controls so the whole thing satisfies both the business and its auditors. That is the difference between

  knowing the screen and knowing the work, and the manual journal — small in volume, large in importance — is one of the

  clearest places that difference shows.

 


 

Comments

Popular posts from this blog

Revaluation

  Revaluation Revaluation in Oracle Fusion Financials   What problem revaluation actually solves   Let me start with the situation that creates the need, because revaluation makes no sense until you feel the problem   it fixes. Your ledger runs in US dollars. Back in October you booked a supplier invoice for 100,000 euros, and on that   day the rate was 1 EUR = 1.10 USD, so the invoice sat in your books at 110,000 dollars. Fast forward to the end of   December. You still haven't paid that euro supplier — the payable is open — and now the rate has moved to 1 EUR = 1.20   USD. That same 100,000-euro obligation is, in dollar terms, now worth 120,000 dollars. You owe 10,000 dollars more   than your books currently say, purely because the exchange rate moved.     Your December 31 balance sheet still shows that payable at the old 110,000. That's wrong. As at the reporting date,   the dollar value of a 100,000-euro li...

Roll Up Group

  Roll Up Group Rollup Groups in Oracle Fusion Financials   You can't understand rollup groups without first understanding the chart of accounts hierarchy   Let me be upfront about something: rollup groups are not a standalone feature you can grasp in isolation. They live   inside the larger machinery of the chart of accounts, parent values, and account hierarchies, and if you try to   explain them without that context you end up reciting a definition nobody can actually use. So I'm going to build the   foundation first, and then the rollup group will click into place as the small but useful piece it actually is.     Start with the chart of accounts. In Oracle Fusion, your chart of accounts is a key flexfield made up of segments —   Company, Cost Center, Account, and so on, whatever your design calls for. Each segment draws its allowable values from   a value set. The Account segment's value set, for instance, holds a...

Reporting Currency

  Reporting Currency     Reporting Currency in Oracle Fusion Financials   Starting with the need, not the feature   Let me open with the business situation that makes someone reach for a reporting currency, because the feature only   makes sense once you feel the problem. Picture a French subsidiary that keeps its books in euros — that's its   functional currency, the currency it pays salaries and suppliers in, the currency its local statutory accounts are   filed in. Perfectly sensible. But the group it belongs to reports in US dollars, and head office wants to see this   subsidiary's numbers in dollars on an ongoing basis, not just as a one-off calculation at year end. Or flip it: a   company operates primarily in dollars, but local regulators in a particular country demand that a parallel set of   records also be kept in the local currency. Either way, the requirement is the same shape — you need to see and ...