DEV Community

Akshra Jain
Akshra Jain

Posted on

Bill Box

Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle Submission 💸

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

BillBox is a local invoice and receipt sorter for Indian freelancers and small shop owners.

Every month, someone who files GST has a pile of bills: printed tax invoices, thermal-paper receipts, phone photos, PDFs from vendors. Their CA needs all of it as a clean sheet with vendor, GSTIN, date, taxable amount, and the CGST/SGST/IGST split. Today that means hours of manual typing, or paying someone to do it.

With BillBox you drag in photos or PDFs of your bills. A vision model running on your own laptop reads each one and pulls out the fields. Then the app double-checks the result with plain rules (valid GSTIN format and checksum, taxable + tax = total, duplicate bills, impossible dates). Anything that fails is flagged for a quick human review. When you're done, you export a CSV or an Excel file with a summary sheet and a detailed sheet, ready to hand to your CA.

Who would pay for it: freelancers, small traders, and shopkeepers who deal with GST bills every month and don't want to upload their financial documents to someone else's server. [TODO: add your pricing idea, e.g. a monthly price or one-time license.]

Demo

Code

https://github.com/akshrakothari/Bill-Box

How I Built It

The whole pipeline runs locally, and the open pieces are what make it work:

Model: an open-weight vision-language model, Qwen2.5-VL 7B, served by Ollama. The model name is a config value, so it can be swapped for another open model without touching code. [TODO: update if you used a different model.]
Backend: FastAPI + Pydantic + SQLite. PyMuPDF turns PDF pages into images, and Pillow/OpenCV cleans up photos (rotation, resizing, contrast).
Extraction: each bill goes to the model with a strict JSON schema prompt at temperature 0. The prompt tells the model to return null instead of guessing, and to read Indian dates day-first.
Validation layer: a rule-based checker written in plain Python catches what a language model can get wrong: GSTIN checksum, tax math, CGST = SGST, line items vs. taxable amount, duplicate invoices. This is what makes the output trustworthy enough to pay for.
Frontend: React + Vite + Tailwind with a split review screen (original bill on the left, editable fields on the right, flagged fields highlighted).
Learning from corrections: when the user fixes a vendor's name or category, BillBox remembers it locally and applies it next time.
Benchmark script: a script that runs a folder of bills against a ground-truth sheet and reports per-field accuracy, exact-match rate, and seconds per document.
Results

Metric Local model (Qwen2.5-VL 7B) Closed vision API
Bills tested [N] [N]
Field-level accuracy [X]% [X]%
Fully correct invoices [X]% [X]%
Avg. time per bill [X]s [X]s
Cost per bill ₹0 [X]

[TODO: One or two honest sentences about where it struggles, e.g. handwritten bills or faded thermal receipts.]

Why Does Open Innovation Matter?

Privacy is the product. Invoices contain GSTINs, customer names, and a business's real revenue. Many small business owners are uncomfortable sending that to a third-party API. Because the model runs on their own machine, the pitch is simple: your documents never leave your laptop. It even works with the internet off.

The economics only work with local inference. A bookkeeping tool for small shops has to be cheap. If every page costs money through a closed vision API, the margin disappears as soon as a user uploads a few hundred bills a month. With a local open-weight model, the cost per document is zero, so I can charge a small flat price and still have a business. [TODO: add your measured API cost per bill here.]

No lock-in. I'm not tied to one vendor's pricing, rate limits, or model deprecations. If a better open vision model comes out, I change one config line and re-run my benchmark.

It can be tuned for a niche. Indian invoices have their own quirks: GSTINs, HSN/SAC codes, CGST/SGST/IGST splits, day-first dates, and messy thermal receipts. With open weights, this is a niche I can fine-tune for later, instead of hoping a general-purpose API gets it right.

[TODO: Add one sentence on where the open approach actually beat the closed one in your own comparison, or where it didn't. Judges like honesty.]

My Agent Session

My First User
<!-- TODO (optional, bonus points): Delete this whole section if nobody has tried it yet. Otherwise answer: --> <!-- Who were they (e.g. a relative's shop, a freelancer friend)? What bills did they run through it? How much time did it save? Did they pay, or would they? What did they ask for next? -->

[TODO: first user story]

Prize Categories
Render

Top comments (0)