> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Journals by Source Module, SAP > Journals by Source Module splits GL postings by the SAP module that created them (SD, MM, FI, PP). A growing SD share means ecommerce integration is scaling; a spike in FI manual postings signals a controls gap. **Card class:** [Non-Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [GL Health](/nerve-centre/connectors#connectors-by-type) > A donut breakdown of GL postings by the SAP module that generated them, the shape of your financial automation. ## At a glance > Every line in the S/4HANA Cloud Universal Journal carries the module that created it: SD (Sales and Distribution) for billing-driven revenue, MM (Materials Management) for goods movements and vendor invoices, PP (Production Planning) for manufacturing postings, and FI (Financial Accounting) for direct journal entries including manual postings. This card draws that mix as a donut over the last 30 days. The shape tells a story: a rising SD share means your ecommerce integration is scaling and posting automatically, while a rising FI manual share means people are typing entries that should be automated, which is a controls and automation gap worth investigating. | | | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **What it counts** | The distribution of journal entries across source modules (SD, MM, FI, PP, and others such as AA asset accounting) over the trailing 30 days, shown as a share of total postings. | | **What it reveals** | The balance between automated, integration-driven postings (SD, MM, PP) and direct FI postings. A healthy commerce-led business is SD-heavy and automated; a high FI manual share is a red flag. | | **Data source** | SAP S/4HANA Cloud Universal Journal (`ACDOCA` / `BKPF`), reading the source-module and transaction-origin attributes on each document. | | **Company Code scope** | Respects the selected Company Code filter; rolls up every Company Code visible to the connected SAP business user / API role by default. | | **Real-time vs batch** | Aggregated over the rolling 30-day window and refreshed on each connector poll. | | **Time window** | `30D` (trailing 30 days) | | **Alert trigger** | Informational, no threshold | | **Roles** | owner, finance | ## Calculation Calculated automatically from your SAP 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 growing commerce business running SAP S/4HANA Cloud, comparing the journal mix across two 30-day windows: one ending 31 Mar 26 and one ending 31 May 26, after a storefront integration go-live in April. | Source module | Share (30D to 31 Mar 26) | Share (30D to 31 May 26) | Read | | --------------------------- | ------------------------ | ------------------------ | ----------------------------------------------- | | SD (Sales and Distribution) | 38% | 61% | Ecom integration scaling, automation working | | MM (Materials Management) | 22% | 19% | Steady goods-movement and vendor-invoice volume | | FI (manual and direct) | 31% | 14% | Manual share falling, controls improving | | PP (Production Planning) | 6% | 4% | Stable manufacturing postings | | Other (AA, etc.) | 3% | 2% | Background | | **Total postings** | 100% | 100% | | Four things to notice: 1. **The SD share jumped from 38% to 61% after the integration go-live.** This is the signal you want to see when a storefront connection scales: more revenue is posting automatically from billing documents instead of being keyed by hand. The donut visibly fills with SD. If you have just connected a commerce platform and the SD share does not move, the integration may not be flowing as expected, which is worth checking against the IDoc and missing-document cards. 2. **The FI manual share fell from 31% to 14%.** Before the integration, nearly a third of postings were direct FI entries, many of them manual catch-ups for sales that the system did not capture automatically. After go-live, automation absorbed most of that work and the manual share dropped by more than half. A falling FI share alongside a rising SD share is the textbook shape of a maturing, well-controlled finance function. 3. **A spike in the FI manual share is the warning to act on.** This card has no alert threshold, but the FI slice is the one to watch. If FI manual postings climb instead of fall, it usually means an integration broke (so people are keying entries to compensate), a process gap opened, or controls slipped. A rising manual share is also a SOX-style audit concern because manual postings carry higher error and override risk. 4. **MM and PP shares are mostly structural.** Goods movements and manufacturing postings tend to track operational volume, not automation maturity, so their shares move slowly. A sudden MM spike can correlate with a goods-movement problem (for example the double-posting that drives negative on-hand), so a jump there is worth a look even though the card is informational. ## Sibling cards merchants should reference together The source-module mix is a context card; it explains the shape behind several sharper signals. Pair it with these. | Card | Why pair it with Journals by Source Module | | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | [Manual Journals (FB50/FB60) as % of Total](/nerve-centre/kpi-cards/sap/manual-journals-fb50fb60-as-of-total) | Zooms into the FI manual slice with a hard threshold. This card shows the mix; that one alerts when manual gets too high. | | [Journal Entries Failing to Post (idoc error queue)](/nerve-centre/kpi-cards/sap/journal-entries-failing-to-post-idoc-error-queue) | A falling SD share can mean sales IDocs are failing rather than posting. Read together to confirm. | | [Idoc Error Queue Depth (last 24h)](/nerve-centre/kpi-cards/sap/idoc-error-queue-depth-last-24h) | The integration-health gauge behind the SD share. A growing error queue caps SD growth. | | [Journal Imbalances (debit != credit)](/nerve-centre/kpi-cards/sap/journal-imbalances-debit-credit) | Tells you which source module is generating broken postings when imbalances appear. | | [Open / Unposted Journal Entries](/nerve-centre/kpi-cards/sap/open-unposted-journal-entries) | A rising manual share often comes with a parked-document backlog. | | [SAP S/4HANA Health Score](/nerve-centre/kpi-cards/sap/sap-s4hana-health-score) | The composite roll-up. Automation maturity (high SD, low manual FI) feeds the score. | ## Reconciling against SAP **Where to look in S/4HANA Cloud:** The closest native equivalents inside the SAP Fiori launchpad are: > **Display Journal Entries / Manage Journal Entries** grouped or filtered by source and transaction origin (conceptually transaction FB03 for individual documents) > **Journal Entry Analyzer** for the analytical breakdown by document type and origin > **Embedded Analytics**: the journal-line CDS query grouped by the source-module / transaction-origin attribute over the period > **Compact Document Journal** for a posting-source overview across a date range Direct link template: `https://my{tenant}.s4hana.cloud.sap/sap/bc/ui2/flp#JournalEntry-displayList` To reproduce the donut, run the journal-entry list for the same 30-day posting-date range and group by source module or transaction origin, then take each module's count as a share of the total. SD-originated documents come from billing, MM from goods movements and logistics invoice verification, PP from production confirmations, and FI from direct postings including the manual FB50 / FB60 transactions. The shares should agree with the card within rounding and any difference in how borderline document types are classified. Common mistakes when comparing against SAP's own reports: * **Counting by amount instead of by document count.** The donut is a count-of-postings share by default. A value-weighted view will look different because a few large FI postings can dominate by amount while being rare by count. * **Misclassifying logistics invoice verification.** Vendor invoices via logistics invoice verification originate in MM even though they hit FI accounts. Grouping by GL account rather than by source module will misattribute them. * **Ignoring reversals and clearing.** Reversal and clearing documents inflate the FI count if included. Decide whether to count them consistently on both sides. **Why our number may differ from SAP's reports:** | Reason | Direction | Why | | ----------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Count vs value weighting** | Either | The card weights by document count. A value-weighted report shifts the mix toward whichever module carries the largest amounts. | | **Source-module classification** | Either | Borderline document types (logistics invoice verification, intercompany) can be attributed to different modules depending on the grouping field. | | **Reversal and clearing inclusion** | Either | Whether technical FI documents (reversals, clearings) are counted affects the FI share. | | **Company Code scope** | Either | Running the SAP report at a different Company Code scope than the dashboard filter changes the mix. | ## Known limitations / merchant FAQs **What does a healthy mix look like?** For a commerce-led business, SD-heavy and automated, with a small and stable FI manual share. As an integration scales, you want to see the SD slice grow and the FI manual slice shrink, because that means revenue is posting automatically rather than being keyed by hand. There is no single correct number; the trend matters more than the level, and the direction of the FI manual share is the most telling line. **Why does this card have no alert threshold?** Because the right mix varies enormously by business model. A manufacturer is MM and PP heavy; a pure DTC retailer is SD heavy; a services business may be FI heavy by design. A fixed threshold would misfire across all of them. The card is informational context; the sharp alert lives on [Manual Journals (FB50/FB60) as % of Total](/nerve-centre/kpi-cards/sap/manual-journals-fb50fb60-as-of-total), which puts a threshold on the one slice that is dangerous everywhere. **Why is a rising FI manual share a problem?** Because manual postings carry higher error and override risk and usually mean automation has broken or never existed for some process. When an integration fails, finance teams compensate by keying entries by hand, so a climbing FI share is often the visible symptom of an upstream integration problem. It is also a SOX-style controls concern: manual entries are the ones auditors scrutinise for segregation-of-duties and approval gaps. **Can a falling SD share be a warning rather than good news?** Yes. If your commerce volume is steady but the SD share drops, it can mean sales documents are failing to post (IDoc errors) rather than business slowing. Always read a falling SD share against [Idoc Error Queue Depth](/nerve-centre/kpi-cards/sap/idoc-error-queue-depth-last-24h) and [Journal Entries Failing to Post](/nerve-centre/kpi-cards/sap/journal-entries-failing-to-post-idoc-error-queue) to tell a real demand change from a hidden integration failure. **Does it count by number of documents or by value?** By document count by default, so the donut reflects how many postings each module generates. This is the right view for automation maturity because it is not skewed by a handful of large entries. A value-weighted view answers a different question (where the money flows) and will look different; both are legitimate but they are not the same chart. **How are logistics invoice verification and intercompany postings classified?** Vendor invoices through logistics invoice verification originate in MM even though they post to FI accounts, and the card attributes them to their originating module rather than by GL account. Intercompany postings can straddle modules depending on how they are generated. If your mix looks off, check how these borderline document types are being grouped before assuming the integration changed. *** ### Tracked live in Vortex IQ Nerve Centre *Journals by Source Module* is one of hundreds of KPI pulses Vortex IQ tracks across SAP 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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.