Subledger-to-GL Posting Failed (any source), Oracle ERP Cloud

Subledger-to-GL Posting Failed (any source) is a live alert feed that fires when journals are rejected by Oracle Fusion’s strict GL validation in the last hour, blocking subledger transactions from the GL.

Metrics type: Key Metrics • Category: Ecommerce Platform

A live alert feed: journals rejected by Oracle Fusion’s strict GL validation in the last hour. When posting fails, Receivables, Payables, and Inventory transactions are blocked from the GL and real-time financials are wrong.

At a glance

Subledger-to-GL Posting Failed (any source) is a real-time alert feed, not a trend KPI. Oracle Fusion applies strict GL validation at the posting stage, rejecting journals on Chart of Accounts segment problems, disabled values, cross-validation rule violations, or unbalanced lines. When the GL posting program rejects a journal, the underlying Receivables, Payables, or Inventory transaction is held out of the General Ledger, so the numbers the business reads in real time are understated until the journal is fixed and re-posted. This feed is source-agnostic: it catches posting failures regardless of which subledger or journal source produced them. Each row is one failed journal in the trailing hour, so finance and engineering can act on the specific entry that the GL rejected.

What it counts	Each row is one journal in an error / rejected posting state (PostedFlag indicating an error) in the last 1 hour, across every journal source: Receivables, Payables, Inventory / Cost Management, Manual, Spreadsheet, and Subledger. The feed lists the source, the ledger, the period, and the validation error that blocked the post.
What blocks the post	Oracle Fusion’s GL validation: a disabled or invalid Chart of Accounts segment value, a cross-validation rule violation, an account combination that does not exist or is end-dated, or an unbalanced journal. Any of these rejects the journal before it reaches the GL.
Why the 1h window	This is the freshest possible pulse on a posting break. A trailing hour surfaces a stalled pipeline almost immediately, before a meaningful slice of revenue and cost goes unaccounted.
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 alert feed, trailing 1 hour)
Alert trigger	>0 PostedFlag=E in last 1h - any rejected journal raises a feed entry
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 Fortune 500 retailer runs Oracle ERP Cloud with Receivables, Payables, and Inventory subledgers feeding a single US primary ledger. On 14 Mar 26 the COA team end-dated an old cost-centre segment value during a reorganisation but a handful of in-flight transactions still referenced it. Over the next hour the GL posting program rejected every journal that carried the retired combination.

Journal source	Failed journals (1h)	Validation error
Receivables (AutoInvoice revenue)	9	Account combination uses an end-dated cost-centre segment
Inventory / Cost Management	4	Same end-dated combination on COGS entries
Payables	2	Cross-validation rule blocks the derived combination
Total failed posts (1h)	15

Four things to notice:

1. These journals exist but did not post. Unlike a Create Accounting failure, the journals were created and then rejected at the GL posting stage. They sit in an error state, visible in the GL, until corrected. This is the stage after Subledger-to-GL Posting Interface Errors (24h).
2. Nine of them are ecommerce revenue. A slice of DTC revenue is held out of the GL while the combination is invalid. The Revenue Booked into GL card understates by that amount until the journals re-post.
3. The fix is a COA correction, then a re-post. The team either re-enables the segment value for the affected window or reclassifies the journals to a valid combination, then re-runs GL posting. The journals clear and the feed empties. No transaction is lost; it was held at the posting gate.
4. The alert fired at the first rejection. With a >0 threshold on a trailing hour, owner, finance, and engineering were notified within the hour of the first failed post, not after a full day of rejections accumulated. Engineering is on the list because the trigger is frequently a configuration change rather than a pure accounting error.

Sibling cards merchants should reference together

This feed is one checkpoint in the subledger-to-GL pipeline. Pair it with the adjacent stages to trace a break end to end.

Card	Why pair it with Subledger-to-GL Posting Failed
Subledger-to-GL Posting Interface Errors (24h)	The earlier stage. Events that fail Create Accounting never become journals; this feed catches the journals that fail to post.
Journals in Error (PostedFlag=E)	The broader error-state journal view. This feed is its real-time, source-agnostic slice.
Open (Unposted) Journals	Rejected posts add to the unposted backlog until they clear.
Journals by Source (JeSource)	Tells you which source is generating the failures.
Revenue Booked into GL	The headline that understates while Receivables journals sit rejected.
GL Period Close Past Deadline	A period cannot close with rejected journals outstanding, so posting failures slip the close.
Oracle Fusion Health Score	The composite that a posting failure drags down hard.

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 to journals with an error or unposted status) Scheduled Processes → Post Journals (review the execution and exception report for rejected journals) Reports and Analytics → OTBI → Financials → General Ledger - Journals Real Time (journals in error status)

Manage Journals lists journals by posting status; the rejected ones carry the specific validation error that blocked them. The count of error-status journals across all sources for the last hour should match this feed when the Business Unit and Ledger scope are aligned. The exception detail names the combination or rule that failed, which is what your team needs to correct.

Common mistakes when comparing against Oracle’s own reports:

• Confusing this with Create Accounting failures. Those events never produced a journal, so they are not in Manage Journals. This feed counts journals that exist and were rejected at posting. They are consecutive, distinct stages.
• Filtering to one source. The feed is source-agnostic across Receivables, Payables, Inventory, Manual, and Spreadsheet. A single-source query understates.
• Counting unposted-but-valid journals as failures. A journal that is simply not yet posted is not the same as one rejected by validation. Match on error status, not just unposted.

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

Reason	Direction	Why
Stage boundary	Card different	The feed counts journals rejected at GL posting, not events that failed Create Accounting. Comparing against the wrong stage will not reconcile.
1h window vs program run	Either	A trailing hour may include or exclude a Post Journals run that an Oracle report bounded by run-id does not.
Source scope	Either	The feed aggregates across every journal source; a single-source Oracle query shows fewer.
Re-posted since sync	Card higher	If your team corrects and re-posts right after the last sync, the feed still shows the rejection until the next refresh.

Known limitations / merchant FAQs

Is this a trend chart or an alert list? An alert list. Each entry is a journal that Oracle’s GL validation rejected in the last hour. The feed clears row by row as journals are corrected and re-posted. There is no trend number; the target is an empty feed.

How is this different from the Create Accounting errors card? Stage. Subledger-to-GL Posting Interface Errors (24h) counts subledger events that failed before a journal was ever created. This card counts journals that were created and then rejected at the GL posting gate. The Create Accounting failure happens first; if you fix it, valid journals are created, and only then could they be rejected here.

What does “any source” mean? The feed does not care which subledger or journal source produced the journal. Receivables, Payables, Inventory, Manual, and Spreadsheet journals all count. This is deliberate: a posting break can originate anywhere, and you want one feed that catches all of them.

What is the single most common cause? A Chart of Accounts change that left an invalid account combination: a segment value disabled or end-dated, or a cross-validation rule that now blocks a combination that in-flight transactions still reference. New transaction types and reorganisations are frequent triggers.

Does a rejection mean the transaction is lost? No. The journal exists in an error state in the GL, and the underlying subledger transaction still exists. Only posting failed. Once the combination is corrected and the journal re-posts, the GL catches up. Nothing is lost; it is held at the posting gate.

Can Vortex IQ re-post the journal? No. Posting journals and changing the Chart of Accounts are controlled accounting actions inside Oracle Fusion, under your change controls and SOX segregation of duties. Vortex IQ detects the rejection in real time, names the source and the validation error, and notifies owner, finance, and engineering. Your team corrects and re-posts in Oracle.

---

Tracked live in Vortex IQ Nerve Centre

Subledger-to-GL Posting Failed (any source) 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.