SlothAudit: Finding the Subscriptions You Forgot You Pay For

This is a submission for the Hacktoberfest Open-Source AI Challenge — Week 3: Slow and Steady.

SlothAudit turns a bank-statement CSV into a short list of recurring charges, price increases, and possible duplicate subscriptions worth reviewing. It is designed to reduce repetitive manual checking, not to make financial decisions for you.

The slow leak

Subscription renewals are easy to forget. A small monthly charge can continue for months, and a price increase can slip by unnoticed. Manually scanning a long statement to find these patterns is tedious.

I built SlothAudit to make that review less repetitive: upload a CSV, run an audit, and inspect the findings instead of starting from every transaction.

• Live demo: https://slothaudit-frontend.onrender.com/ (free hosting, so the first load can take a minute)
• Source code: https://github.com/riyaax07/slothaudit
• Sample CSV: demo_transactions.csv

The lazy payoff

Using the bundled synthetic demo dataset:

• 83 transaction rows become 10 audit findings to review.
• The audit estimates approximately ₹5,015.92 in monthly recurring commitments (₹60,191 a year). This includes a variable utility bill and one overlapping plan, so it's "commitments", not just subscriptions.
• The hypothetical annual savings estimate is ₹2,388.

The 10 findings are 7 active recurring charges, 1 inactive/churned subscription, 1 overlapping-plan candidate, and 1 price-increase alert. The alert is linked to an active subscription and isn't double-counted in the totals.

Example 1, a price increase. The synthetic data shows DevToolbox going from ₹499 to ₹699 per month (about a 40% increase) on 2024-06-10. SlothAudit flags it and suggests verifying with your statements whether the change was authorized.

Example 2, an overlapping plan. The ₹2,388/year estimate comes from one candidate: a ₹199/month StreamFlix charge running alongside the primary ₹649 plan, annualized over 12 months. It's only a potential saving if that second plan is genuinely unwanted. SlothAudit can't know whether two plans serve different people or purposes without your confirmation.

These are results from synthetic data, not measured savings from real customers.

What it does

• Recurring-payment detection: identifies likely monthly and annual payment patterns, including variable utility bills.
• Price-increase alerts: highlights a clear step-up from an established billing amount.
• Duplicate candidates: flags overlapping recurring streams for review.
• Inactive subscriptions: notes charges that stopped, so you can confirm autopay was actually terminated.
• Savings estimates: calculates hypothetical savings where the findings support them.
• Evidence references: every finding includes a summary and linked transaction IDs.
• JSON export: lets you save the audit report for further review.

SlothAudit does not cancel subscriptions, contact merchants, or label a transaction as fraud. Findings are prompts for human review, not final financial decisions.

How it works

CSV upload → parsing and validation → merchant normalization → deterministic audit rules → findings → dashboard → JSON export

The parser validates the uploaded CSV and normalizes transaction descriptions into canonical merchant names. The audit engine then applies explicit rules to identify recurring patterns, possible price increases, and overlapping charges. The frontend displays the findings and lets you export the report.

A deliberate choice: the detector is deterministic

The audit engine, not a language model, decides which patterns to flag and calculates the associated amounts. That keeps the core results reproducible and makes it easier to inspect why a finding was produced.

The optional explanation layer is separate. Its role is to describe an existing finding in plain language, not to invent findings or change the audit calculations.

Built with

React + Vite, Python + FastAPI, a deterministic rules engine, pytest, and Render for hosting. SlothAudit's code is released under the MIT license.

Where open models fit, and what is verified today

SlothAudit includes an optional explanation provider configured for google/gemma-2-2b-it through Hugging Face's inference router. It validates the generated response and falls back to deterministic explanations if the provider fails or returns invalid output.

Important limitation: I have not verified a successful live Gemma response end-to-end. The hosted inference attempts hit provider/credit errors. The integration code and automated fallback tests exist, but I am not presenting the model as a demonstrated live feature. In the live demo, the "Explain Finding" button returns a deterministic, template-based explanation.

The model card lists the gemma license, governed by Google's Gemma terms. That is separate from SlothAudit's MIT license, and Gemma is an open-weight model, not an OSI-style open-source one. I don't bundle or redistribute any model weights. Anyone deploying the optional model should review the applicable terms.

Why open innovation matters

An auditable rules engine makes the core financial calculations inspectable instead of hiding them behind a model call. An open-weight model adds flexibility: developers can swap the explanation model and, with a suitable local runtime, potentially run explanations on-device so statement data doesn't need to leave the user's machine for that step.

That local explanation workflow is a direction for the project, not a claim about the deployed demo.

Privacy: what is true today

• Uploaded CSV data is processed in memory. SlothAudit has no database and doesn't save uploads to disk.
• The core audit doesn't need an external AI service to calculate findings.
• The public demo is hosted on Render, so an uploaded file is sent to that hosted backend for processing. Please use the synthetic sample dataset on the public demo, and don't upload a real bank statement unless you're comfortable sending it to that service.
• When you run the project locally, the core audit runs on your own machine. If you enable a hosted explanation provider, the finding context sent to it is subject to that provider's terms.
• In-memory processing is not a blanket security guarantee.

Limitations

• The bundled example is synthetic; results don't establish accuracy on real bank statements.
• The rule-based detector can miss patterns (for example, irregular billing) or flag candidates that need human review.
• Savings figures are hypothetical, not guaranteed outcomes.
• Hosted Gemma inference has not been verified end-to-end.
• Precision and recall have not been measured against a labeled real-world dataset.
• SlothAudit is a review aid, not financial advice.

Try it

1. Download the sample CSV (synthetic, safe to use).
2. Open the live demo and upload the file.
3. Run the audit and expand a few findings to see their transaction IDs.
4. Export the JSON report.
5. Explore or run it locally from the GitHub repository.

What's next

Next steps: verify the model path end-to-end (ideally with a local runtime), evaluate against a labeled dataset, support more bank CSV formats, add a one-click sample loader, and show the underlying transactions inside each finding.

The goal is simple: make recurring-payment review a smaller, more inspectable task, one slow, steady improvement at a time.