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.
| What it counts | The number of GL journal batches and headers whose posting status resolves to error rather than posted or unposted. In standard Oracle Fusion terms these are journals that failed the posting program (Post Journals / Create Accounting) with a validation rejection: invalid account combination, disabled segment value, unbalanced entered or accounted amounts, posting into a closed or never-opened period, or a cross-validation / security rule block. Spans every journal source (Manual, Spreadsheet, Receivables, Payables, Inventory, Subledger Accounting) across every Business Unit and Ledger the connected role can see. |
| Why journals land in error | The most common trigger on a commerce-connected ledger is a Chart of Accounts change: a new natural-account segment value added during a fiscal-year setup, or a cost-centre disabled by the GL team, that breaks combinations the AutoInvoice or Create Accounting programs were about to post. Out-of-balance manual journals, period-status mismatches, and cross-validation rule additions are the next most common. |
| What it does NOT count | Journals that posted cleanly (posted_flag = 'Y'), and journals merely sitting unposted but valid (those appear on the Open (Unposted) Journals card). An error journal is specifically one Oracle tried to post and bounced. |
| Business Unit scope | Respects the dashboard’s selected Business Unit and Ledger filter. By default rolls up every Business Unit and primary Ledger the connected role can see. |
| Time window | RT (real-time, current ledger state) |
| Alert trigger | >0 - any journal in error fires the alert, because a healthy ledger has none |
| Roles | owner, finance, engineering |
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.| Source of the error journals | Count | Underlying cause |
|---|---|---|
| Receivables (AutoInvoice via Subledger Accounting) | 11 | Posting to the retired cost-centre still mapped on active customer sites |
| Inventory (Create Accounting) | 4 | New product-line natural account not yet added to a cross-validation rule |
| Manual (Spreadsheet upload) | 2 | Out-of-balance journal, entered debits did not equal entered credits |
| Payables | 1 | Posting attempted into a period that had just been closed |
| Total Journals in Error | 18 |
- 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.| Card | Why pair it with Journals in Error |
|---|---|
| Open (Unposted) Journals | Valid journals waiting to post. Error journals are a subset of the close problem; unposted journals are the rest. Read together for the full posting backlog. |
| Subledger-to-GL Posting Interface Errors (24h) | The subledger side of the same failure. Many error journals originate as Create Accounting failures in Receivables, Payables, or Inventory before they ever reach the GL. |
| Journals by Source (JeSource) | Tells you which source the error journals came from, so you know whether to chase the integration, the close team, or a manual uploader. |
| GL Period Close Status | Error journals block a clean close. Watch both as period-end approaches. |
| Manual JEs as % of Total | High manual volume is the breeding ground for out-of-balance error journals. |
| Oracle Fusion Health Score | The roll-up that this card feeds into. A non-zero error count drags the composite health score. |
| Revenue Booked into GL | The number that understates while Receivables journals sit in error. |
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.
| Reason | Direction | Why |
|---|---|---|
| Business Unit / Ledger scope mismatch | Either | The card rolls up every Business Unit and Ledger the role can see; an Oracle query scoped to one ledger shows fewer. Always match the dashboard filter. |
| Sync window | Card lower | The card refreshes on its sync cadence; a journal that errored in the last few minutes appears in Oracle’s live UI first. It lands on the card at the next sync. |
| Subledger vs GL boundary | Card lower | Create Accounting failures that never produced a GL journal are counted on the subledger card, not here. Oracle’s Manage Journals view also excludes them. |
| Cleared between snapshots | Card higher | If your team clears an error journal in Oracle right after the card’s last sync, the card still shows it until the next refresh. |
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.