The story before the software
Reconciliation software is usually pitched as matching software. But matching clean data is easy. The real job is surviving the data finance teams actually produce — files touched by tired clerks at month-end, exported from systems configured years ago by someone who left, maintained by people who know their business but not every section of the Income-tax Act.
And here is the reframe that changes the pitch. Many of these errors are not noise the software must tolerate — they are exactly what reconciliation exists to find. A payment recorded twice. An entry posted to the wrong month. A receipt that bounced but was never reversed. Finding these is the product. The failure mode of most reconciliation tooling is not that it cannot match clean data; it is that it presents itself as a matching engine when its actual job is a discovery engine.
So we built a catalogue of every human error we could enumerate — 57 of them, in five families — and we manufacture each one, deliberately, into realistic Indian financial data before any release. Each pattern comes with a pre-computed expected outcome: the right exception class, the right rupees, the right rule citation. A test only passes when the product surfaces the error exactly as specified. Silently absorbing an error, or — worse — letting an error improve the match rate, is an automatic failure of the test programme.
The five families at a glance
The 57 patterns are not a flat list. They fall into five families that behave differently, demand different controls, and pose different classification questions for the Detection Envelope. Each family card links to the full article that walks every pattern, with Indian regulatory context and a worked example.
Family 1 — Carelessness
The month-end-at-9pm class. Nobody is careless on purpose.
Byte-identical duplicates. Transposed digits. The fat-finger zero. Day and month swapped when the day is ≤ 12 and the file still parses. A return typed as a positive. The same file uploaded twice into two slots. These are what fatigue does to a clean process — they are not a moral failing, they are a working condition.
Read the full family →Family 2 — Knowledge gaps
Not carelessness — a wrong belief, applied consistently. The most dangerous family, because consistency looks like correctness.
The wrong GST rate on every invoice of a stream. TDS deducted under the wrong section, so the rate follows the wrong rule. CGST plus SGST where IGST belonged. Reverse charge missed on an RCM-liable purchase. Tax computed on the GST-inclusive base. Applied once these look like errors; applied consistently they look like policy — which is why they survive review.
Read the full family →Family 3 — Misconfigured systems
Nobody typed anything wrong. The software that produced the file was set up wrong — once, years ago.
Fiscal-year label shifted by one across every export. A UTC timestamp export moving month-boundary rows into the wrong period. Amounts silently exported in lakhs. Voucher numbers reset mid-year so the same number appears in both halves. A saved-view header that still says "Debit" while the column underneath now carries something else. Every entry is what the operator typed; every total is wrong.
Read the full family →Family 4 — Gaps in the data
What is missing is invisible by definition — unless the arithmetic is forced to account for it.
A missing fortnight in the middle of a statement. An entire bank account not supplied. A register that ends mid-month while the ledger runs full. Random rows lost across a stream. The hardest of all — the window-dressed truncation, where the tail is cut AND the closing balance restated to match, producing a file internally consistent with itself and internally inconsistent with the world.
Read the full family →Family 5 — Missing and mistimed entries
The quarry. These are not data-quality problems — finding these is what reconciliation is FOR.
Money in the bank, not in the books. Money in the books, not in the bank. The cutoff straddle. A reversal with no original. A bounce that the bank shows and the books do not. Cheques issued and never presented. The bounce pair — credit and return both in the bank at net zero while the books certify money that has already gone. This family is the reason the discipline exists.
Read the full family →Full sub-programme index and cross-references in the Reconciliation Error Catalogue hub .
What the Detection Envelope is (and what it isn't)
The Detection Envelope is a written, per-customer report Terra Insight delivers to every TransactIG deployment before go-live. It classifies every one of the 57 error patterns as one of three things — for the customer's own data shape, ERP configuration, and companion registers.
The product surfaces the error as the correct exception, with the correct rupees attached, on realistic data of your shape. Delivered as an exception on the register, with rule citation and audit trail.
Depends on the shape of your data or on a companion register being uploaded. The classification names the exact condition so the operator can either satisfy it or make a documented decision to accept the residual risk.
No reconciliation on earth can catch this class from the data supplied. Published as such — with the reason spelled out — so the exception plan is designed around it rather than under a false assumption that automation covers it.
What it is not
It is not a marketing claim that we catch all 57. We do not. And when we sell to you, we say so in writing, on the letterhead the auditor reads. The Detection Envelope carries the weight of a specification: an exception plan built around it is designed with clear eyes about what the automation does and does not cover.
It is also not a demo artefact. It is the document that names, for your data, which controls stay with the machine and which controls the operating cadence has to run around it — the four-eyes review at Day 5 bank sign-off, the independent tax review at Day 10, the controller gate at Day 15 that anchors the Section 16(4) ITC time bar, the sampling protocol the statutory auditor runs under Section 143(3)(i). Every structural miss on the envelope has a named human control that catches it instead.
Why this framing matters
Silently absorbing an error is a failure. Letting an error improve the match rate — because the wrong side quietly balances against the wrong side — is a worse failure. The test programme grades against both. The single most damaging thing a reconciliation engine can do is to look correct while producing wrong output, because it misleads the operator and gives the auditor false assurance. The Detection Envelope exists precisely so that every customer knows, in writing, which patterns are under the automation and which are not.
The structural-miss truism
An error consistent on both sides of the arithmetic is invisible to any cross-check ever built.
This is a mathematical property of two-sided comparison, not a limitation of any specific engine. If both sides carry the same wrong GST rate, the same day-month swap, the same rounded paise, the two sides agree and no cross-check surfaces an exception. The design implication is that the controls around a structural miss cannot be automation — they have to be the data-source layer, the four-eyes gate, the auditor's sample. Naming which of the 57 falls into this class for your data is how we make those human controls a plan rather than a hope.
Your auditor gets this document
The Detection Envelope is not an internal handshake. It is signed off jointly with the finance manager, the controller, and — where the deployment falls under Section 143(3)(i) reporting on internal financial controls, or under CARO 2020 Clause 3(ii)(b) reporting on quarterly bank statement reconciliation to books — the statutory auditor. The envelope becomes part of the reconciliation working paper file. Any material change to the customer's data shape, ERP configuration, or upstream data sources triggers a scheduled re-run so the classification stays truthful. Honesty is not a launch event. It is a maintained artefact.
What "tested against" means, precisely
The 57 are not a checklist we tick off in a review meeting. Each pattern is manufactured — deliberately — into realistic Indian financial data. A duplicate voucher is written into a bank narration file with the exact spacing an ICICI export uses. A transposed digit is planted into a ₹34,80,000 aggregated corporate wire so the split totals no longer reconcile against the six-invoice remittance advice. A day-month swap is inserted into an OEM debit-note stream where the day is ≤ 12, so the file parses cleanly on both sides and only the ageing bucket exposes the drift.
Every manufactured error carries a pre-computed expected outcome: which exception the engine should raise, what rupee value should be attached, which rule citation should appear on the audit trail, which classification the variance should carry. The test runner asserts against all four. A partial match is not a pass. A "close enough" match is not a pass. A match that raises the right rupees under the wrong classification is not a pass. Grading is binary and unforgiving because reconciliation grading in the real world is binary and unforgiving — every rupee ends up either recovered, at risk on the ageing ledger, or written off, and the classification determines which of those three the future looks like.
This is what allows the Detection Envelope to be written honestly. When we tell a customer a pattern is a catch, it is because the test manufactured the exact pattern into data shaped like the customer's and the product surfaced the exception with the right rupees. When we tell a customer a pattern is a structural miss, it is because the two-sided arithmetic itself does not permit detection — and we say so. There is no middle where "the demo worked" stands in for "the specification holds."
Why we do not publish which of the 57 we catch — on this page
The classification is a per-customer report, not a public claim. Whether the day-month swap is a catch depends on whether your bank export normalises dates to ISO or preserves the raw dd/mm string. Whether the fiscal-year drift is a catch depends on whether your ERP includes the year label in the export or infers it from the header. Whether the bounce-pair unbooked pattern is a catch depends on whether your bank statement carries the return code in the narration or in a separate flag column, and whether your books side certifies against a receipt register or against the aggregated day-total.
A one-size claim for all 57 would be technically wrong for every customer. It would be right on average and useless in any specific instance — which is the failure mode of the "99% accuracy" number that has quietly discredited most of this software category. The Detection Envelope substitutes a per-customer classification for a marketing average. What you get on the page is the frame; what you get in your envelope is the answer.
The public claim we do make: we test against every one of these 57 patterns; every test manufactures the error deliberately into realistic Indian financial data with a pre-computed expected outcome; and every deployment gets the resulting classification in writing before go-live. The claim on your data shape lives in the document delivered to your controller, not on this page.
Prepared for the worst
Most reconciliation tools are demonstrated on clean data. TransactIG is tested on sabotaged data — 57 distinct human errors, from a transposed digit to a bounced receipt the books never reversed, each deliberately manufactured into realistic Indian financial data with a pre-computed expected outcome. A test only passes when the product surfaces the error as the right exception, with the right rupees attached — silently absorbing an error, or worse, letting an error improve the match rate, is an automatic failure.
And because honesty is the product: we publish our Detection Envelope — the written statement of what we catch, what we catch conditionally, and what no reconciliation can structurally catch (an error consistent on both sides is invisible to any cross-check ever built). Your auditor gets that document. That is what "prepared for the worst" means.
The Terra Insight trust stack
The 57 Errors + Detection Envelope sits inside a broader body of published discipline — the annual leakage measurement, the reconciliation design method, the day-by-day operating playbook, and the product that runs against all three.
India Reconciliation Leakage Index 2026 →
The annual measurement of revenue leakage across TDS, GST, NACH, and platform settlements. Seven leakage classes, published methodology, no fabricated industry-wide rupee total.
Reconciliation Error Catalogue →
The full sub-programme index — five family articles, worked Indian regulatory examples for each of the 57 patterns, and the LinkedIn anchor post that opens the bounce-pair story.
Reconciliation Process Design →
The design method that identifies every way each reconciliation function can fail, rates the failures on Severity, Occurrence, and Detection, and specifies the prevention and detection controls. What the envelope sits above.
The Reconciliation Playbook →
The twenty-day operational cadence — bank, TDS, GSTR-2B, and GSTR-1 vs GSTR-3B as a synchronised sequence. Where the envelope's structural-miss controls turn into named sign-off gates on named days.
The 57 Errors — CA Reference One-Pager →
The full 57 patterns plus the Detection Envelope explanation, packaged as the trust artifact for the chartered accountant reviewing a reconciliation software choice on behalf of a client.
TransactIG →
Reconciliation infrastructure for Indian enterprises — 24+ industry presets, ISO 27001:2022, AWS Mumbai, DPDP Act 2023 aligned. The product that carries the Detection Envelope as a delivery artefact.
Detection Envelope — frequently asked questions
What are the 57 human errors?
How is the Detection Envelope different from a coverage claim?
Do you catch all 57 errors?
What happens if an error is consistent on both sides?
When do I receive my Detection Envelope report?
Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Request your Detection Envelope
The envelope is delivered inside the standard 2–4 week configuration window. Tell us your industry, ERP, and monthly transaction volume, and we will schedule the shape-mapping session that produces the report. ISO 27001:2022 certified. AWS Mumbai. DPDP Act 2023 aligned.