Conflicts of Interest in Grant Review

In short. A conflict of interest in grant review is any relationship or interest that could reasonably make a reviewer's judgement of an application look partial, whether or not it is. Handling it takes four parts: a written definition, a declaration from every reviewer, an assignment process that keeps conflicted pairs apart before scoring starts, and a recorded route for reassignment and for conflicts discovered late. Keep a log of all four, because the audit trail is what lets you defend a decision afterwards.

Conflicts rarely come from bad faith. They come from small fields, shared institutions and long memories. The reviewer who co-authored a paper with an applicant eight years ago, the one whose spouse sits on the applicant's board, the one who once rejected the same team at another fund: each can be handled well or badly, and the difference lies almost entirely in process. This article sets out a process that works for grants, fellowships, seed funds and prizes.

Define a Conflict Before You Ask About It

If you ask reviewers "do you have any conflicts?" you will get different answers from people with the same facts. Define the term in the reviewer guidance, with examples, and keep the list short enough to remember.

Typical categories in funder practice:

State the look-back period, commonly three to five years for professional ties, and say that a perceived conflict counts. "Could a reasonable applicant think this reviewer might favour or disfavour them?" is a better test than "do I think I am biased?", because people are poor judges of their own bias.

Collect Declarations at Two Moments

Declare once, up front, and again when the assignments are known.

1. At onboarding. Each reviewer declares standing conflicts: their institution, organisations they advise or hold stakes in, and people they cannot review. This is a general statement made before any application is seen.
2. At assignment. Each reviewer sees their allocated applications and confirms or declares a conflict against each. Reviewers often recognise a conflict only on seeing the idea or the team.

Make declaring easy and unembarrassing. A reviewer should be able to say "conflict" in one action with a one-line reason, without a conversation. If declaring is awkward, reviewers will quietly score and move on. Also make "none" an explicit answer, not silence, so that a blank can be told apart from a declaration of no conflicts.

Assign Around Conflicts, Not After Them

The cleanest conflict is one that never reaches the reviewer. Rather than handing out batches and waiting for objections, use what you already know:

• Match standing declarations to applicants. Compare each reviewer's declared institutions and listed relationships with applicant institutions, team members and referees, and exclude those pairs automatically.
• Respect load. Excluding conflicts can leave some applications with too few eligible reviewers. Check coverage before you start: every application needs its required number of reviews from non-conflicted people, and no reviewer should carry a quarter of the pile.
• Balance expertise against load. Assign by subject expertise first, then spread the remainder to the lightest-loaded eligible reviewers.
• Preview before you apply. Look at the proposed plan, who scores what, which pairs were kept apart and why, and fix anomalies before reviewers are notified.

For a call of 130 applications with three reviews each, that is 390 review slots. Spread over 14 reviewers it is about 28 each. Even a handful of exclusions makes it worth checking the arithmetic rather than assuming it will work out.

Reassign Quickly When a Conflict Appears

Conflicts surface late: a reviewer opens a file on day four and recognises a friend. Have a defined path.

1. The reviewer declares the conflict with a short reason. They stop reading and do not discuss the application.
2. Any score or comment they have already entered is withdrawn from the calculation, not merely hidden.
3. The programme office picks a replacement who is not conflicted and has capacity, ideally with similar expertise.
4. The replacement scores independently, without seeing the withdrawn reviewer's notes.
5. The change is logged: who declared, when, why, and who replaced them.

The same path applies when the programme office discovers a conflict the reviewer did not declare, for example a shared co-investment found while checking references. Treat that as a process failure to fix, not as an accusation, unless the facts suggest otherwise.

What About Committee Members?

Reviewers who score are not the only people with influence. Chairs and committee members who discuss and decide also need to declare, and the rule at the decision stage should be firmer than at scoring: a member with a conflict leaves the room, or the shared screen, for that application and does not vote. Record the recusal in the minutes with the time. A committee that publishes who recused on what is in a stronger position than one that does not.

Keep an Audit Trail

An audit trail is a time-ordered record of who did what to which record. For conflicts, the minimum useful entries are:

• Standing declarations, with date and version of the form.
• The assignment plan as applied, including the pairs excluded and the reason.
• Each conflict declared, with timestamp, reviewer, application and stated reason.
• Each reassignment, with the replacement and the date.
• Each recusal at committee, with the meeting reference.
• Who changed any of the above, and when.

Two properties matter more than detail. The log must be append-only in practice, so that entries cannot be quietly edited, and it must be readable by someone outside the programme team, such as an internal auditor or a funder. A spreadsheet with a change history can do this if it is locked down and someone owns it. A system that records the events automatically does it with less effort and fewer gaps.

Tell Applicants How You Manage Conflicts

Applicants cannot see inside your process, so describe it. Two or three sentences in the call document are enough: reviewers declare conflicts before they see an application, conflicted reviewers do not score it, and committee members step out of decisions on applications they are connected to. Many applicants will never read it, but the ones who lose a close decision will, and a published rule is far easier to point to than an assurance given after the fact. It also tells your own reviewers that the rule is taken seriously, which changes how readily they declare.

How IdeaScore Handles It

In IdeaScore, conflict-aware assignment draws its plan as soon as the page opens: evaluators on one side, applications on the other, lines showing who would score what and why, and a lock on each pair kept apart because of a conflict. The plan shows how many assignments are by expertise and how many by lightest load, lists open declarations below, and you apply it when you are satisfied. Evaluators declare conflicts themselves, and Suggest evaluators will propose people for a whole round.

That removes most of the manual cross-checking described above. It does not remove the need for a clear definition or for committee recusal, which are decisions for your programme.

A Checklist for Programme Offices

• A written definition with categories, examples and a look-back period.
• Standing declarations collected at onboarding, with "none" as an explicit answer.
• A second declaration at assignment, against specific applications.
• Automatic exclusion of declared pairs, and a coverage check before applying.
• A reassignment path that withdraws prior scores and logs the change.
• Committee recusal rules, recorded in minutes.
• An audit log that is append-only in practice and readable by an outsider.
• A short note to applicants saying how conflicts are managed, which costs nothing and builds trust.

Conflicts will not disappear in a small field. What a programme can control is whether they are caught early, handled the same way each time and recorded in a form that someone else can read. That is what makes a decision defensible.