Features
Getting years of history into a tracker without giving up your inbox
Every expense tracker has the same first-week problem. You install it, you log four coffees, and the charts are meaningless because they describe four coffees. The app has no idea what a normal month looks like for you, so nothing it says is useful yet. That is week one. Week two is when most people stop.
The usual fix is automation, and the usual automation asks for something large: blanket SMS access, or your bank login through an aggregator. Both work. Both also hand over far more than the transaction list — an app with SMS permission gets the inbox, not a filtered view of bank alerts.
There is a third option that almost nobody markets, because it involves the user doing something once: import the statement. One file, months of history, no standing permission at all.
What importing actually buys you
Downloading a statement takes about a minute in your bank’s app. What arrives on the other side is the thing that makes a tracker worth using:
- Real baselines. Your budgets can be set from what you actually spend, not a guess.
- Charts with shape. Category trends, a spend heatmap and month comparisons need months to compare.
- An assistant with something to work with. “Is this month unusual?” needs a normal month to measure against. Klera’s on-device AI says so honestly when the history is thin — importing is the fastest way past that.
And it costs one file access, once. Not an ongoing permission that sits in your settings quietly reading everything.
No “which bank?” screen
The old way to build this is a per-bank template library: pick your bank, and the app applies a layout it was taught. It works right up until your bank changes its statement design, or you use one of the several hundred banks nobody wrote a template for.
Klera reads the structure out of the file instead. It works out where the header is, which column is the date, which holds the amount, and which way each row points — from the document itself. That means statements it has never encountered import fine, and the fallback when a file is genuinely ambiguous is to ask you to map the columns by hand rather than to guess wrong.
What that covers today:
- Bank PDFs from net banking, including the password-protected ones banks email you. Klera asks for the password, uses it for that parse, and never stores or logs it.
- Excel and CSV, including the
.xlsfiles that are secretly HTML and the CSVs with unusual delimiters — sniffed rather than assumed. - UPI-app statements from PhonePe, Google Pay and Paytm. These are harder than bank statements: many have no separate debit and credit column, so the direction has to be recovered from the “Paid to” / “Received from” wording, and dates often arrive without a year, resolved from the statement period printed on the cover page. Klera pulls the UPI reference and funding account into a tap-to-copy payment-details card too.
- Exports from other money apps — including Klera’s own, so a PDF you exported is a PDF you can re-import.
Getting these right is unglamorous work. Real statements are full of traps: an amount printed as Rs.1,234 that parses a hundred times too small, header rows that repeat mid-document, pages with no column header at all. Klera’s parsers reconcile against the running balance and the statement’s own printed totals, so a file that drifts is caught rather than quietly imported wrong.
All of it happens on your phone. The file is never uploaded to be processed, which is not a policy decision but a structural one — there is no server to upload it to.
The genuinely hard part: duplicates
Import a statement covering a month you have already been logging by hand, or in which notification capture caught a few payments, and you can end up with the same transaction twice. It is the failure mode that makes people abandon import entirely, because cleaning it up by hand is worse than not importing.
So three checks run before anything is written:
- File level. If you have imported this exact file before, Klera recognises it and tells you up front.
- Row level. Each row carries a reference from the statement itself — a UPI reference or transaction ID where one exists — which is a far better key than a fuzzy match.
- Near-match level. Same amount, close date, same payee gets flagged as a probable duplicate even without a shared reference.
You see all of this in a preview before committing: a summary header, filter tabs, search, bulk selection, and category chips you can correct in place. Nothing is written until you say so.
And if it still goes wrong, an import is one object. Settings → Tools → Import history lists every batch, and any one of them can be undone in a tap — not by hunting down 300 transactions individually.
Two honest limits
Scanned statements do not work yet. The file needs a real text layer. A photo of a statement, or a PDF that is really a picture, will not parse — that support is planned but not shipped. Digital PDFs from net banking are fine.
Review the preview. Auto-categorisation is good, not psychic. It will not always know that a payment to a person’s name was rent. The preview is where you fix that in bulk, and it is worth the two minutes.
Getting it all back out
An app that makes it easy to bring data in and hard to take it out has told you what it thinks the relationship is. So, in one tap and without asking anyone:
- CSV and PDF export, filtered by date, account, category and type — with financial-year (April–March) presets, because that is the export people actually need, and a category-wise income-and-expense summary that works as a simple P&L for freelancers and small shops.
- Complete JSON export of every table, in an open format. Not encrypted — it is for moving your data somewhere else, so treat the file accordingly.
- Encrypted backup file, or an automatic encrypted backup into your own Google Drive.
- Per-person udhaar statement PDF with a running balance, for when someone asks what exactly they owe you.
Your history should be portable enough that leaving is easy. That is not generosity; it is the only version of this that respects the fact that it is your data.
Klera is free, works offline, and needs no account. Import your last statement, and the app knows your money from the first day instead of the second month — start here.
Frequently asked questions
Can I import my bank statement into an expense tracker?
Into Klera, yes — PDF, Excel (.xlsx/.xls) or CSV. Download the statement from your bank's net banking or app, open Klera → Import transactions, and pick the file. The whole parse happens on your phone; nothing is uploaded to be processed.
Do I have to tell it which bank the statement is from?
No. Klera detects the table structure from the file itself rather than matching a bank template, so statements it has never seen still import. If a file is genuinely ambiguous it asks you to map the columns by hand instead of guessing.
Can I import PhonePe, Google Pay or Paytm statements?
Yes. UPI-app statements parse end to end, including working out the direction of each transaction from the “Paid to” / “Received from” wording when there is no separate debit and credit column, and pulling out the UPI reference and the funding account into a payment-details card.
What about password-protected PDFs?
Most banks email statements locked with a password. Klera prompts for it, uses it only for that parse, and never stores or logs it.
Will importing create duplicates?
Three checks run before anything is written: the whole file is recognised if you have imported it before, individual rows are matched against a reference from the statement itself, and near-matches on amount, date and payee are flagged. You see the preview with duplicates marked before you commit, and you can undo an entire import from Settings → Tools → Import history.
Can I get my transactions back out of Klera?
Always, in one tap, without asking us. CSV and PDF export with filters by date, account, category and type, financial-year (April–March) presets, and a category-wise income-and-expense summary that works as a simple P&L. There is also a complete JSON export of every table, an encrypted backup file, and a per-person udhaar statement PDF.
Can I import a photo of a statement?
Not yet. The file needs a real text layer, so a scanned or photographed statement will not parse — support for that is planned. Digital PDFs from net banking, and any Excel or CSV export, work today.