How Cornell Recovered $100,000 in Unidentified Payments With a Claude Skill
Cornell's finance and AI teams built a small Claude skill called /treasury that recovered roughly $100,000 in unidentified payments. Here is the two-pillar adoption model that produced it, and what it means for enterprise back-office teams running their own AI labs.
A $100,000 line item that almost walked out the door
Cornell's finance team had a quiet leak. Across years of incoming payments, a subset of incoming transfers was landing in the university's accounts without a matching receivable — well-formed bank activity that did not tie to anything on the books. The team had already accepted it as a known gap: small enough to live with, too expensive to chase line by line. Then the university's AI Innovation Hub, working with Treasury, built a small Claude skill called /treasury and asked it to read the same data they had been reading by hand for a decade. Within a working sprint it flagged roughly $100,000 in back payments that should have been identified on arrival and were not. The story matters because the pattern is repeatable — and because it shows what an enterprise AI lab actually does when it sits next to a domain team instead of above it.
Why the gap existed in the first place
Most enterprise finance functions run on the same assumption: if a payment is large or unusual, a person will notice it. The reality is that mid-size transactions — a $4,200 vendor refund, a $9,800 grant disbursement, a $22,000 tuition reconciliation — slip through because they are below the threshold that triggers a human review and above the noise floor that gets auto-coded. The information needed to identify them usually exists somewhere in the organization: in a memo, in an email thread, in a colleague's inbox on a Tuesday afternoon. The institutional memory is real; the institutional system that captures it is not.
This is the failure mode that classic automation scripts do not solve. The data is structured on the way in (a bank record is a bank record) but the matching context is unstructured, distributed across dozens of systems, and held by people who are not in the finance department at all. A rule engine cannot reason across it. A human can, slowly. An AI assistant with permission to read the surrounding context can do it at the speed of an arriving transaction.
What the /treasury skill actually does
The Cornell team did not build a model. They built a thin Claude skill — a small wrapper that knows where Cornell's payment, grant, vendor, and student-system records live, and that can reason across them when the bank's daily file arrives. The pattern is closer to giving a sharp junior analyst a desk in the treasury office than it is to deploying a model.
1. It reads the inbound bank activity against the systems of record. Each line item gets evaluated against the canonical list of expected payors, programs, and reference codes for that day. Most lines match a known source; a small fraction do not, and those are the ones worth attention.
2. It writes a short reasoning note for each unmatched line. The note is what an analyst would write if they had the time — what was looked up, what was checked, what remains ambiguous. That note is what makes the human-in-the-loop step fast. The reviewer is editing a draft, not starting from zero.
3. It routes the draft to a person, not to a queue. The skill flags the items that warrant review and leaves the rest alone. Treasury staff time gets spent on the lines that need it, not on the 95 percent that did not.
4. It keeps the institutional memory explicit. When a judgment is made — "this vendor always pays on the second business day, so a third-day arrival is suspicious" — that judgment is logged. The next quarter's review starts from last quarter's decisions, not from a blank notebook.
The two-pillar adoption model that made it work
Cornell's AI Innovation Hub is explicit about the structure that produced the result, and it is worth reading carefully because most enterprise AI failures live in this exact gap. The Hub runs on two pillars at once, and the recovery of the $100,000 in payments is the kind of outcome that only happens when both pillars are present.
Pillar one: broad incentives for every employee to use AI in their own work. Cornell runs internal training, gives every staff member direct access to frontier models, and rewards — through performance reviews and small grant programs — the staff who find novel uses inside their own function. This is what surfaced the initial idea. Someone in finance had been quietly experimenting with Claude against reconciliation tasks. The Hub's job was to notice and to remove friction.
Pillar two: a dedicated lab of AI builders who can harden a good idea into a tool. The Innovation Hub is staffed by people who can take a promising prompt, wrap it in a skill with proper access controls, integrate it into the surrounding systems, and ship it inside a sprint. Without this pillar, the idea stays a clever demo. Without pillar one, the lab has no queue of ideas worth hardening.
Most enterprises invest heavily in one pillar and quietly starve the other. They buy enterprise model licenses (lab without incentives) or run an AI training program (incentives without a lab). The Cornell case shows the second-order effect: the $100,000 is not the value of a model, it is the value of a pipeline that turns local curiosity into institutional tooling.
What changes for a board reading this case
Three things are worth carrying forward. First, the size of the win is not the point — $100,000 is a line item at Cornell and it would be a line item at most enterprises. The point is that the same shape of gap exists in almost every mid-sized back-office process: a place where institutional memory is real but unsystematized, and where the matching context lives outside the system of record. Every finance, HR, legal, and grants team has a version of it.
Second, the cost of the build was small. A small lab, a willing domain partner, a few weeks of focused work. The economics are not "can we afford to build this?" but "how many of these are quietly leaking value while we wait?"
Third, the governance model is already inside the design. The skill writes a draft for a human reviewer; the human signs off; the system records the decision. There is no fully-automated path that lets an AI move money. That is the right shape for a treasury function, and it is the right shape for most regulated back-office work.
A practical starting point for an enterprise team
If the Cornell case is a useful pattern, the first step is to inventory the back-office workflows where institutional memory is real but the system that captures it is not. Reconciliation, vendor onboarding, expense classification, grant attribution, contract renewal — each of these has a small number of people who know the unwritten rules. Pair that inventory with a small, well-supported lab that can turn one of those workflows into a skill inside a quarter. Do not start with the largest gap; start with the one whose domain partner is willing and whose review loop is fast.
The pattern that produced the Cornell result is not exotic. It is two pillars held in tension — every employee encouraged to find AI uses in their own work, and a dedicated team whose job is to ship the ones worth shipping. The $100,000 in recovered payments is what falls out when both pillars are funded.
Book a strategy consultation to map the back-office gaps in your organization against the AI lab model that is now proven to ship.