Case study

The invoice that should never have been sent: building InvoxAI in a two-day hackathon

A recurring headache in accounting, a two-day company hackathon, and a small team that decided to fix the problem instead of just complaining about it.

By Chinmay Bandekar · Hasso Plattner Foundation · 2026

The problem my Lead kept running into

Every foundation pays a steady stream of invoices from vendors and partners, and someone has to check that each one is actually correct before it goes to payment. My Lead was the person who kept running into the same frustration: invoices would go out for payment with the wrong VAT calculation, a mismatched entity or vendor address, or terms that quietly broke our procurement policy. The errors were usually only caught after the invoice had already been sent forward, which meant escalation, a round of back and forth with the vendor to correct it, and sending it through again. It was not a rare event. It was a recurring cost of doing business that nobody had actually sat down to fix.

That was the problem sitting in the room when the foundation ran a two-day internal hackathon, open to anyone with an idea worth two days of focused building.

Where the idea actually came from

We did not walk into the hackathon with InvoxAI as the plan. The idea came out of brainstorming once we were there: if the recurring problem was invoices slipping through with errors that were, in principle, checkable, why not build something that checks them before they ever reach a human's desk. From that conversation, the scope grew almost immediately beyond just our own foundation. If this worked for us, there was no reason it could not eventually help our partner organizations and grantees do the same check on their own invoices.

We were a team of three for those two days. My Lead defined the actual business logic, the specific checks an invoice needed to pass and the reasoning behind each one. A student colleague at the foundation supported the build. I was responsible for the architecture and building the application itself, a React frontend for uploading invoices and contracts, and a Node.js backend that called the Anthropic Claude API to run the checks and return a result.

What the tool actually checks

This is the part that made InvoxAI more than a toy demo. Working from my Lead's specification, the tool validates an invoice against a real list of failure points: the VAT number and whether the VAT calculation is correct for the relevant region, the entity name and address, the vendor name and address, whether the vendor should be tax exempt, and whether the invoice complies with our procurement policy, along with several other checks drawn directly from the mistakes that kept recurring. Each of these is a real reason an invoice used to bounce back after the fact. Building them into a single upfront check meant the mistake gets caught once, at upload, instead of after it has already gone halfway through the payment process.

The tool flags what it finds. It does not silently approve or reject an invoice on its own; it surfaces the issues so a person can review them and decide, which matters for the same reason it mattered in every other AI system I have built here: the model can catch a mismatch far faster than a person scanning line by line, but the decision to send money still belongs to a person.

From hackathon prototype to production

Two days is not enough time to build something polished, only enough time to prove an idea works. What made InvoxAI different from a typical hackathon demo that gets forgotten in a folder somewhere is that it kept going after the two days ended. It is in production use today, checking invoices before they are sent for payment, catching the same VAT, entity, and procurement issues that used to slip through and come back as a second round of work.

What's next

The idea that came up in that first brainstorm, taking this beyond our own foundation to partner organizations and grantees, is still the direction I would like to see it go. Right now it solves the problem for us. The natural next step is packaging the same checks in a way that any partner organization with the same recurring invoice headache could use it too, without needing their own hackathon to get there.

The takeaway

InvoxAI is my favorite reminder that a two-day hackathon is a real production pipeline if you let it be one. The best ideas here did not come from a roadmap document, they came from someone describing a problem she deals with every week and a small team deciding, in the room, that it was worth fixing properly.