Count of GL transactions where debits do not equal credits, or a sub-ledger does not tie to the GL. Should always be zero in a healthy ledger.
At a glance
The number of general ledger transactions that fail the most fundamental rule in accounting: debits must equal credits. It also catches the next layer up, where a sub-ledger (AR, AP, inventory, cash) does not tie back to its GL control account. In a healthy Sage Intacct ledger this number is zero, always, because Intacct enforces double-entry at the point of posting. A non-zero reading therefore means something abnormal: an interface or connector pushing unbalanced data, a sub-ledger that has drifted from its control account, a partially-posted batch, or a corruption in an imported journal. This is a fix-now card, not a monitor-the-trend card.
Calculation
Calculated automatically from your Sage data by summing debits against credits per transaction and comparing each sub-ledger to its GL control account. 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 ecommerce group on Sage Intacct, single entity, annual revenue ~$30M across Shopify and a wholesale Adobe Commerce portal. Heavy use of automated order-to-GL posting via the commerce connectors. Snapshot taken 9 Jun 26 during the May 26 close. Default alert threshold of zero, so the card fired the moment the first imbalance appeared.
Five things to notice:
- Five imbalances is five too many, and unlike most cards the correct target here is zero, not “below threshold.” Every other KPI on the dashboard has a healthy non-zero range; this one does not. Double-entry is the bedrock of the ledger, so any imbalance means the books are, at that moment, not internally consistent. The card fires at the first occurrence precisely because an imbalance left to sit will block the close, corrupt the trial balance, and eventually surface as an audit finding. The action is not to watch the trend; it is to clear all five before the period closes.
-
The three Order Entry connector imbalances are the most urgent because they point at an active feed, not a one-off. A partial batch import (some order lines posted, the offsetting lines did not) is the classic shape of an interface that timed out or hit a validation error mid-batch. The danger is that the feed is still running, so every subsequent order may be landing the same way. This is why the card carries an
engineeringrole: the fix is not a finance correction, it is stopping and repairing the integration. On this account the engineering team found the connector had hit an Intacct API rate limit mid-batch and posted the debit lines before the credit lines failed. Pair with Journals by Source Module to confirm the imbalance concentrates in the connector feed and not in manual entries. - **The AR sub-ledger drift of 4,210, that confirms the drift and pinpoints it.
- The manual JE saved in an error state is the easiest to clear and the easiest to prevent. A one-sided journal that got posted (or partially posted) is almost always a draft that should never have left the preparer’s hands. The fix is a one-line correction; the prevention is a posting control that refuses to release an unbalanced draft. Intacct normally enforces this, so a one-sided manual JE that made it to the GL usually points at an import path that bypassed the UI validation. Pair with Manual JEs as % of Total: a high manual-JE share plus recurring imbalances means the manual posting process needs a control review.
- This card is a hard gate on the close, which is why it links straight to the close status cards. A period cannot be cleanly hard-closed while imbalances exist, because the trial balance will not tie and the consolidated numbers will be wrong. So a non-zero reading here directly threatens Period Close Status and, over time, Period Close On-Time Rate (12mo). On this account the five imbalances were the single reason the May close was at risk; clearing them (engineering repaired the connector and reposted the three batches, finance corrected the AR drift and the manual JE) let the close complete on the same day the card was cleared.
Sibling cards merchants should reference together
Reconciling against Sage
Where to look in Sage Intacct: The native Sage Intacct views to run side by side with this card:Reports → General Ledger → Trial Balance for the period: a healthy trial balance nets to zero, so any non-zero total is the headline imbalance General Ledger → All → Journal Entries filtered to the period, scanning for any batch where the debit and credit columns do not match Reports → Accounts Receivable → AR Aging and Reports → General Ledger → Account Activity on the AR control account, compared to confirm the sub-ledger ties to the control Reports → Accounts Payable → AP Aging compared to the AP control account for the same tie General Ledger → All → Open Batches for batches stuck in a partially-posted or error state Interactive Custom Report (ICR) on the GL data source summing debit minus credit per batch, flagging any non-zero net, and a second ICR tying each sub-ledger total to its control accountIntacct enforces balanced double-entry on UI postings, so a true intra-transaction imbalance almost always entered through an import or API path. The Trial Balance is the fastest native confirmation: it must net to zero. For Multi-Entity Console accounts run the Trial Balance per entity, because an imbalance in one subsidiary can be masked at the consolidated level by an offsetting position elsewhere. Common reconciliation pitfalls:
- Rounding in multi-currency entries: a balanced foreign-currency entry can show a tiny residual if the exchange-gain/loss account is misconfigured. This is a configuration fix, not a true imbalance; the card flags it but the cause is the FX account setup.
- Timing during an active posting window: a snapshot taken mid-batch can catch a transaction between its debit and credit postings. The card re-evaluates on refresh, so a transient mid-post imbalance clears itself; a persistent one is real.
- Sub-ledger as-of timing: comparing an AR aging run at one moment to a GL control balance at another can show a phantom drift. Always tie sub-ledger to control at the same as-of timestamp, which the card does internally.
Cross-connector reconciliation:
The cross-connector value is root-cause speed. An imbalance inside Intacct alone tells you the books do not tie; the commerce connectors tell you why. When this card spikes at the same time as Commerce Orders Without Sage Intacct Order, the cause is almost certainly the order feed: it dropped some orders entirely and posted others as half-batches. Seeing both at once turns a forensic GL investigation into a single engineering ticket against the connector, which is how the imbalance gets cleared in hours instead of days.