SMS expense tracker: how reading your bank's alerts works

Here is an illustrative alert of the kind Indian banks send for a UPI debit. Wording varies by bank; the fields barely do.

XX-BANKNM: Rs 349 debited from A/c XX4821 on 25-09-26 to VPA freshbasket.shop@bankhandle. UPI Ref 426812345678. Avl Bal Rs 18,452. Not you? Report to your bank.

The sender ID is a registered header, not a phone number; the part after the hyphen identifies the sender. A ten-digit mobile number claiming to be your bank is not a bank alert. Then the verb, which matters more than it looks: debited, spent and withdrawn mean money out; credited means money in; eligible, pre-approved and offer mean nothing happened. The account is masked to four digits.

The counterparty varies most. For UPI it is the payee's virtual payment address; for a card, the merchant name as the network carries it, often cut short; for an auto-debit, the mandate holder. Then the date, a reference (for UPI a 12-digit number that also appears in any email alert for the same payment) and, in many formats, the balance after the debit.

A parser does five things to each message. It checks the sender against known bank and card headers and drops everything else unread. It classifies what is left: debit, credit, OTP, promotion or notice. It extracts the fields with patterns written for each bank's format. It names the counterparty, looking a UPI address up in a database of known handles, because freshbasket.shop@bankhandle means nothing on a monthly summary. And it stores one transaction: date, amount, account, merchant, reference.

The balance is where a good parser earns its keep. The previous alert on this account showed ₹18,801; minus ₹349 is ₹18,452, which is what this alert says, so nothing happened in between. The next alert reads ₹200 debited, balance ₹17,552. The parser expected ₹18,252. The ₹700 gap is a debit with no SMS, perhaps an auto-debit reported only by email. A tracker that does not reconcile never learns it missed anything.

You can run this check yourself on any two consecutive alerts that show a balance.

Take an illustrative month: 76 debits from one bank account and one card. (The companion page on tracking UPI spending covers why small payments escape memory; this one asks what each record contains.)

UPI is 60 of the 76 debits, across three apps: 38 on the one used most, 16 and 6 on two others. That is 78.9 percent of the alerts but ₹11,700, only 26.6 percent of the ₹43,954 that left. The other 16 debits carry 73.4 percent: nine card transactions for ₹11,400, three NACH auto-debits for ₹14,500 (a ₹12,000 EMI, a ₹1,800 insurance premium, a ₹700 mandate), two ATM withdrawals for ₹6,000, and charges of ₹236 and ₹118, which are ₹200 and ₹100 plus 18 percent GST.

The most-used app's history shows its 38 debits: 50 percent of the rows and ₹7,600, just 17.3 percent of the money. The SMS thread sees 74 of the 76, every UPI debit whichever app started it, because one bank executed all 60. By value that is ₹40,854, or 92.9 percent. The two it missed, a ₹2,400 card payment and the ₹700 mandate, were alerted by email only.

Cash is the largest limit. The ₹6,000 withdrawn is 13.7 percent of the month, recorded as two debits and then invisible: the vegetable vendor and the auto fare never touch the bank.

Merchant names are second. A card alert can read 'Rs 1,180 spent on card XX7730 at SRI LAKSHMI SUPE', the rest cut off. A UPI alert may show an address or an aggregator's legal name instead of the shop. The amount is right; the who needs a lookup, and a tracker names only what its database knows.

Third, some debits get no SMS: certain banks and issuers alert some transaction types by email only. Here that is ₹3,100 the SMS thread never saw. Fourth, some debits arrive twice, as a confirmation or a resent message; the month had 4 such copies. Fifth, promotions borrow the alert's shape. A bank-header message saying a ₹2 lakh loan is ready to be credited has an amount, a masked account and a verb that sounds like money moving. Of 112 bank-header messages that month, only 74 were debit alerts; 18 were OTPs, 10 promotions, 6 credits and 4 duplicates. A parser that counts every bank message with a rupee figure gets 38 wrong.

Sixth, the phone number. Alerts go to the number registered with the bank. Change it without telling the bank, or keep one account on a second SIM, and the tracker on your phone sees nothing from it.

In the illustrative month 12 email alerts arrived, one for each card transaction and NACH debit. Two were the only record of their debit, the ₹2,400 and the ₹700. With both channels, the tracker sees all 76 debits, 100 percent of the money.

The other 10 emails repeated debits SMS had already reported, worth ₹22,800: ₹9,000 of card spend and ₹13,800 of NACH. A tracker that reads both and does not deduplicate reports 86 debits and ₹66,754, 51.9 percent more than actually left. The overcount lands on the EMI and card spend, the lines people judge a month by.

Matching amounts is not enough. Two ₹20 teas a minute apart are two payments. The reliable key is the reference number where both messages carry it; otherwise amount, account digits and a narrow time window, checked against the counterparty.

Unyfy reads bank and card transaction emails and, on Android, transactional SMS to record each debit with no manual entry and no bank password or UPI PIN, mapping UPI handles to merchant names from a database of about 10,000 entries and dropping any debit already seen through the other channel.

iPhone does not let third-party apps read the SMS inbox, which is why SMS expense trackers are Android apps, and why on an iPhone the only automatic route to this data is the bank's email alerts. Android allows it once you grant the SMS permission, which Google Play treats as restricted, so an app must justify needing it.

That permission is not selective: the app can technically read your OTPs and your family's messages. So check what the tracker does with it. It should read the sender header first and discard anything not from a bank or card issuer, unstored. It should never keep or transmit OTPs, which have no tracking value; here they were 18 of the 112 bank-header messages. It should parse on the phone where possible, so only date, amount, last four digits and merchant leave the device. And it should let you delete what it holds.

None of that shows in the permission prompt. Look in the privacy policy and the Play Store data-safety section. Vagueness there is an answer.

Work down the table. The first question is the fastest: reading an SMS needs no bank login and no UPI PIN, so an app that asks for either wants access its job does not need. The third is the other disqualifier, because raw upload means your OTPs and personal messages sit on someone else's server.

Then test it against your own count. Before trusting its first monthly total, count one week of debit alerts in your SMS thread by hand. Missing rows point to an email-only channel or a second bank; extra rows point to duplicates or promotions read as spending.