A match you can’t explain isn’t a reconciliation. It’s a guess with a good interface.
Ensuring clinical trial sites are paid accurately sounds straightforward. Compare what should have been paid with what was actually paid, investigate the differences, and resolve them. Anyone who has managed investigator payments knows how much complexity that sentence hides.
Across a study, teams may need to reconcile hundreds of thousands of records. The same procedure can appear differently in a site budget, an EDC-derived transaction, and even across different payment reports. One payment may cover several procedures; one procedure may occur across several visits. Add site-specific rates, amendments, credits, and timing differences, and there is rarely a simple answer key.
A VLOOKUP can retrieve a match when a reliable shared key exists. It cannot establish whether differently described records represent the same contractual obligation. Before matching can work, someone must define what those records mean.
AI offers tremendous promise for reducing that burden. It can help interpret descriptions, propose classifications, and summarize discrepancies. But how we use it matters.
Our Head of Product, Kristen Lueck, previously has outlined where AI belongs in trial finance. I want to apply that perspective to investigator reconciliation—and a particular risk I’ll call “black box matching.”
The promise is appealing: upload your files and receive matches and potential overbillings in minutes. Whether that promise comes from a general-purpose AI assistant or a purpose-built platform, an organized output does not establish that the matches are correct.
Black box matching is AI-inferred pairing of payments with expected transactions where the criteria behind each match cannot be inspected and the result cannot be reliably reproduced on demand.
You can see the pairing, but you cannot adequately examine, configure, or rerun the logic that produced it. A convincing explanation after the fact is not the same as a recorded rule that actually governed the match.
Picture a 500,000-row payment file where the matches are only “mostly right.” Someone now has to establish which ones are correct. If every pairing needs to be rechecked, the apparent time savings disappear. In fact, you have created an entirely new review burden.
The question to ask is simple: Can you show me exactly why these records matched—and reproduce the result?
At Auxilius, our approach builds on years of working with real study payment data. Our guiding principle is AI at the edges, with a deterministic core applying approved rules to make the matches. Applying this to our reconciliation process, it follows three steps:
1. Configure the model and approve the rules
Establish how sites, subjects, visits, procedures, contract terms, and payments relate to one another. Define equivalent descriptions, bundled and split records, applicable rates, and matching tolerances. AI suggests classifications; qualified people review and approve them before they affect the reconciliation.
This addresses the first problem with black-box matching: similar language does not necessarily mean the same financial obligation.
Investigator payments expertise is essential to developing this model. Someone must understand how protocol requirements become contractual obligations, how sites bill for the work, and how payment reports can obscure what actually happened. That experience determines which rules to build and which exceptions to investigate.
2. Run deterministic matching
Our automated engine executes the approved rules so the same inputs and configuration produce the same outputs. Each match retains its source records and the rule that produced it, while controls ensure totals tie back to the source and records are not dropped or double-counted.
This addresses the second problem: that LLM-generated pairings can vary across runs, prompts, settings, or model versions, making a changed result harder to explain.
Ambiguous records remain visible for review. A repeatable process still requires validation, but it gives teams a defined basis for investigating and correcting errors. It doesn’t create an additional audit for the team.
3. Make the results actionable
Every expected transaction receives a clear status, such as matched, overpaid, underpaid, or not yet paid. Where invoice data is available, the process can also distinguish transactions not yet billed. Duplicate payments and payments without a corresponding expected transaction remain explicit exceptions.
AI can then summarize patterns, highlight recurring discrepancies, and help teams prioritize investigation. People decide what action to take.
This also addresses the third problem: repeatedly asking a frontier LLM to interpret and compare raw records can add unnecessary processing cost. A structured model and reusable rules reduce that repeated work. Buyers should still ask how processing time, capacity, and pricing change as their data grows to eliminate unpleasant surprises down the road.
With explainable matches and visible exceptions, teams can spend less time wondering if their reconciliation is air-tight and more time resolving underpayments, investigating potential overpayments, and understanding what remains outstanding. That supports more productive site conversations and financial balances they can explain.
The technology matters. So does the payments expertise built into the model. Together, they make automation useful: less time reconstructing the answer and more time acting on it.
For more on Auxilius’s approach to AI, read Kristen’s article, Where AI Belongs in Trial Finance (and Where It Doesn’t).
Interested in automating your investigator reconciliation? Request a demo—we’d love to connect.
.jpg)
.svg)
.jpg)