Inspiration

Evan won a prize at TreeHacks earlier this year. The organizers first tried to ship him the physical prize, then found out they couldn't because he's Canadian. So they switched to a wire. The payment had to go through Stanford's accountants, which meant every step passed between the organizers, the student government's finance office, and Evan. Forms got requested, sent, and requested again. Emails sat on delivered. Nobody was sure what the next step was. It took about 9 months for the money to arrive.

No one really messed up. The organizers just had no way of knowing, right when he won, that a Canadian winner needs a W-8BEN, a withholding decision and an international transfer. Jin co-directs Hack@Brown, so this is the part of running a hackathon we already knew from the inside. When we talked to other organizers, everyone had a story like this. Someone waited weeks on a reimbursement because of one missing receipt. A prize got announced before anyone checked if it could be shipped to the winner. Tax forms got chased down months after. It doesn't help that most student hackathons don't hold their own bank account, so every payment means asking the university or a fiscal sponsor to send it.

So we asked: what if one agent with limited permissions did the work of the travel coordinator, the accounts payable clerk and the tax preparer, while a person still decides when money moves?

What it does

Eve handles the money side of a hackathon or any large-scale event: travel reimbursements, expenses, cash and physical prizes, and even the cross-border tax work. Organizers set budgets and rules, attendees submit receipts and claim prizes in a portal, and Eve prepares every payout with its evidence.

  • Overview. Organizers see the budget left, payouts waiting for release, what's blocked and why, and the prize pipeline before the closing ceremony.
  • Travel claims. Attendees upload receipts in a portal. Eve reads them, converts currencies, checks them against the event's caps and policy, looks for duplicates, compares the fare with what other attendees paid and what that route actually cost, and either pays it or flags it for a person.
  • Prizes. For each item prize Eve compares shipping it, buying it locally and paying a cash equivalent, and checks whether it can be shipped to the winner's country. Team splits requires each member to confirm. Eve collects the W-9 or W-8BEN and works out withholding, fees and FX before anything is approved.
  • Fraud guards. Boosted fares get flagged. Travel claims from hackers with no project on record get escalated. A bank account change right before payout freezes the payment until it's confirmed through the original contact channel.
  • Approvals. Every proposal shows the gross, withholding, fees and expected net. Only a controller can release a payment. Organizers can't release payments, and nobody can approve a payment they asked for. The agent doesn't get special access either. It's just another role with limited permissions. Controllers can approve straight from a Slack DM, and organizers get channel alerts and digests.
  • Sponsor portals. University finance portals don't have APIs, so normally a student retypes every sponsor packet by hand. Eve opens the portal on a sandboxed desktop with computer use, fills it out, fixes errors the portal throws at it (like a missing W-8BEN), and stops before Submit, where a person has to press it. Eve also reconciles the sponsor's remittances afterward.
  • Books and filings. Every payment goes into a balanced double-entry ledger that can't be edited after the fact, and every number traces back to the decision that produced it. At the end you can export a journal for QuickBooks and generate 1099 and 1042-S worksheets.

We seeded a fake 300-person event with 160 travel claims and 25 prizes, and planted 40 problems in it: underage attendees, expired tax forms, padded fares, a bank account change right before payout, and so on. Eve caught all 40, with no false positives and no wrong payouts.

How we built it

Frontend: Next.js 16 App Router, React 19, TypeScript, Tailwind CSS 4, shadcn/ui, Base UI and TanStack Table.

Backend: Server actions and route handlers, Postgres on PlanetScale with Drizzle, Better Auth for accounts and roles, Zod, and pdf-lib for documents. Long-running jobs like the nightly review and payout proposals run on Vercel Workflow so they survive restarts.

AI: Claude, through the Vercel AI SDK and the Anthropic SDK, reads receipts with structured extraction and runs the event review agent. Sponsor portal entry runs on an E2B Linux desktop with Claude computer use. The code decides when to Submit, not the model.

We purposefully kept the AI out of the math. Caps, tax rules, withholding and ledger entries are all plain deterministic code with tests, and the model never decides an amount. If Claude isn't sure about something on a receipt, it goes to a human instead of guessing.

Money movement is simulated and the tax forms are drafts, not real filings.

Challenges we ran into

  • Autonomy without a superuser. The agent's limits are enforced in code, not in the prompt. It can propose and hold a payment, never release one.
  • Numbers that don't match. The same payment can look different depending on where you check. The receipt might say one amount, while the card charge another after currency conversion, and the sponsor's records a third. Eve has to pick which number to trust and explain why.
  • Tax rules are messy. They change all the time, and we're builders, not accountants. We couldn't verify every rule we implemented, so we marked the ones we weren't sure about as unverified.
  • Keeping the ledger correct while lots of things happen at once. Duplicate releases and half-finished jobs scared us most, so we wrote tests that try to pay the same claim twice.
  • Getting computer use to recover from the portal's errors without letting it click things it shouldn't.

Accomplishments that we're proud of

  • 40 out of 40 planted problems caught on the demo event, zero wrongful payouts.
  • Payments that need a controller really do need one. Not even the organizer or the agent can push them through.
  • A balanced ledger that can't be edited afterwards, where every number traces back to the decision that produced it.
  • Watching Eve run into a W-8BEN error on the sponsor portal, attach the form and keep going was a pretty good moment.

What we learned

Paying people wasn't the hard part. The hard part was knowing what you need before you pay: which form, which country, whose sign-off. If you know that the moment someone wins or uploads a receipt, the rest is mostly bookkeeping.

We also got more careful about where the model goes. It's really good at reading messy receipts and web pages. We just don't want it deciding how much tax to withhold.

What's next for Eve

  • Real payouts through Stripe and wire providers instead of the simulated rail, plus verified flight booking through Duffel
  • Verifying the Canadian rules and treaty handling with an actual tax professional
  • Official IRS and CRA forms and e-filing instead of drafts
  • Email verification and invitation emails so real organizations can sign up
  • Trying it on a real event, starting with Hack@Brown, and ideally one where someone is still waiting on their prize

Built With

Share this project:

Updates

Submission history