Journals that Oracle Fusion rejected at posting time and that have not made it into the General Ledger.
At a glance
Journals in Error is the live count of General Ledger journals that Oracle Fusion attempted to post and rejected, leaving them in an error state rather than posted. Oracle Fusion rejects a journal when the account combination is invalid, a Chart of Accounts segment value has been disabled, the journal is out of balance, the accounting period is closed, or a cross-validation rule blocks the combination. Each one of these journals is revenue, cost, or cash that exists in your subledgers but has not reached the GL, so it silently understates your real-time financials until someone clears it. The count should sit at zero on a healthy ledger.
Calculation
Calculated automatically from your Oracle ERP Cloud data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US Fortune 500 distribution group runs Oracle ERP Cloud across four Business Units under two primary ledgers (US Distribution Inc in USD, Canada Distribution ULC in CAD). On 14 Mar 26 the GL team added three new natural-account segment values for a product-line reorganisation and disabled an old cost-centre that was being retired. The card was at zero on 13 Mar 26. By the morning of 15 Mar 26 it read 18.
Four things to notice:
- The card flipped from 0 to 18 inside 24 hours of a COA change. This is the classic pattern. The Chart of Accounts edits on 14 Mar 26 were valid in isolation, but they broke account combinations that the AutoInvoice and Create Accounting programs were already queued to post. The disabled cost-centre was still mapped on active customer sites, so every Receivables journal that touched those sites bounced.
- Eleven of eighteen are Receivables journals from the commerce integration. That means roughly two days of ecommerce-driven revenue is sitting in error, not in the GL. Until cleared, the Revenue Booked into GL card understates by that amount, even though the cash and the orders are real.
- The fix is in Oracle, not in Vortex IQ. The finance team reopens the closed period for the Payables item, corrects the cost-centre mapping for the Receivables batch, adds the new natural account to the cross-validation rule for Inventory, and rebalances the manual journal, then re-runs Post Journals. The card returns to zero once every batch posts cleanly.
- The alert fired at the first non-zero reading. Because the threshold is
>0, the owner, finance, and engineering roles were notified the moment the first journal errored, not after a backlog built. That is the point of a real-time GL-health pulse: catch the COA break on day one, not at month-end close when the controller is staring at an unexplained variance.
Sibling cards merchants should reference together
Journals in Error is the sharpest single GL-health signal, but it is most useful read alongside the rest of the posting-pipeline cards.Reconciling against Oracle ERP Cloud
Where to look in Oracle ERP Cloud: The closest native equivalents in the Oracle Fusion UI are:Navigator → General Accounting → Journals → Manage Journals (filter Batch Status / Posting Status to Error) Navigator → General Accounting → Period Close → Close Status (shows journals blocking the close) Reports and Analytics → OTBI → Financials → General Ledger - Journals Real Time (subject area listing journal posting status)In Manage Journals, set the posting-status filter to surface journals that failed posting; the count of those headers should match this card when you select the same Business Unit and Ledger scope. The posting program’s own output log (Scheduled Processes → Post Journals → View Log) lists the precise rejection reason per batch, which is what your finance team needs to clear each one. Common mistakes when comparing against Oracle’s own reports:
- Confusing unposted with error. Manage Journals shows both Unposted (valid, waiting) and Error (rejected) journals. Only the latter belong on this card. Filter on posting status, not batch status alone.
- Forgetting the period filter. A journal can error because its period is closed. If you query a single open period in Oracle but the card spans all open periods and Business Units, the counts diverge legitimately.
- Querying the subledger instead of the GL. A Create Accounting failure in Receivables shows in the subledger accounting events, not yet as a GL journal. That failure belongs on the Subledger-to-GL Posting Interface Errors card, not this one.
Known limitations / merchant FAQs
What is the single most common cause of a sudden spike on this card? A Chart of Accounts change. When the GL team adds a natural-account segment value, disables a cost-centre, or tightens a cross-validation rule, account combinations that the AutoInvoice and Create Accounting programs were about to post can suddenly become invalid. The journals that touch those combinations bounce into error. This is why the card is so often the first sign that a COA edit had downstream effects nobody anticipated. Does an error journal mean the underlying transaction is lost? No. The transaction still exists in the subledger or the journal staging table. The error means it has not reached the GL. Once the cause is fixed (account combination corrected, period reopened, journal rebalanced) and the posting program re-runs, the journal posts and the financials catch up. Nothing is lost, but the GL is understated until then. Why is the alert threshold zero rather than a tolerance band? Because a healthy Oracle Fusion ledger posts every valid journal and holds none in error. Unlike a backlog metric where some queue depth is normal, an error journal is always an exception that a human must resolve. A threshold of>0 reflects that any error is worth a look, especially because a single COA break tends to cascade into many error journals at once.
Can Vortex IQ clear the error journals for me?
No, and deliberately so. Clearing an error journal means changing accounting data: correcting account combinations, reopening periods, rebalancing entries. That is a controlled action that belongs to your finance team inside Oracle Fusion, under your own change controls and segregation of duties. Vortex IQ detects, surfaces the likely cause, and notifies the right roles. The fix happens in Oracle.
How does this differ from the Subledger-to-GL posting errors card?
This card counts journals that already exist as GL journals and failed the GL posting program. The Subledger-to-GL Posting Interface Errors card counts the upstream failure: Receivables, Payables, or Inventory transactions whose Create Accounting run failed before producing a GL journal at all. They are two stages of the same pipeline. A spike on the subledger card today often becomes a spike here once the journals are created but still cannot post.
Why might finance see a number in Oracle that differs from the card by one or two?
Timing. The card refreshes on a sync window, so a journal that errored or was cleared in the minutes since the last sync will differ between the live Oracle UI and the card. The two reconcile at the next refresh. For an exact real-time count, the native Manage Journals view filtered to error status is always live.
Does this card respect the period close?
Yes. A journal attempting to post into a closed period is one of the standard error causes, so it appears here. As period close approaches, this card and the GL Period Close Status card are best read together: error journals are one of the things a controller must clear before the period can be closed cleanly.