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]

raw.githubusercontent.com

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]

raw.githubusercontent.com

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]

raw.githubusercontent.com

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

1. Bills enter the local processing workflow.
2. Mastra orchestrates bill processing and weekly audits.
3. A forecasting engine estimates costs and checks for unusual bills.
4. Explanations, email drafts, and a deterministic digest are generated.
5. 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…

View on GitHub

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 the local bill-processing workflow.

For me, open innovation isn't just about using an open-weight model. It's about having the freedom to experiment, understand limitations, evaluate results, and design the safeguards around the technology.

The principle behind SlothBank is simple: let AI handle the repetitive work, let code check the numbers, and keep people in control of financial decisions.

The Lazy Payoff

The hoped-for payoff is straightforward: less repetitive bill reading, less manual comparison, and an easier way to identify which charges deserve attention.

SlothBank brings extraction, historical comparison, anomaly flags, forecasting, and email drafting into one workflow. Instead of starting every review from scratch, a user can begin with a structured summary and investigate the exceptions.

I haven't measured real-world time savings yet, so I won't claim a specific number of minutes saved. The current work demonstrates the workflow and its early evaluation results; measuring time saved against a manual review process is a valuable next step.

The principle is automate the tedious parts, keep the important decisions human.

Prize Categories

• Best Use of Gemma — SlothBank uses Google's open-weight Gemma 3 4B model through Ollama for local bill-information extraction, supported by structured validation and evaluation.
• Best Use of Mastra — Mastra is part of the AI workflow used to connect the model-assisted processing with the wider application.
• Best Use of Render — SlothBank has a deployed public demo that presents synthetic example data in read-only mode. The local bill-processing workflow remains separate from the hosted demo.

What's Next?

SlothBank is a prototype, and there is more work to do:

• Evaluate extraction against a larger and more diverse set of bills.
• Improve source-level traceability so a user can connect extracted fields to the relevant region of the original document.
• Compare forecasting models against appropriate simple baselines.
• Test anomaly detection on legitimate price changes as well as unusual charges.
• Improve the public demo while keeping it synthetic and read-only.

The most important lesson so far is that useful AI isn't just about getting a model to produce an answer. It's about checking that answer, measuring its limitations, and designing the workflow so a person can make an informed decision.

Thanks for reading, and happy Hacktoberfest! 🦥

devchallenge #hf26challenge