Journals that exist but have not posted to the GL. A rising backlog is a slow leak in your real-time financials.
At a glance
Open (Unposted) Journals is the live count of General Ledger journals that have been created but not yet posted. Unlike error journals, these are valid and waiting; the posting program simply has not run, or they are pending review and approval. Every unposted journal is real revenue, cost, or cash that exists in the system but is not yet reflected in GL balances, so a growing backlog quietly distorts every real-time report you run and, at period-end, blocks a clean close. On a well-run ledger with frequent automated posting this count stays low and stable. A climbing trend is the warning.
| What it counts | The number of GL journal headers with a posting status of unposted across every source (Manual, Spreadsheet, Receivables, Payables, Inventory, Subledger Accounting) and every Business Unit and Ledger the connected role can see. These are journals that passed creation but have not yet been run through Post Journals, or are held pending approval. |
| What it does NOT count | Posted journals (posted_flag = 'Y'), and journals that failed posting and sit in error status (those are on the Journals in Error card). |
| Why a backlog matters | GL balances, the Income Statement, the Balance Sheet, and every OTBI real-time report reflect only posted journals. Unposted journals are invisible to those reports until they post. A large backlog means your real-time financials are understated by whatever is sitting in the queue. |
| What causes a backlog | A paused or failed scheduled Post Journals job, a long approval queue, a flood of subledger journals from a busy commerce period that has outrun the posting cadence, or journals held back during a controls review. |
| 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 | >50 - a backlog above fifty unposted journals warrants attention on most large-enterprise ledgers |
| Roles | owner, finance |
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 large-enterprise B2B distributor runs Oracle ERP Cloud with a scheduled Post Journals job set to run every four hours. The card normally hovers around 15 to 25 unposted journals between posting runs. On 20 Mar 26 the scheduled job failed silently after a credential rotation, and nobody noticed until the card crossed its alert line on 22 Mar 26.| Timestamp | Unposted count | What happened |
|---|---|---|
| 20 Mar 26, 08:00 | 22 | Normal between-run level |
| 20 Mar 26, 12:00 | 41 | Scheduled post job failed to start (credential expired) |
| 21 Mar 26, 09:00 | 58 | Backlog building, alert fired at the 50 line |
| 22 Mar 26, 09:00 | 96 | Two days of Receivables and Payables journals queued |
- The backlog was valid journals, not errors. Nothing was wrong with the journals themselves. The posting program simply stopped running after a credential rotation invalidated the scheduled job. Every one of those 96 journals was ready to post; they just had not been told to.
- For two days the GL understated reality. Revenue, COGS, and supplier costs that the business genuinely incurred were sitting unposted, so the Income Statement and every real-time report were low by the value in the queue. A controller pulling a flash report on 21 Mar 26 would have seen an artificially soft day.
- The alert caught it before period-end. Because the threshold is
>50on a real-time count, the finance and owner roles were notified on 21 Mar 26, two days into the outage but well before the month-end close. Re-running the posting program cleared the backlog in one batch and the card returned to its normal band. - A persistent low-level rise tells a different story. If the count had crept up slowly over weeks rather than spiking, the cause would more likely be posting cadence failing to keep pace with commerce volume, or a clogged approval queue, both of which are process fixes rather than a one-off job failure.
Sibling cards merchants should reference together
Open (Unposted) Journals is the posting-backlog gauge. Read it alongside the cards that explain why the backlog formed and what it blocks.| Card | Why pair it with Open (Unposted) Journals |
|---|---|
| Journals in Error (PostedFlag=E) | The other half of the posting problem. Unposted journals are valid and waiting; error journals were rejected. Together they are the full posting picture. |
| GL Period Close Status | An unposted backlog is one of the first things that blocks a clean close. Watch both as period-end nears. |
| Subledger-to-GL Posting Interface Errors (24h) | When subledger posting stalls, journals pile up unposted. This card shows the upstream failure. |
| Journals by Source (JeSource) | Tells you which source is contributing most to the backlog. |
| Revenue Booked into GL | The number that understates while revenue journals sit unposted. |
| Oracle Fusion Health Score | The composite that a growing posting backlog drags down. |
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 Posting Status = Unposted) Navigator → General Accounting → Period Close → Close Status (unposted journals blocking the close) Scheduled Processes → Post Journals (job history; check the last successful run and any failures)In Manage Journals, set the posting-status filter to Unposted and count the headers; the total should match this card when the Business Unit and Ledger scope are the same. The Scheduled Processes view tells you whether the posting job is running on its cadence, which is the usual root cause of a backlog. Common mistakes when comparing against Oracle’s own reports:
- Confusing unposted with error. Manage Journals lists both. Only journals that have not been posted and are not in error belong on this card. Filter precisely on posting status.
- Ignoring the approval queue. Journals held in an approval workflow show as unposted even though they cannot post until approved. They legitimately count here; check the approval queue if the backlog seems stuck.
- Looking only at one period. A backlog can span multiple open periods. Querying a single period understates the total the card shows.
| Reason | Direction | Why |
|---|---|---|
| Sync window | Either | The card refreshes on its cadence; journals posted or created since the last sync differ from the live Oracle UI until the next refresh. |
| Approval-held journals | Either | Whether you include journals stuck in approval changes the count. The card includes unposted journals regardless of approval state. |
| Multi-period scope | Card higher | The card spans all open periods the role can see; a single-period Oracle query shows fewer. |
| Business Unit / Ledger scope | Either | The card rolls up every Business Unit and Ledger the role can see; a scoped Oracle query shows a narrower count. |