I Built a Private AI Bookkeeper for Freelancers — Without Depending on a Proprietary AI API

tags: devchallenge, hf26challenge, ai, opensource

This is a submission for the "Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle" (https://dev.to/challenges/hacktoberfest-week2-2026-10-12).

Your Invoices Are Nobody Else’s Business: Building a Local-First AI Bookkeeper

Imagine finishing a month of freelance work, opening a folder full of invoices and receipts, and realizing that your next task is to manually organize every single document.

Extract the vendor name. Find the invoice date. Identify the total. Categorize the expense. Check for missing information.

Repeat.

For freelancers and small business owners, this is the kind of administrative work that quietly eats into time they could spend doing actual work.

AI can help automate it. But what if the documents contain sensitive financial information? And what happens when the cost of using an AI API starts eating into the savings from automation?

That got me thinking: Can I build a useful AI bookkeeping assistant that gives freelancers more control over their data, their costs, and the technology they depend on?

That’s the idea behind BillBuddy Local, my project for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

The project is currently in development, and this is the problem I’m setting out to solve.

What I’m Building

BillBuddy Local is a planned privacy-first AI assistant that helps freelancers, independent consultants, and small businesses turn invoices and receipts into organized financial records.

Instead of manually copying information from document to spreadsheet, the goal is to make the process as simple as uploading a document and reviewing the extracted information.

Here’s the workflow I’m working toward:

1. Upload: Import an invoice or receipt as a PDF or image.
2. Extract: Use OCR and an open-weight AI model to identify details such as the vendor, invoice number, date, subtotal, tax, and total.
3. Validate: Check for missing fields, inconsistent amounts, and potentially incorrect extractions.
4. Review: Let the user correct the results before they become part of the financial records.
5. Export: Generate structured CSV records that can be used in a spreadsheet or shared with an accountant.

The goal isn't to replace accountants or let an AI make financial decisions without supervision.

It's to eliminate repetitive data entry while keeping people in control of their records.

Who would pay for it?

I'm starting with a specific audience: freelancers, solo consultants, independent creators, and small agencies that regularly handle invoices but don't need an expensive enterprise accounting platform.

The business model I'm exploring is a free local version, with potential paid features such as batch processing, team workflows, additional export formats, and optional hosted deployment.

My initial pricing hypothesis is ₹299–₹799 per month, depending on the features and usage limits.

That price isn't validated yet. One of my goals is to get the product in front of potential users and find out whether the time saved is valuable enough for them to pay for it.

A side hustle needs more than a clever technical implementation. It needs a problem people actually want solved.

Demo

Status: In development.

I'm working toward an end-to-end demo that shows a sample invoice being processed, the extracted fields being reviewed, and the final record being exported.

I'll add the working demo link here once the application is ready.

Code

GitHub repository: "Fiza-Naaz339/BillBuddy"

I'm developing the project in the open so that the implementation, technical decisions, and future improvements can be inspected and reproduced.

As development progresses, I'll document the setup instructions, model configuration, sample documents, and tests needed to run the application.

How I Plan to Build It

I don't want BillBuddy Local to be another chatbot that simply reads a document and returns a paragraph.

I want to build a document-processing pipeline where each component has a clear responsibility.

The planned architecture consists of:

• Frontend: React and TypeScript for document uploads, extracted-field review, corrections, and exports.
• Document processing: Python and OCR to convert invoice PDFs and receipt images into machine-readable text.
• Open-weight AI: Google's Gemma is my planned model to explore for extracting and normalizing invoice information into structured fields.
• Validation: Python-based checks for required fields, date formats, numeric consistency, and missing or questionable values.
• Storage and export: A database for organized records, with CSV export for downstream bookkeeping workflows.

These are the technologies and architectural choices I'm working toward; the complete pipeline is not implemented yet.

One principle I want to follow throughout the build is that the language model shouldn't be responsible for everything.

OCR can handle text recognition. The model can interpret the extracted text and propose structured fields. Deterministic code can validate predictable rules. The user can resolve uncertainty.

Separating these responsibilities should make the system easier to test, debug, and improve.

How will I know if it actually works?

A polished interface isn't enough to prove that an AI document-processing tool is useful.

Once the pipeline is implemented, I want to evaluate it against a set of manually verified invoices and receipts.

The measurements I'm interested in include:

• Field-level extraction accuracy for vendor names, dates, invoice numbers, and totals.
• The number of missing or inconsistent fields detected.
• How often users need to correct the model's output.
• Processing time per document.
• The estimated cost per processed document.

I'd also like to compare the chosen open-weight model against a baseline using the same documents and evaluation rules.

I haven't collected these results yet. I'd rather measure actual performance than claim improvements based on assumptions.

Why Does Open Innovation Matter?

For this project, open innovation isn't just a technology preference. It could change the economics and privacy options available to the people using the product.

1. Financial documents deserve control

Invoices and receipts can contain personal information, business relationships, addresses, and tax details.

My goal is to support a local-first workflow in which document processing can happen on hardware controlled by the user.

That requires more than running the language model locally. OCR, storage, logs, and other processing must also be configured appropriately if the entire workflow is to remain local.

For users who prefer a hosted experience, deployment and data-handling choices will need to be clearly documented.

1. AI should make a side hustle more affordable, not less

A product aimed at freelancers needs sustainable economics.

If every processed invoice requires a paid proprietary API call, the cost structure depends partly on another provider's pricing and usage limits.

An open-weight model gives me the option to investigate local inference or self-managed hosting, depending on the model's hardware requirements and the needs of the customer.

Open-source AI isn't automatically free. Hardware, hosting, maintenance, and development still have costs. The advantage is having more flexibility over how those costs are managed.

1. I want the freedom to change models

Different models have different strengths, resource requirements, and performance characteristics.

An open-weight approach gives me room to evaluate alternatives, experiment with inference runtimes, and optimize the pipeline for the invoice formats my users actually encounter.

If a smaller model provides sufficient accuracy at lower operating cost, I can investigate using it. If a model struggles with certain documents, I can compare alternatives using the same evaluation set.

The goal is to choose based on evidence rather than being locked into one provider's ecosystem.

1. Open code creates opportunities for collaboration

Invoices vary across vendors, industries, and countries.

An open codebase could allow other developers to contribute document parsers, validation rules, language support, integrations, and evaluation datasets.

I want this project to be something developers can inspect, learn from, and adapt to their own use cases.

For me, open innovation means more than making source code available. It means giving people the flexibility to understand and improve the tools they rely on.

What's Next?

My immediate priority is to turn the idea into a working end-to-end application.

The next milestones are:

• Build the document-upload and OCR pipeline.
• Integrate and evaluate the chosen open-weight model.
• Add structured extraction and validation.
• Build the review and CSV-export workflow.
• Test the application against manually verified sample documents.
• Get feedback from a freelancer or small business owner.

The final step matters just as much as the technical work.

I want to find out whether the application actually saves time, which errors users care about most, and which features would make it useful enough to pay for.

I don't have a validated customer or measured performance results to share yet. Those are things I want to earn through implementation and real-world testing.

My measure of success won't be how many AI features I can fit into the application.

It will be whether someone can finish their bookkeeping faster, review the results with confidence, and maintain control over their financial documents.

That's the side hustle I'm working toward: practical AI, built with openness and user control at its core.

Prize Categories
Best Use of Gemma: If Gemma actually powers the document-processing workflow.
Best Use of Render: If Render is genuinely used for the application or AI runtime.
Best Use of Tiger Data: If Tiger Data/pgvector is actually part of the implemented solution.
Best Use of Sentry Agent Tracing: If Sentry's relevant agent-tracing capabilities are integrated and you can show the resulting traces.