Open (Pending) Transactions, Sage

Card class: Hero • Category: Ecommerce Platform

GL transactions sitting in Pending, Reviewed or Submitted state and not yet posted. A growing backlog usually means an approval-routing rule is broken.

​

At a glance

The count of transactions sitting in a pre-posted workflow state in Sage Intacct: Pending, Reviewed, or Submitted, but not yet Posted. These are not failures (those are on Transactions Failing Validation (imbalance / missing VAT)); they are valid transactions waiting for an approval step that has not happened. A small, churning backlog is normal and healthy: transactions arrive, get approved, and post. A large or growing backlog is a symptom, almost always that an approval-routing rule is broken, an approver is absent, or a workflow step has no owner. Unposted transactions are revenue, cost, and VAT not yet in the GL, so a swelling pending count is a period that will not close on time and numbers that are quietly understated.

​

Calculation

Calculated automatically from your Sage 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 UK group on Sage Intacct with an approval workflow on AP bills and manual journals (anything over a threshold routes to the Financial Controller for approval before posting). DTC through Shopify Plus, B2B through BigCommerce B2B, order-to-cash auto-posts but AP and journals require approval. Snapshot 23 Jun 26. Reporting currency GBP. Alert at 50. Five things to notice:

1. Seventy-four pending is above the alert, and the breakdown points straight at the cause: sixty-one items stuck at first approval. Almost all of the backlog is sitting in Pending, awaiting the Financial Controller’s approval, which means one approval step is the bottleneck. The most likely explanations are concrete and quick to check: the Controller is on leave with no delegate configured, an approval threshold was changed so more transactions now route to them, or an approver who left was never removed from the routing and the step is effectively dead. The card turned the vague feeling of “AP seems behind” into a specific, ownable diagnosis. Pair with the breakdown to see which state holds the backlog, because the state tells you which step is broken.
2. GBP 191,000 of value is sitting outside the GL, which is the financial framing finance cares about. This is not an abstract queue; it is GBP 142,000 of AP bills and GBP 49,000 of journals that are not yet in the ledger, so the trial balance, the expense run-rate, and the VAT input-tax position are all understated until they post. If the period close runs while 74 transactions are pending, the close is built on incomplete numbers. This is why a pending backlog is an upstream cause of a stalled close and, downstream, a late VAT return. Pair with Period Close Status to see the close consequence.
3. The four Submitted items are healthy and should be ignored in the triage. Submitted means the transaction has cleared approval and is queued to post on the next run; it will clear itself within the normal cycle. The triage attention belongs on the Pending and Reviewed states, where transactions are actually waiting on a human decision. Reading the breakdown rather than the headline stops you from treating self-clearing items as a problem. The discipline is: act on Pending and Reviewed, watch Submitted clear on its own.
4. The fix is a workflow fix, not a data fix, which is what makes this card different from the validation card. Nothing here is wrong with the transactions; they are valid and waiting. The fix is to repair the approval route: assign a delegate for the absent approver, correct the threshold, or reassign the orphaned step. Once the route works, the 61 Pending items can be approved in a batch and the count falls back to a healthy churn. This is why the card carries owner and finance roles rather than engineering: the lever is workflow configuration and approver availability, both finance-operations concerns.
5. A healthy steady-state is a low, churning number, and the shape of the trend matters more than any single reading. A pending count that hovers around 10-20 and turns over daily is normal: transactions arrive, get approved, and post. A count that climbs steadily day over day is the warning sign, because it means inflow exceeds approval throughput, which only happens when the workflow is broken or under-resourced. Reading the trend tells you whether you have a one-off spike (an approver took a few days off) or a structural problem (the routing is broken). Pair with Sage Health Score, which reflects a swelling pending backlog as a coding-hygiene drag, and Smart Coding Queue Depth (24h) for the related coding-side backlog.

​

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:

Applications → General Ledger → Journal Entries filtered to non-posted states shows the journals waiting in the workflow. Applications → Accounts Payable → Bills filtered to Pending / Reviewed shows AP bills awaiting approval, usually the largest component. Company → Setup → Approval workflows / Configuration shows the approval rules, thresholds, and assigned approvers, which is where a broken route is diagnosed and fixed. Lists → (each module) → filtered by state shows the pre-posted population per sub-ledger. Interactive Custom Report (ICR) on the transaction data sources filtered to state not equal to Posted, grouped by state and source module.

For Multi-Entity Console accounts, check the approval configuration per entity, because routing rules and approvers are set at the entity level and a broken route in one subsidiary will not affect another. Common reconciliation pitfalls:

• Pending vs failed. A pending transaction is valid and waiting; a failed transaction was rejected and never entered the workflow. The card counts pending states; a “needs attention” view in Sage might lump failures and pending together, reading higher than this card.
• Which states count. Sage’s exact workflow states depend on how approvals are configured. The card counts everything before Posted, but if your workspace defines additional custom states, confirm the field map includes them.
• Drafts. A Draft that a user saved but never submitted is technically pre-posted but is not waiting on an approver; some teams exclude pure drafts from the count because they are author-owned, not workflow-stuck. Confirm whether drafts are in or out.

Why our number may legitimately differ from a Sage Intacct workflow list: Cross-connector reconciliation: The cross-connector point is that a pending backlog is the gap between “a transaction exists” and “a transaction counts”. The commerce platform shows the order as complete and the customer as charged; the AP system shows the bill as received; but until the transaction clears its approval workflow and posts, none of it is in the GL, the trial balance, or the VAT base. Sage Intacct is the only system that knows the difference between recorded and posted, because it owns the workflow that sits between them. A backlog here is the early signal that the books are drifting out of date, days or weeks before the stalled close makes it obvious. Catching it as a rising pending count, and fixing the broken approval route, is how a finance team keeps the close boring.

​

Known limitations / merchant FAQs

What is the difference between pending and failed? A pending transaction is valid and waiting for an approval step; a failed transaction was rejected by validation (out-of-balance, missing VAT code) and never entered the workflow at all. Pending lives on this card; failed lives on Transactions Failing Validation (imbalance / missing VAT). The distinction matters because the fixes are completely different: a pending backlog is fixed by repairing the approval route, while a failure is fixed by correcting the transaction. What does a healthy pending count look like? Low and churning. A count that hovers around 10-20 and turns over daily, as transactions arrive, get approved, and post, is the picture of a working workflow. The absolute healthy number depends on volume: a high-throughput business will sit higher than a low-volume one, which is why the alert threshold is configurable. The shape matters more than the level: a stable, churning count is fine; a steadily climbing one is the warning. My count is above the threshold, what do I check first? Open the state breakdown and find which state holds the backlog, then check the approval route for the step that feeds it. The usual causes, in rough order of frequency, are: an approver on leave with no delegate, an approval threshold change that re-routed more transactions to one person, an approver who left the business still assigned to the route, or a workflow step with no owner. All four are workflow-configuration fixes, not data fixes. Why is a pending transaction a problem if it is valid? Because until it posts it is not in the GL, so it is missing from revenue, cost, VAT, and the trial balance. A small, fast-clearing backlog is fine; a large or growing one means the books are increasingly out of date and the period cannot close cleanly. Unposted AP understates expenses and input VAT; unposted revenue understates the top line. The transaction being valid does not help anyone until it actually counts. Should approvals be automated to avoid backlogs? Partially. Auto-posting low-risk, high-volume transactions (like reconciled order-to-cash entries) keeps them out of the workflow entirely, which is the right design for routine flow. Approval workflows should be reserved for what genuinely needs a human check (AP bills over a threshold, manual journals). The backlog problem is usually not too much automation but a manual approval step that is under-resourced or mis-routed. The fix is reliable routing and delegates, not removing controls. Do drafts count as pending? It depends on the field map. A pure Draft is something an author saved but never submitted, so it is pre-posted but not actually waiting on an approver. Some teams exclude drafts because they are author-owned rather than workflow-stuck; others include everything before Posted. Confirm which convention your workspace uses, because it changes the headline. The more meaningful number for diagnosing a broken workflow excludes author-owned drafts. How does the alert threshold relate to my volume? The default alert of 50 is a reasonable mid-market starting point, but the right threshold scales with transaction volume. A business posting thousands of transactions a day will naturally carry a higher steady-state pending count than one posting dozens, so set the threshold above your normal churn but below the level that indicates a backup. The goal is for the alert to fire when the workflow is genuinely backing up, not on a normal busy day. Is engineering involved in fixing this? Usually not. Unlike the validation-failure card, where integration mapping is often the cause, a pending backlog is almost always a workflow-configuration and approver-availability problem, which is finance-operations territory. The card carries owner and finance roles for that reason. Engineering only enters the picture if the approval routing itself is driven by a custom integration or external system, which is uncommon. How does this behave across a Multi-Entity Console group? Approval routing is configured per entity, so a broken route in one subsidiary backs up only that subsidiary’s count. Watch each entity separately, because a group total can hide a single entity whose approver left while the others churn normally. The card respects the dashboard entity filter, and each pending item carries its entity so the backlog routes to the team that owns that entity’s workflow. How fresh is the count? Real-time. The card reads the live workflow state, so the count falls the moment a batch of pending items is approved and posts. This immediacy is why it is a real-time time window: a finance manager who clears the backlog can watch the number drop, which confirms the fix worked. It also means the trend is meaningful day to day, which is the read that distinguishes a one-off spike from a structural backup. What is the relationship between this and the smart-coding queue? They are adjacent backlogs at different workflow stages. The smart-coding queue (Smart Coding Queue Depth (24h)) is transactions waiting to be coded; this card is transactions waiting to be approved and posted. A transaction can pass through both. When both are deep at once, the whole transaction pipeline is backing up, which is a strong signal that the period close is at risk and the Sage Health Score will reflect it.

---

​

Tracked live in Vortex IQ Nerve Centre

Open (Pending) Transactions 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.