Skip to main content
Metrics type: Key MetricsCategory: Ecommerce Platform
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:
  1. 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.
  2. 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 engineering role: 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.
  3. **The AR sub-ledger drift of 4,210isadifferentclassofproblemandneedsafinancecorrection,notanengineeringfix.Hereeveryindividualentryisbalanced,buttheARsubledgertotalnolongertiestoitsGLcontrolaccount.Thisusuallyhappensafterasubledgerrebuild,adirectjournaltothecontrolaccount(whichIntacctgenerallypreventsbutthirdpartytoolssometimesforce),oratiminggapduringaheavypostingwindow.Thefixistoidentifytheentrythatbrokethetieandreverseandrepostitcorrectly.Pairwith[A/RBalance(live)](/nervecentre/kpicards/sage/arbalancelive):iftheliveARbalanceandtheGLcontrolaccountdisagreebyexactly4,210 is a different class of problem and needs a finance correction, not an engineering fix.** Here every individual entry is balanced, but the AR sub-ledger total no longer ties to its GL control account. This usually happens after a sub-ledger rebuild, a direct journal to the control account (which Intacct generally prevents but third-party tools sometimes force), or a timing gap during a heavy posting window. The fix is to identify the entry that broke the tie and reverse-and-repost it correctly. Pair with [A/R Balance (live)](/nerve-centre/kpi-cards/sage/ar-balance-live): if the live AR balance and the GL control account disagree by exactly 4,210, that confirms the drift and pinpoints it.
  4. 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.
  5. 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 account
Intacct 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.
Why our number may legitimately differ from a Sage Intacct trial balance check: 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.

Known limitations / merchant FAQs

Why is this number not zero when Sage Intacct enforces double-entry? Because Intacct enforces it on UI postings, but data can enter through import files, the API, and third-party connectors that bypass the UI validation. A partial batch import, an integration that posts one side and fails the other, or a sub-ledger rebuild that does not re-tie can all produce an imbalance that the UI would have refused. This card catches what the UI cannot. Is any level of imbalance acceptable? No. Unlike every other card on the dashboard, the correct value here is zero. The threshold is set to fire at the first occurrence precisely because an imbalance is an error, not a range. The only nuance is distinguishing a true imbalance from a transient mid-post snapshot or a multi-currency rounding config issue, both of which the card separates out. What is the difference between an intra-transaction imbalance and sub-ledger drift? An intra-transaction imbalance is one journal where debits do not equal credits. Sub-ledger drift is when every entry balances but a sub-ledger total (AR, AP, inventory) no longer ties to its GL control account. The first is usually a connector or import fault; the second is usually a control-account journal or a rebuild that did not re-tie. They need different fixes. Who should own clearing an imbalance? It depends on the type, which is why this card carries owner, finance, and engineering roles. Connector and import imbalances are an engineering fix (repair the feed, repost the batch). Sub-ledger drift and one-sided manual JEs are a finance correction (identify the breaking entry, reverse and repost). The card’s source-module drill tells you which team to route to. Does a multi-currency entry ever cause a real imbalance? A correctly configured multi-currency entry stays balanced using the exchange-gain/loss account. If you see a tiny residual on foreign-currency entries, the cause is almost always a misconfigured FX gain/loss account, not a true imbalance. Fix the account configuration and the residuals disappear. Can an imbalance hide in a suspense account? Yes, and this is the dangerous case. An interface that routes the unmatched side of a transaction to a suspense account keeps the GL technically balanced while hiding the real problem. The card flags suspense-account growth separately so a balanced-but-wrong ledger does not pass silently. A growing suspense balance is itself a red flag. Why does clearing this card matter for the close? A period cannot be cleanly hard-closed while imbalances exist: the trial balance will not net to zero and the consolidated numbers will be wrong. That makes this a hard gate on Period Close Status. Clearing the imbalances is often the single action that lets a stuck close complete. Sage Intacct vs Sage 50 / 200 on imbalance detection? The double-entry invariant is universal, but how each product exposes batch-level debit/credit sums and sub-ledger-to-control ties differs. Intacct’s structured batch and control-account model makes the detection clean. This connector targets Intacct; the reconciliation paths on Sage 50 or 200 differ, so reach out about availability. How fresh is the count? It is a live read of the GL at typical Intacct refresh cadence (around 5 to 15 minutes). Because a transient imbalance can appear mid-posting and clear on the next refresh, a persistent non-zero reading across refreshes is the one to act on, while a single flicker during a heavy posting window may resolve itself. Does multi-entity complicate this? An imbalance in one entity can be masked at the consolidated level by an offsetting position in another, so always read the per-entity view. The card reports at the dashboard entity scope and drills per entity, which is how you isolate the subsidiary or interface at fault rather than chasing a netted consolidated figure. Implementation Partner role on this metric? The Partner usually owns the integration architecture and the control-account configuration, both of which are common imbalance sources. When this card fires, the Partner is often the right first call for connector and import imbalances, while finance handles sub-ledger and manual corrections. Align the source-module mapping in the Vortex IQ field map so the card routes to the right owner automatically.

Tracked live in Vortex IQ Nerve Centre

Transaction Imbalances is one of hundreds of KPI pulses Vortex IQ tracks across Sage 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.