Open (Unposted) Journals, Oracle ERP Cloud

Open (Unposted) Journals counts GL journals created but not yet posted to the General Ledger. A growing backlog delays period close and distorts real-time financial reporting.

Metrics type: Key Metrics • Category: Ecommerce Platform

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

Four things to notice:

1. 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.
2. 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.
3. The alert caught it before period-end. Because the threshold is >50 on 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.
4. 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.

Why our number may legitimately differ from Oracle’s reports:

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.

Known limitations / merchant FAQs

What is the difference between unposted and error journals? An unposted journal is valid and waiting; the posting program has not yet run on it, or it is pending approval. An error journal is one that Oracle tried to post and rejected for a validation failure. Unposted is a queue-depth problem; error is an exception that needs fixing. This card counts the former; the Journals in Error card counts the latter.

Is a small unposted count normal? Yes. Between posting runs there is always a working set of journals created but not yet posted, especially on a busy commerce-connected ledger where Receivables and Payables journals arrive continuously. The card normally sits in a low, stable band. The alert threshold is set above that band so it fires on genuine backlog, not on the normal between-run working set.

Why does an unposted backlog distort real-time reporting? GL balances and every report built on them reflect only posted journals. An unposted journal is real economic activity that is invisible to those reports until it posts. So a large backlog means your Income Statement, Balance Sheet, and flash reports are understated by whatever sits in the queue. The bigger the backlog, the more your real-time numbers lag reality.

What is the most common cause of a sudden backlog? A scheduled Post Journals job that stopped running, often after a credential rotation, a configuration change, or an environment issue. The journals keep arriving from the subledgers but nothing posts them, so the count climbs steadily. Checking the Scheduled Processes history for the last successful Post Journals run is the fastest way to confirm this cause.

Can Vortex IQ post the journals for me? No. Posting journals changes GL balances and is a controlled action that belongs inside Oracle Fusion, under your own approval and posting controls. Vortex IQ detects the backlog, surfaces the likely cause (for example a stalled posting job), and notifies the right roles. Your team runs Post Journals in Oracle.

Does this card help with period close? Directly. An unposted backlog is one of the first blockers a controller must clear before a period can close. Reading this card with GL Period Close Status in the days before period-end gives early warning that the close will stall unless the backlog is cleared.

---

Tracked live in Vortex IQ Nerve Centre

Open (Unposted) Journals is one of hundreds of KPI pulses Vortex IQ tracks across Oracle ERP Cloud and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.

Start for free or book a demo to see this metric running on your own data.