This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
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.
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:
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.
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
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.
In one synthetic example, Shellter Home Insurance was billed $171.56, compared with an expected amount of $146.00.
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.
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.
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.
The dashboard brings spending history, merchant-level forecasts, and a concise summary into one place.
![SlothBank dashboard overview]
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]
Merchant-level estimates help users understand expected upcoming expenses. These forecasts are experimental and should be interpreted alongside their evaluation results.
![SlothBank expense forecasting]
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
GitHub repository: [Slothbank]
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.
These screenshots show the local dashboard using the project's synthetic sample data.
The project supports a baseline forecaster and a TabPFN integration. Real model behavior depends on local configuration and dependencies.
The repository contains the project implementation, including the application server, dashboard, local processing workflow, and supporting evaluation work.
SlothBank combines open-weight AI with conventional software components. Each part has a specific responsibility.
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.
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.
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.
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 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.
SlothBank is a prototype, and there is more work to do:
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! 🦥