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 |
- 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).
- 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.
- 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.
- The alert fired at the first rejection. With a
>0threshold 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.
| 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. |