I Built SlothBank Using Gemma 3 and Mastra to Catch Unexpected Bills with AI 🦥

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady SlothBank: Let the AI Read the Bill. Let Code Check the Numbers. 🦥 Bills are easy to ignore until something changes. A subscription becomes more expensive. An insurance premium increases. An internet bill arrives with a charge that looks slightly different from last month. Individually, these changes can seem small. Finding them means opening bills, comparing amounts, checking historical records, and deciding whether something deserves attention. I built SlothBank, a local-first AI bill-monitoring project that helps make that process less tedious. The idea is simple: let AI handle the repetitive reading, let deterministic code check the numbers, and let a human make the final decision. What I Built SlothBank is an AI-assisted bill-monitoring prototype designed to help people review recurring bills, identify unusual changes, and prepare follow-up emails without handing the final decision over to an AI model. The workflow brings together: - Bill extraction: Use an open-weight language model to extract structured information from bills. - Validation: Check extracted data and financial relationships with deterministic code rather than trusting model output blindly. - Anomaly detection: Compare bill amounts with historical expectations and flag unusual differences for review. - Forecasting: Estimate upcoming expenses using a baseline forecasting approach. - Human-reviewed follow-up: Prepare draft emails that users can inspect and edit before sending. - Dashboard: Bring the results together in one place so users can review their bills and potential anomalies. The goal isn't to declare every unusual bill incorrect. A higher charge might reflect a legitimate price change, a new service, or a different billing period. SlothBank highlights what deserves a closer look; it doesn't automatically accuse a provider of making an error. How the workflow fits together Bills / Historical Records | v Gemma 3 4B via Ollama | v Structured Extraction | v Deterministic Validation | v Anomaly Detection + Forecasting | v Dashboard | v Human-Reviewed Email Drafts Testing what the model actually gets right I didn't want to rely on a demo that merely looked convincing. I also evaluated extraction on a small set of 20 synthetic bills. | Metric | Single-shot run | Validation-enabled run | |---|---|---| | Merchant exact-match accuracy | 80% | 85% | | Billing-date accuracy | 95% | 100% | | Total-due accuracy | 95% | 100% | | Line-item accuracy | 95% | 100% | | All fields exactly correct | 80% (16/20) | 85% (17/20) | | Failed validations | 1 | 0 | The all-field exact-match result increased by 5 percentage points, from 16 to 17 correctly extracted bills out of 20. These are preliminary results on a small synthetic dataset, not proof of production-level accuracy. Both runs averaged one attempt per bill, so I can't attribute the improvement to retries. The experiment does, however, reinforce why structured validation and evaluation matter when language models handle financial information. An example of an anomaly In one synthetic example, Shellter Home Insurance was billed $171.56, compared with an expected amount of $146.00. - Difference: $25.56 - Increase: approximately 17.5% That is a useful signal to investigate, not proof that the bill is wrong. The user still needs to inspect the original bill and determine whether the difference is justified. Being honest about forecasting SlothBank also experiments with forecasting upcoming expenses. In one small backtest with eight observations, the baseline model had a mean absolute error (MAE) of $13.52, while a naive last-value benchmark had an MAE of $8.01. The baseline did not outperform that simple benchmark. I am keeping that result visible rather than presenting forecasting as a solved problem. A meaningful next step is to improve the evaluation, compare suitable models, and establish when a more complex approach is actually worthwhile. SlothBank in Action The extraction evaluation below uses a separate fixed set of 20 synthetic bills; the bill count shown in the live dashboard reflects its current demo dataset. Dashboard Overview The dashboard brings spending history, merchant-level forecasts, and a concise summary into one place. ![SlothBank dashboard overview] Anomaly Review Unusual amounts are highlighted for investigation. An anomaly is a signal to review the bill, not proof that the provider made a mistake. ![SlothBank anomaly review] Expense Forecasting Merchant-level estimates help users understand expected upcoming expenses. These forecasts are experimental and should be interpreted alongside their evaluation results. ![SlothBank expense forecasting] Demo Live demo: SlothBank The deployed public demo presents synthetic example data in read-only mode. Audit execution is disabled in this mode, allowing visitors to explore the example output without triggering the local processing workflow. Screenshots: View the evidence folder on GitHub Code GitHub repository: [Slothbank] Shanaya31 / slothbank A local-first AI bill monitoring prototype with cost forecasting, anomaly explanations, and human-reviewed email drafts. SlothBank - Slow and Steady SlothBank is a local-first bill-monitoring prototype that tracks spending, estimates future costs, flags unusual bills, explains line-item changes, and drafts emails for human review. Demo-data notice: Included bills and ground truth are synthetic. Forecasts and anomaly flags are estimates, not proof of overcharging. Draft emails are never sent automatically. Screenshots These screenshots show the local dashboard using the project's synthetic sample data. Anomaly review Forecasts and spending history How it works - Bills enter the local processing workflow. - Mastra orchestrates bill processing and weekly audits. - A forecasting engine estimates costs and checks for unusual bills. - Explanations, email drafts, and a deterministic digest are generated. - The local interface displays the latest report. The project supports a baseline forecaster and a TabPFN integration. Real model behavior depends on local configuration and dependencies. Requirements - Node.js compatible with the installed dependencies. The current dependency set calls for Node.js 22.22.0 or… The repository contains the project implementation, including the application server, dashboard, local processing workflow, and supporting evaluation work. How I Built It SlothBank combines open-weight AI with conventional software components. Each part has a specific responsibility. - Gemma 3 4B: The open-weight language model used for bill-information extraction. - Ollama: Runs the model locally, avoiding a mandatory external model-inference API for the local workflow. - Mastra: Supports the AI workflow and orchestration. - TypeScript and Node.js: Power the application server and connect the components. - Python: Supports the forecasting and data-processing work. - JSON: Stores structured reports and makes the results available to the dashboard. - Render: Hosts the public, read-only demo using synthetic example data. The local application and hosted demo have different responsibilities. The local workflow can use local processing and reports, while the hosted demo is designed to present a fixed synthetic example without exposing personal bills or enabling audit execution. I deliberately kept the public demo read-only. A public URL should make it easier to understand the project, not quietly turn a prototype into a service that processes visitors' financial documents. Why combine AI with deterministic code? Language models are useful for interpreting semi-structured documents, but plausible output isn't necessarily correct output. A model can extract the wrong amount, miss a field, or misinterpret a line item. SlothBank therefore separates extraction from validation: the model helps interpret the document, while code checks structured values and flags issues for review. This separation is important in financial workflows, where an answer that sounds confident can still be wrong. Why Does Open Innovation Matter? Financial documents-utility bills, insurance statements, and subscription invoices-can reveal a lot about a person's life. They contain amounts, billing histories, service details, and sometimes sensitive account information. I wanted to explore how AI could make reviewing these documents easier without making a third-party commercial model API a requirement for the local workflow. Open innovation gave me the flexibility to build around that idea. - More control over privacy: SlothBank uses Google's open-weight Gemma 3 4B model through Ollama for local inference. In the local workflow, documents can be processed on the user's own machine rather than automatically being sent to a hosted model API. That offers greater control over sensitive data, although privacy still depends on how the entire application handles files, logs, and storage. - Fewer dependencies on per-token API pricing: Running an open-weight model locally can avoid per-request inference charges from a commercial model provider. It isn't entirely cost-free-hardware, electricity, and maintenance still matter-but it makes experimentation and repeated local testing more accessible. - Freedom to inspect, evaluate, and improve: With Gemma 3, Mastra, and the surrounding application code, I could experiment with structured extraction, add deterministic validation, and measure the results instead of simply trusting a model's output. My small synthetic-bill evaluation also showed why this matters: a model's output needs to be checked, not just accepted because it looks plausible. - A practical path to sharing the project: Render provides a way to make a public demo accessible without asking everyone to set up the entire development environment. SlothBank's hosted demo uses synthetic example data and read-only interactions, keeping it separate from