Skip to main content
Metrics type: Key Metrics • Category: Ecommerce Platform
The count of journals rejected at posting because debits do not equal credits. Always investigate.

​
At a glance

The number of journals the system refused to post because the entry was unbalanced: total debits did not equal total credits. Double-entry accounting will not let an unbalanced journal hit the GL, so these are blocked at the gate. Each one is a stalled posting and a sign that something upstream (an integration mapping, an FX rounding step, a manual keying error) produced a journal that cannot be committed. The correct count to aim for is zero.

​
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 apparel brand on Finance & Operations with an automated marketplace order sync, snapshot 12 Jun 26 (live count). The card is showing a non-zero reading, so the alert has fired. The live count is 3, which trips the >0 alert and turns the card red. Four things to notice:
  1. Any non-zero count is actionable. Unlike a trend card, the target here is literally zero. Three rejected journals means three postings are blocked from the GL right now.
  2. Two of the three are tiny FX rounding gaps. INTG-44120 and INTG-44121 are off by about $1.50 each, the classic signature of currency rounding in an integration batch where line-level rounding does not sum to the header. These are systemic, not human, and usually fixed once in the integration’s rounding-account setup.
  3. The third is a real keying error. GENJNL-0907 is out by a round $2,000, which looks like a transposed or missing line in a manual accrual. That is a human error to correct directly.
  4. Engineering is on the roles for a reason. The recurring integration imbalances need a code or configuration fix (a rounding-difference account), not just a re-key. This is the one GL card where Finance and Engineering investigate together.

​
Sibling cards merchants should reference together

Journal Imbalances is the sharpest GL error signal there is. Pair it with these to find the source and the blast radius.

​
Reconciling against Microsoft Dynamics 365

Where to look in Business Central / Finance & Operations:
Finance & Operations: General ledger > Journal entries > General journals (lines with a posting error; the validation message states the imbalance) Finance & Operations: System administration > Inquiries > Batch jobs (failed posting batches carry the balance-check error in the log) Business Central: Finance > Journals > General Journals (attempt to post; the out-of-balance error is shown on the batch) Business Central: Notifications / Error Messages (the posting routine lists the unbalanced batch and amount)
To reconcile: in the native journal, the column totals for debit and credit will not match on a rejected journal, and the posting routine names the difference. The card’s count should equal the number of journals showing that error, subject to the sync window. Why our number may legitimately differ: This card is GL-internal with no commerce-side equivalent. The cross-connector tie is causal, not numeric: integration-created imbalances (FX rounding on synced Shopify or BigCommerce orders) are the most common recurring source, which is why a spike here often coincides with a surge in synced order volume.

​
Known limitations / merchant FAQs

Why is the alert set at any value above zero? Because an unbalanced journal cannot post, full stop. Double-entry accounting requires debits to equal credits, so every rejection is a stalled posting that needs fixing. There is no “acceptable” non-zero level, which is why the threshold is greater than zero. What usually causes these? Three patterns dominate: FX rounding in integration batches where line-level rounding does not sum to the header, manual keying errors (a transposed or missing line), and intercompany postings that do not balance across entities. The first is systemic, the other two are usually one-offs. Why are FX rounding imbalances so common? When an order in one currency is posted with line-by-line conversion to the base currency, the rounded line amounts can sum to a few cents off the rounded header total. Without a rounding-difference account configured, the journal is rejected. The fix is a one-time setup, not a daily re-key. Should Finance or Engineering fix these? Both, which is why engineering is on the roles. Manual keying errors are Finance’s to correct. Recurring integration imbalances need a configuration or code fix (a rounding account, a mapping correction), which is Engineering’s. Does a rejected journal corrupt my GL? No. That is the point: the system refuses to post it, so the GL stays balanced. The cost is operational, a blocked posting and delayed close, not a corrupted ledger. How is this different from the broader “rejected at posting” card? Journals Rejected at Posting counts every rejection reason. This card isolates the debit ≠ credit subset, which is the most fundamental and almost always the most urgent. Can a rounding-difference account hide real problems? It can. Auto-absorbing small gaps keeps the queue clean but masks systemic rounding drift. Set a tight tolerance so genuine errors still get rejected and surfaced here. Same on Business Central and Finance & Operations? Yes. The error messages and screens differ but the underlying balance check and this card’s count behave identically.

​
Tracked live in Vortex IQ Nerve Centre

Journal Imbalances (rejected at posting) 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.