Clinical Research Site Management Software: Why a Multi-Site Network Finds Unbilled Visits Six Months Late

Why a site network breaks the CTMS it bought

A site director opens the quarterly numbers and sees a receivable that does not match anything. One sponsor has paid, but the remittance is a two-page PDF listing patient identifiers and amounts with no reference to a visit or a line item. Another sponsor has not paid for eight visits at site three because the coordinator recorded the visit in the source but nobody flagged that the protocol allows an unscheduled visit to be billed separately. A third protocol closed out four months ago and nobody chased the holdback written into the clinical trial agreement. Somewhere in that mess is real money, and finding it means one person and a spreadsheet for three days.

This is not a discipline problem. It is a data model problem. A site network's revenue is generated at the intersection of a protocol, a patient, a visit, a procedure and a contract term, and no site-side CTMS on the market holds all five in a way that lets you ask what am I owed today across every sponsor. Coordinators are measured on visit windows and data queries. Nobody is measured on whether the visit turned into an invoiceable line, which is exactly why it often does not.

Problem 1: the budget grid is the product, and it lives in a PDF

Every clinical trial agreement carries a budget: per-visit amounts, per-procedure line items, screen failure reimbursement at some fraction of the screening visit, pass-through costs for IRB fees, pharmacy set-up, records storage and archiving, plus invoiceables that only trigger on an event such as an unscheduled visit, a serious adverse event report or an unplanned monitoring visit. It arrives as an appendix in a PDF or a spreadsheet, and in most networks it gets summarised into one number per visit inside the CTMS. That summarisation is where the money leaks, because the events that pay best are the ones that do not appear on the visit calendar.

Advarra OnCore models protocol calendars and financials seriously, but it was shaped around academic medical centres with institutional finance offices, and implementing it at a six-site private network is a heavy lift for the shape of your problem. RealTime-CTMS is genuinely site-first and is a good product for a single-site operation, with strong eSource and payment handling. Advarra Clinical Conductor covers site financials well. The consistent gap across all of them is portfolio reconciliation: matching what a sponsor actually paid, in the format they actually pay it, against what your grid said each visit and event should generate. That step still ends in Excel, and it is the step that finds the money. Florence eBinders and Complion are strong at eRegulatory and eSource, but they are binder systems. They are not trying to solve the money and should not be judged for it.

What a custom build does: the budget grid becomes a structured object, not a summary. Each protocol version carries visit definitions, procedure lines with amounts, conditional invoiceables with their trigger, pass-throughs, holdback terms and payment schedule. When a coordinator records that the ECG and the PK draw happened at visit four, the system generates the exact lines that contract permits, and when a procedure was in the schedule but not performed, it says so before the visit closes rather than after the payment cycle.

Problem 2: visit windows and procedure completion are two different truths

The coordinator's day runs on visit windows: this patient is day 84 plus or minus 3, that patient needs a fasting draw before 10am, this one has a lab kit that expires next week. The finance question runs on procedure completion: did the procedures the contract pays for actually get done and recorded. Those two views come from the same events and are almost never joined, so a visit can be perfectly compliant and still generate half the revenue it should.

Build one event, two views. The visit record carries the window, the protocol-required procedures, the actual completion timestamps and the billable mapping. The coordinator sees a work list ordered by window risk. The site director sees the same data as expected revenue, recognised revenue and revenue at risk because a required procedure has no completion record. When a protocol amendment changes the schedule mid-study, the system versions the grid and applies the right version by visit date, which is the detail that spreadsheets always get wrong on retrospective reconciliation.

Problem 3: sponsor remittances arrive as a lump with no line detail

Sponsors and their payment vendors pay on their own cycles, often quarterly, often in arrears, and the remittance advice is a PDF or a portal export whose structure differs by sponsor and sometimes by study. Nobody at your network has the hours to open each one and tie lines back to visits. So payments get applied at the invoice or study level, the receivable ages quietly, and by the time anyone looks the timely dispute window in the contract has passed.

This is the one place where AI genuinely earns its keep here, and it is not a chatbot. A document extraction pass reads each remittance in whatever layout it arrives in and produces structured lines: subject identifier, visit reference, amount, adjustment reason. A matching engine then reconciles those lines against the expected lines your budget grid generated, and produces three buckets: matched, short paid with a reason, and never paid. In our experience the extraction settles into the high eighties as a no-touch rate after a few weeks of correction, and the unmatched queue is the actual work product, because it is a list of things to dispute while you still can. Budget grids themselves can be parsed the same way at study start-up, which cuts protocol set-up from days to hours.

Problem 4: feasibility and enrollment decisions made without portfolio math

A sponsor offers a protocol. Someone in business development looks at the per-patient amount and says yes. Nobody computes what that protocol will consume: coordinator hours per visit, the exam room, the centrifuge, the monitor visits, the regulatory workload at start-up, and the twelve months of follow-up visits after enrollment closes that generate very little. A network that says yes to everything runs out of coordinators, misses enrollment on the studies that pay, and takes the reputational hit on both.

The build should carry a capacity model: coordinator hours per visit type by protocol, room and equipment constraints, and projected visit volume from enrollment forecasts. Then a feasibility screen answers a real question, which is what this protocol earns per coordinator hour compared with what you already have on the calendar. Sites that run this discipline start declining protocols, and declining the wrong protocol is worth more than any efficiency feature in the system.

Problem 5: the coordinator's day, and the systems nobody logs into

Coordinators already work in the sponsor's EDC, the sponsor's IRT, an eRegulatory binder, the hospital EHR and a paper source worksheet. Any system you build that asks for a sixth login and offers nothing back will be filled in on Friday afternoon from memory, and your financial data will be worth exactly what that is. The build has to give the coordinator something they want on day one: the visit work list with windows and required procedures, the lab kit expiry warnings, the reminder that a patient stipend is owed. Give first, then the billing data arrives as a by-product of work people already do.

What this costs and how long it takes

A first release with structured budget grids, visit and procedure capture, invoiceable generation and a portfolio receivables view runs $70,000 to $150,000 and ships in 12 to 18 weeks, based on Digital Heroes delivery experience. A full platform adding remittance extraction and reconciliation, coordinator scheduling and capacity, enrollment forecasting, patient stipend handling, eRegulatory integration and finance-grade revenue reporting runs $180,000 to $450,000 phased over 6 to 12 months.

What drives price up in a site network specifically: the number of sponsors whose remittance formats you must parse, because each one is its own layout. Integration with an existing CTMS or EHR, since read-only extracts are cheap and bidirectional sync is not. Patient stipend and travel reimbursement, if you want debit card issuance rather than manual payments. Multi-entity accounting, if your sites are separate legal entities with their own books. And study start-up workflow if you want regulatory document tracking rather than just money. What keeps it down: starting with your top ten protocols by revenue and one site, then expanding, because the grid modelling is where the learning is and ten protocols teach you almost everything twenty would.

Build versus buy, and when buying is the honest answer

Buy if you are a single site running under about ten concurrent protocols. RealTime-CTMS or Clinical Conductor will do more for you sooner than anything custom, and your reconciliation problem is small enough that a monthly spreadsheet is not a real risk. Buy also if your studies are overwhelmingly from one or two sponsors on standard grids, since the parsing and matching problem that justifies a build barely exists for you.

Build when two or more of these are true. You run more than roughly 25 concurrent protocols across two or more sites. Your receivables are reconciled by a person with a spreadsheet and that person is your operational single point of failure. You have discovered unbilled invoiceables more than once and cannot say with confidence that you have found them all. You take studies from many sponsors with materially different contract structures. Or you are acquiring sites and each one arrives with a different system and a different way of describing a visit. The tipping point is that at portfolio scale, the reconciliation logic between contracts, visits and payments is your business, and you cannot keep renting it from a product designed for a single site.

How to choose a developer for site network software

Ask them to whiteboard the data model before you sign. A partner who has done this draws protocol, protocol version, visit definition, procedure line, subject, actual visit, generated invoiceable and payment application, and they will immediately ask what happens when an amendment changes the grid mid-study. Anyone who draws studies, patients and invoices has built a billing app and will learn clinical research on your budget.

Ask specifically how they will handle a remittance PDF that has no visit reference on it. If the answer is that the sponsor should send better data, they have never done this work. Ask what they will do about protocol deviations and screen failures, because both are money and both are edge cases in every off-the-shelf tool.

Ask who owns the code, the repository and the cloud accounts, and get it written down before kickoff. A site network's grid library and payment history become the most valuable operational asset the business has. At Digital Heroes it is yours from the first commit, and any partner who hedges on that question is selling you a dependency rather than a system.