Clinical Trial Budget Template: A Per-Patient Cost Model

At a glance

• A defensible trial budget is built from a per-patient cost model, the schedule of assessments costed per visit and multiplied by enrollment, not a generic Excel grid filled with guesses.
• Costs sort into three buckets: per-patient costs (driven by the protocol’s procedures), site costs (fixed and pass-through), and overhead.
• The schedule of assessments is the backbone: price each procedure at each visit, sum per visit, sum across visits for a per-patient cost, then multiply by participants.
• Every line item should be benchmarked against a real reference, so your numbers are pressure-tested rather than invented.
• The template described here is a sheet-by-sheet Excel scaffold you can build today; the value is the model, not the grid.

Most “clinical trial budget template” results hand you a blank spreadsheet grid and leave you to fill it with numbers you are guessing at. That is how budgets end up indefensible: a flat total with no model behind it, impossible to justify to a board or pressure-test against reality. A good budget is built bottom-up from the protocol, with each number traceable to a cost driver and a benchmark.

This guide builds that model. It lays out the three cost buckets, walks the schedule-of-assessments to per-patient-cost method, describes the Excel scaffold sheet by sheet, and shows how to benchmark each line. It is a costing how-to, not a payments system or a pricing guide for software.

The three-bucket cost taxonomy

Sort every cost into one of three buckets. This is what turns a flat grid into a model:

• Per-patient costs. Costs driven by the protocol’s procedures, incurred for each participant: clinic visits, procedures, labs, imaging, assessments, and participant stipends. These scale directly with enrollment and are the heart of the model.
• Site costs. Costs at the site level rather than per participant: site activation fees, IRB/EC fees, archiving, and pass-through costs. Some are fixed, some are per-site.
• Overhead and study-level costs. Costs that sit above sites and participants: project management, monitoring, data management, vendors, and the institutional overhead applied on top.

Keeping these separate is what lets you flex the model: change enrollment and the per-patient bucket scales; add a site and the site bucket grows; the overhead bucket moves more slowly.

From schedule of assessments to per-patient cost

The schedule of assessments (SoA), the protocol’s grid of which procedures happen at which visits, is the backbone of the per-patient cost. The method:

1. List the visits down one axis (screening, baseline, each treatment visit, follow-up).
2. List the procedures down the other (physical exam, ECG, labs, imaging, drug administration, questionnaires).
3. Mark which procedure happens at which visit (this is the SoA itself).
4. Assign a cost to each procedure.
5. Sum per visit to get a cost per visit.
6. Sum across visits to get the cost per participant.
7. Multiply by planned enrollment (and adjust for screen failures, which incur screening costs without enrolling) to get the per-patient bucket total.

This bottom-up build is what makes the budget defensible: every dollar traces to a specific procedure at a specific visit, straight from the protocol.

The Excel scaffold, sheet by sheet

Build the template as a small workbook:

Sheet	Contents
Assumptions	Enrollment, number of sites, screen-failure rate, overhead rate
Schedule of assessments	Visits x procedures grid, with cost per procedure
Per-patient cost	Cost per visit and total per participant (from the SoA)
Site costs	Per-site and fixed site-level costs
Overhead / study-level	PM, monitoring, data management, vendors, institutional overhead
Summary	The three buckets rolled up to a total, with per-patient and per-site views

Drive everything from the Assumptions sheet so you can run scenarios: change enrollment or site count and the whole budget updates. Lead with this scaffold; keep the prose around it tight.

Benchmarking: pressure-testing your numbers

A model is only as good as its inputs, so benchmark each line rather than trusting a single quote. Practical methods:

• Procedure costs: check per-procedure costs against published fee schedules and standard-of-care cost references for your region, so a lab or imaging cost is grounded in a real range.
• Per-patient totals: compare your computed per-patient cost against published per-patient cost ranges for similar trial phases and therapeutic areas. A number far outside the range is a flag to investigate, not necessarily wrong, but worth explaining.
• Site and overhead: benchmark activation fees and overhead rates against your own prior trials and published industry figures.

When you name a real source for each benchmark (a fee schedule, a published cost study, your historical actuals), the budget stops being a guess and becomes a defensible estimate. Always cite the source you used for a given range rather than asserting a number.

Red flags that your estimate is off

Benchmarking is most useful when it surprises you. A few signals that a number needs a second look:

• A per-patient cost far outside the published range for the phase and therapeutic area, in either direction. Too high suggests double-counting or a procedure priced at list rather than negotiated rate; too low usually means a procedure or visit was dropped from the schedule of assessments.
• A round-number total with no model behind it. If the budget is a single figure rather than a roll-up of the three buckets, it has not been built bottom-up and cannot be defended line by line.
• No screen-failure adjustment. A budget that costs only enrolled participants understates screening costs, because every screen failure still incurs the screening visit and its procedures.
• Overhead applied inconsistently, or pass-through costs buried inside per-patient lines so the same dollar is counted twice. Keep pass-throughs visible and overhead applied once, on a defined base.

Adapting the model

• Small single-site study: collapse the site bucket to one site, keep the per-patient model, and lean on your own prior actuals for benchmarks.
• Multi-site study: parameterize site count, and account for site-to-site cost variation (different regions, different fee schedules).
• Scenario planning: because the model is driven by the Assumptions sheet, you can run best/expected/worst enrollment cases and see the budget range, which is far more useful to a board than a single number.

A note on what this budget is and isn’t

This is a planning and estimating model, not a payments system. It tells you what the trial should cost; it does not execute site payments, track invoices, or manage milestone-based disbursements (those are operational finance functions, often in a CTMS’s budgeting module, which a lean team may not need). Keep the estimating model and the payments machinery separate; conflating them is how a clean budget turns into an unmanageable spreadsheet.

A coordination note for lean teams: a clinical project management tool can help track the trial’s operational progress against the plan, though budget execution and payments are a distinct function. TrialTrack, for instance, is a coordination tool that deliberately leaves out budgeting and payments modules, so the cost model above lives in your spreadsheet, not in it. Match the tool to the job.

Common budgeting mistakes for small and lean teams

A few errors recur often enough at small sponsors, biotechs, and academic sites to be worth naming directly, because each one quietly makes the budget indefensible:

• Budgeting top-down from a target. Starting with “we have a grant of X, make it fit” inverts the model: the budget should fall out of the protocol’s costs, and if that exceeds the grant the answer is to change the protocol or the enrollment, not to shave numbers until they fit.
• Forgetting pass-through and site-startup costs. Per-patient costs are visible and easy to model, so the per-patient bucket gets all the attention while site activation fees, IRB/EC fees, archiving, and shipping quietly go missing. They are real money and belong in the site bucket.
• Ignoring screen failures and dropouts. Both cost money without contributing a completing participant, and a budget that assumes everyone enrolled completes will run short.
• No contingency. Trials slip and scopes change. A budget with no contingency line is a budget that will be wrong the first time a protocol amendment adds a visit.
• Treating the budget as a one-time artifact. The defensible budget is a living model driven by the Assumptions sheet, re-run as enrollment, site count, and actuals come in, not a number frozen at kickoff.

Avoiding these is less about sophistication than discipline: build from the protocol, keep the buckets separate, account for the participants you pay for but do not enroll, and leave room for the surprises every trial delivers.

Frequently asked questions

How do you build a clinical trial budget? Bottom-up from a per-patient cost model: cost the schedule of assessments per visit, sum to a per-patient cost, multiply by enrollment, then add site and overhead costs. Benchmark every line.

What are the main cost buckets? Per-patient costs (driven by the protocol’s procedures), site costs (activation, IRB/EC, pass-through), and overhead/study-level costs (PM, monitoring, data management, vendors, institutional overhead).

Why build around the schedule of assessments? Because it ties every per-patient cost to a specific procedure at a specific visit, making the budget traceable and defensible rather than a flat guess.

How do you pressure-test the numbers? Benchmark each line against a real source: published fee schedules for procedures, published per-patient cost ranges for the phase and therapeutic area, and your own prior actuals. Cite the source you used.

Is this the same as a payments system? No. This is a planning and estimating model. Executing site payments and tracking invoices is a separate operational finance function.

The bottom line

A defensible clinical trial budget is a per-patient cost model, not a generic grid: cost the schedule of assessments per visit, roll it up per participant, multiply by enrollment, add site and overhead buckets, and benchmark every line against a real source. Build it as a scenario-driven Excel scaffold, keep estimating separate from payments, and you will have a budget you can actually defend, line by line.