On-Device AI Budgeting App: How Booji Works

Rules handle the predictable cases

A Kotlin parser uses regular expressions to pull out details like amount, debit vs. credit, merchant, account, and any balance included in the SMS. It also rejects messages that aren't completed transactions - things like one-time passwords, promotional offers, payment requests, and reminders about future debits.

Rules work best when the input is known and repeatable. They're also easier to test than relying on a model to "interpret" everything from scratch. Booji includes tests for several Indian bank and payment-message formats, including HDFC, SBI, ICICI, Axis, and PhonePe. And if both a payment app and a bank send alerts for the same transaction, the bank message that includes the balance takes priority.

Still, a parser can only recognize what it was designed to expect. If a message template changes - or if you get an alert it hasn't seen before - it may fall outside the rules. Instead of treating every unrecognized message as junk, Booji can set aside bank-looking SMS that include a rupee amount and ask you to review them.

AI is a fallback reader, not the ledger

When you decide to process those messages, Gemma extracts fields like amount, direction, merchant, and account into structured data. The app saves the result, and you can discard it if it's wrong. Each message is read once, so fixing a transaction doesn't require resubmitting it to the model.

That separation is the point. A model can make sense of unfamiliar phrasing, but it can also make mistakes. Booji makes the model's output something you can review, not a hidden "fact." Kotlin stays responsible for the known formats; the model covers selected exceptions.

Balances need reconciliation, not just addition

Some bank messages include a balance; many don't. Booji can start from the latest reported balance and then roll forward by adding subsequent credits and subtracting debits. It keeps credit-card available limits separate from actual cash in a bank account - because a credit card limit isn't money sitting in your bank.

It also tries to prevent double-counting. Card bill payments and transfers between your own accounts can be identified and excluded from spending. Transactions remain editable: you can correct a category or direction, mark an item as a transfer, ignore it, or add a note. Those controls matter because no automated interpretation - deterministic or not - can perfectly match what you meant to track.

Past: where has the money gone?

The Past view groups transactions into spending categories, with jar sizes reflecting each category's share of expenses. You can open a jar to inspect the transactions and spot which merchants show up repeatedly. Categories can be corrected, and merchant-level changes can be applied to future activity.

Merchant names are often inconsistent. The same business might appear under a shortened legal name, a payment processor label, or a slightly different spelling. Booji uses keyword rules for the obvious cases, and it can ask Gemma to categorize and normalize less familiar names in batches. There's also a safeguard: it only accepts a cleaned-up name if it clearly shares the beginning with the original, which reduces accidental merges between unrelated merchants. Your corrections override the model's suggestions.

Graveyard: which recurring charges deserve attention?

Recurring payments are easy to miss because each one can be small and familiar. Booji looks for transactions from the same merchant with amounts within 15% of the median, and with intervals that cluster around roughly a week, a month, or a year. It requires the pattern to appear at least twice before labeling it recurring.

The Graveyard shows each recurring charge like a headstone - name and monthly cost. You decide whether it's still active or a "zombie" subscription you don't want anymore. Booji can then total the charges you've marked as zombies.

That "zombie" label is meant to be cautious. Software can detect repetition, but it can't know whether a gym membership, streaming subscription, or design tool is actually worth keeping. Calling it a zombie without your say-so would turn a helpful reminder into a judgment you didn't consent to.

Future: what might the rest of the month cost?

The Future view projects spending through month-end, shows a range of possible outcomes, and estimates where your balance might land. It also calls out recurring charges expected before the end of the month and any anticipated income, like a salary that hasn't arrived yet.

For users in India, Booji can adjust for national and selected regional festivals. If a relevant festival is coming up, it sets aside a named allowance instead of assuming the next few weeks behave like an ordinary month. Where comparable past spending exists, the estimate can use that history; otherwise, the app treats the allowance as a typical multiplier and makes it explicit rather than pretending it's based on your personal data.

This isn't meant to tell you to spend less. A forecast is most useful when it explains the assumptions behind the numbers and leaves the decision to you. If it points to a likely squeeze, you can adjust spending, move money around, or accept the trade-off.

The model reads, sorts and writes; Kotlin does the arithmetic

A recurring problem with language models is that "sounds right" doesn't always mean "is right." In early testing, Booji's generated notes could get month-to-month differences wrong, mislabel an undecided charge as a confirmed zombie, or describe a negative figure incorrectly.

The fix was to strip the model of arithmetic responsibilities. Kotlin calculates the spending totals, recurring costs, forecast ranges, remaining money, and differences. Gemma then gets those completed facts in a small structured input and turns them into short explanations. If a number isn't provided, it shouldn't appear in the model's note.

This division of work is more reliable than asking the model to both analyze the ledger and do the calculations. It also makes results easier to inspect: the numbers come from the app code, while the model contributes explanation and interpretation.

Local processing has real costs

"On-device" doesn't mean "no permissions" or "no network ever." Booji needs SMS access to read bank notifications, and the initial model download requires an internet connection. The model also takes storage, and inference speed depends on the phone you're using. A device that falls back to CPU processing may feel slower than one with suitable GPU support.

The architecture described doesn't include a backend, account system, or a model API. The app's only network use is downloading the weights. The app code is MIT licensed, while the Gemma weights use an Apache 2.0 release. Those are good properties for a project that leans on inspectability - but users still need to check permissions and code, and not treat "local AI" as a full security audit.

Why the forecast uses a range

For discretionary spending, Booji looks at the previous eight weeks and divides activity into seven-day windows. It uses the median window to estimate the expected daily pace, and uses the 25th and 75th percentiles to define a lower and upper range. That reduces the impact of a single outlier compared with a simple average.

Then it adds recurring charges expected before month-end and income that hasn't arrived yet. It estimates the required month amount from spending already recorded plus remaining expenses, then compares that with expected income to calculate likely leftover money.

The range matters because spending varies. A single number can look more certain than the underlying data supports. In other words: treat the forecast as planning help, not as a guaranteed balance.

Festival adjustments are explicit assumptions

A "typical month" and the weeks around Diwali can look very different. Booji includes a small calendar of national and region-specific Indian festivals, then adds a named allowance when a festival (or its lead-up) falls within the forecast period.

If the SMS history includes comparable festival spending, the app can base the estimate on that history. If not, it applies a stated typical multiplier and makes the distinction visible. It doesn't try to guess what people in a specific location might spend, and it avoids assumptions based on gender. Those guesses would add a layer of personalization without a solid basis.

The data source sets the ceiling

An SMS-based ledger can miss cash purchases, transactions that never triggered a message, alerts that were deleted, and messages the parser can't read. It can also misclassify a transaction that looks unusual. The model fallback helps with unfamiliar wording, but it still can't turn incomplete SMS history into a complete financial record.

Booji is built for Android, and its demonstrated bank-message formats are focused on India. That makes the approach more immediately useful for Indian users than for someone in the US or UK, where notification formats and account data access differ. The app demo inbox can fill the app with synthetic HDFC-format messages for testing, but that's not the same as supporting every bank everywhere.

Use the forecast as a planning aid and check any important numbers against your bank records. If you have multiple accounts, shared spending, or substantial cash use, manual corrections and omissions may matter more.

The real question isn't whether automation removes review - it's whether it makes review small enough that you'll actually do it consistently.