This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend Sometimes, the best project ideas don't come from brainstorming sessions or trying to use the latest technology. They come from noticing a problem someone close to you deals with every day.
For this challenge, I built InvoiceLens for a friend who runs a small online business selling handmade tote bags and custom-printed T-shirts. Running a small business means juggling a lot of things at once: managing orders, keeping track of expenses, handling suppliers, and making sure the paperwork doesn't pile up. Invoices and receipts are part of that work, but manually reviewing them and entering their details into spreadsheets can be tedious, especially when you're already busy running the business.
I wanted to explore whether AI could make that process a little easier.
InvoiceLens is an invoice and receipt assistant designed to extract key information from documents and make it easier to review and organize the results.
The project focuses on extracting details such as vendor information, invoice numbers, dates, subtotals, taxes, and totals. It also includes validation checks to flag arithmetic inconsistencies and allows extracted records to be reviewed and edited before being exported to CSV.
One thing I wanted to get right was that AI output shouldn't automatically be treated as correct. A model might read an invoice incorrectly, misinterpret a tax amount, or return an inconsistent total. InvoiceLens separates extraction from validation so that potential problems can be flagged for human review rather than silently accepted.
I built this as a prototype inspired by my friend's business needs, with the goal of exploring a more manageable invoice workflow for small businesses.
This project reminded me that building for someone means thinking beyond whether the code works. It also means understanding the person's workflow, the mistakes that matter, and where automation should leave room for human judgment.
A note about the demo: The hosted version currently uses mock extraction, so it does not run the Gemma model on uploaded documents. The local version integrates Gemma 3 4B through Ollama for local inference. The hosted demo is useful for exploring the interface and workflow, but its output should not be interpreted as actual AI extraction from your uploaded invoice.
The project is open source!
GitHub repository:
Your invoices stay yours.
A local-first assistant that turns invoice and receipt images and PDFs into structured, editable records with validation warnings and a reviewed CSV export. Built for Indian freelancers, small businesses and small CA practices. Extraction runs on your own machine with an open-weight model (Gemma 3 4B through Ollama), with Tesseract OCR as a fallback.
Status: working scaffold. The full pipeline runs end to end and is covered by automated tests that use a fake model. It has not yet been measured against real model output; no accuracy claim is made anywhere in this repository. See Evaluation.
Feel free to explore the implementation, suggest improvements, or build on the idea.
InvoiceLens combines an AI extraction workflow with a separate validation and review process.
The main technologies I used were:
One of the most useful lessons from building InvoiceLens was understanding the difference between extracting information and verifying it.
During testing with a synthetic invoice, the model correctly identified the subtotal and individual tax amounts but reported the total tax as ₹11,800 instead of ₹1,800. Rather than trusting the model's output, the validation logic flagged the inconsistency.
That example reinforced an important design principle for me: AI should assist with repetitive work, but it shouldn't remove the user's ability to question, correct, and verify the result.
InvoiceLens is still a prototype. Model extraction can be inaccurate, the validation rules cannot detect every possible mistake, and the current hosted demo does not perform real model inference. It isn't a replacement for accounting software or professional tax review.
Open innovation made it possible for me to experiment with a local, open-weight model rather than building the entire project around a proprietary AI API.
Using Gemma 3 4B through Ollama gave me a way to explore local inference, inspect the model's behavior, and build the surrounding validation logic myself. It also gave me more control over how the local processing workflow is configured.
For a tool intended to handle financial documents, the ability to explore local processing is particularly interesting. It creates an opportunity to design workflows in which documents can be processed on a user's own machine instead of automatically sending them to a remote model provider.
Of course, using an open-weight model alone doesn't guarantee privacy, accuracy, or security. Those still depend on how the application is built and deployed.
For me, open innovation means being able to experiment, understand the limitations, and adapt technology to a real problem without being locked into one provider's ecosystem. Best Use of Gemma — if this category is available for this challenge.
Gemma 3 4B is the core model explored in InvoiceLens's local extraction workflow. The project combines it with deterministic validation and human review to investigate how an open-weight model can support a practical small-business task.
Building InvoiceLens was a reminder that a meaningful project doesn't have to begin with a huge idea. Sometimes, it starts with a small problem faced by someone you know and a question: Can I build something that might make this a little easier?
That's what I set out to explore with InvoiceLens. 💚