The variance taxonomy — patent-filed, audit-grade
Match rates get the airtime. The variance taxonomy is where the real economic value lives. Every transaction the engine cannot clear lands in a typed code that explains why — and that typed code is the input every downstream workflow needs.
Terra Insight has filed a patent on this taxonomy. It is the structural reason finance teams using TransactIG close faster and stop the revenue leakage hidden inside their unreconciled residual.
This page describes the taxonomy, the downstream automation it enables, and the audit-trail value it produces. It does not name internal scoring weights or pass mechanics — those remain inside the patent.
Why unmatched residual is the real problem
A finance team that lifts its match rate from fifty-one to eighty-eight percent has done a serious piece of work. The twelve percent that remains, however, is not a rounding error. It is where revenue leakage, late-cycle fraud, unposted income, and the audit findings that shape next year’s management letter all concentrate. Untyped residual is just a long Excel list. Typed residual is an action queue.
The distinction matters because the residual is rarely homogenous. Inside that twelve percent are gateway fees that nobody booked back, TDS that a customer withheld but never deposited, GSTR-2B mismatches that quietly killed input credit, NACH bounces still inside the re-presentation window, and a small but real population of fraud-pattern lines. Each requires a different action, owned by a different team, governed by a different control. A status field that says “unmatched” cannot drive any of that.
This is the structural difference between reconciliation software and reconciliation infrastructure. Software gives the team a list. Infrastructure gives the team a typed contract that downstream automation, the auditor, and the regulator can consume in parallel. The variance taxonomy is the contract.
Typed variance codes — what each class captures
The customer-facing classes below are the public catalogue. The full proprietary classification, with its sub-codes and routing matrix, sits inside the patent. Every code below is a stable contract that downstream automation can switch on.
Timing variance
Receipt and booking land in different periods — settlement T+1 across a month-end cut, NACH credit cleared before the invoice is posted, GST month closed before a supplier filed.
Routes to the period-end reclassification queue. The line is held in a control account, automatically released when the matching counter-leg arrives, and aged out as a write-off candidate only if both ends never reconcile.
Partial-settlement variance
Receipt clears one or more invoice tranches but not the full booked value — a TPA paying ninety percent of a claim, a marketplace netting a return against a settlement batch, a customer over-deducting TDS.
Opens an invoice-tranche pairing workflow. The matched portion is closed; the unmatched delta is typed (gateway fee, TDS deduction, return netting, customer dispute) and routed to its own resolution queue with the source documents pre-attached.
Fee variance — gateway MDR, processing charges
Gross transaction less the gateway MDR, GST on MDR, processing charges, and platform commission. Razorpay, PayU, Cashfree, and marketplace settlements all carry a fee leg that the ERP never sees unless someone books it.
Auto-creates the journal voucher with the MDR-plus-GST split, references the gateway settlement statement, and posts to the configured fee account. The recoverable GST input credit is queued for the next GSTR-3B without manual touch.
Tax-withholding variance
TDS deducted at source by a customer under Section 194C, 194J, 194H, 194I, or 194Q but never booked as a recoverable credit in the ledger — or the inverse, where TDS was booked but the customer never deducted.
Routes to the TDS reconciliation workflow with the customer Form 26AS extract, the underlying invoice, and the actual receipt pre-attached. The credit is posted to the deductee ledger, queued for the next 26AS verification, and flagged for the quarterly TDS reconciliation pack.
GST variance — ITC against 2B
Input tax credit booked against a supplier invoice that does not appear in GSTR-2B, or appears with a different taxable value, GSTIN, or HSN. Rule 36(4) restricts ITC to what 2B confirms.
Drops into the ITC-recovery workflow with the supplier contact, the invoice reference, the missing 2B entry, and the e-invoice IRN where one exists. Supplier follow-up templates, DRC-01B/01C correspondence, and the IMS acceptance flow are all switched on from this single variance code.
FX variance
Foreign-currency invoice booked at the AS 11 rate, settled at the actual remittance rate — the exchange-rate delta is a typed variance, not an unexplained difference.
Posts the realised exchange gain or loss to the configured FX account, retains the rate-source evidence for the auditor, and reconciles against the Form 15CA / 15CB cross-border tax withholding where applicable.
Missing-leg variance
One side of the transaction is booked; the other side is silent. A customer receipt with no matching invoice; an invoice with no matching receipt past the credit period; a NACH debit with no mandate entry.
Triggers a source-document chase — the receipt is held against the customer master while the invoice is requested, or the aged invoice is escalated to collections. The variance ages on a defined ladder rather than disappearing into other-receivables.
Duplicate variance
Two records, one event — the same invoice booked twice, the same receipt cleared twice, the same NACH batch processed on retry. Common where ERP and bank ingestion overlap or a manual journal duplicates a system entry.
Quarantines the duplicate, surfaces both candidate records side by side with the deciding metadata, and writes the de-duplication decision into the audit trail. The cleared record is preserved; the duplicate is reversed with full provenance.
Aged-write-off candidate
An unmatched line that has crossed the policy-defined ageing threshold without resolution — typically eighteen months for trade receivables, longer for tax credits. Not every variance is recoverable; some need to be acknowledged.
Routes to the management approval workflow with the full ageing history, the variance class it cycled through, and the recovery attempts on file. The write-off voucher carries the audit chain back to the original variance code rather than a generic other-expense reason.
Fraud-pattern variance
A variance whose shape matches a known fraud or anomaly pattern — round-tripped receipts, settlement just below a control threshold, employee-vendor name collision, repeated narration with shifting beneficiaries.
Escalates out of the routine reconciliation queue into the internal-audit channel. The variance is held, the supporting evidence pack is built automatically, and the resolution requires a documented sign-off above the operator level.
From typed code to automated downstream action
The mechanical value of the taxonomy is what it switches on. A TDS-withheld-not-booked variance routes to the TDS reconciliation workflow with the source documentation pre-attached — the customer’s 26AS extract, the underlying invoice, and the actual receipt. The resolver works the exception, not a document chase. A gateway-fee variance creates the MDR-plus-GST journal voucher automatically and queues the recoverable GST input credit for the next 3B without a finance analyst opening a workbook.
A partial-settlement variance opens a tranche-pairing workflow that matches the receipt against the relevant invoice slice and types the unmatched delta separately — a marketplace return netted from a settlement is not the same exception as a customer short-paying an invoice, even if both look identical in the bank statement narration. A fraud-pattern variance leaves the routine reconciliation queue entirely and lands in the internal-audit channel with the evidence pack already assembled.
The taxonomy is the bridge between matching output and the downstream work that actually closes the books. The matching engine answers “what did not clear?”. The taxonomy answers “why, who owns it, and what evidence is already on hand?”. Cross-link to the matching engine page for how the residual is produced, and the architecture page for the end-to-end flow.
Why this is patent-filed, not feature-marketed
A status field on unmatched rows is not a taxonomy. Most reconciliation tools expose “matched” and “unmatched” as the available states, with an optional free-text note for the operator to explain the latter. The TransactIG taxonomy is a structured, multi-axis classification of the why-behind-a-mismatch, mapped to a stable downstream-automation contract that the workflow engine, the ledger writeback, the auditor report builder, and the recovery playbook all consume.
That contract is the patent-filed differentiator. Competitors expose unmatched residual as one bucket; TransactIG exposes the typed why behind every line. The code is stable across versions, so a workflow built against the TDS-withheld-not-booked variance keeps working when the matching engine is upgraded underneath it. The taxonomy is the interface; the engine is the implementation. The patent protects the interface.
This page describes the customer-facing classes and their routing intent. It does not publish the internal sub-codes, the scoring rules, or the pass-by-pass mechanics that produce the classification. Those remain inside the patent filing and inside the operating system — available to enterprise customers under NDA, not to the open web.
India-tax-aware variance routing
The taxonomy is engineered for the India tax surface, not retrofitted onto a global reconciliation product. The five types below are first-class variance attributes, not free-text annotations on a generic exception.
TDS section-aware routing
Withholding variances are typed by the underlying section (194C contractor, 194J professional, 194H commission, 194I rent, 194Q purchase, 195 non-resident, 206C TCS) rather than collapsed to a single "TDS" bucket. The downstream workflow knows which section means which deductee documentation, which form, and which 26AS row to verify against.
GSTR-2B ITC mismatch typing
The taxonomy separates "invoice missing from 2B", "invoice present with value mismatch", "invoice present with GSTIN mismatch", and "invoice present but supplier filing late". Each routes to a different supplier-side action and a different IMS treatment. A single "GST exception" status would force a manual triage step that the typed classes eliminate.
E-invoice IRN reference variance
Where an invoice is e-invoice-applicable but the IRN reference is missing, mismatched, or duplicated, the variance is typed as an e-invoice reference variance — not a generic invoice-number mismatch. The downstream workflow consults the GSTN IRP record rather than the supplier portal.
NACH return reason code typing
NACH returns carry a structured reason code — insufficient funds, mandate cancelled, account closed, technical reject, signature mismatch. The taxonomy preserves the code as a first-class variance attribute so re-presentation logic, customer-communication templates, and collection workflows can switch on it without scraping a free-text field.
26AS and AIS linkage
A variance flagged against a receipt can be linked directly to the underlying 26AS or AIS line where the counterparty has reported the transaction to the income-tax department. The reconciliation evidence is the same evidence the assessing officer will see — there is no second narrative to maintain for the assessment.
Cross-link to TDS reconciliation software and GST reconciliation software for how the taxonomy lands on the two largest India-specific surfaces in production.
Audit trail — the regulator-defensible side
Every variance code carries a tamper-evident audit record. The same trail serves statutory audit, internal audit, ICFR attestation, SOX-equivalent control testing, and CAG or RBI inspections without a parallel reconstruction.
Variance provenance
Every code carries the timestamp at which it was raised, the configuration version that produced it, and the source records — ERP entry, bank statement line, GSTR-2B row, 26AS extract — that were compared. Re-running an old reconciliation produces the same classification because the configuration is versioned, not mutable.
Action history
Every state change on the variance — assignment to a queue, document attachment, escalation, resolution, write-off approval — is logged with the principal who acted and the justification recorded. The history is queryable per variance, per workflow, and per user.
Resolution evidence
When a variance closes, the resolution artefact is preserved — the recovered receipt, the journal voucher reference, the supplier acknowledgement, the IMS action taken, the write-off note. The auditor reading the trail next year sees the same artefact the resolver attached.
Tamper-evident chain
The trail is append-only and tamper-evident. Edits do not overwrite history; they extend it. The chain is engineered for statutory audit, internal audit, ICFR attestation, SOX-equivalent control testing, and direct production to a CAG or RBI inspection without an out-of-band rebuild.
See the security sub-page for the certifications, controls, and data-residency posture that surround the trail.
Configurable per industry preset
The taxonomy is universal. The routing is per-tenant. A partial-settlement variance does not mean the same thing to a hospital’s TPA team that it means to a D2C brand’s marketplace audit team — and TransactIG ships with the industry preset for both.
| Industry preset | Routing behaviour |
|---|---|
| Hospital and TPA | Partial-settlement variances route to a clinical-coding review queue paired with the TPA remittance advice. The taxonomy class is universal; the queue is configured for the medical-coding team that owns under-paid claim follow-up under IRDAI guidelines. |
| D2C and marketplace | Partial-settlement and fee variances on Razorpay, PayU, Amazon, Flipkart, and Meesho settlements route to a marketplace-fee-audit queue with the gateway statement and the platform commission grid pre-attached. The audit team works exceptions, not extracts. |
| NBFC and lending | Missing-leg variances on disbursement and collection legs route to the credit-operations control queue. NACH return reason codes drive re-presentation logic and customer-contact templates separately from settlement reconciliation. |
| IT services and SaaS | TDS-withheld-not-booked variances against Section 194J professional payments route to the global customer-master enrichment workflow, with the Form 26AS extract verified before the credit is taken. |
| Manufacturing and ERP-heavy | Fee, TDS, and partial-settlement variances on SAP FI and Oracle Fusion integrations route to the plant-finance queue with the relevant cost centre and profit centre dimensions preserved through to the resolution voucher. |
Twenty-four-plus industry presets ship in production. The matching engine sub-page covers how presets drive the multi-pass pipeline; this page covers how they drive downstream routing on the residual.
How the taxonomy stops revenue leakage
Typed variance codes surface the seven classes of revenue leakage TransactIG was built to catch. Each leakage class below maps onto a code in the taxonomy and a routing rule that turns the exception into a recoverable action.
Gateway fees never booked back
Fee variance on every settlement batch. The MDR, GST-on-MDR, processing charge, and platform commission are typed at line level rather than absorbed into a single net receipt. The GST input credit on the MDR fee is queued for the next return — recoverable, not lost.
TDS withheld but never claimed in 26AS
TDS-withheld-not-booked variance pairs every customer deduction against the assessee 26AS view. Deductions that appear in customer ledgers but not in 26AS — or vice versa — are typed and routed to the deductor follow-up workflow before the assessment cycle.
ITC missed because GSTR-2B never reconciled to 3B
GST-ITC-mismatch variance, with the four sub-types (missing, value, GSTIN, late filing) each carrying its own supplier-side action. The IMS acceptance / rejection / pending flow is driven from the typed code rather than rebuilt monthly in Excel.
NACH bounces not re-presented
Partial-settlement or missing-leg variance with the NACH reason code preserved. Re-presentable codes (insufficient funds, technical reject) trigger the re-presentation calendar; non-re-presentable codes (mandate cancelled, account closed) trigger customer recovery.
Customer over-credits and unapplied receipts
Missing-leg variance on the receipt side. The over-credit is held against the customer master rather than parked in suspense, and the resolution workflow pairs it against the next invoice or returns it within the policy window.
Marketplace deductions absorbed into net settlement
Fee and partial-settlement variances typed per deduction class — return processing, advertising fee, FBA storage, channel commission. Each is its own ledger line rather than a single net Amazon SPN receipt that hides what was deducted.
Write-offs disguised as timing differences
Aged-write-off candidate variance, raised only after the timing-variance ladder has exhausted its resolution attempts. The write-off voucher carries the full ageing chain so the write-off is acknowledged, documented, and approved — not silently parked in other-receivables.
The Stop revenue leakage pillar covers the full Seven Classes framework and the buyer’s perspective. The Buyer’s guide cluster is the right starting point for an evaluation team.
Want the full variance catalogue and routing matrix?
Enterprise customers receive the full variance catalogue, the sub-code reference, and the routing-matrix template for their industry preset under NDA. Walk through it with the team that built it.
Request variance catalogue