The mix of GL journals by source. A Receivables spike is healthy automation; a Manual spike is a controls gap.
At a glance
Journals by Source breaks down every General Ledger journal posted in the window by its journal source: Manual, Receivables, Payables, Inventory, Spreadsheet, Subledger Accounting, and any custom source your implementation defined. The shape of this mix is a quiet but powerful health signal. A ledger dominated by Receivables, Payables, and Inventory journals is one where automation is doing the work. A ledger with a swelling Manual or Spreadsheet slice is one where humans are hand-keying entries the system should be generating, which is exactly what auditors flag and exactly where errors creep in. The card tells you the composition, not just the count.
| What it counts | The count of GL journal headers grouped by journal source over the window. Standard Oracle Fusion sources include Manual, Spreadsheet (ADFdi upload), Receivables, Payables, Cost Management / Inventory, Assets, Payroll, and Subledger Accounting, plus any custom source registered in the GL. The donut shows the proportional split; the underlying tooltip shows the count per source. |
| What a healthy mix looks like | The bulk of journals coming from automated subledger sources (Receivables, Payables, Inventory) via Subledger Accounting. On a commerce-connected ledger, a Receivables-heavy mix is the expected and healthy pattern, because AutoInvoice and Create Accounting are turning ecommerce orders into revenue journals automatically. |
| What a worrying mix looks like | A Manual or Spreadsheet slice that grows period over period. Manual journals are legitimate for accruals, reclasses, and corrections, but a rising manual share signals a controls gap, a broken integration that people are working around by hand, or estimation churn in the close. |
| 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 | 30D (trailing 30 days) |
| Alert trigger | None - this is a diagnostic composition card, read alongside Manual JEs as % of Total which carries the alert |
| 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 consumer-goods company runs Oracle ERP Cloud with a Shopify Plus DTC channel and a B2B Adobe Commerce portal feeding Order Management. The 30-day window is 14 Mar 26 to 12 Apr 26. The controller pulls the source mix.| Journal source | Count | Share | Read |
|---|---|---|---|
| Receivables (AutoInvoice via SLA) | 2,140 | 61% | Healthy - ecommerce revenue automating into the GL |
| Payables | 690 | 20% | Healthy - supplier bills posting via Create Accounting |
| Inventory / Cost Management | 410 | 12% | Healthy - COGS and inventory moves automating |
| Manual | 180 | 5% | Watch - up from 70 last period |
| Spreadsheet (ADFdi) | 70 | 2% | Watch - month-end reclasses |
| Total | 3,490 | 100% |
- Receivables at 61% is the signature of a healthy commerce-connected ledger. The integration is doing its job: orders become Sales Orders, AutoInvoice creates Receivables transactions, and Subledger Accounting posts them to the GL automatically. You want this slice to be the largest.
- The Manual slice more than doubled, from 70 to 180. Five percent is not alarming in absolute terms, but the trend is the signal. Something is being hand-keyed that was not last period. The controller should ask why before it grows further.
- On investigation, the Manual spike traced to a broken Inventory integration. A cost-source change meant some inventory accounting events were not posting automatically, so the cost team booked them by hand. The right fix is to repair the integration, not to keep hand-keying. This is the kind of root cause the source mix surfaces that a single total never would.
- This card carries no alert by design. The composition is diagnostic. The alert lives on the companion Manual JEs as % of Total card, which fires when the manual ratio crosses its threshold. Read the two together: this card shows the full mix, that card watches the dangerous slice.
Sibling cards merchants should reference together
Journals by Source is a composition lens. It is most useful next to the cards that quantify the dangerous slices and the posting pipeline.| Card | Why pair it with Journals by Source |
|---|---|
| Manual JEs as % of Total | The companion card that puts a threshold and an alert on the Manual slice this card shows. |
| Journals in Error (PostedFlag=E) | Tells you which source the error journals came from, so you know whether to chase the integration or a human uploader. |
| Open (Unposted) Journals | A backlog by source helps you see whether one source is clogging the posting queue. |
| Subledger-to-GL Posting Interface Errors (24h) | When Receivables, Payables, or Inventory automation breaks, people fall back to manual journals; this card shows the source-side failure. |
| Accrual Reversals (last close) | Manual accruals and their reversals are a recurring slice of the manual source; high reversals plus high manual share is an estimation-quality flag. |
| Oracle Fusion Health Score | The composite that a deteriorating source mix feeds into. |
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 (group or filter by Source) Reports and Analytics → OTBI → Financials → General Ledger - Journals Real Time (Journal Source is a standard dimension) Navigator → General Accounting → Period Close → Close Status (journal counts feeding the close, by source)In OTBI, the General Ledger Journals Real Time subject area exposes Journal Source as a dimension, so you can build the exact same donut. The counts per source should match this card when you select the same period, Business Unit, and Ledger scope. Common mistakes when comparing against Oracle’s own reports:
- Mixing posted and unposted. This card counts journals over the window; be clear whether your Oracle query includes unposted journals or only posted ones, and match the card’s setting.
- Custom source confusion. Many Fortune 500 implementations register custom journal sources (for example a named integration source). If your Oracle query buckets these differently from the card, the slices will not line up. Confirm the source list.
- Subledger Accounting labelling. Journals that originate in subledgers can show with the subledger source (Receivables, Payables, Inventory) or under a Subledger Accounting umbrella, depending on how SLA was configured. Check which convention your implementation uses.
| Reason | Direction | Why |
|---|---|---|
| Source taxonomy | Either | Custom journal sources may be grouped differently between the card and an ad-hoc Oracle query. Match the source list to reconcile. |
| Posted vs all | Either | If the card counts all journals in the window but your Oracle report filters to posted only, the mix shifts. Align the posting-status filter. |
| Window boundary | Small | The trailing 30-day window and Oracle’s period or date-range filter can include or exclude journals near the boundary. |
| 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 mix. |