AI-Driven Financial Assistant for Smart Expense Tracking

Various personal finance applications are available, each offering unique features. Intuit Mint was a service for web & mobile that allowed users to consolidate multiple accounts & monitor their spending. Mint's core capability was to let users "track bank, credit card, investment, & loan balances & transactions through a single user interface," & also to establish budgets & financial objectives. You Need A Budget (YNAB) is a budgeting application founded on the "envelope system." It's accessible via web & mobile interfaces & guides users to assign every dollar of income to specific budget categories. YNAB facilitates both automatic transaction imports from financial accounts & manual entries, & it provides financial reports for review. Walnut, which has since been rebranded as Axio, is a well-known Indian mobile application that streamlines expense tracking by interpreting SMS notifications & categorizing transactions. The Walnut app "automates expense tracking, allowing [users] to monitor daily & monthly financial activities effortlessly," covering credit card payments & utility bills within a single platform. It also includes features such as bill reminders & adaptable credit/loan services designed for Indian users. Freely available open-source desktop programs like GnuCash & Home Bank are also commonly used for personal accounting. GnuCash serves as a no-cost accounting tool for both personal & small-business finances; it is "designed to be easy to use, yet powerful & flexible" & enables users to keep track of bank accounts, investments, income, & expenses. HomeBank is a multi-platform free software solution for personal accounting. It can bring in transaction data from formats like OFX, QFX, & QIF, & is seen as a free substitute for commercial personal banking software. Unlike Mint, YNAB, or Walnut, GnuCash & HomeBank are desktop programs that necessitate manual data importation. To summarize, Mint & YNAB focus on aggregating accounts & budgeting (Mint operates on a free/ad-supported model, while YNAB uses subscriptions). Walnut centers on mobile & SMS-based tracking, & GnuCash/HomeBank function as free desktop accounting tools. Currently, none of these alternatives provide AI chatbots or automated email parsing. This gap motivates our proposed system, which aims to merge automated data collection with AI-powered insights.

OBJECTIVES

The main goals of this undertaking are to design, build, & assess a web-based expense tracker that:

• Facilitates Natural Language Interaction: Enables users to pose budget & expense questions in ordinary language (e.g., “How much did I put towards groceries last month?”) & get answers.
• Streamlines Data Entry & Categorization: Leverages AI (OCR/NLP) to automatically pull out & classify expense entries (bills) & assets, thereby cutting down on manual input.
• Delivers Personalized Insights: Offers summaries, identifies trends, & provides recommendations (such as overspending warnings or budget adjustments) derived from the user's data.
• Guarantees Data Persistence: Securely stores financial data (assets & bills) within a MySQL database for querying & reporting purposes.
• Incorporates Advanced AI (Gemini): Utilizes a leading-edge LLM to understand queries, convert them to SQL, & interpret the outcomes, demonstrating the advantages of AI integration in personal finance.

These aims are set to lessen the user's workload & enhance financial understanding by marrying a user-friendly interface with robust AI processing.

SCOPE

The reach of this system encompasses personal (single-user) budget & expense monitoring. It addresses:

• Types of data: Expenses (bills) & assets (like savings or income sources). Two database tables are employed to log entries.
• Queries supported: Natural language questions concerning sums, counts, & specifics of expenses & assets (e.g., totals, recent transactions, category breakdowns).
• Platform: A web application featuring a PHP frontend, a Python Flask API backend, & a MySQL database.
• AI Capabilities: The system utilizes the Google Gemini API (LLM) for NLP functions (understanding queries, generating SQL). This version does not handle payment execution or multi-user collaboration.

Complex subjects such as in-depth security measures, multi-user accounts, or direct payment gateway integration (like UPI transfers) are beyond the purview of the current prototype. The primary aim is to showcase NLP-driven queries & automation within a straightforward budgeting framework.

4. Problem Statement

Managing personal finances effectively means tracking income & expenses & adhering to a budget. Yet, for many, manual tracking proves to be a burdensome task. As highlighted in recent studies, “Traditionally, managing personal finances required individuals to manually track expenses… These processes were time-consuming, error-prone”. In reality, numerous individuals find budgeting & logging expenses so tedious that they avoid it altogether. One study notes that most people give up on detailed budgets because “keeping track of monthly costs can be exceedingly challenging”. Similarly, others have pointed out that manually entering expenses is “time-consuming” & that even basic tools (like OCR receipt scanners) frequently misidentify transactions. These shortcomings result in a poor understanding of spending habits & lead to missed opportunities for savings.

In the meantime, progress in artificial intelligence is paving the way for new solutions. AI-enhanced finance tools can automate the categorization of spending & deliver personalized insights in real time. For instance, AI methods such as natural language processing (NLP) & machine learning (ML) have been “widely adopted to track expenses, categorize spending, & provide real-time financial feedback”. By harnessing these techniques, we can address the difficulties associated with traditional budgeting applications.

Figure 1: Iterative Waterfall Model

The system is structured using a multi-tier architectural approach, bringing together a PHP-based front-end, a Python Flask back-end, & a MySQL database. The PHP web interface, which forms the presentation layer, manages user interactions such as logging in, viewing dashboards, & inputting transactions. PHP interacts directly with the MySQL database (via mysqli or PDO) to save & fetch user & transaction information. The Python Flask application, acting as the application layer, carries out the AI-driven functionalities & background operations. It functions as a RESTful API service that the PHP frontend can communicate with using HTTP (JSON) requests when necessary. For example, the chatbot interface within the web UI dispatches user queries to a Flask endpoint, which then processes the query & sends back a response. Both PHP & Flask have shared access to the central MySQL database. Flask establishes a connection using a Python database library (such as SQLAlchemy or PyMySQL) to read & write data related to budgets, expenses, & user settings. This setup allows PHP pages & Python APIs to work with the same data repository. The Flask backend also incorporates machine learning models (for NLP & predictions) & background services. For example, a Flask-based worker routinely calls the Gmail API to retrieve & parse emails (as detailed later). The application can be hosted on a LAMP/LEMP stack, with Apache or Nginx serving the PHP components, & a WSGI server (like Gunicorn) running the Flask application.

Figure 2: Layered Architecture with Mathematical Model

The diagram (referenced below) depicts the entity relationships within the database. In the broader architecture, users engage through the PHP front-end & the chatbot interface, while the Flask service manages AI integration. This division of responsibilities makes development simpler & allows for the utilization of both PHP's extensive web ecosystem & Python's machine learning libraries.

6. Database Schema

Figure 4 would display the database blueprint for the system. Key elements include User, Expense, Category, Budget, Recurring Expense, & Payment Method. Each User can be associated with numerous Expenses & multiple Budgets (representing one-to-many relationships). Every Expense record contains fields such as amount, description, date, & links to the user & a specific category. The Category table outlines spending categories (e.g., Food, Travel). Within this structure, a User also "establishes" multiple Budgets & has several Recurring Expense entries. Each Budget is tied to a particular Category, enabling users to define a budget for each category.  Similarly, recurring expenses are assigned to a category. The Payment Method table (e.g., Cash, Credit Card) is connected to expenses to specify how each expense was settled. All these elements use distinct primary keys (like userId, expenseId) & foreign keys to ensure data consistency & relationships. This relational framework supports intricate queries (such as combining Expenses with Categories & Users) & guarantees dependable data storage.

7. Chatbot NLP Interaction Workflow

The system features a natural-language chatbot that users can ask for insights (e.g., “How much did I spend on groceries last month?”). The chatbot's operational flow is as follows:

• User Input: The individual types their question into the chat interface provided on the web UI.
• NLP Processing: The query text is dispatched to the Flask backend’s NLP engine. This engine breaks down the input into tokens, performs intent classification, & identifies entities (like dates, categories, or amounts).
• Action Selection: Depending on the classified intent (for instance, “query total spending” or “set budget”), the system determines the subsequent action.
• Database Query: If the intent necessitates data retrieval (such as spending history), parameters (like time range or category) are employed to search the MySQL database for relevant transactions.
• Response Generation: The system creates a reply that is easy for humans to understand. This might be a pre-set summary (e.g., “You spent Rs. X on Food in March”) or a dynamically generated response using an AI language model.
• Output: The generated response is sent back to the front end & shown to the user.

8. System Technology Stack

Let's break down the technologies that make this system tick. It's designed with a few different pieces working together. Basically, PHP scripts are managing user sessions & sending requests off to the backend part, which is a Flask API. For keeping track of all the financial figures, the system relies on MySQL. This is an open-source relational database, a solid choice for structured data like financial records. We're using two main tables within it: one to log expenses & another for incomes & savings. MySQL is known for being dependable & its SQL language is pretty standard for working with this kind of transactional data. To make sure pulling up records over specific time periods is quick, we put special indexes on the date fields in the tables. Moving to the middle layer, the system's API is built using Python Flask. Think of Flask as a lightweight framework for creating web services. It's what receives the incoming data (usually sent as JSON), figures out what needs to happen next, orchestrates things like talking to the AI model, & handles communicating with the MySQL database (likely using something to help Python talk to MySQL easily). Flask got the nod here because it's straightforward & plays nicely with JSON, which is handy for data exchange. Now, the real brains for understanding what users are typing in naturally? That's where Google Gemini AI comes in, specifically the 1.5 Pro version of its API. This is the core engine for processing natural language. Gemini is a powerful large language model, good at understanding complex requests. A key feature we use is its JSON mode, which helps get structured outputs from it. We're using Gemini for a couple of main jobs: figuring out the user's intention behind their query (like "show me my spending" or "how much did I save last month?") & generating the right database queries (SQL) to get that information. Compared to just looking for keywords, using a sophisticated model like Gemini significantly boosts the system's ability to understand natural language, including context & different ways of saying the same thing. Putting it all together, these technologies form the system's foundation. The PHP frontend & the Flask backend communicate over standard web protocols (HTTP, using AJAX calls), passing data back & forth formatted as JSON. The decision to use this mix of languages was really to show you could build a system with components in different languages; you could swap out the PHP part for a full Python or JavaScript frontend, or even change the backend technology, & the central AI logic would still function.

Table 1: provides a feature-by-feature comparison

This sequence enables adaptable, conversational interactions. The NLP engine (which might utilize pre-trained models or custom classifiers) interprets the user’s natural language. Subsequently, the application logic fetches or updates data as required. For instance, if a user inquires about monthly totals, the system translates this into SQL queries targeting the Expense table & then calculates the sum.

9. System Architecture

The overall design follows a typical three-tier web structure, chosen for its scalability & modularity. (A Figure 1, not shown here, would illustrate these parts):

• Frontend (PHP): A PHP 5.6.2 application is responsible for delivering the user interface. It manages HTML/CSS pages, user authentication processes, & form submissions. For instance, users input their queries or expense details through web forms. PHP then transmits these requests to the backend API. (It's worth noting that PHP 5.6.2 is no longer supported, so this choice might lead to maintenance challenges down the line. It was selected for this project due to compatibility with our existing hosting environment.)
• Backend (Python Flask): A Flask server manages API requests coming from the frontend. It includes endpoints like one for receiving a user's natural language input. Flask routes trigger internal logic to handle requests, which involves connecting to Gemini through its REST API.
• Database (MySQL): We utilize a MySQL database that features two main tables: one for expenses (with columns such as id, date, amount, category, description, etc.) & another for assets (id, date, value, source, etc.). The backend employs SQL (via an ORM or parameterized queries) to add & fetch data. For example, a query like “Show my total bills this month” would be translated into a SQL command. All data operations are carried out securely to guard against injection vulnerabilities (by using prepared statements). The SQL results are then passed back to Flask, which formats them as JSON for the frontend.
• AI Integration (Gemini API): The project incorporates Google’s Gemini API for natural language processing. We make use of the Gemini 1.5 Pro model, a medium-sized multimodal LLM designed for reasoning tasks. According to Google, Gemini 1.5 Pro “can process large amounts of data at once, including codebases with 60,000 lines of code, or 2,000 pages of text”. We capitalize on this ability by sending user queries & the database schema to Gemini. Gemini then figures out the user's intention (query classification) & generates either a corresponding SQL query or a direct answer. For instance, a prompt might contain information about the assets & bills tables along with a question; the model then returns SQL or JSON results. In essence, the AI layer acts as a bridge between user language & the structured financial data, facilitating natural-language querying.

METHODOLOGY:

10.1 NLP-Based Query Classification

When a text query is received from the user (e.g., “How much did I allocate to utilities in May?”), the system initially uses NLP methods to determine the query's intent. We utilize the Gemini LLM for this task: it analyzes the sentence to pinpoint the action (like aggregating a sum, listing items, or comparing values) & any relevant entities or time periods. This method is similar to intent recognition employed in financial chatbots. For instance, Gemini’s prompt might direct it to produce a JSON output specifying the intent type (such as SUM, COUNT, or ITEM_LIST) & the pertinent parameters (table, columns, conditions). This step is vital for managing diverse natural-language expressions. The classification module can also direct queries to suitable sub-processes (e.g., flows related to assets or bills) based on keywords identified by the model.

10.2 SQL Generation & Execution

After the query's intent is grasped, we convert it into a SQL query. The LLM is employed for SQL generation: the system sends the original query, descriptions of the schema, & the identified intent to Gemini, which then outputs a SQL statement. This technique aligns with the NL-to-SQL translation approaches discussed in existing literature. For example, given the sample query & the intent SUM with the context "bills," Gemini might generate a query like SELECT SUM(amount) FROM bills WHERE category = 'Utilities' & date BETWEEN '2025-05-01' & '2025-05-31';. The backend subsequently runs this SQL command against the MySQL database. We use parameterized execution or an ORM to safely insert values, thereby preventing SQL injection. The outcome (e.g., the total sum) is retrieved from the database & sent back as part of the API response.

10.3 Categorization (Assets & Bills)

We divide financial records into two primary groups: assets (which include sources of funds, income, or savings) & bills (representing expenses or liabilities). Each table within the database is dedicated to one of these categories. During data input, the frontend allows users to label their records accordingly (for example, entering a salary into assets, or a grocery receipt into bills). We also enable the LLM to propose categories: if a user states, “I paid ?50 to shop on 2025-06-03,” Gemini can deduce that this is a bill likely belonging to the “Food” or “Groceries” category. In the database, these tables can include extra fields (such as category, notes) to store additional metadata. This straightforward categorization ensures that queries can be effectively routed: asset-related queries only access the asset table, so bill-related queries access the bill table

10.4 User Interaction Flow

A typical interaction for a user goes like this: the user accesses the web interface, logs in, & then has the option to either record a new transaction or ask a question.

• Recording a transaction: The user completes a form with details like date, amount, category, & a description for either a bill or an asset. Upon submission, the PHP front end transmits this information to Flask (for instance, via a POST request to an endpoint like /add_transaction), which then inserts a new row into the relevant MySQL table. The frontend confirms that the action was successful.
• Asking a query: The user types a question into a text box (e.g., “What is my current asset balance?”). The PHP frontend relays this text to Flask (to an endpoint like /query). The Flask handler then calls the Gemini API, providing a carefully constructed prompt that includes the user's question & the database schema. Gemini returns a SQL query (or a direct answer); Flask executes the SQL if necessary & sends the result back to PHP, which then displays it to the user.

In essence, the methodology combines the art of prompt engineering with traditional database querying. The LLM handles the complex task of interpreting often vague user language & generating precise SQL, a method supported by recent advancements in NL2SQL research. Simultaneously, the system's logic ensures that only safe & valid queries are executed against the database.

10.5 Mathematical Models Used

Table 2: Mathematical models used in the proposed system

10.6 Testing Strategy

We utilized several layers of testing. Unit testing focused on individual functions & modules (e.g., employing PHPUnit for PHP elements & pytest for Flask/Python modules). Integration testing confirmed that end-to-end processes worked correctly (for example, submitting a form & verifying that the data appeared in the database). System testing involved sample users to ensure that requirements were met (covering UI flows & chatbot accuracy). Test cases encompassed edge scenarios (like handling invalid input) & regression testing was performed after any updates.

10.7 Performance Evaluation

The application's performance was gauged under various load conditions. Using tools such as Apache JMeter, we monitored key metrics like average response time & throughput. Following best practices in performance engineering, we tracked both average & percentile response times to ensure the system remained responsive. For instance, when subjected to 50 concurrent users, the system consistently kept its average API response time below 1 second. We also measured CPU & memory consumption to pinpoint any potential bottlenecks. These metrics confirmed that the system is capable of scaling to anticipated load levels without any significant drop in performance.

Figure 3: Deployment Diagram