Every vendor in clinical trial financial management is now an AI company, and every demo has a sparkle icon. But if you ask how the AI actually works, you'll usually get some version of "it's proprietary."
Here's our position at Auxilius: AI belongs at the beginning of your financial process and at the end. It does not belong in the middle. If a vendor tells you AI is doing your calculations, that should worry you, not impress you.
Every forecast, accrual, or reconciliation follows the same arc. You set up the inputs, you run the calculation, and you make sense of what came out.
The beginning is a setup problem. Which cost methodology fits this study? What enrollment curve is realistic given these sites and this protocol? What should the forecast settings be for a region you've never run in before? This is where teams spend hours staring at blank configuration screens, and it's where AI is excellent. It can read the shape of your study, compare it against patterns, and suggest a starting point that a human then reviews and approves.
The middle is a math problem. Given these approved inputs, what is the number? This part should be deterministic: the same inputs produce the same output every time, with every step traceable. Not because it's old-fashioned, but because the entire value of the number depends on it.
The end is a language problem. The calculation produced a variance. But why? What moved, where, and what does it mean for the study? This analysis and narrative creation is the other place AI shines. It can read across thousands of line items and surface the story a human would have taken a day to piece together, with every claim pointing back to real, traceable numbers.
And the very end is a judgment problem, which is to say it's yours. Everything upstream exists to put you in a position to make a good call: parameters you approved, a number you can trace, a story you can check. No part of this process makes the decision for you, and you should be suspicious of any product that wants to.
AI at the edges. Deterministic engine in the middle.
You can't trust a number you can't reproduce. If you rerun last month's close and get a different answer, you don't have a financial system, you have a suggestion box.
Variance analysis depends on it. FP&A relies on month-over-month comparison. If the model producing your forecast is probabilistic or quietly “learning,” you can never tell whether a variance reflects your trial or your tooling. When the engine is deterministic, every variance is a real signal.
You have to explain the number to someone, even when no auditor is in the room. Every accounting team eventually stands in front of a CFO and explains why the accrual moved two million dollars. "The AI updated its estimate" is a career-limiting answer. "Enrollment ran ahead of plan at these twelve sites, here's the evidence" is not. The AI can help you write that explanation, but the explanation has to describe a calculation that actually exists.
In clinical trials, someone will eventually make you prove it. This is where trial finance parts ways with general-purpose tooling. Accruals for clinical studies get audited. Sponsors are asked to defend numbers to external auditors and, ultimately, to regulators, and neither accepts "the model felt like it." Every number needs a lineage: which inputs, which rules, which source data, and who approved what. A black-box middle isn't just inconvenient at audit time, it's disqualifying. If your vendor's answer to "walk me through this accrual" involves the word "proprietary," you're the one who inherits that problem in the audit.
Large language models are simply bad at this part. LLMs are probabilistic language systems. They are remarkable at language tasks: drafting narratives, interpreting messy inputs, suggesting configurations. They are unreliable at precise arithmetic across thousands of line items. A vendor claiming AI performs your calculations is doing one of two things: running deterministic code and marketing it as AI, or actually letting a probabilistic system touch your numbers. One of those is dishonest. The other is worse.
If you want to see this play out in one workflow, look at investigator reconciliation: taking your raw site payments report and matching it against the investigator transactions in your financial model, derived from EDC data and site budgets. This is one of the messiest jobs in trial finance, which is exactly why "our AI handles it" can sound so appealing. That pitch carries a giant prerequisite: AI only works on a job like this if the data coming in is structured and clean. We've run this on real studies for years and we have yet to meet a sponsor or CRO where that's the case. Here's what the matching actually involves:
There is no key. Nothing in a payments file links a line directly to a transaction in your model. The join has to be built from imperfect pieces: site, patient, a description that first has to be classified, dates that may not agree. A match built from fuzzy pieces is only trustworthy if the way they combine is explicit and fixed.
There is no shared language. A payments file can have hundreds of sites each describing procedures in their own words, with no standard taxonomy connecting a payment description to a protocol visit or procedure. There's no existing structure for AI to map into; the structure has to be built first, classification by classification, confirmed into rules. AI can help propose those classifications, but it cannot conjure the ontology that isn't there.
Nothing is one-to-one. One visit in your model can be billed in four different payment lines: procedure, radiologist time, tech time, admin fees. Conversely, one payment line can cover three different procedures/visits. On one oncology study, we found that some sites were billing multi-region scans as a single record while the model tracked each scan as an individual record - Chest, Abdomen, or Pelvis CT scan in three distinct lines. How things group has to be decided before anything can match. AI can certainly help propose those groupings, but the proposal should be something you see and approve, not something that happens silently inside the match.
Everything must be accounted for. Every record must end either matched (carrying the rule that matched it) or unmatched. Nothing should be dropped or double-counted, and your totals must tie back to the source. With a probabilistic system, you run the risk that a row quietly disappears or gets counted twice, and that nobody notices.
Especially because the unmatched pile is a key output. The value of a reconciliation lives in what didn't match perfectly: that's where the billing lags, the naming mismatches, and the rate discrepancies show up. An LLM's failure mode is helpfulness. It wants things to pair up, and a matcher that forces pairings destroys the exact evidence the exercise exists to produce.
Then there's scale. We've reconciled payments files from large Phase 3 studies with over 500,000 rows. That's real compute even for a purpose-built algorithm. Now imagine pushing half a million rows through an LLM, cross-comparing under tolerance logic, every month. If a vendor tells you AI-powered reconciliation at that scale is "included," ask them to put the per-run cost in the contract, because the token bill says that promise doesn't survive contact with a Phase 3 study.
The thread through all of this is one word: probabilistic. A language model produces likely answers, and for drafting, mapping, and interpreting, likely is exactly what you want. However, the match itself isn't likely or unlikely, it's right or wrong. The danger of a probabilistic matcher isn't bad output you'd catch, it's reasonable-looking output you'd trust.
AI interprets the mess. The rules make the match. AI summarizes and helps you identify exceptions. You decide what to do about them. So when a vendor puts "AI" on their reconciliation, ask what's underneath. If AI helps configure rules that a person approves and a deterministic engine runs, that's the right architecture, and they should be able to show it to you. If AI is making the matches, find that out before your site payments depend on it.
If a vendor won't tell you how their algorithm works, it's usually because there isn't one, or because there isn't the underlying data and structure to back it up.
Take this list into your next demo, including ours. In our next post: how we're tackling all of this at Auxilius, and the two families of agents we're building because of it.
.png)