Journals by Source Module, Microsoft Dynamics 365

Journals by Source Module: posted journals over the window split by AR, AP, GL, Inventory, Project and Bank. How to read it, why it matters, and how to act on it.

Metrics type: Supporting Metrics • Category: Ecommerce Platform

Posted journals over the window, split by the sub-ledger module that originated them. A rising AR share usually means ecom integration is scaling.

At a glance

The mix of posted journals over the period, grouped by source module: AR (sales / receivables), AP (purchase / payables), GL (manual and recurring), Inventory, Project, and Bank. It answers “where is GL activity coming from?” in one donut, and the AR slice is the proxy for how much commerce traffic is now flowing through Finance.

What it counts	Posted journal lines over the window, grouped by the originating source module. In Business Central this maps to the Source Code on each G/L Entry (for example SALES, PURCHASES, GENJNL, INVTPCOST, BANKACC). In Finance & Operations it maps to the SubledgerVoucher / source-document type behind each LedgerJournalTrans posting. Each posted line is counted once, in the module that created it.
What it excludes	Unposted journals (still in batch / not-yet-posted state) are excluded; they live on the Open (Not Posted) Journal Entries card. Rejected journals are excluded; they live on Journal Imbalances (rejected at posting).
Unit	Count of posted journal lines (a donut by module). Switch to amount view to weight by value rather than line count.
Currency	Counts are currency-agnostic. If you flip to the amount view, values consolidate in the Reporting Currency across legal entities.
Multi-Company	Aggregated across every legal entity the connected identity can see, then split by module. Filter to a single legal entity to isolate one entity’s mix.
Time window	30D (default trailing 30 days)
Alert trigger	None. This is a composition / trend card, not a threshold alarm.
Roles	owner, finance

Calculation

Calculated automatically from your Microsoft Dynamics 365 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 UK home & garden brand on Business Central with a single legal entity, snapshot 12 Jun 26 covering the trailing 30 days. They went live on an automated Shopify-to-BC sales sync eight weeks ago, so the AR slice is climbing month on month.

Source module	Posted journals (this period)	Share	Posted journals (prior period)	Prior share
AR (Sales / Receivables)	4,180	58%	2,910	47%
AP (Purchase / Payables)	1,260	17%	1,340	22%
GL (manual + recurring)	690	10%	880	14%
Inventory	980	14%	920	15%
Bank	90	1%	80	1%
Project	20	0%	30	1%
Total	7,220	100%	6,160	100%

Four things to notice:

1. The AR slice jumped from 47% to 58%. That is the integration working as intended. Automated Sales Invoice postings from the commerce sync now dominate the journal mix, exactly what you want to see in the first quarter after going live.
2. The GL (manual) slice shrank from 14% to 10%. As automation takes over, fewer manual corrections are needed. Read this card next to Manual Journals as % of Total to confirm the manual control burden is genuinely falling, not just being diluted by AR volume.
3. AP volume is roughly flat. Purchasing cadence has not changed, which is expected. A sudden AP spike unconnected to a buying campaign is usually a sign of a duplicated import batch worth investigating.
4. Total journal volume rose 17% with no extra headcount. That is the efficiency story for the board: more transactions absorbed through automation, not people.

Sibling cards merchants should reference together

Journals by Source Module tells you the shape of GL activity. Pair it with these to read the health behind the shape.

Card	Why pair
Open (Not Posted) Journal Entries	This card counts what posted. That card counts what is stuck before posting. A rising AR posted share with a growing not-posted queue means the sync is creating work faster than it clears.
Manual Journals as % of Total	The GL slice here is mostly manual. That card turns it into a control-risk percentage.
Journal Imbalances (rejected at posting)	The error counterpart. A module with high posted volume and high rejections needs attention at the source.
Revenue Booked into GL	The AR module is where most revenue postings originate. If AR journal count rises but GL revenue does not, the postings are non-revenue (adjustments, applications).
Batch Job Error Queue (24h)	Automated postings run as batch jobs. A drop in a module’s posted count often traces back to a failed batch here.

Reconciling against Microsoft Dynamics 365

Where to look in Business Central / Finance & Operations:

Business Central: Finance > G/L Registers (each register shows its Source Code; filter and group by Source Code) Business Central: Reports > Finance > G/L Trial Balance (with Source Code analysis view enabled) Finance & Operations: General ledger > Inquiries and reports > Voucher transactions (group by journal name / source) Finance & Operations: General ledger > Journal entries > General journals (filter to Posted, group by journal type)

Group the native register or voucher list by Source Code (BC) or journal name / subledger source (F&O) and the per-module line counts should match this card to within the OData sync window. For an audit-grade tie-out in BC, run G/L Registers, export to Excel, and pivot on Source Code over the same date range.

Why our number may legitimately differ:

Reason	Direction	Why
Source Code mapping	Either	The card maps each posting to a module via its Source Code (BC) or subledger source (F&O). Heavily customised charts or custom Source Codes may roll into “GL / Other” until the field map is configured.
Line count vs voucher count	Card higher	The card counts journal lines by default. A native voucher view that counts vouchers (one per document) will read lower for multi-line documents. Compare like for like.
OData / DMF sync lag	Card up to 15 min behind	Vortex IQ pulls posted entries on a 15-minute cache. A late posting may appear in BC / F&O before the card refreshes.
Recurring journals	Either	Recurring GL journals can post under GENJNL or a custom Source Code depending on setup. If they should count as AR or Inventory, the field map needs that mapping.
Legal-entity scope	Either	The card aggregates across selected entities. A native report run for one entity will not match a consolidated card view.

This card is GL-internal, so there is no direct commerce-side counterpart. The cross-connector signal is indirect: when the Shopify or BigCommerce order volume climbs, the AR slice here should climb in step. A divergence (orders up, AR journals flat) points at a stalled integration rather than an accounting issue.

Known limitations / merchant FAQs

What exactly is a “source module”? It is the sub-ledger or process that originated the posting: AR for sales and receivables, AP for purchases and payables, GL for manual and recurring journals, Inventory for stock movements and costing, Project for project transactions, Bank for bank and cash postings. In BC this is the Source Code on the G/L Entry; in F&O it is the subledger source behind the voucher.

Why is there no alert on this card? It is a composition and trend card, not a threshold alarm. There is no single “bad” mix. What matters is the direction of travel, which is why the prior-period comparison sits next to each slice. The alerting lives on the related error and queue cards.

A rising AR slice, good or bad? Usually good for a commerce business: it means automated sales postings are scaling. It becomes a watch-item only if it rises while the not-posted queue or rejection count rises too, which means volume is outrunning the close process.

Does it count by number of journals or by value? By posted line count in the default donut. Switch to the amount view to weight modules by value, which surfaces a small number of high-value AP or GL postings that the count view hides.

Are unposted or rejected journals included? No. Only posted journals count here. Unposted entries are on the Open (Not Posted) Journal Entries card and rejections are on Journal Imbalances (rejected at posting).

My Inventory slice is large, is that a problem? Not inherently. Inventory costing and movement postings (for example INVTPCOST in BC) generate a lot of lines per shipment. A large Inventory slice is normal for a high-SKU, high-volume merchant. Watch the trend, not the absolute size.

Does it work the same on Business Central and Finance & Operations? Yes, the concept is identical. The underlying field differs (Source Code in BC, subledger source / voucher type in F&O) but the card normalises both into the same six modules.

---

Tracked live in Vortex IQ Nerve Centre

Journals by Source Module is one of hundreds of KPI pulses Vortex IQ tracks across Microsoft Dynamics 365 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.