Journal Approval

Journal Approval

Journal Approval in Oracle Fusion Financials — The Second Set of Eyes Before Money Moves

Here's a principle that sits at the heart of financial control, and it's almost embarrassingly simple: the person who

  creates a transaction shouldn't be the only person who decides it's valid. Someone else should look. That's it. That's

  the whole idea behind journal approval — a second set of eyes on an entry before it's allowed to hit the ledger and

  affect the numbers everyone relies on.

 

  It sounds obvious, but it's the foundation of a huge amount of how finance protects itself. Fraud, error,

  misclassification, the honest mistake made at 11pm during a brutal close — a great many of these get caught simply

  because the system insists that somebody other than the preparer reviews and approves the entry before it posts.

  Journal approval is where that insistence lives in Oracle Fusion. It's the workflow that takes a journal someone has

  created and routes it to the right reviewer, holds it until they sign off, and only then lets it proceed to posting.

 

  But — and this is the part that makes it interesting to actually work on — approval is a balancing act. Too little

  approval and you've got a control gap; entries flow to the ledger with nobody checking them. Too much approval and

  you've strangled your own close; every trivial entry sits in a queue waiting for a manager who's in meetings all day,

  and the month-end grinds to a halt while people chase signatures. The art of designing journal approval is finding the

  line where you get meaningful control without crippling the process. Let me walk through it the way I'd explain it on

  a project — what it is, how it works, how you design the rules, where the traps are, and how to keep it healthy.

 

  What journal approval actually does

 

  When a journal is created — typically a manual journal, since that's where human judgment and human error live —

  journal approval intercepts it before posting and routes it through a workflow. The journal goes into a

  pending-approval state. It can't post yet. It sits there until the designated approver (or approvers) reviews it and

  either approves it, in which case it can proceed to posting, or rejects it, in which case it goes back to the preparer

  to fix or withdraw.

 

  So approval inserts a deliberate checkpoint into the journal lifecycle. Recall the lifecycle: a journal is created

  (unposted), it gets validated and balanced, and eventually it posts to affect balances. Approval sits between creation

  and posting. It's the gate. Nothing gets through to the ledger without passing it, when approval is required for that

  journal.

 

  The crucial phrase there is "when approval is required," because not every journal needs approval, and deciding which

  ones do is the core design question. This is where the Source comes back into the picture. As I've discussed in the

  context of journal Sources, you typically don't want every single journal going through approval — that would include

  the enormous volume of journals flowing in automatically from the subledgers, which have already been controlled

  upstream in Payables, Receivables, and so on. Forcing those through GL approval would be pointless friction. Instead,

  approval is usually targeted at the journals that genuinely carry risk — manual entries, top-side adjustments, the

  things a human keyed directly into the GL. The Source is one of the primary levers for drawing that line: require

  approval for Manual and Spreadsheet sources, skip it for trusted subledger sources.

 

  How approval is switched on and scoped

 

  There are a couple of layers to where approval requirements get set, and understanding them helps you reason about why

  a particular journal did or didn't route for approval.

 

  At one level, there's a setting that governs whether journal approval is enabled at all for a ledger — a master

  switch, in effect. If approval isn't enabled, journals just post without any workflow. So the first thing to confirm

  when approval isn't behaving as expected is whether it's actually turned on for the ledger in question.

 

  At another level, the Source carries a "require approval" characteristic, as I mentioned when discussing Sources. This

  lets you say, per source, whether journals from that origin should go through approval. So you can have approval

  enabled for the ledger but configured so that only certain sources actually trigger it. This source-level control is

  one of the cleanest ways to express the basic policy of "scrutinize manual, trust the subledgers."

 

  And then, layered on top of all that, there's the approval workflow itself — the rules that decide, for a journal that

  does require approval, who approves it and how the routing works. This is the rich part, and it's built in Fusion's

  workflow/approvals engine (the BPM-based approval management that underlies Fusion's workflows generally). This is

  where you express rules like "route to the cost center manager," "escalate above a certain amount," "send high-value

  entries to the controller," and so on. The setup for these rules is done through the approvals configuration —

  managing the journal approval rules in the relevant setup area — and it's where most of the design effort goes.

 

  So the picture is: a master enablement, a source-level requirement that decides which journals are in scope, and a

  workflow rule set that decides how the in-scope ones get routed and to whom. Get those three layers straight and the

  behavior stops being mysterious.

 

  Designing the routing rules — where the real work is

 

  The heart of journal approval design is the routing rules: for a journal that needs approval, who has to approve it,

  and under what conditions? Fusion's approval engine is flexible enough to express quite sophisticated policies, and

  the skill is in matching the rules to the organization's actual control needs without over-engineering.

 

  A few of the common dimensions you build rules around:

 

  Amount thresholds. This is probably the most common and most sensible. The idea is that scrutiny should scale with

  materiality. A small entry might need only a single approval from an immediate supervisor; a large one might need to

  go up the chain to a senior finance manager or controller; a very large one might need multiple approvals or sign-off

  from someone quite senior. So you build rules that say, in effect, "if the journal is under this amount, one level of

  approval; if it's between this and that, route higher; if it's above this, route to the top." This concentrates the

  heavy scrutiny on the entries that actually matter while letting routine small entries clear with minimal friction.

  It's one of the most effective ways to balance control against speed — you're not making everyone chase the controller

  for a hundred-dollar reclass, but the million-dollar adjustment definitely gets serious eyes.

 

  Organizational hierarchy / supervisory routing. Approvals often route up a management chain — the journal goes to the

  preparer's manager, and potentially up further levels depending on amount or other factors. Fusion can route based on

  a supervisory hierarchy, so the approval follows the org structure. This is intuitive and maps to how organizations

  actually think about authority. The number of levels it climbs can be tied to the amount or other attributes.

 

  Account or cost center ownership. Sometimes you want the journal to be approved by whoever owns the accounts or cost

  centers it affects, rather than (or in addition to) the preparer's own manager. A journal hitting a particular

  department's costs might route to that department's manager for approval, because they're the one who should be

  confirming the charge is legitimate. Routing based on the accounts involved supports this kind of ownership-based

  control.

 

  Source and category. As discussed, the source determines whether approval is needed at all, and you can also use

  source and category to differentiate routing — perhaps certain categories of entry warrant different or additional

  scrutiny.

 

  Other attributes. Depending on the sophistication required, rules can consider various journal attributes to make

  routing decisions. The engine is capable; the discipline is in not building something so elaborate that nobody can

  understand or maintain it.

 

  A key concept in the routing is the notion of approval levels or a chain — a journal might need to pass through more

  than one approver in sequence, climbing levels until it reaches someone with sufficient authority for its amount. The

  rules define how high it has to climb. So a journal isn't necessarily approved by one person; it might need a chain of

  approvals, with the length of the chain driven by materiality.

 

  The trap of over-engineering

 

  I want to dwell on a failure mode I see constantly, because it's where well-intentioned design goes wrong: making the

  approval rules too complicated.

 

  It's tempting, when you have a flexible engine, to encode every nuance of the organization's authority structure into

  the rules — every threshold, every special case, every exception, multiple parallel approvers, elaborate conditional

  routing. And you can. But every layer of complexity you add is a layer that has to be maintained, understood, and

  explained, and that can break or behave unexpectedly. Worse, overly complex approval rules tend to produce friction

  and confusion in practice — journals route to unexpected places, approvers don't understand why something landed in

  their queue, entries get stuck, and the close slows down while people figure out what's happening.

 

  The best journal approval designs I've seen are surprisingly simple. They capture the genuinely important control

  distinctions — manual versus subledger, a couple of amount thresholds, routing up the management chain — and stop

  there. They resist the urge to encode every conceivable scenario. Because here's the reality: a control that's simple

  enough for everyone to understand and that runs reliably provides more actual assurance than a baroque one that's

  technically more "complete" but that nobody fully understands and that periodically misbehaves. Simplicity is itself a

  control virtue. When the approval flow is comprehensible, approvers know what they're approving and why, preparers

  know where their entries will go, and the whole thing runs smoothly. When it's a labyrinth, people lose confidence in

  it and start working around it, which defeats the purpose entirely.

 

  So my standing advice on approval design is: start simple, capture the essential distinctions, and only add complexity

  when there's a concrete, justified need that the simple design genuinely can't handle. Resist complexity for its own

  sake. The goal is meaningful control that people understand and that doesn't strangle the close — not the most

  elaborate rule set you can build.

 

  The approver's experience and notifications

 

  For approval to work in practice, the people approving need to actually know they have something to approve, and they

  need to be able to act on it easily. Fusion handles this through notifications and worklist items. When a journal

  routes for approval, the approver gets notified — through their notifications/worklist in the application, and

  typically by email as well — and they can review the journal and approve or reject it, often directly from the

  notification.

 

  This experience matters more than people realize for the speed of the close. If approvers don't see their

  notifications promptly, or find the review cumbersome, journals sit in queues and the close drags. So part of making

  approval work is making sure approvers are responsive and that the notification mechanism is reaching them. The

  ability to approve from an email notification, for instance, removes friction and speeds things up, because the

  approver doesn't have to log in and navigate to act.

 

  There's also the question of what happens when an approver is unavailable — on vacation, off sick, or simply

  unresponsive. This is a real operational issue, because an approver who's out can become a bottleneck that holds up

  the close. Fusion's approval framework supports mechanisms to handle this — delegation (the approver hands their

  approvals to someone else for a period) and escalation (if an approval sits too long without action, it escalates to

  someone else or up the chain). Configuring sensible delegation and escalation, and making sure people use vacation

  delegation when they're away, is part of keeping approval from becoming a chokepoint. An approval process with no

  backstop for absent approvers will inevitably stall at the worst possible time — during a close when someone key is on

  leave.

 

  Rejection, resubmission, and the feedback loop

 

  Approval isn't only about saying yes. When an approver sees a problem — wrong account, wrong amount, insufficient

  explanation, a charge they don't recognize — they reject the journal, ideally with a comment explaining why. The

  journal goes back to the preparer, who can correct it and resubmit, or withdraw it. This feedback loop is where

  approval delivers a lot of its value: it's not just a rubber stamp, it's a genuine review that catches problems and

  sends them back to be fixed before they ever hit the ledger.

 

  For this loop to work well, two things matter. First, approvers need enough information to review meaningfully — which

  is why good descriptions and attachments on journals are so valuable. An approver staring at a bare entry with no

  explanation can't really review it; they can only rubber-stamp or reject blindly. A journal with a clear description

  and supporting documentation attached lets the approver actually assess it. So good preparer discipline (clear

  descriptions, attached support) and good approval are two halves of the same coin. Second, rejection comments need to

  be clear, so the preparer knows what to fix rather than guessing. A rejection with no explanation just creates a

  frustrating back-and-forth.

 

  The quality of the review is, honestly, the thing that determines whether approval is a real control or theater. An

  approval process where approvers genuinely scrutinize entries catches problems. One where approvers reflexively

  approve everything because they're busy and trust the preparer provides the appearance of control without the

  substance. This is a human and cultural issue as much as a configuration one — the system can route the journal to the

  right person, but it can't make that person actually look. Part of a consultant's job, and finance leadership's job,

  is fostering a culture where approval is taken seriously and approvers understand they're accountable for what they

  approve.

 

  Practical scenarios from the field

 

  Let me ground this with situations that actually come up.

 

  The over-engineered rules that nobody understood. A client came to me frustrated that their journal approval was a

  constant source of confusion — entries routed to unexpected people, things got stuck, and the close was suffering.

  When I looked at the rules, they'd built an enormously complex set of conditions trying to capture every nuance of

  their authority matrix, with multiple thresholds, parallel approvers, and elaborate special cases. Nobody fully

  understood it, including the people who'd built it. We tore it down and rebuilt a much simpler design: manual journals

  require approval (subledger ones don't), with two amount thresholds driving how far up the management chain the entry

  climbs. Suddenly everyone understood it, journals routed predictably, and the close sped up. The control was actually

  better because it was comprehensible and reliable. The lesson I keep relearning: simpler approval design usually

  beats elaborate design.

 

  The close that stalled on a vacationing approver. A client hit a wall during month-end because a key approver was on

  vacation and a stack of journals was sitting in their queue with nobody able to act. They hadn't set up delegation, so

  the entries just languished. We got it unstuck and then put in place a discipline: approvers set vacation delegation

  before they go away, and escalation rules kick in if an approval sits too long. The lesson: design for absent

  approvers from the start, because someone will always be out during a close, and an approval process with no backstop

  becomes a bottleneck at exactly the wrong moment.

 

  The rubber-stamp culture. At one client, approval was configured fine, but in practice the approvers approved

  everything within seconds without really looking, because they were swamped and trusted their teams. Then an error

  slipped through — a misclassified entry that a real review would have caught — and it caused a reporting problem. The

  fix wasn't technical; it was cultural and procedural. We worked on making approval meaningful: ensuring journals had

  proper descriptions and attachments so review was actually possible, and reinforcing with finance leadership that

  approvers are accountable for what they sign off. The lesson: approval is only a real control if the review is real.

  Configuration routes the journal; it can't make anyone actually scrutinize it.

 

  The threshold that was set too low. A client had set their approval thresholds so low that virtually every entry,

  however trivial, required senior approval. The result was a flood of tiny entries clogging the controller's queue,

  which both wasted the controller's time and meant the genuinely important entries didn't get the focused attention

  they deserved because they were buried in noise. We raised the thresholds so that small routine entries cleared with

  light approval and the heavy scrutiny concentrated on material entries. The lesson: thresholds should match

  materiality, so attention goes where it matters and the process isn't drowned in trivia.

 

  Common misunderstandings worth clearing up

 

  A few recurring confusions, addressed directly.

 

  "All journals go through approval." Usually not, and usually shouldn't. Subledger-sourced journals are typically

  excluded because they're controlled upstream; approval is targeted at manual and other risk-carrying entries. The

  Source is the main lever for deciding what's in scope. Forcing everything through approval is pointless friction.

 

  "Approval happens after posting." No. Approval sits between creation and posting. A journal requiring approval can't

  post until it's approved. It's a gate before the ledger, not a review after the fact.

 

  "More approval rules mean better control." Often the opposite. Over-engineered rules create confusion, friction, and

  unexpected behavior, and a control nobody understands provides less real assurance than a simple, reliable one.

  Simplicity is a control virtue. Start simple and add complexity only when genuinely justified.

 

  "Approval is just a formality." It's only as good as the review behind it. Reflexive rubber-stamping provides the

  appearance of control without the substance. Real scrutiny — enabled by good descriptions and attachments and a

  culture of accountability — is what makes approval an actual control.

 

  "If an approver is out, the journal just waits." That's the failure mode you want to avoid. Use delegation and

  escalation so absent approvers don't become bottlenecks during the close. Design for absence from the start.

 

  "Thresholds don't matter much." They matter a lot. Set too low, they drown the process and senior approvers in trivia;

  set sensibly, they concentrate scrutiny on material entries and let routine ones clear easily. Match thresholds to

  materiality.

 

  Setting up and governing journal approval well — a checklist from experience

 

  If you're implementing Fusion GL or tightening up a client's approval process, here's roughly how I'd approach it.

 

  First, confirm the basics: is journal approval enabled for the ledger, and which sources are configured to require it?

  Scope approval to the journals that genuinely carry risk — manual and spreadsheet entries — and exclude the trusted

  subledger sources that are controlled upstream.

 

  Second, design the routing rules to be as simple as they can be while capturing the essential control distinctions.

  Use a small number of amount thresholds to scale scrutiny with materiality, route up the management chain, and

  consider account/cost-center ownership where it genuinely matters. Resist the urge to encode every nuance — start

  simple and add complexity only when there's a concrete, justified need.

 

  Third, set thresholds to match materiality, so routine small entries clear with light approval and senior attention

  concentrates on the entries that actually matter. Don't drown the process in trivia.

 

  Fourth, design for absent approvers from day one. Configure escalation so stalled approvals move along, encourage

  delegation when people are away, and make sure the close doesn't depend on a single person being at their desk.

 

  Fifth, make the approver experience smooth. Ensure notifications reach approvers reliably and that they can review and

  act easily, so journals don't languish in queues and slow the close.

 

  Sixth, reinforce the preparer side: insist on clear descriptions and attached supporting documentation, because

  approval can only be meaningful if the approver has enough information to actually review the entry.

 

  Finally, treat approval as a cultural as well as a technical control. Foster the understanding that approvers are

  accountable for what they sign off and that approval is a genuine review, not a rubber stamp. The system routes the

  journal; the people make it a real control.

 

  Wrapping up

 

  Journal approval is the embodiment of one of the oldest and soundest principles in financial control: the person who

  creates a transaction shouldn't be the only one who decides it's valid. It inserts a deliberate checkpoint into the

  journal lifecycle, sitting between creation and posting, holding a journal until a second set of eyes has reviewed and

  approved it — so that errors, misclassifications, and improper entries get caught before they ever reach the ledger

  and shape the numbers the whole organization relies on.

 

  The mechanics layer up: a master enablement for the ledger, a source-level requirement that decides which journals are

  in scope (manual and spreadsheet entries typically, with trusted subledger journals excluded because they're

  controlled upstream), and a workflow rule set that decides how in-scope journals route and to whom. The routing rules

  are where the design effort lives — amount thresholds that scale scrutiny with materiality, routing up the management

  hierarchy, account or cost-center ownership where it matters. And around all of it sit the practical necessities:

  notifications that actually reach approvers, delegation and escalation so absent approvers don't stall the close, and

  a rejection-and-resubmission loop that turns approval into a genuine feedback mechanism rather than a one-way gate.

 

  But the deepest lesson, the one I keep coming back to, is about balance and simplicity. Journal approval is a

  balancing act between control and speed: too little and you've got a gap, too much and you've strangled your own

  close. And the way you strike that balance well is usually through simplicity — capturing the genuinely important

  control distinctions in rules that everyone understands and that run reliably, rather than building an elaborate

  labyrinth that's technically complete but that nobody comprehends, that misbehaves, and that people eventually work

  around. A simple, comprehensible, reliable approval process provides more real assurance than a baroque one. And no

  amount of clever configuration substitutes for the human reality that approval is only a control if the approver

  actually looks — which depends on good information to review and a culture that takes the responsibility seriously.

 

  For a functional consultant, the message to carry to clients is that journal approval is essential, but its value

  comes from getting the balance right: scope it to what matters, keep the rules simple and understandable, set

  thresholds to concentrate scrutiny where materiality demands, design for the inevitable absent approver, and cultivate

  a culture where approval is a real review. Do that, and journal approval becomes exactly what it's meant to be — a

  smooth, trusted, second set of eyes that catches problems before money moves, without becoming the thing that holds the whole close hostage.