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% |
- 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.
- 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.
- 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.
- 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. |