This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.
What I Built
Every Friday, the accountant processes payments to the contractors and suppliers who keep my girlfriend's business running. For that to happen, invoices need to be received, reviewed, approved, correctly named, and forwarded to the accountant before the deadline.
It sounds straightforward, until you consider how many invoices arrive by email, often from different contractors, in different formats, with different naming conventions—or none at all.
The accountant requires PDF filenames containing the vendor, property, and invoice amount, following a specific convention. My girlfriend was spending far too much time opening attachments, checking details, renaming files, and forwarding them. Worse, mistakes or delays could mean someone didn't get paid that Friday.
That's how HappyGF, an AI-powered accounts payable assistant, came about.
The application helps her process incoming vendor invoices, extract the relevant information, prepare correctly named PDFs, and get approved invoices ready for the accountant.
It also remembers what has already been processed. Recently, a contractor accidentally submitted the same invoice twice. HappyGF recognized the duplicate instead of treating it as another invoice to process. A small detail, perhaps, but an important one when dealing with payments.
This isn't an experiment looking for a use case. She's already using the application for real work, and I'm now releasing an open-source edition for other businesses dealing with similar accounts payable workflows.
Demo
Video: https://youtu.be/Ttzg6bqgyA8
The demonstration uses fictional vendors, properties, and invoices to show the workflow from incoming email to an accountant-ready PDF.
Code
GitHub: https://github.com/MokapotLabs/invoice-assistant
The open-source edition includes the application, configuration, tests, and instructions for running it.
How I Built It
HappyGF is written in Java using The Pipeline Framework (TPF), an open-source framework I've been developing over the past few years.
One thing I learned along the way is that not every AI task needs the same model. Reading an unfamiliar invoice, recognizing a company logo, and deciding which property an invoice belongs to are different problems.
The open-source edition uses three models through Ollama:
- Qwen 3.5 4B for invoice text analysis.
- Qwen3-VL 4B for visual recognition, including company logos.
- Tev1 for structured supplier and property decisions.
Tev1 is particularly interesting. It's a small, open-weight decision model that uses the same Jev-style API as the hosted decision service I've been using. Rather than asking a generative model to produce another paragraph of text, the application can ask a specific question, supply possible answers, and receive a structured decision.
Once the invoice has been interpreted, ordinary application code applies the filename convention, tracks processing state, detects duplicates, and manages the approval workflow. The AI assists with interpretation; it doesn't get to authorize payments or bypass business rules.
Microsoft Graph provides the Outlook integration, while TPF handles the typed pipelines, persistence, external operations, and execution concerns.
Local AI sounded perfect. Then I tried running it on an 8 GB MacBook.
My original intention was to keep inference local, using Ollama. It works, and I've used it extensively for development and automated testing.
Unfortunately, the application isn't something my girlfriend uses continuously. She opens it when there are invoices to process, and Ollama may need to load the models into memory. Some invoices also require visual recognition, which means switching models.
On her 8 GB MacBook, that can turn into a one- or two-minute wait. Not exactly the experience you want when you're trying to get through a pile of invoices before Friday.
Running Ollama on another machine would help, but keeping another computer running just to process a few invoices each week feels rather wasteful.
So I tried hosted inference through OpenRouter.
The current hosted setup uses Gemini 3.1 Flash Lite and Jev 1.13. It's fast, requires no local model installation, and the API key has accumulated less than four US cents in usage so far.
Introducing Jev also made a noticeable difference to cost. By moving suitable decisions away from the generative model, I've seen roughly a 50% reduction in inference spending.
These are observations from a lightly used application, not a controlled benchmark, but they surprised me. At this volume, inference costs are practically negligible compared with the time saved.
The open-source edition retains Ollama support, so users can choose local inference instead.
Why Does Open Innovation Matter?
The experience with HappyGF has changed how I think about local AI.
Invoices contain commercially sensitive information, including supplier identities, properties, amounts, and business correspondence. Running open-weight models locally means that information doesn't have to leave the business's own hardware for AI inference.
But local execution comes with costs of its own: memory, processing power, model loading, and maintenance. On modest hardware, those costs can make a perfectly functional application unpleasant to use.
Hosted inference offers a different balance. OpenRouter provides controls over prompt logging, provider data collection, and zero-data-retention routing. Those protections are useful, but remote inference still requires sending information to an external provider, whose data-handling policies matter.
Open-weight AI gives us a choice; it doesn't mean local inference is always the best choice.
For HappyGF, the practical benefit of open innovation is the ability to experiment with smaller, specialized models, run inference locally when confidentiality requires it, and choose hosted alternatives when convenience matters more.
Tev1 is a good example. A small decision model can handle certain questions without invoking a larger generative model. And because both the application and TPF are open source, the surrounding workflows and business rules remain inspectable and adaptable.
The goal isn't to eliminate every external dependency. It's to avoid making any particular inference provider or model an architectural requirement.
My First User
My girlfriend has been using HappyGF for her actual accounts payable work.
She's responsible for ensuring that invoices reach the accountant in time for the weekly payment run, and the application was built around the problems she encountered doing that.
One recent incident illustrates its value particularly well: a contractor submitted an invoice twice. HappyGF identified the duplicate, avoiding another round of manual checking and reducing the risk of processing the same invoice again.
Her experience has driven the application's development, including decisions about which integrations are worth keeping and whether local inference is practical on the hardware she already owns.
She hasn't paid me for the application, but she uses it for real work. I'm interested in discovering whether other managers and accounts payable teams face similar problems and would find an open-source alternative useful.
Top comments (0)