Transactions Failing Validation (imbalance / missing VAT), Sage

Card class: Hero • Category: Ecommerce Platform

A real-time alert table of transactions rejected by validation in the last hour. Each row is an out-of-balance journal or a revenue line with no VAT code that is being blocked before it reaches the GL.

​

At a glance

A live alert table, not a single number. Each row is a transaction that Sage Intacct’s validation rejected in the last hour. Two failure families dominate: out-of-balance journals (debits do not equal credits) and revenue lines missing a VAT code. These are the transactions that are not making it into the GL, which means they are not in your numbers, not in your VAT base, and silently holding up period close. The card is hour-windowed and real-time on purpose: validation failures cluster around integration runs and bulk imports, so the operator who fixes them wants to see the burst as it happens, while the originating batch is still warm and the cause is obvious. Each row is an integration failure or a coding failure to fix before it blocks the GL.

​

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 taking DTC orders through Shopify Plus and B2B orders through BigCommerce B2B, with the order-to-cash flow integrated into Intacct AR and the GL. Snapshot 23 Jun 26, 14:00, one hour after the afternoon order-sync batch ran. Reporting currency GBP. Threshold is any failure in the last hour. Five things to notice:

1. The three missing-VAT-code rows are one root cause, not three problems, and that is the most important read on this card. All three come from order-sync batches where a product or product type has no VAT code mapped in the integration. The fix is upstream and singular: map the VAT code for that product class once, and every future order of that class posts cleanly. The card groups by source precisely so you see “Shopify order sync produced three VAT failures” rather than three unrelated incidents. Pair with Revenue Lines Missing VAT Code (MTD) for the month-to-date accumulation of exactly this failure, which is the MTD-compliance lens on the same data.
2. INV-bc-9913 (zero-rated item) is the subtle one, because zero-rated is not the same as no code. A zero-rated B2B item still needs a VAT code; the code says “zero-rated”, which is a digital record HMRC requires, not the absence of a record. The integration dropped the code because someone assumed a zero-rated item needs no VAT treatment. It does. This is one of the most common MTD mistakes, and at GBP 2,400 of blocked revenue it is also the largest VAT-failure row here. The fix is to map the zero-rated VAT code, not to exempt the item from VAT handling.
3. JE-imp-3310 is a two-pound rounding break that blocks a fourteen-thousand-pound journal, which is the classic out-of-balance trap. The FX revaluation import dropped two pence somewhere in a multi-currency rounding step, so the journal is two pounds out and Intacct refuses the entire entry. The amount out (GBP 2) is trivial; the amount blocked (GBP 14,002) is not, and the period cannot close honestly while a revaluation journal is sitting rejected. These rounding breaks are almost always an integration mapping or rounding-rule issue, which is why engineering is a role on this card. The fix is on the import side, not in the GL.
4. JE-man-771 is a human out-of-balance, and the GBP 9,500 amount makes it urgent. A manual journal someone keyed during the day does not balance, so it is rejected and the GBP 9,500 it represents is not in the ledger. Unlike the integration failures, this one is fixed by a person re-keying the journal correctly, and it needs a name against it before it is forgotten. The card carries the finance role precisely for these human-origin failures; the engineering role is for the integration-origin ones; owner sees the aggregate risk.
5. An empty table is normal between integration windows, and a table that is never empty is the diagnosis. Validation failures should arrive in bursts around sync runs and clear quickly as someone fixes the upstream mapping. A table that is persistently non-empty means a structural problem: an unmapped product class, a broken FX rounding rule, or a coding habit that keeps producing unbalanced manual journals. These are the transactions standing between you and a clean period close, so a chronically non-empty table predicts a late close and, downstream, a late VAT return. Pair with Period Close Status and Open (Pending) Transactions to see the close-blocking consequence.

​

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:

Company → Audit Trail / Setup → Audit shows the rejected transaction attempts and the validation error messages Intacct returned. Applications → General Ledger → Journal Entries filtered to unposted or rejected entries shows the out-of-balance journals sitting unposted. Platform Services → Integration / Import logs shows the bulk-import failures with the per-line error detail (this is where the order-sync VAT failures surface). Applications → Tax → VAT Setup shows the VAT codes available to map; a missing-code failure is fixed by mapping the right code here and in the integration. Interactive Custom Report (ICR) on the relevant data sources filtered to failed or unposted transactions in the trailing window, grouped by source.

For Multi-Entity Console accounts, check the import logs at the entity scope where the integration runs, because a sync configured against one entity will only produce failures visible at that entity. Common reconciliation pitfalls:

• Failed vs unposted vs pending. A failed transaction was rejected and does not exist as a posted record; an unposted journal was saved but not yet posted; a pending transaction is awaiting approval. The card counts validation rejections (failed), not the normal approval backlog (which is Open (Pending) Transactions). Do not conflate the two.
• Where the failure is logged. Integration-origin failures appear in the import logs; user-origin failures appear in the audit trail or as unposted entries. The card pulls from both, so a single-source reconciliation will see fewer rows than the card.
• Retried and resolved. A failure that was retried successfully within the hour may still appear in a raw log but is no longer a live problem. The card reflects the current live state, so it can show fewer rows than a cumulative log of all attempts.

Why our number may legitimately differ from a Sage Intacct log: Cross-connector reconciliation: The cross-connector point is that a validation failure is the exact moment commerce revenue fails to become accounting revenue. The storefront recorded the sale; the customer was charged; but the transaction never reached the GL because a VAT code was missing or a journal did not balance. Anyone looking at the commerce platform sees a completed order; anyone looking at the GL sees nothing, because the record was rejected on the way in. Only Sage Intacct’s validation layer, surfaced here in real time, catches the failure at the boundary while the originating batch is still warm. This card is how a finance and engineering team fixes the upstream mapping once rather than chasing a revenue gap and a late VAT return weeks later.

​

Known limitations / merchant FAQs

What is the difference between an out-of-balance failure and a missing VAT code failure? An out-of-balance journal has debits that do not equal credits, so Intacct refuses to post it because the fundamental accounting equation is broken. A missing VAT code is a revenue (or other VAT-eligible) line submitted without the VATCODE that UK MTD requires for a digital VAT record. The first is an arithmetic problem usually caused by an integration rounding or mapping error; the second is a coding problem usually caused by an unmapped product class. They are fixed in different places, which is why the card tags each row by type. Why only the last hour? Because validation failures arrive in bursts tied to sync runs and bulk imports, and the operator who can fix them wants to see the live burst while the originating batch is fresh and the cause is obvious. A longer window would bury today’s fixable failures under yesterday’s already-resolved ones. For the accumulating, compliance-oriented view of missing VAT codes, use Revenue Lines Missing VAT Code (MTD); for the standing population of imbalances, use Transaction Imbalances. A zero-rated item failed for missing VAT code, but it has no VAT, why? Zero-rated is not the same as no code. A zero-rated item still needs a VAT code that records it as zero-rated, because HMRC requires a digital record for every VAT-eligible transaction, including zero-rated and exempt ones. The integration dropped the code on the assumption that “no VAT” means “no code”. Map the zero-rated VAT code in the integration and the line posts cleanly. This is one of the most common MTD mistakes. A two-pound imbalance blocked a fourteen-thousand-pound journal, is that proportionate? Yes, and it is the correct behaviour. Intacct will not post any journal whose debits and credits do not match, regardless of how small the discrepancy is, because a ledger that tolerates “close enough” is not a ledger. The fix is to find the missing two pounds, which in an integration import is almost always a rounding or mapping error in a multi-currency or multi-line entry. The amount out is trivial; the amount blocked is what matters. Does this card show normal pending transactions awaiting approval? No. Those are not failures; they are the normal approval backlog, and they live on Open (Pending) Transactions. This card counts only transactions that validation rejected, meaning they were refused entry to the GL because something was structurally wrong. A pending transaction is healthy and waiting; a failed transaction is broken and blocked. Why is engineering a role on a finance card? Because the most common and most repeatable failures are integration-origin: an unmapped VAT code on a product class, or a rounding rule that drops pennies in a multi-currency import. Those are fixed in the integration configuration, which is engineering’s domain. Finance fixes the human-origin failures (a manually keyed unbalanced journal); engineering fixes the systemic ones; owner sees the aggregate blocked-revenue risk. The card carries all three roles because the fix location depends on the source. If a transaction failed, is the customer affected? Often not directly, because the failure is on the accounting side, not the order side. The customer was charged and the storefront shows their order as complete; the failure is that the revenue did not post to the GL. The risk is downstream: understated revenue, an incomplete VAT base, a stalled period close, and eventually a late VAT return. So while no customer email lands today, the compliance and reporting consequences accumulate quietly until someone fixes the upstream cause. How fast should I clear a failure? Out-of-balance and missing-VAT failures should be cleared within the same close cycle at the latest, and ideally within the hour during integration windows because that is when the cause is freshest. A failure left to age becomes a close blocker, and a missing-VAT failure left to accumulate becomes an MTD-compliance problem. The card’s hour window is a deliberate nudge to fix them while they are warm. Does a Multi-Entity Console change anything? The logic is identical per entity. The practical note is that integration-origin failures appear at the entity the sync runs against, so a group with per-entity integrations should run the card on all entities during sync windows. Each row carries its source and entity so the alert routes to the team that owns that integration or that ledger. How fresh is the card? Real-time, typically within a few minutes of the validation rejection, because it reads the failure responses as they occur rather than waiting for a batch report. This immediacy is the whole point: the card exists to catch the burst while the batch that caused it is still in front of the operator. What other failure types can appear besides imbalance and missing VAT? Other validation rejections show up tagged by type, for example posting to a closed period, a missing required dimension, an invalid or inactive GL account, or a currency mismatch. Out-of-balance and missing-VAT are foregrounded because they are by far the most common and the most consequential for MTD and close, but the card does not hide the others; it labels them so you know which kind of fix each row needs.

---

​

Tracked live in Vortex IQ Nerve Centre

Transactions Failing Validation (imbalance / missing VAT) 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.