Where treasury and AI actually meet

I sat through a vendor pitch last quarter where the demo opened with "AI-powered treasury intelligence". The actual product was a dashboard with five filters and a CSV export. The AI was a chatbot that answered questions about how to use the dashboard. The treasurer next to me, who was being sold to, audibly sighed.

There is a real conversation to be had about AI and treasury. It is just not the one most vendors are having. The two places the combination earns its keep, in our experience so far, are unglamorous and specific.

One. Document understanding

The most boring and most valuable use of language models in treasury is reading documents. Invoices, bank statements, contracts, KYC packs, supplier-onboarding emails. The data extraction problem in mid-market finance is enormous, and it is exactly the kind of problem language models are good at when constrained correctly.

Notice the word constrained. A model that reads an invoice and confidently extracts the wrong amount is worse than no model at all. The interesting engineering work is not in the model. It is in the structured fields you require the model to populate, the validation rules that catch model errors before they become workflow errors, and the human review queue where uncertain extractions land.

At Calabash, every model extraction writes to a structured invoice record, every field has a confidence score, and any field below a threshold goes into a review queue rather than to payment. The model is not making decisions. The model is doing the typing the AP clerk used to do, faster and at lower cost, with a human catching the cases the model gets wrong.

The lift is not on the high-confidence cases. The model handles those fine. The lift is on getting the low-confidence ones reviewed quickly so the throughput as a whole is faster than the all-human baseline. That is a workflow problem, not an AI problem.

Two. Anomaly surfacing

The second place AI earns its keep is in surfacing things that look off. A payment about to go out to a new bank account that has only been on file for forty eight hours. A supplier whose invoice amounts have drifted up by twenty percent over six months without a contract change. A buyer who is approving requisitions twenty minutes faster than usual.

None of these are deterministic flags. None of them are easy to write as a rule. All of them are pattern-recognition problems where a model trained on the historical workflow data can flag patterns a human reviewer would also flag, given infinite time to look.

The use is not to autoblock the payment or autosuspend the buyer. The use is to put the flag in front of the treasurer or AP lead at the right moment, with the specific pattern that triggered it explained in language they can act on. The decision is theirs. The pattern detection is the model's.

What we are not doing

We are not building a treasury copilot. We are not building a natural-language interface to the cash position. We are not building generative reports. The treasurers I have talked to do not want any of that. They want the data they look at to be right, they want anomalies to surface before they become problems, and they want their evenings back.

AI helps with two of those. It does not help with the third. The third comes from getting the primitives right.

The honest line

If you read this and decide you want AI in your treasury function, the question to ask the vendor is not "what AI features do you have". The question is "which extraction tasks does your model do unattended and what is the false-positive rate of your anomaly detection". If they cannot answer either with a specific number, you are looking at marketing.

If you ask us those questions, we will give you a real answer about where we are. We are early. We are honest about being early. Sign up for Calabash Business at calabash.app/b2b.