Your bank has been emailing you a receipt for every transaction for years. Each UPI debit, card swipe, salary credit and autopay mandate arrives as a machine-generated alert with an amount, a date and an account attached — which means a complete, timestamped record of your spending already exists, sitting unread in Gmail. The work of expense tracking in India was never collecting the data. It was reading it.
Open Gmail and search for the sender your bank uses for alerts. What comes back is not marketing. It is a stream of automated notices, one per event, each generated by the same template every time. That consistency is the whole reason this works: a human-written receipt is unpredictable, but a system-generated alert has the amount in the same place in every single message.
Five kinds of alert carry almost everything worth tracking.
| Alert | Triggered when | Usually carries |
|---|---|---|
| UPI debit | You pay a person or merchant | Amount, payee VPA, date and time, account tail, reference number |
| Card transaction | A credit or debit card is authorised | Amount, merchant string, card tail, date, sometimes city |
| Credit received | Salary, refund or inbound transfer lands | Amount, remitter name or narration, date, account tail |
| Mandate notice | An autopay or e-mandate is due or executed | Amount, merchant, due date, mandate reference |
| Statement | A card or account billing cycle closes | Total due, minimum due, due date, full transaction list |
The first four are the live feed. The fifth is the reconciliation: a statement email is the issuer's own authoritative list, which is useful precisely because it can be checked against the individual alerts that arrived during the same cycle.
The distinguishing property of an email alert is not that it contains the transaction. An SMS contains it too. It is that the email persists. Alerts sit in the mailbox until deleted, so the history is readable on the day you first connect rather than accumulating from that day forward.
Most Indian expense apps historically read the SMS inbox instead, because bank alerts arrive there too and the text is shorter and easier to parse. That route has narrowed considerably.
On Android, Google Play's policy on SMS and Call Log permission groups restricts those permissions to apps that are the user's default handler for SMS, phone or assistant, and limits use to functionality core to the app's stated purpose. An expense tracker is not a messaging app, so it does not qualify as a default handler — the same constraint Android's own developer documentation describes. Where SMS is genuinely needed for one-time verification, Google directs developers to the SMS Retriever API, which hands the app a single matching message rather than the inbox.
On iOS the route never existed at all. Apple ships MessageUI for composing a message the user then sends, and no public framework for reading the messages that arrive. There is nothing to request and no permission prompt to grant.
Email sidesteps the question. A mail API is a documented, revocable, read-only integration on both platforms, which is why it is the one mechanism that behaves identically on an iPhone and an Android phone. That platform asymmetry is worth understanding on its own terms, and it is covered in more depth alongside how automatic expense tracking works in India.
Take a single UPI debit notification. Stripped of its formatting, the useful content is roughly: an amount, a payee identifier, a timestamp, the last few digits of the account, and a reference number. From those five fields a parser produces one row.
Worked example, with the assumptions stated. Suppose a month contains 180 such alerts across one bank account and two credit cards. Assume each alert yields an amount and a date reliably, since those are numerically formatted and appear in a fixed position. Assume the payee string is reliable as an identifier but not always as a name. Then:
@ handle, land in an uncategorised bucket until told once what they are. A neighbourhood grocer stays a phone number until you name it.The important distinction: the total is exact from the first day, because it depends only on amounts. The breakdown improves over the first few weeks, because it depends on naming. Any tool claiming a perfect category split on day one is describing something other than what the data supports.
Being specific about the failure modes is more useful than claiming there are none.
Cash is invisible. An ATM withdrawal produces one debit alert. What the cash then bought produces nothing at all. No parsing improvement fixes this, because the information was never created.
Merchant names are frequently unhelpful. A UPI alert carries the payee's Virtual Payment Address, which the recipient's bank assigned; it is an identifier, not a shop sign. Card alerts carry the merchant descriptor from the payment network, which is often an abbreviated legal entity name bearing little resemblance to the brand on the door.
Refunds and reversals arrive as separate credits, sometimes days later, and have to be matched back to the original debit or the month looks worse than it was.
Alerts can be switched off. Email alerts are frequently disabled by default in favour of SMS. An account whose email alerts were never enabled contributes nothing, and the gap is silent — nothing indicates that a fifth account exists.
The honest test of any tracker is whether its monthly total matches your statements. If it does, the arithmetic is sound and the remaining work is naming things. If it does not, an account is missing or transfers are being counted as spending — and no amount of category polish fixes either.
The spreadsheet is the honest competitor here, and for the first fortnight it wins. It is free, private, arbitrarily flexible, and it forces attention on every rupee in a way an automated feed never will.
It decays for a structural reason rather than a motivational one. Entry happens at the moment of spending, which is the moment you are least inclined to do admin. A missed day is recoverable from memory; a missed week is not. Once the sheet is known to be incomplete, its numbers stop being trusted, and an untrusted number stops being consulted. The failure is not laziness — it is that the method requires perfect compliance to produce a usable answer, and nothing that requires perfect compliance survives a bad month.
Automated parsing inverts that trade. It gives up granularity that manual entry captures beautifully — the reason for a purchase, the split of a shared bill — in exchange for never missing a transaction. For the specific question of where the money went, completeness beats richness, because a category breakdown drawn from 60% of transactions is not 60% right. It is misleading.
Only the automated alerts a bank or card issuer sends when money moves — UPI debits and credits, card authorisations, salary and other credits, autopay mandate notices, and statement emails. These are machine-generated and follow a fixed layout per sender, which is what makes them parseable. Personal email, newsletters and receipts written by humans are not part of the record and are not needed to build one.
Most Indian banks and card issuers send both, but the email alert is often switched off by default rather than absent. It is usually enabled under alert or notification preferences in net banking, listed separately from SMS. If a particular account genuinely sends no email at all, its transactions will not appear, and the honest answer is that the account has to be handled another way rather than assumed to be covered.
No. Cash leaves no electronic trail, so an ATM withdrawal appears as a single debit and everything you then spend that cash on is invisible. This is a real limitation rather than a temporary gap. The practical effect is that a withdrawal shows up as one lump under cash, and if a large share of spending is cash, the category breakdown below it will be correspondingly incomplete.
As far back as the alerts still exist in the mailbox, which is what makes email different from a live feed. Because the emails were already delivered and stored, past months can be read on the first connection instead of starting from zero. Anything deleted, or sent before alerts were switched on, cannot be recovered — the inbox is the archive, so its gaps become the record's gaps.
Because the alert carries the payee's Virtual Payment Address rather than a shop name, and a VPA is an identifier chosen by the recipient's bank or payment provider. A neighbourhood store might arrive as a phone number followed by an @ handle. The amount, date and account are exact; the human-readable name often is not, which is why categorisation needs correcting occasionally even when the arithmetic never does.
TLDR Money reads the transaction alerts already sitting in your Gmail and sorts them, including the three months before you signed up. Read-only access, no SMS permission, no bank login.
Join the waitlistNo spam, ever.
This is an explanation, not advice about your money. TLDR Money is not a registered investment adviser and earns no commission on any product mentioned. Figures are illustrative; your own numbers, taxes and circumstances will differ.