Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Finance-IT teams build TDS and bank reconciliation in-house because the first version is quick, then spend years maintaining parsers, rules and audit controls.
List recurring maintenance events, the controls an audit-ready build needs and who fixes each, then compare three-year effort in people-days against a bought platform.
A decision table of factor, in-house, bought platform and question to ask, with an accountability column, filled in with the reader's own inputs.
A build-or-buy decision based on three-year effort and accountability rather than first-month effort.
An in-house TDS and bank reconciliation tool is easy to start and costly to keep. Bank statement formats drift, TDS forms and codes change every year, and the audit trail and exception queue need design work most first versions skip. Compare three-year effort in people-days, not first-month effort.
If your team still works in spreadsheets, start with when manual reconciliation tops out and Excel and Python vs reconciliation software. This page is for finance-IT teams with developers who are weighing a build.
What keeps breaking in a custom TDS and bank tool?
| Event | What breaks | Who must fix it |
|---|---|---|
| Bank changes statement layout or narration format | Parser fails or matches drop | Developer |
| New bank account or new bank added | New parser and rules | Developer |
| TDS forms change (Form 26AS to Form 168, Form 16A to Form 131, from 1 April 2026) | Import and mapping | Developer and tax team |
| Section-to-code change (194J to code 1027, 194C to codes 1023 and 1024) | Matching keys | Developer and tax team |
| Rate change (Section 194H from 5 percent to 2 percent, 1 October 2024) | Expected TDS checks | Tax team, if rates are settings; developer if hard-coded |
| ERP upgrade or new export column | Ledger import | Developer |
| Tolerance rule changes | Match logic | Developer and finance |
| Author of the tool leaves | Everything above | Nobody, until someone learns the code |
The last row is the common failure. The reconciliation failure mode analysis shows how these breaks surface as unmatched items months later.
What must a build include to be audit-ready?
Most in-house builds start with matching and add controls later, if at all. An audit-ready build needs:
- Edit log that cannot be disabled. The proviso to Rule 3(1) of the Companies (Accounts) Rules, 2014, in force from 1 April 2023, requires this for accounting software, and auditors apply similar tests to tools that feed the books.
- Maker-checker on manual matches and write-offs.
- Period lock so closed months cannot change silently.
- Evidence export linking each match to its source rows.
- Access control by role, not shared logins.
- Re-runnable months that produce the same result.
Each is a design task, not a patch. See can auditors rely on reconciliation software reports for the tests an auditor runs.
How do build and buy compare?
| Factor | In-house | Bought platform | Question to ask | Accountable when a match is wrong |
|---|---|---|---|---|
| First version | Weeks | Evaluation and setup | How long to a first closed month? | Build: your developer. Buy: shared |
| Bank format changes | Your developer | Vendor | Who notices a format change, and how? | Build: you. Buy: vendor for parsing |
| TDS form and code changes | Your developer and tax team | Vendor supplies, you approve | How was the April 2026 change handled? | Shared |
| Audit controls | Must be designed | Should exist; test them | Show me the edit log and rule history | Build: you. Buy: vendor for the feature |
| Key-person risk | High | Lower | Who maintains it if one person leaves? | Build: you |
| Fit to your process | Exact | Configured | What cannot be configured? | Both |
Measure effort in people-days rather than rupees, so the comparison holds whatever your salary costs.
What does a three-year effort count look like?
Illustrative template, to fill with your own inputs: two analysts and one developer run the in-house tool. List the recurring events for a year:
- Bank format changes: 4 a year at 3 developer-days each = 12 days
- TDS form, code or rate change: 2 a year at 5 days each (developer plus tax team) = 10 days
- ERP upgrade or export change: 1 a year at 5 days = 5 days
- Audit-request support: 2 a year at 4 days each = 8 days
- Analyst time on exceptions the tool cannot explain: 2 days a month = 24 days
That is 59 people-days a year, or 177 over three years, before any new bank, entity or control is added. Replace each figure with your own history. Then ask a vendor which of those events it absorbs and which still fall on your team.
If you build anyway, what should you insist on?
Some teams will build, and for a narrow, stable process that can be right. If you do, set four rules from day one:
- Rates, thresholds and codes as dated settings, never hard-coded. When Section 194-I rent moved to ₹50,000 per month from 1 April 2025, a settings change should have been enough.
- Two people who can maintain the code, with written documentation of every parser and rule.
- Controls before features. Ship the edit log, period lock and maker-checker before adding a second bank.
- A yearly review against a bought platform, using the effort count above. If maintenance passes the build effort, revisit the decision.
How Terra Insight fits
TransactIG delivers TDS reconciliation and bank-to-books reconciliation with an exception queue, audit-ready exports and configurable industry presets, which covers the buy column for those two streams. The reconciliation software comparison page sets out the wider evaluation dimensions; pricing is discussed in discovery. For aggregator streams in restaurants, see the restaurant build vs buy framework.