InvoicePilot：自由工作者的本地優先發票管理工具

InvoicePilot: A Private Invoice Desk for Freelancers

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

What I Built

InvoicePilot is a local-first invoice organizer for freelancers and solo business owners who are tired of manually sorting client bills and receipts. Paste invoice text—or import a .txt file—and it pulls out the vendor, client, invoice number, date, subtotal, tax, total, and line items. It groups detected items into categories and includes a check that compares the invoice total with subtotal plus tax.

The person I built this for is a freelancer who wants a quick expense snapshot without signing up for another cloud accounting service. InvoicePilot is a prototype, not a business with paying customers yet. A possible paid product would be a one-time purchase or a small subscription for freelancers who value a private, lightweight workflow; I have not validated pricing with users.

Demo

Live demo: InvoicePilot on Render. Click Try sample, confirm the hosted-demo privacy notice, then click Organize invoice to see the dashboard, category breakdown, reconciliation check, and export/save actions. This public demo sends submitted text to the Render service for processing, so use fictional/test data only—not real invoices.

For local use, install the dependencies, run python app.py, and visit http://127.0.0.1:5000. InvoicePilot accepts pasted text and .txt files; it does not do PDF or image OCR.

Code

Repository: github.com/anshika361/InvoicePilot

The app is built with Python and Flask. The code includes the invoice parser, the local Ollama integration, and the browser interface for CSV export and browser-local saves.

How I Built It

InvoicePilot has two local processing paths:

1. A deterministic parser extracts common invoice fields and line items. It also assigns simple categories such as design, development, travel, and software.
2. If Ollama is running locally with the llama3.2 model installed, the app can ask that open-weight model to help structure invoice text. If Ollama is unavailable, the built-in parser remains usable without a cloud AI request.

The model is not the calculator: numeric totals parsed from the invoice source stay authoritative even if the model returns a different number. The dashboard compares subtotal plus tax with the stated total and shows a warning when they do not match. That’s important for financial data, where a plausible but incorrect number is worse than an obvious warning.

The interface also supports CSV download, copyable summaries, and saving up to 12 invoice summaries in the browser’s local storage. Those saved summaries stay in that browser; they are not a shared account or a server-side database. Local mode processes invoice text on the user’s device. The public Render demo is different: submitted text is sent to the hosted service and should only be used with fictional/test data.

For this development run, Ollama was not installed, so I verified the fallback path—not a live model inference. I added a test that simulates a conflicting model total to check that it cannot override the invoice’s parsed total. The project’s seven tests pass. I still need to run and record a real Ollama-backed invoice before describing the open-model extraction as demonstrated.

Why Does Open Innovation Matter?

Invoices contain names, client relationships, and money. In local mode, invoice text stays on the user’s device instead of going to a third-party AI service. An open-weight model can run on hardware the user controls, and the model can be swapped or adapted as invoice formats and user needs change. There is no per-request model API bill in this local setup, although running a model still has hardware and electricity costs. The public Render demo is a convenience for trying the sample workflow, not a private place to process real customer invoices.

The fallback also matters: the basic workflow does not depend on an account, network connection, or paid model endpoint. Open tools make it possible to inspect and change the processing path instead of being locked into one provider’s pricing or data policies.

I’m keeping the boundary clear: the current app supports local Ollama inference, but the sample session I verified used the deterministic fallback because Ollama was unavailable. The open-model path needs a hands-on test before I can claim it improved extraction quality over the fallback.