The share of journal postings created manually rather than by a sub-ledger or system process. A high reading signals control risk and automation gaps.
At a glance
The percentage of total journal postings over the period that were entered by hand, as opposed to generated automatically by a sub-ledger (AR, AP, Inventory) or a system process (recurring, batch, integration). It is a control-health gauge: the more your numbers depend on people typing entries, the more exposed you are to error, fraud, and key-person risk.
| What it counts | Manual journal postings divided by total journal postings over the window, expressed as a percentage. In Business Central, “manual” means entries posted from the General Journal by a user rather than carrying a sub-ledger Source Code (SALES, PURCHASES, INVTPCOST and the like). In Finance & Operations it means LedgerJournalTrans lines on a manually created general journal, as opposed to subledger-generated vouchers. |
| What counts as “manual” | General journal entries keyed by a user, including corrections, reclasses, accruals, and adjustments. Recurring journals are treated as system-generated even though a human set them up, because each posting runs automatically. |
| Unit | Percentage (a gauge). The denominator is total posted journals over the same window. |
| Currency | The ratio is currency-agnostic. The amount-weighted variant consolidates value in the Reporting Currency. |
| Multi-Company | Calculated across selected legal entities. Filter to one entity to see whether a single entity is driving a high reading. |
| Time window | 30D (default trailing 30 days) |
| Alert trigger | >25% |
| 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 US health & beauty brand on Business Central, single legal entity, snapshot 12 Jun 26 over the trailing 30 days. The controller suspects too much is being done by hand at month-end.| Journal origin | Posted journals | Share |
|---|---|---|
| Sub-ledger generated (AR / AP / Inventory) | 5,940 | 79% |
| Recurring / batch / integration | 720 | 10% |
| Manual general journals | 840 | 11% |
| Total | 7,500 | 100% |
- 11% is healthy for a single-entity commerce brand. Most postings flow from automated sales and purchase sub-ledgers. The manual layer is reclasses and accruals, which is normal accounting hygiene.
- Watch the month-end spike. If you scope to the last five business days of the period in isolation, the manual share often jumps to 30%+ because accruals and corrections cluster at close. A high reading driven purely by close-week is less alarming than a high reading spread evenly across the month.
- Above 25% sustained is the warning. It means routine activity is being booked by hand, which is where misstatement and fraud risk concentrate. The usual fix is to automate the offending category (a recurring journal for predictable accruals, or fixing a broken sub-ledger mapping) rather than to work faster.
Sibling cards merchants should reference together
Manual Journals as % of Total is a control-health summary. Pair it with these to find the cause and the consequence.| Card | Why pair |
|---|---|
| Journals by Source Module | The composition view. The GL slice there is the numerator here. Use it to see whether a rising manual share is masked by growing AR volume. |
| Open (Not Posted) Journal Entries | Manual entries are the most likely to sit unposted. A high manual share plus a large not-posted queue is a close-process bottleneck. |
| Accrual Reversals (last close) | Accruals are the biggest manual category. If reversals are noisy, much of the manual share is accrual churn. |
| Journal Imbalances (rejected at posting) | Manual entries are where unbalanced postings come from. A high manual share raises the odds of rejections. |
| Period Close On-Time Rate (12mo) | Heavy manual work slows close. A rising manual share usually drags on-time close performance down over time. |
Reconciling against Microsoft Dynamics 365
Where to look in Business Central / Finance & Operations:Business Central: Finance > G/L Registers (entries with the general-journal Source Code are the manual numerator) Business Central: Reports > Finance > G/L Trial Balance (with Source Code analysis to isolate manual postings) Finance & Operations: General ledger > Journal entries > General journals (filter to Posted; these are the manual journals) Finance & Operations: General ledger > Inquiries and reports > Voucher transactions (group by source to separate manual from subledger)To reproduce the ratio: count posted manual general-journal lines over the period, divide by total posted journal lines over the same period and scope. The card should match within the OData / DMF sync window. Why our number may legitimately differ:
| Reason | Direction | Why |
|---|---|---|
| Definition of “manual” | Either | The card classifies by Source Code (BC) / journal source (F&O). If your team uses a custom Source Code for adjustments, the field map must mark it manual or it falls into the system bucket. |
| Recurring journals | Card lower | Recurring journals are treated as system-generated. A native count that lumps them with manual entries will read higher. |
| Line vs voucher count | Either | The card uses line count by default. A voucher-based native count weights multi-line documents differently. |
| Close-week clustering | Either | The reading is window-sensitive. A 30-day window dilutes the month-end manual spike; a 5-day close-week window concentrates it. Match the window before comparing. |
| OData / DMF sync lag | Card up to 15 min behind | Late manual postings appear in BC / F&O before the card refreshes. |