Items waiting in Sage Intacct’s Smart Coding (auto-categorisation) queue beyond 24h. Backlog usually means unrecognised PSP fee descriptors or new vendors needing rule training.
At a glance
The number of transactions sitting in Sage Intacct’s Smart Coding queue that have been waiting longer than 24 hours for categorisation. Smart Coding is Intacct’s machine-assisted coding layer: it reads incoming documents and transactions (supplier bills, bank lines, PSP settlements) and suggests the GL account, dimensions, and vendor automatically. When it recognises something it codes it in seconds. When it does not, the item parks in the queue waiting for a human to code it and, ideally, to train a rule so the machine handles it next time. A backlog older than 24 hours means recognition is failing somewhere, usually a new PSP fee descriptor, a new vendor, or a changed invoice format, and that backlog is the upstream source of manual journals, coding errors, and a stalled close.
Calculation
Calculated automatically from your Sage data by counting the Smart Coding queue items whose age exceeds 24 hours. 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 ~$28M across Shopify, Amazon, and a wholesale Adobe Commerce portal. Heavy PSP and marketplace settlement volume. Snapshot taken 9 Jun 26. Default alert at any item aged beyond 24h. The card renders the aged-item count with an age-band breakdown behind it.
Five things to notice:
- 142 aged items is a real backlog, and the breakdown immediately shows it is a recognition problem, not a staffing problem. The instinct on seeing a queue backlog is “we need more hands to clear it.” But 64 of the 142 are a single new PSP fee descriptor and 38 are a single new Amazon settlement charge type. That is two patterns, not 102 individual decisions. Training two Smart Coding rules clears 102 of the 142 items at once and stops them recurring. The card’s value is making that obvious: a backlog that looks like a labour problem is almost always a handful of unrecognised patterns, and the fix is rule training, not overtime.
- An aged Smart Coding queue is the upstream cause of a rising manual-JE share and a slowing close. Every item that sits in the queue uncoded is a transaction that is not yet in the GL where it belongs, which means reconciliations cannot complete and finance often resorts to a manual journal to get the number booked before close. That is why this hero card sits at the top of a causal chain that runs straight into Manual JEs as % of Total and Period Close Status. On this account the 142-item backlog was directly responsible for a spike in daily PSP fee journals; clearing the queue by training the two rules dropped the manual share at the same time.
- PSP and gateway fee descriptors are the most common cause and they change without warning. Payment processors periodically tweak the text on their fee lines, add a new fee type, or change a settlement format, and the moment they do, Smart Coding stops recognising the pattern and the fees start parking in the queue. This is invisible until something downstream breaks, which is exactly why a live queue-depth card matters: it catches the descriptor change within a day instead of at close when finance discovers a pile of uncoded fees. The engineering role on this card reflects that the durable fix is often a mapping or rule change at the integration layer, not just one-time coding.
- New-vendor backlog is benign and self-resolving once rules are trained. The 22 new-vendor bills are a normal consequence of onboarding three suppliers in a week: Smart Coding has not seen them before, so the first few bills park in the queue. Coding them and training a per-vendor rule means the next bill from each supplier auto-codes. This cohort is not a warning sign; it is the system learning. The thing to watch is whether new-vendor items clear promptly (healthy) or accumulate because nobody is training rules during onboarding (a process gap). Pair with Active Vendors to see whether a vendor-onboarding wave explains a temporary queue bump.
- A standing queue that never reaches zero is a training-discipline signal, not a capacity signal. If the queue is cleared every day but always refills with the same patterns, the team is coding items without training rules, which means the same work recurs forever. A healthy Smart Coding operation trends the aged-item count toward zero over time because every new pattern gets a rule the first time it appears. On this account the queue had been hovering around 120-150 for weeks, which on inspection meant the team was hand-coding the recurring PSP fees daily rather than training the rule once. The fix was a single rule and a training habit, after which the aged count fell to single digits.
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:Accounts Payable → Smart Coding (or Transaction Capture / AP Automation, depending on your edition) for the live queue of uncategorised items and their age Cash Management → Bank Transaction Matching for bank lines awaiting a coding rule Accounts Payable → Bills → Draft for supplier bills captured but not yet coded and posted Company → Setup → Smart Coding Rules (or the equivalent rule list) to see which patterns are trained and which are missing Interactive Custom Report (ICR) on the AP automation / transaction-capture data source filtered to uncoded items with age greater than 24 hours, grouped by source vendor or descriptorIn Intacct the Smart Coding queue is the staging area between capture and posting, and each item carries a captured-at timestamp, which is what this card uses to compute age. The native Smart Coding screen is the closest equivalent; this card adds the 24-hour age cut and the source grouping that turns the raw queue into an action list. For Multi-Entity Console accounts check the queue per entity at the dashboard scope, because unrecognised transactions tend to concentrate in the entity receiving a new PSP or a new vendor. Common reconciliation pitfalls:
- Edition differences: Smart Coding is branded and surfaced slightly differently across Intacct editions and the AP automation add-on. The card maps to whichever transaction-capture queue your instance uses; a native screen name may differ from the card’s label.
- Captured vs received timestamp: the age clock starts when Intacct captured the item, which can lag when the document actually arrived (an emailed bill captured the next morning). The card uses the capture timestamp; a team measuring from email receipt will see slightly older ages.
- Auto-coded but unposted items: an item Smart Coding categorised but that is still in draft awaiting approval is coded, not queued. The card counts uncoded items, not unposted-but-coded ones, so it can read lower than a raw “items not yet in the GL” count.
Cross-connector reconciliation:
The cross-connector value is that the Smart Coding queue is the exact point where the messy outside world (a PSP that renamed its fee line, a marketplace that added a settlement charge, a new supplier) meets the orderly ledger. The commerce and payment connectors know a new transaction pattern has appeared; Intacct knows it could not code it; this card joins the two so the cause is named, not guessed. When the queue spikes and the cause is a new Amazon settlement type, the fix is a rule trained against that connector’s data, which clears the backlog and stops it returning. That is the difference between clearing a queue and curing it.