Match every rupee to the record it belongs to.
SmartRecon reads your bank statements, settlement files, billing exports and ledgers, works out how they connect, and matches them automatically. Whatever it can't match reaches a person with a plain-language reason and a suggested action.
Setup asks only what your data can't answer. No mapping screens.
Rising to 92–95% by month twelve, as the system learns from your team.
The AI model runs inside your infrastructure.
Two exports, one spreadsheet, half a morning.
Most teams still reconcile by exporting two files, pasting them into Excel and hunting for differences. It takes two to four hours. Errors surface at month-end, revenue sits unallocated, and the audit trail is a folder of spreadsheets.
- The bank sees one credit. The POS system has 400 transactions behind it.
- One bill, three payment modes. Card, wallet and cash must add up to a single bill total.
- Settlement lags the sale by one to five days, depending on provider and weekday.
- Fees and tax are deducted before payout. The amount that lands is never the amount billed.
- Item-level files run past 80,000 rows. They must be rolled up before they can be compared to a bill.
It learns how your files connect. You confirm a few things.
Traditional tools need an expert to map every column by hand. SmartRecon looks at the values inside your files and finds the connections itself.
In your card settlement file, the settled amount is consistently 1.8% below the charged amount. This holds across 1,089 rows.
Is 1.8% your contracted rate with the bank?
Evidence first, one bounded question, and "I don't know" is always a valid answer.
-
It reads values, not column names
A column called PYMT_CHGAMNT shares no words with "amount", yet its values match your POS amounts row for row. SmartRecon compares actual values across every pair of files, so odd headers stop mattering.
-
It rejects false connections
Two reference columns can look alike and share only 4% of their values. Those are dropped rather than guessed at. Above 95% overlap a link is applied without asking; borderline links become a question.
-
It finds fees and deductions by measuring them
When settled amounts sit a steady percentage below charged amounts, SmartRecon spots the pattern and asks you to confirm the rate. It never assumes one.
-
Five questions at most
Typical first-run questions cover the contracted fee rate, what is out of scope, whether split payments count as one bill, and which file is your source of truth. Templates remember the answers, so later clients are asked less.
-
Changes take seconds, not a reload
Discovery works on a 500-row sample of each file, so adjusting a mapping is near-instant. The full file is loaded once, in the background, after you confirm.
-
Later runs skip setup
Every run starts with a header check that takes milliseconds. Setup repeats only if a provider changes a column, you add a source, or a fee rate drifts from what you confirmed.
Matching that follows how money actually moves.
Seven resolvers run in order, each working on what the last could not match. Matching runs as indexed database queries, so results are fast, repeatable and explainable.
| Resolver | What it handles | What happens |
|---|---|---|
| Exact match | Reference, amount and date all agree. | Matched. No review. |
| Fee disaggregation | Gross ₹10,000 arrives as ₹9,820 after a 1.8% card fee. | Matched. The fee is recorded separately, against the rate you confirmed. |
| Tolerance band | A ₹6 rounding difference between two systems. | Matched within limits you set, such as ₹10 or 0.5%. |
| One payment, many invoices | ₹1,00,000 with no reference, against open invoices of ₹40,000, ₹35,000 and ₹25,000. | Finds the combination that adds up, oldest invoices first. |
| Many payments, one invoice | Monthly instalments that together close one invoice or loan instalment. | Keeps a running balance across runs and closes the invoice on the last payment. |
| Many to many Person review | Several payments against several invoices with no clean pairing. | Proposes an allocation. A person always approves it. |
| Learned matching | A mistyped reference or a partial narration. | Uses the payer's history: known accounts, usual payment day and mode, usual deductions. Matches when confident, suggests when not. |
| TDS deduction India template | A payment short by exactly 2%, 5% or 10% of the invoice. | Recognised as tax deducted at source. The TDS receivable entry is prepared. |
Matched against the open balance
Each invoice is first reduced by credit notes, prior payments and write-offs. Matching against the original invoice amount is the most common cause of false exceptions in standard tools.
The payer is identified first
The customer is established from invoice references, remittance advice, registered bank accounts and UPI handles before any amount is compared. Amount alone never identifies a customer.
Split and bulk records are handled
A bill paid as ₹800 by card and ₹200 by UPI can be matched as one unit. An 87,000-row item file is rolled up to a few thousand bill totals before matching starts.
Built for how India pays, and how files really arrive.
The engine is shared. The domain knowledge sits in templates, so Indian payment rules are handled by design, not bolted on.
Payments
- UPI, NEFT, RTGS, NACH, cards and cash slips reconciled in one run.
- Card and gateway fees including GST on the fee, checked against your contracted rate.
- TDS at standard rates, with the receivable entry prepared automatically.
- UPI handles read correctly. A handle that repeats across a customer's payments is treated as identity, not as a transaction reference.
- Bounces and reversals are detected and handled, including NACH returns.
- Settlement lag of one to five days is absorbed by date tolerance.
Files
- Non-standard layouts. Headers are found by scanning the first 50 rows, including files with summary blocks above the data.
- Split files, such as a register delivered as two half-months, are merged automatically.
- Duplicates are caught by file fingerprint, so the same file is never counted twice.
- Totals are checked. If a settlement file states a total, SmartRecon confirms it against the sum of its rows.
- Late sources. For each source you choose whether a run waits, runs without it, or blocks.
- Large files. Files up to 500 MB stream into the database instead of into memory.
Every reconciliation starts with a question.
The question decides which source is the starting point and what every percentage means. One run produces separate views for each role, so no one is handed a blended number.
Which customers haven't paid?
- Fully paid785 (72.8%)
- Partly paid144 (13.3%)
- Unpaid150 (13.9%)This becomes the chase list.
Do we know where every rupee came from?
- Fully allocated847 (94.0%)
- Partly allocated32 (3.6%)
- Unallocated22 (2.4%)Unidentified money, to investigate.
Figures shown are from an illustrative franchise collections run.
Exceptions your team can act on in seconds.
Unmatched items don't land in a spreadsheet. Each one arrives as a short explanation, a suggested action, and the data one click away.
₹42,300 payout from a marketplace
This payout doesn't match any combination of open invoices within tolerance. It may be an unclaimed return deduction.
Show the data
Payout of ₹42,300 received 12 September. Nearest open invoice combination: ₹43,050, a gap of ₹750. This marketplace has deducted returns before.
-
One exception at a time
Plain language first, data collapsed by default. No UTR numbers or account codes until the reviewer asks for them.
-
Three actions at most, named for what they do
"Raise dispute with the bank", not "Submit". Every decision is recorded and feeds the learning loop.
-
Patterns surfaced, not just items
If three of today's exceptions come from the same branch, the morning summary says so. It points to a batch delay rather than three unrelated problems.
-
Wording that fits the reader
The same exception is explained in invoice terms to an AR manager and in credit terms to treasury.
-
Minutes, not hours
In a reference retail run, a first-time client spent about 3 minutes on setup questions and 18 minutes clearing exceptions. That compares to three to four hours by hand.
It gets more accurate every cycle.
Accuracy improves from accumulated evidence: confirmed matches, reviewer decisions and payment history. Nobody has to tune parameters.
Typical share of transactions auto-matched (shaded range), with approximate daily review time underneath. Based on a retail settlement reference implementation.
-
Within your job
Each confirmed match updates the payer's profile: known accounts, usual payment day and mode, typical deductions. When reviewers resolve the same kind of exception the same way again and again, later runs arrive with that action pre-suggested.
-
Across a template
Once a pattern is confirmed by several clients, such as a provider's fee rate or a column link, it becomes a template default. The next client is asked nothing about it.
-
In reviewer decisions
Resolutions that repeat consistently are promoted to suggestions. A new reviewer sees "Raise dispute with the bank" pre-selected because it has been the right call before.
AI does the reading. People keep the authority.
Financial decisions carry accountability, so SmartRecon draws a clear line between what the system does alone and what it never does.
Handled automatically
- Column types and roles, inferred from values
- Connections and systematic differences across files
- Loading files and running the matching pipeline
- Plain-English narration of every exception
- Learning from reviewer decisions
Confirmed once by you
- Contracted fee rates
- What is in and out of scope
- Whether split payments count as one bill
- Which file is your source of truth
Never done without a person
- Raising a formal dispute with a provider
- Writing off a difference
- Approving a many-to-many allocation
- Anything above your high-value threshold
- Changing a matching rule
The AI runs locally
Language-model steps use a model hosted inside your infrastructure. No data leaves your environment.
Identifiers are masked
Names, account numbers and IDs are replaced before any model call. Amounts stay, because they are needed for an accurate explanation.
The model never decides a match
Matching is deterministic and repeatable. AI explains and suggests. It doesn't match, post or dispute.
Every stage is restartable
Each stage stores its output independently, runs in the background and reports live progress. Nothing waits on a screen.
How a run works.
Three stages happen once, at setup. The rest run every cycle, in the background, until a person is needed.
Collect files
Upload, bank-portal bot, folder watch or API. Split files merged, duplicates dropped.
Read a sample
500 rows per file: types, ranges, gaps and constants.
Find connections
Values compared across every pair of files.
Confirm
You answer the few questions the data can't.
Load and match
Full load into the database, then the seven resolvers.
Explain exceptions
A plain-English reason for each unmatched item.
Review
One exception at a time, with a suggested action.
After the first run, stages 2 to 4 are skipped. A header check confirms the files still look the same, and only the affected setup steps repeat if something changed. A typical recurring run takes about eight minutes of machine time.
Only new work is processed. Each run handles new records and earlier open items. Anything already matched is left alone, so runs stay fast as history grows.
Timings are from a retail POS reference run: eight sources and about 4,200 records a month.
One platform, configured for your domain.
The matching engine, exception workflow and role-based views are shared. What changes per template is the business logic: how fees and TDS are treated, what counts as a match, and who sees what.
Retail and POS settlement
Billing, POS aggregator and payment provider files: cards, UPI and wallets across outlets.
B2B invoices and franchise collections
NEFT, RTGS, UPI, NACH and cash receipts against open invoices in your ERP, including partial payments, instalments and TDS.
NBFC loans and EMIs
Bank credits, the loan system and the general ledger, with EMI instalments, prepayments, penal interest and bounces.
Bank reconciliation
Every credit and debit in the statement allocated to a source transaction, across banks and payment modes.
Marketplace settlements
Payouts reduced by commission and tax collected at source, matched to the invoices they settle.
Supply chain three-way match
Purchase order, goods receipt and vendor invoice, including partial receipts and quantity differences.
Healthcare collections
Lab and hospital billing against corporate and patient payments.
Your own scenario
A custom template starts with no prior knowledge and learns everything from your files.
The same approach applies to partner and channel commission reconciliation, direct and indirect tax reconciliation, inventory reconciliation across ERP and warehouse systems, and vendor invoice and payment reconciliation.
Runs on IB-X, alongside the systems you already have.
SmartRecon doesn't replace your ERP, loan system or bank. It sits between them, and IB-X agents handle the work around the matching.
Bring the files in
Unattended bots log into bank portals, including ones behind your firewall, and download statements on a schedule.
Run the cycle
Schedules, per-source waiting rules, exception routing, SLAs and escalation are orchestrated in one workflow.
Post what's approved
Approved allocations are written back to NetSuite, SAP, Tally or your ERP, under posting controls your finance team signs off.
See everything
Every run is logged with status, step-level detail and an exportable audit trail. Deploy as SaaS or self-hosted.
Questions finance teams ask.
Do we have to replace our ERP or loan system?
No. SmartRecon pulls from whichever systems you have, does the matching, and posts approved entries back through connectors. Your systems of record stay as they are.
Why 75–82% in the first month, not higher?
Because it starts with no payment history and no client-specific edge cases. Those two things are what close most of the gap, and they only exist once the system has seen your data. The 75–82% that matches is matched with no human involvement, and the rest arrive as explained exceptions, not raw rows. Rates typically climb to 84–88% in month two and 89–91% by month three.
Does our data leave our network?
The language model runs locally inside your infrastructure, and identifiers such as names and account numbers are masked before any model call. The model explains exceptions. It does not decide matches.
Can it write off differences or raise disputes by itself?
No. Disputes, write-offs, many-to-many allocations and anything above your high-value threshold always need a person. Those steps require authority, and every decision is logged.
What happens when a bank or provider changes a file format?
Each run checks the header row of every file first. If a column has been renamed or added, only the affected setup steps repeat for that source, and you're asked only about what changed.
How long does setup take?
The system's part takes under a minute on a sample of your files. Your part is a few minutes answering questions, not days of expert mapping. Full loading and matching then run in the background.
See what SmartRecon finds in your files.
Share a sample of your exports and we'll show you the connections it discovers and the matches it makes.