> ## 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. # Journal Imbalances (rejected at posting), Microsoft Dynamics 365 > Journal Imbalances (rejected at posting): journals rejected because debits do not equal credits. How to read it, why it matters, and how to act on it. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > 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. | | | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | Journals rejected at posting because debits ≠ credits. In Finance & Operations these are `LedgerJournalTrans` postings that fail the balance check (posting status does not advance to Posted; the balance validation throws). In Business Central these are General / Sales / Purchase Journal batches where the posting routine errors with an out-of-balance message and refuses to post. | | **What it excludes** | Journals rejected for other reasons (closed period, posting permissions, dimension validation) are a separate signal; this card is specifically the debit ≠ credit imbalance. Unbalanced lines still sitting unposted but not yet attempted are on [Open (Not Posted) Journal Entries](/nerve-centre/kpi-cards/microsoft-dynamics/open-not-posted-journal-entries). | | **Unit** | Count of rejected (unbalanced) journals (a live KPI). | | **Currency** | The count is currency-agnostic. The imbalance amount, when shown, is in the journal's currency or the Reporting Currency. | | **Multi-Company** | Aggregated across selected legal entities. Filter to one entity to isolate the source. | | **Time window** | `RT` (real-time live count) | | **Alert trigger** | `>0` (any imbalance is worth investigating) | | **Roles** | owner, finance, engineering | ## 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. | Rejected journal | Source | Debit | Credit | Imbalance | | ------------------ | ---------------------- | ----------- | ----------- | -------------- | | INTG-44120 | Marketplace sync batch | \$18,420.00 | \$18,418.50 | \$1.50 | | INTG-44121 | Marketplace sync batch | \$9,640.00 | \$9,638.40 | \$1.60 | | GENJNL-0907 | Manual accrual | \$42,000.00 | \$40,000.00 | \$2,000.00 | | **Total rejected** | | | | **3 journals** | 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. | Card | Why pair | | ------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | | [Journals Rejected at Posting (PostingStatus=Rejected)](/nerve-centre/kpi-cards/microsoft-dynamics/journals-rejected-at-posting-postingstatusrejected) | The wider rejection bucket. This card is the imbalance subset; that card includes all rejection reasons. | | [Open (Not Posted) Journal Entries](/nerve-centre/kpi-cards/microsoft-dynamics/open-not-posted-journal-entries) | The queue these came from. Rejected journals fall back to unposted until fixed, so the two move together. | | [Intercompany / Operating-Unit Imbalances](/nerve-centre/kpi-cards/microsoft-dynamics/msd-intercompany-balance) | A common cause: an intercompany posting that does not balance across entities or operating units. | | [Journals by Source Module](/nerve-centre/kpi-cards/microsoft-dynamics/journals-by-source-module) | Tells you which module the rejections cluster in, which points at the upstream cause. | | [Batch Job Error Queue (24h)](/nerve-centre/kpi-cards/microsoft-dynamics/batch-job-error-queue-24h) | Integration-driven imbalances usually surface as failed posting batches here too. | ## 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:** | Reason | Direction | Why | | ------------------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Rejection reason scope** | Card lower | This card counts only debit ≠ credit imbalances. A native list of all failed postings (closed period, permissions, dimensions) reads higher. The broader bucket is [Journals Rejected at Posting](/nerve-centre/kpi-cards/microsoft-dynamics/journals-rejected-at-posting-postingstatusrejected). | | **Auto-balancing setup** | Card lower | If a rounding-difference account auto-absorbs small FX gaps, those journals post and never appear here. Disabling that setup makes more imbalances visible. | | **Re-posted between refreshes** | Either | A journal fixed and re-posted may clear from the native view before the card's next sync, or still show briefly on the card. | | **Legal-entity scope** | Either | The card aggregates selected entities. A native check on one entity will not match a consolidated count. | | **OData / DMF sync lag** | Card up to 15 min behind | A freshly rejected journal may appear in F\&O / BC before the card refreshes. | 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](/nerve-centre/kpi-cards/shopify/total-revenue) or [BigCommerce](/nerve-centre/kpi-cards/bigcommerce/total-revenue) 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](/nerve-centre/kpi-cards/microsoft-dynamics/journals-rejected-at-posting-postingstatusrejected) 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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.