Subledger transactions that failed to reach the GL in the last 24 hours. The break is upstream of the journal, in Create Accounting.
At a glance
Subledger-to-GL Posting Interface Errors is a Fusion-specific count of Receivables, Payables, and Inventory subledger transactions that failed to post through to the General Ledger in the last 24 hours. In Oracle Fusion the path from a subledger transaction to a GL journal runs through Subledger Accounting (SLA) and the Create Accounting program, which applies your accounting rules to each transaction and generates the journal. When Create Accounting hits a dimension or segment validation failure, an invalid account combination, or a rule it cannot resolve, the transaction errors out before a GL journal is ever created. That is what this card catches: the break that happens upstream of the journal stage. Because it is a 24-hour window, it is the freshest possible signal that your commerce-to-GL pipeline has stalled.
| What it counts | The number of subledger accounting events (Receivables, Payables, Inventory / Cost Management) whose Create Accounting run failed in the last 24 hours, leaving the transaction without a posted GL journal. These are SLA-stage failures, distinct from GL-stage posting errors. |
| How it differs from Journals in Error | Journals in Error counts GL journals that already exist and failed the GL posting program. This card counts subledger transactions that failed before a GL journal was even created. Same pipeline, earlier stage. |
| Most common cause | A dimension or segment validation failure in Create Accounting: a Chart of Accounts segment value disabled or not yet added, an account-derivation rule that cannot resolve a combination for a new transaction type, or a cross-validation rule blocking the derived combination. |
| Why the 24h window | This is an operational early-warning pulse. A 24-hour window surfaces a pipeline break the same day it happens, before a full day of commerce revenue and supplier costs 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 | 24H (trailing 24 hours) |
| Alert trigger | >0 - any failure in the subledger-to-GL path is an exception that needs a human |
| 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 a Shopify Plus DTC channel feeding Order Management. Create Accounting is scheduled to run hourly across Receivables, Payables, and Inventory. On 14 Mar 26 the COA team added a new product-channel segment value but did not extend the Subledger Accounting account-derivation rule to cover it. The next Create Accounting run started failing on every transaction that touched the new channel.| Subledger | Failed events (24h) | Underlying cause |
|---|---|---|
| Receivables (AutoInvoice revenue) | 142 | SLA account-derivation rule could not resolve the new channel segment |
| Inventory / Cost Management | 38 | COGS accounting event referencing the same new combination |
| Payables | 6 | Unrelated, supplier site with a disabled cost-centre |
| Total Subledger-to-GL Posting Errors (24h) | 186 |
- No GL journals were created for these 186 events. The failure is at the Create Accounting stage, before journal creation. So these transactions do not even appear on the Journals in Error card yet, which counts existing GL journals. This card is the earliest place the break shows up.
- 142 of them are ecommerce revenue. A full day of DTC revenue on the new product channel did not reach the GL. The Revenue Booked into GL card understates by that amount until the SLA rule is fixed and Create Accounting reprocesses the failed events.
- The fix is an SLA rule change, then a reprocess. The finance team extends the account-derivation rule to map the new channel segment to the correct natural account, then re-runs Create Accounting. The previously failed events now generate valid GL journals, post, and the card returns to zero. No data was lost; it was held at the SLA stage.
- The alert fired at the first failure. With a
>0threshold on a 24-hour window, the owner, finance, and engineering roles were notified within the hour of the first failed Create Accounting run, not at the end of the day when 186 events had accumulated. Engineering is on the role list precisely because the root cause is often a configuration or integration issue, not a pure accounting one.
Sibling cards merchants should reference together
This card is the earliest signal in the posting pipeline. Pair it with the downstream and adjacent cards to trace a break end to end.| Card | Why pair it with Subledger-to-GL Posting Interface Errors |
|---|---|
| Journals in Error (PostedFlag=E) | The next stage. Once subledger events produce journals that still cannot post, they show here. Read the two in sequence. |
| Open (Unposted) Journals | A subledger stall also starves the GL of journals, so the posting backlog picture is incomplete without it. |
| OIC Integration Flow Failures (24h) | If the failure is in the inbound data path rather than SLA, this card shows it. Together they isolate where the break is. |
| Subledger-to-GL Posting Failed (any source) | The broader, source-agnostic view of the same failure class. |
| Revenue Booked into GL | The number that understates while Receivables events sit unaccounted. |
| Oracle Fusion Health Score | The composite that a subledger posting failure drags down hard. |
| Manual JEs as % of Total | When SLA posting breaks, teams hand-key the entries, lifting the manual ratio. |
Reconciling against Oracle ERP Cloud
Where to look in Oracle ERP Cloud: The closest native equivalents in the Oracle Fusion UI are:Scheduled Processes → Create Accounting (review the output and exception report for failed events) Navigator → Receivables → Accounting → Review Journal Entries (and the equivalent under Payables and Cost Management) Reports and Analytics → OTBI → Financials → Subledger Accounting - Journals Real Time (events with an incomplete or error accounting status)The Create Accounting program produces an execution report listing the events it could not account. The count of failed events there, across Receivables, Payables, and Inventory for the last day, should match this card when the Business Unit and Ledger scope are aligned. The exception detail names the precise rule or combination that failed, which is what your team needs to fix. Common mistakes when comparing against Oracle’s own reports:
- Looking in Manage Journals. Failed Create Accounting events do not appear as GL journals, so they are not in the GL journals view. Look at the Create Accounting output and the subledger Review Journal Entries pages instead.
- Counting accounted events as failures. Create Accounting in draft mode produces draft entries that are not yet final; do not confuse a draft run with a failure. Match the card to final-mode failures.
- Wrong subledger scope. The card spans Receivables, Payables, and Inventory. Querying only one subledger understates the total.
| Reason | Direction | Why |
|---|---|---|
| Stage boundary | Card different | The card counts SLA-stage failures, not GL-journal posting errors. Comparing against Manage Journals will not reconcile; compare against Create Accounting output. |
| 24h window vs program run | Either | The trailing 24-hour window may include or exclude a Create Accounting run that an Oracle report bounded by run-id does not. |
| Reprocessed since sync | Card higher | If your team reprocesses failed events right after the card’s last sync, the card still shows them until the next refresh. |
| Subledger scope | Either | The card aggregates across Receivables, Payables, and Inventory; a single-subledger Oracle query shows fewer. |
Known limitations / merchant FAQs
How is this different from Journals in Error? Stage. This card counts subledger transactions whose Create Accounting run failed, so no GL journal was ever created. Journals in Error counts GL journals that already exist and failed the GL posting program. The subledger failure happens first; if you fix it, valid journals are created, and only then could they fail at the GL posting stage. They are two consecutive checkpoints in the same pipeline. Why is this card labelled Fusion-specific? Because the subledger-to-GL path through Subledger Accounting and the Create Accounting program is an Oracle Fusion architecture. The way Fusion separates the subledger event, the SLA accounting rules, and the GL journal is distinct from how other ERPs structure posting. This card maps directly onto that Fusion pipeline, which is why engineering is on the role list: the cause is frequently an SLA configuration or integration issue. What is the single most common cause? A dimension or segment validation failure in Create Accounting. Most often a Chart of Accounts change (a new segment value added, or a cost-centre disabled) that the SLA account-derivation rules were not extended to handle, so the program cannot resolve a valid account combination for the affected transactions. New transaction types from a new sales channel are a frequent trigger because the rules predate the channel. Does a failure here mean the order or invoice is lost? No. The subledger transaction (the Receivables invoice, the Payables bill, the inventory move) still exists in its subledger. Only the accounting step failed. Once the SLA rule is corrected and Create Accounting reprocesses, the events generate valid journals and the GL catches up. Nothing is lost; it is held at the accounting stage. Why is the threshold zero? Because a healthy pipeline accounts every subledger event successfully. A Create Accounting failure is always an exception that a human must resolve, and one configuration break typically cascades into many failed events at once, as the worked example shows. A>0 threshold means the right people hear about it the same hour, not at day-end.
Can Vortex IQ rerun Create Accounting?
No. Running Create Accounting and changing SLA rules are controlled accounting actions that belong inside Oracle Fusion, under your change controls. Vortex IQ detects the failure within the 24-hour window, points at the likely cause, and notifies owner, finance, and engineering. Your team fixes the rule and reprocesses in Oracle.