Khata: Turning Paper Bills into Useful Business Records
Submission: Hacktoberfest Open-Source AI Challenge — Week 2: Side Hustle
Challenge: https://dev.to/challenges/hacktoberfest-week2-2026-10-12
What I Built
Small shops often handle bills and purchase records on paper. Entering those details into a ledger takes time, and handwritten or printed bills can be difficult to process consistently.
I built Khata, a local bill-to-ledger prototype for small shops in India. It uses AI to extract information from bill images and helps turn that information into structured records.
The current prototype includes:
- Bill image preprocessing using OpenCV.
- Local vision-based extraction using Ollama and Gemma 3 4B.
- Structured extraction output and validation checks.
- A Streamlit interface for reviewing and correcting extracted details.
- A local SQLite ledger for saved bills and line items.
- Monthly summaries and an experimental product-demand forecasting feature.
The goal is to reduce repetitive data entry while keeping the shopkeeper in control of the final record.
Demo
Video demo: Watch Khata Demo
In an initial test, one shopkeeper processed 10 bills:
- Manual process: 60 minutes
- Using Khata, including corrections: 40 minutes
- Time saved: 20 minutes (about 33%)
This is an early, small-scale test rather than a broad performance study.
Code
GitHub repository: View Khata on GitHub
How I Built It
Khata is built around a local-first workflow:
- A user uploads a bill image.
- OpenCV preprocessing improves the image for extraction.
- Ollama runs the Gemma 3 4B vision model locally to extract bill details.
- Pydantic-backed structure and validation checks help identify missing or inconsistent values.
- The user reviews and corrects the extracted information in the Streamlit interface.
- Confirmed records can be saved to a local SQLite database.
- The project includes scripts to build product-demand data and generate experimental restocking forecasts using TabPFN where there is enough historical data.
The main tools are Python, Streamlit, OpenCV, Ollama, Gemma 3 4B, Pydantic, SQLite, pandas, and TabPFN.
I also evaluated extraction against a small set of 20 bills. The current results were:
- Total accuracy: 19/20 (95%)
- Item-count accuracy: 17/20 (85%)
- Date accuracy: 7/9 (77.8%), calculated only for the nine bills with usable ground-truth dates.
These numbers describe this small test set and should not be treated as a guarantee of real-world accuracy. The prototype still needs testing on more shops, bill formats, and dates.
Why Does Open Innovation Matter?
Small businesses should be able to experiment with useful technology without being locked into a single cloud service. Using an open-weight model locally gives developers more control over the workflow and makes it possible to inspect, adapt, and improve the system.
Local inference can also reduce dependence on per-request API services, although the actual cost and privacy benefits depend on the hardware and deployment setup. Khata is an experiment in making practical AI tools more accessible while keeping the data workflow understandable and under the user's control.
My First User
I tested Khata with one shopkeeper using 10 bills. The manual workflow took about 60 minutes, while using Khata—including corrections—took about 40 minutes. That is a saving of 20 minutes, or roughly 33%, in this initial test.
The shopkeeper was maybe willing to pay, depending on the features, speed, and reliability. Their expected price was around ₹400–₹500 per month if the tool becomes faster and consistently saves time.
They also suggested two useful additions:
- Tracking products or amounts given and taken on credit.
- End-of-day restocking alerts that account for sales and a delivery lead time of around 3–4 days.
They mentioned Tally as an existing option, so accuracy and a clear advantage over current bookkeeping tools will matter if Khata is to be useful in real shops. This feedback is from one early user, so it is a starting point—not proof of product-market fit.
What I Learned
Building Khata made one thing clear: extracting data is only one part of the problem. The output has to be easy to verify, errors need to be visible, and the resulting records must be useful for everyday decisions.
The project is still a prototype. Its current limitations include inconsistent extraction on some bills, a small evaluation dataset, and limited historical data for demand forecasting. The next step is to improve reliability and test the workflow with more real bills and shopkeepers.
What would make a tool like this genuinely useful for a small shop credit tracking, faster bill entry, restocking alerts, or something else?
Other Team Members
Rishi Raj Goel @rishi_rajgoel_c5e99c8b81