This is the story of how a two-semester collaboration between the Cornell AI Innovation Hub, graduate students, and the Treasury team transformed a time‑consuming, manual investigation process into a tool that helps staff complete the work more efficiently.

The Problem: Money Cornell Couldn’t Spend

Every year, Cornell’s bank account receives hundreds of wire transfers and ACH payments that arrive without enough information to route them anywhere. No invoice number. A vague or abbreviated vendor name. No department code. The money lands in a generic General Ledger holding account and sits there, unavailable to the departments it belongs to.

If a payment isn’t resolved in time, New York State law requires Cornell to escheate the funds, turning them over to the state as unclaimed property. Historically, the backlog has peaked at $4 million.

Cheryl Barnes and Marie Graves on the Cash Management team were spending up to half their workday on this problem. The work is painstaking: searching old emails, Googling vendor abbreviations, calling contacts, cross-referencing past transactions. Some payments take hours to resolve. Many stay unresolved.

The active backlog stood at roughly $1 million across a couple hundred transactions.

The Team

This project started in Fall 2025 as a collaboration between the AI Hub and Cornell Treasury Operations, and continued through the spring semester.

On the AI Hub side: Pete Stergion and Phil Williammee served as co-tech leads. Ayham Boucher and David Keith Nelson provided oversight and kept the project on track. A cohort of graduate students spent the fall semester doing the foundational work: analyzing payment data, prototyping automation workflows in n8n, and testing AI models across Gemini, GPT, and Claude. Their analysis confirmed the key insight that shaped the entire approach: vendor names are present on 99% of unidentified payments, while invoice and PO numbers appear on fewer than 4%. That finding told the team where to focus.

On the Treasury side, Cheryl Barnes, Marie Graves, Kevin Mooney, and Debra Federation were collaborative partners throughout. Kevin provided three years of General Ledger (GL) history from Oracle, over 10,000 resolved payment records. That data became the backbone of the tool.

How We Built It

At the start of Spring 2026, the team had a semester of groundwork: meeting notes, data analysis, workflow prototypes, manual process documentation, and a sanitized version of the payment and GL data with PII removed. The question was how to turn all of that into a production tool.

Using Claude Code’s Plan Mode, the team loaded in everything: the project background, the manual process Treasury staff follow today, all the meeting notes from the fall semester, the student workflow prototypes, and the sanitized data files. Rather than jumping into writing code, Claude Code read through all of that context and proposed a full implementation architecture for the team to review and approve before a single line was written. The plan covered the pipeline structure, the matching strategy, how the AI layer would be used, and where the tool would live. Once approved, execution happened within that structure.

That context-first, plan-then-build approach is what made it possible to go from a semester of notes and prototypes to a working tool in a single session.

Before running the tool against the current backlog of unidentified payments, the team validated it with a backtest. We fed it thousands of historical payments Treasury had already resolved, hid the known answers, and checked whether the tool reached the same conclusions. Three scenarios were run against the full GL dataset of 9,131 resolved payments, each mirroring a situation Treasury staff hit in the field.

For returning vendors with consistent routing, the most common case, the tool hit 97% accuracy across 500 test payments on the base fuzzy-matching pass and 100% with the full AI pipeline. For vendors it had never seen, identification jumped from 76% to 100% once the Gemini search and Claude synthesis layers kicked in, confirming the AI layer earned its keep on the hardest cases.

The backtest also surfaced the tool’s main limitation: vendors who pay multiple Cornell departments. It identifies the right vendor every time but can’t always pick the exact department account when a vendor’s history is split across several. That caveat is documented for the Treasury team so they know where to apply extra scrutiny.

The Pipeline

The tool is a custom Python pipeline accessible as a skill inside Claude Code.

Treasury staff export their standard unidentified payments spreadsheet from Kyriba (their treasury management system) and hand that file to the tool. From there, the pipeline runs three stages.

Historical matching. The tool loads the GL data and uses fuzzy string matching to find the closest vendor match for each new payment. The matcher filters out noise words like “Inc,” “LLC,” and “Corp” that inflate scores for unrelated vendors, and it gates on token overlap so that a single common word cannot generate a false positive. If a vendor has paid Cornell before, the tool finds them.

AI-powered vendor research. For payments where the historical match is inconclusive, the tool queries the Cornell AI Gateway using Gemini Enterprise Web Search to look up the vendor: who they are, their accounts payable contact, any known relationship with Cornell.

Claude synthesis. All the evidence comes together: the original payment details, the fuzzy match result, and the web search findings. Claude, running through the Cornell AI Gateway, weighs that evidence and produces a structured recommendation for each payment: the most likely department, a confidence level, and a suggested point of contact for outreach.

The final output is a formatted Excel spreadsheet, sorted by confidence, with department and contact pre-populated. The whole run takes a few minutes.

The Results

The AI Hub team ran the first batch and handed the output spreadsheet to the Treasury team. They sent outreach emails to 23 departments. Seven responded. Five payments totaling $100,000 were confirmed, matched and identified.

That’s $100,000 recovered from one batch.

While the tool can generate recommendations in minutes, resolution still depends on treasury staff follow‑up with departments to verify the claims. The Treasury team is continuing to work through the remaining items using this approach.

What’s Next

The next step is onboarding. The AI Hub is bringing the Treasury team into Cornell’s Claude pilot program and setting them up with the custom /treasury skill so they can run the investigation pipeline themselves. The goal is a sustainable workflow the team owns and operates directly, with the AI Hub providing ongoing guidance and support to monitor performance and address any issues if results begin to degrade.

The Takeaway

The project worked because the team put in the groundwork. Graduate students spent a semester establishing the analytical foundation. Treasury staff shared their domain knowledge and their data. When it came time to build, the AI had everything it needed to design a real solution rather than a generic one. The $100,000 is a start.

The Cornell AI Hub partners with Cornell departments to design and build AI tools that solve operational problems. If your team has a workflow that could benefit from AI, reach out.