From systems of record to systems of activity
The belief I started with, and still hold: the value is moving from where data is stored to where work is decided.
Every piece of finance software built in the last thirty years is a system of records. Tally records transactions. SAP stores ledger entries. These systems are passive — they wait to be queried. They don't know the close is three days behind, that a vendor was paid twice, or that this quarter's TDS is being computed under the wrong section.
The human is the active intelligence. The accountant opens the report, notices the anomaly, chases the exception, closes the month. The software is a warehouse. The human is the worker.
Finance operations is ten years behind sales in making that shift. From my product charter, June 2026
In the CRM transition, the activity layer captured the value — not the record layer. In Indian finance the record layer is already spoken for: Tally holds 90%+ of SMB books. The activity layer is not yet built. That is the bet I have been making with my time.
Signal over noise
The product is not the automation. The product is the exception.
Out of three hundred reconciled transactions, the value sits in the thirteen that got flagged — each with a plain-language reason and a recommended resolution. The other 287 are a log, not a view.
This wasn't a UX preference I argued for. It was something a real client's statutory books proved to me.
The matching engine confirmed everything was fine. The checker found the money. Three vendors sat in Brokerage & Commission ledgers with no corresponding Form 26Q entry — exposure carrying 1%/month interest under §201(1A) and potential 30% disallowance under §40(a)(ia).
A reconciliation tool finds mismatches between two declared records. What creates real exposure is the record that isn't there — and finding an absence means reasoning forward from the expense head, to the section that should have applied, to the threshold, to the silence where a filing should be. That reframing changed what I thought I was building.
Finding the problem
Who is in enough pain to change how they close their books — and who can actually decide to pay for that change?
Before writing a line of agentic workflow code, that was the question I kept coming back to. The answer moved once, and moving it is the most useful thing I learned all year.
I mapped Indian SMBs by how they actually staff accounting at each revenue band — not how they should, but what I saw on the ground.
| Annual revenue | The business | Who does the data entry | How often |
|---|---|---|---|
| < ₹1 Cr | Small kirana, daily essentials | The CA sends a junior accountant to collect bills and receipts | Once a month |
| ₹1–5 Cr | Larger store — e.g. cloth retail | A junior accountant sits in the shop and enters bills into Tally on site | Weekly |
| ₹5 Cr+ | Modern retail | 1–2 outsourced staff dedicated to the business | On site, most days |
| ₹5–15 Cr | Modern retail with its own brand | One fully dedicated accountant — still outsourced, not yet in-house | Daily |
| ₹15 Cr+ | D2C brand with strong digital presence | The business hires its own full-time in-house accountant | Daily, in-house |
Somewhere between ₹5 and ₹15 crore, a business is paying for a dedicated resource but hasn't yet decided to own the function. Real recurring spend on bookkeeping, real dependency on someone who isn't their employee, and no owned system of record for how that work gets done. That's where I aimed.
To reach them I went through the top 300 CA firms — not as the end customer but as the channel, chosen for the AI-implementation muscle that separates them from the median firm. That choice wasn't about reach. Three things made a firm a far better place to stand than any single business.
One firm carries 200–400 clients. Standing behind a single firm meant watching the same pain repeat across hundreds of businesses at once — rather than discovering it one company at a time, one sales call at a time.
A firm that size can fund building an AI capability for its own team, and has someone inside who can run it. A single ₹5–15 Cr business has neither the budget nor the person, and won't grow one for this.
The firm sees what actually happened to the end client — what got filed, what got disallowed, what the auditor flagged, what the notice said. That feedback loop is the only thing that makes a system smarter month over month.
Taken together: my bet was that a firm capable of running a pilot moves faster than the businesses themselves, and teaches you more per conversation.
What I actually tested
Not a survey — a real go-to-market motion over roughly six months. Outbound to 300+ large firms, pitching at the AI Summit at Bharat Mandapam, and POCs at VSN&Co, HNA (Hiregange & Associates), Guru & Jana, Kuhoo Finance and Taxpert.
Five proofs of concept
Not pitch decks. Five firms handed over real books and real people, and I built against each of them.
They are listed and dated by when each engagement began. Each POC targeted a different finance workflow, identified through a customer journey discovery workshop run with the firm — mapping how work actually moved through their team, where it stalled and who it stalled on, before anything got built. Together — after months working alongside their teams, not weeks of interviews — they are the reason I can describe this market from the inside rather than from a survey.
The first build, and where the thesis met a screen. A CFO cockpit with a structured query contract: every answer has to arrive carrying the evidence rows it was derived from and an explicit statement of what it could not determine. The reasoning layer, not the frontend, chooses which KPIs and charts answer the question.
What it taught me: the layer from ledgers to MIS to dashboard is broken at every joint — each asset sitting with a different person, each maintaining their own version. A dashboard built on top of that cannot answer with atomic visibility; it shows numbers nobody can trace back to a transaction. The problem was never the chart.
The full lifecycle of bank fixed deposits for a multi-entity group across four jurisdictions — booking, approving, accruing, posting. Maker, Checker and CFO roles, with approval tier derived from the deal's own economics rather than picked from a dropdown. Control enforced at the database: six Postgres roles whose grants make a forbidden write impossible even if the application layer has a bug.
What it taught me: controls and decisions belong to the user; agents are for task execution. Enforce that split at the lowest possible layer — and never let a user declare their own authority.
Form 26Q declarations reconciled against a live company's Tally books, section by section, across a full financial year. A five-pass matching cascade, then a separate compliance checker that reasons forward from the expense head to the section that should have applied — and flags the filing that was never made.
What it taught me: the exception is the product. Matching confirmed everything was fine; the checker found the money.
The agentic build. An articled-clerk agent that reads Tally, reconciles GSTR-2B against the purchase register, chases missing vendor confirmations over WhatsApp, drafts the corrective journal entries and queues them for partner sign-off. Every tool declares a risk tier; the ones that write to the ledger don't execute at all until a partner types CONFIRM.
What it taught me: the buyer is the partner. Replace the grunt hours, never the judgment — and brand every vendor message as the firm, never as us.
Lekha AI for GST compliance — the whole monthly and quarterly lifecycle in one loop: GSTR-1, GSTR-2B reconciled against the purchase register, GSTR-3B, and challan creation. The 2B reconciliation is the painful part and mandatory monthly for ITC claims, but the value is in never leaving the loop. The build's answer to hallucinated compliance rules: a curated registry of versioned statutory rules, each with a citation, an effective-date range and a named owner. Where no rule fits, the agent must escalate rather than reason from training data.
What it taught me: for a CA firm to be genuinely empowered, the end client has to be the ultimate user of the system — an answer that stops at the firm's desk never reaches the person whose books it concerns. And the human-in-the-loop thesis held: citations made every answer checkable, and a person still made the call.
Interest was high at every one of them. All five ended on the same sentence.
Same thesis. A different person on the other side of the table. The specifics are in 07.
Why Indian CA firms aren't ready for agentic systems yet
This isn't a hedge. It's the thesis I'd defend in a room, and I'd genuinely like to be argued with on it.
Agentic adoption is still genuinely early here, and the reluctance is not ignorance. These firms have watched good sellers end up at the mercy of Amazon and Flipkart — dependent on a platform that later set the terms. Handing an agent the keys to a client's books looks, from where they sit, like the same trade.
An agent is not finished when it is built. Consistent, predictable outcomes come from running it over and over against one client's real context — and those cycles are where the AI brain actually matures. That phase needs AI engineers on payroll for months. It is capex, not a subscription, and nobody in this chain is funding it.
With Claude Code on the desk, a capable firm can build its own workflows — and every week that works raises their confidence that doing it in-house is real rather than theoretical. That growing confidence was the most effective competitor I met, and it isn't a product I can outbuild.
India is a genuinely different market to sell AI-native services into. You cannot price at pre-AI, legacy-bookkeeping rates while you are the one running and owning the service end to end with AI. A subsidised entry price is a real option — but it is a strategic bet that needs funding behind it to burn.
Choosing the vertical
Move the ICP from the custodian to the entity that owns its own books — then work out which kind of business that should be.
The refusal in chapter one told me what to stop doing. Before committing to any segment I ran the field through four filters, each one drawn from something the CA-firm chapter had already cost me to learn. Anything that failed a filter was set aside, however large the market looked.
D2C and e-commerce brands selling through quick commerce — Blinkit, Zepto, Instamart — and the marketplaces clear all four. They own their books outright, their deductions come with claim windows measured in working days, the line-item volume is punishing, and every platform already publishes the data through a portal. I kept CA firms as a referral and credibility layer, not as the channel.
Quick commerce, specifically
Sellers get paid net of deductions, and the deductions never arrive with the sale.
The pain, specifically
Sellers get paid net of deductions, and those deductions never land in the same accounting period as the sale. Six deduction types arrive from Blinkit, Zepto and Instamart across four different systems, on four different days — and each platform does it its own way. Left unmanaged, books lag reality by two to three weeks.
It's getting structurally worse, not staying flat. Blinkit moved to a 1P inventory model on 1 September 2025 — reconciliation now happens at PO ↔ GRN ↔ invoice ↔ debit-note level rather than order level, and every short supply legally requires a GST credit note. Instamart is heading the same way. Zepto's RTV process is its own trap: it arrives as a tax invoice on the vendor requiring a purchase voucher, but the original sale never reverses — quietly inflating both sales and purchases and breaking P&L reconciliation if nobody catches it.
And there's a hard clock. Miss the claim window and the deduction is simply unrecoverable.
Which segment, and why
I ranked segments by where the deduction pain is structurally worst, not biggest in absolute size.
(agency estimate)
ad deductions (Redseer)
one ₹4 Cr brand
The evidence, graded honestly
The pricing learning — the one I'd lead with next time
Pricing is the friction in AI adoption. Not capability. The buyer needs a value proposition they can compute, and if they can't compute it they wait.
I did not read this. I paid for it — across six design partners and more than fifty businesses, over a year of conversations that ended politely and went nowhere.
The mechanism, in one line
Deductions are not a reporting problem. They are a cash problem. An unreconciled deduction is a receivable you cannot confirm, and a receivable you cannot confirm is working capital you cannot deploy. Manage the deduction stream, AR becomes predictable, and predictable AR is capital released.
What fifty conversations actually taught me
A config-driven, per-client agentic pipeline — not a generic rules engine. SKU and ledger mapping learned from each client's own historical vouchers rather than a one-size-fits-all chart of accounts. Every credit note drafted and reviewed before it posts; nothing writes to Tally without a human check. Failed postings become exception records with a suggested fix, never a silent retry.
Architecture of trust
Everyone is shipping an agent. The question is whose agent a finance team will let near the ledger.
The answer I arrived at is not a feature list. It is a claim about what is actually scarce.
Every component I built exists either to protect that budget, or to earn the right to spend one unit of it. The claim I would defend in a room
What earns the right to interrupt a human
Most of the work is deciding what never reaches a person. The rest is justifying the few times you do.
Two ways to keep the budget cheap
The 10,000-row rule. Would this agent still work if the file had ten thousand rows? If the LLM sits inside the iteration loop, no — cost and latency scale linearly with volume, which is an architecture mistake rather than a scale problem. The LLM takes the supervisor seat; tools do the iterating. That's why the reconciliation engine has no LLM in its matching path at all.
Rules the model is forbidden to invent. The dominant failure of LLMs in compliance is confident invention of a plausible rule. I answered it structurally: a curated registry of versioned compliance rules, each carrying a statutory citation, an effective-date range, a named owner and a review date. Every conclusion carries the rule IDs it applied. When no rule fits, the agent must flag the line as a gap and escalate. It may not reason from training data. Because rules are versioned by effective date, a historical period gets reconciled under the rules that applied then.
What one unit of attention actually buys
Here is a real exception from that run, at full size. Everything I believe about this product is visible in one card.
ex-005 from the committed reconciliation fixture, rendered as the product renders it. Note what the card refuses to do. It does not show a confidence score alone, it does not offer a “post anyway”, and the rule it cites carries a version, an owner and a review date so a partner can disagree with the rule rather than with the machine.The rule behind the rules: autonomy is earned against reversibility
Three tests decide whether a feature ships — can it explain itself, can you stop it, does it ask before anything irreversible. But tests are pass/fail, and what I actually needed while building was a way to decide how much autonomy a given action had earned. This is that decision, drawn.
How the gate is enforced
A gated tool's handler doesn't execute and then ask forgiveness. A separate function builds the approval request without performing the action, so there is no code path where the side effect happens before a human sees it.
Descope autonomy, not intelligence. Core product thesis
Lekha, as an operating system
Every piece of finance software built in the last thirty years is a system of records. It waits to be queried. The human is the active intelligence in that arrangement.
Tally records your transactions. An ERP holds your asset register. None of them know your close is three days behind, or that a vendor payment went out twice, or that a quarter's TDS is being computed under the wrong section. They store what happened. Somebody has to open the report before anything is noticed.
The consequence of the last section is that this can be inverted. If attention is the scarce resource, the software should be the thing that works continuously and the human should be the thing that gets interrupted rarely — which is the opposite of how finance software has always been arranged.
The builds aren't separate products. They're the layers of one, discovered in the wrong order — modules first, platform last, because that's the order the design partners arrived in.
Tally is desktop software; its only programmatic door is an XML gateway on localhost:9000, and a browser on an HTTPS page can't call it. That one constraint explains the shape of the whole market — why most tools shuttle CSVs, and why the cloud suites have to ask the SMB to migrate. I shipped a signed Windows connector, then documented ten reasons my own architecture was wrong, and rebuilt it to dial outward over TLS so automation runs without a human sitting at a browser.
Three separate products independently needed it. That convergence is what told me it's infrastructure rather than a feature.
What I want to do next
One workflow, taken all the way — the opposite of the last eight months.
The ICP is settled, the price fit is found, and the first customer is paying. The right move now is depth, not breadth: take quick-commerce deduction reconciliation from one live account to a repeatable product, in the segment where the pain is structurally worst and getting worse.
That means closing the loop end to end — platform deductions ingested, reconciled against the seller's own books, credit notes drafted and posted into Tally under human approval, exceptions surfaced in an activity feed with the claim-window clock visible. Nothing in that path needs an invention. Every piece is either shipped or specified. It needs hands, and a narrow enough focus to use them in one direction.
Alongside it, I'm continuing structured seller interviews across health/nutra and beauty to see how far the pricing holds across the segment.
If any of this is your world, I'd like to talk
If you run finance at a D2C or quick-commerce brand and the deductions above sound like your month — I'd genuinely like to hear how you handle them today, whether or not you ever become a customer.
If you're building in this space — reconciliation, book close, or finance agents for the Indian market — I have a year of expensive negative results and one hard-won ICP. Most of it is more useful to you before you spend the money than after.
If you're a larger company adding AI to an existing finance product — a compliance platform, an accounting suite, an order-to-cash or ERP player — what's here is a working Tally write-back layer, a validated deduction taxonomy for quick commerce, an agent safety architecture that survives a CA's scrutiny, and a map of which segments have budget and which don't.
And if you're just a founder who's curious how a year like this actually goes — that conversation is free, and I've been on the other side of it enough times to want to pay it back.
Going deeper
Six product dossiers, each committed to its own repository. Every number on this page traces back to committed source.
The shared substrate. The market barrier, my own v1 self-critique, the v2 outbound architecture, the Tier 1 write-back spec, read-side validation on 4,758 vouchers.
The engine, the five-pass cascade, the omission checker, and the full measured run against real client statutory filings.
Derived approval tiering, six role-bound database engines, append-only audit, and the full process record.
The charter, the three design tests, the 10,000-row rule, the cockpit query contract, and the CFO-facing narrative deck.
The gated agent loop, the compliance registry, hash-chained audit, 334 traceability tags, and a trace-level evaluation framework.
Seven steps, two gates, tokenized approval, real role enforcement — and the accounting question we refused to guess.