Why Foundations Reject Grant Proposals (and a Pre-Submission Checklist to Catch It First)

Most rejected grant proposals aren't rejected because the program is bad. According to Debbie Rey, who supervises the central proposals-processing office at the W.K. Kellogg Foundation, 80% of the applications that cross her desk are turned down immediately — and the reason, in her account, is usually that "the applicants didn't do their legwork," skimming a funder's philosophy statement without digging into the specific initiatives a given department is actually running (Chronicle of Philanthropy, "Grant Makers Reveal the Most Common Reasons Grant Proposals Get Rejected," 2003).

That piece is more than two decades old, and any individual foundation's process has surely changed since. But the patterns the program officers interviewed described — misaligned priorities, ignored guidelines, sloppy math, vague descriptions — are the same categories that show up in newer, independent lists of why proposals fail. This article pulls together what grant makers and research-proposal reviewers say actually sinks an application, attributed source by source, and ends with a checklist built specifically around those causes — not a generic "things to double-check" list, but one aimed at the mistakes described below.

What grant makers say gets proposals rejected

The Chronicle of Philanthropy interviewed program officers at several foundations about the mistakes they saw most often. Attributed to the specific people who said them:

• Skipping the funder-specific research. Beyond the "philosophy statement" problem above, Jim Durkan, president of the Community Memorial Foundation, described charities that "send out a proposal to as many grant makers as they can, on the theory that one is bound to click," instead of confirming a real match first — advice he summarized as "the time they spend researching will be returned tenfold."
• Not following stated guidelines exactly. Katherine T. Freshley, senior program officer at the Eugene and Agnes E. Meyer Foundation, said page limits are meant literally: "When we say 10 pages, we're really serious about that," and described applicants who squeeze 12 pages of content into 10 by shrinking type and margins — which, with a foundation reading hundreds of proposals, "just makes the program officers work harder."
• "Fishing expeditions." Freshley also flagged proposals that list several different programs and let the foundation pick one to fund, rather than making a specific request — a pattern she called a sign of an inexperienced writer.
• Sending duplicate copies to multiple people at the same funder. Debbie Rey advised finding the correct single contact person rather than blanketing several staff members with the same application: "it just causes confusion, and it's hard for us to keep track." She also noted proposals where several people had signed a cover letter, leaving it "unclear who to contact."
• Math errors in the budget. David Littlefield, communications officer at the California Wellness Foundation, said that of 11 grants the foundation recently awarded, three of the applications had math problems in the budget, and recommended having a treasurer or finance staff member review every budget before submission — "when program staff without a strong finance background do the work, details often get missed."
• Unrealistic budget trajectories. Andrea L. Reynolds, chief operating officer of the Community Foundation of Greater Memphis, said a multi-year budget with implausible jumps (her example: $100,000 the first year, $200,000 the second, $1 million the third) raises immediate doubts about an organization's ability to actually use that much money, not just its math.
• Geographic or programmatic mismatch. Gretchen Wolfram of the Lilly Endowment gave a simple example of a fit restriction that's easy to miss: "We do a lot of education grant making, but it's virtually all in Indiana" — a limitation stated on the funder's own site, but one an unresearched applicant outside that geography could easily overlook.

What research-proposal reviewers say gets proposals rejected

A different list, aimed at academic and scientific research proposals rather than foundation grants, comes from SUNY Geneseo's sponsored research office, adapting a set of common rejection reasons originally published in the research-methods text Proposals That Work (Locke, Spirduso, and Silverman, 1987), via the University of Montana's Office of the Vice President for Research (SUNY Geneseo, "Common Reasons Grant Proposals Are Rejected"). The framing is blunt: "the proposal review process involves individual, human readers. This fact produces an implacable rule. What is not noticed is not funded." The reasons on that list that overlap most directly with the grant-maker list above:

• The submission deadline was not met.
• The proposal's topic was not appropriate to the funding agency it was sent to.
• Guidelines for content, format, or length were not followed exactly.
• The proposal "was not absolutely clear" and "was not absolutely complete" in describing one or more elements of the study — two separate failure modes, not one.
• The budget was unrealistic for the equipment, supplies, and personnel it claimed to need.
• The literature review or background section suggested the authors "did not know the territory" — i.e., were unfamiliar with existing, relevant work in the area.
• The writing quality was poor: "sweeping and grandiose claims, convoluted reasoning, excessive repetitions, or unreasonable length."
• The proposal had "an unreasonable number of mechanical defects" — reviewers read carelessness in the document as a signal that the same carelessness might extend to how the project itself gets run.

The two sources describe different kinds of funders — private and family foundations on one side, research-funding agencies and academic review panels on the other — and neither is a substitute for the other. But laid side by side, the overlap is the useful part: both independently point to the same handful of failure categories, not a long, undifferentiated list of unrelated mistakes.

The common thread across both lists

Read together, the specific complaints above cluster into a small number of underlying problems:

• Fit, not quality. A proposal for a genuinely strong program can still be rejected because it went to the wrong funder, the wrong department within that funder, or the wrong geography — the Kellogg, Durkan, and Lilly Endowment examples are all versions of this.
• Vague or incomplete description. SUNY Geneseo's list separates "not clear" from "not complete" on purpose — a proposal can describe its plan in polished prose and still leave out something a reviewer needed to evaluate it.
• Guidelines treated as suggestions. Page limits, deadlines, formatting rules, and single-point-of-contact instructions all show up as their own rejection reasons across both sources — not because breaking them is rude, but because it forces an already-overloaded reviewer to do extra work, or simply disqualifies the submission outright.
• Budget math and budget realism are two different checks. Littlefield's complaint is about arithmetic errors; Reynolds's is about a budget that adds up correctly but describes growth no reviewer would find credible. Both need checking, separately.
• Carelessness reads as a signal. Both sources connect sloppy mechanics — typos, inconsistent formatting, unclear contacts — to a reviewer's doubts about whether the same organization would manage the grant carefully if funded.

A pre-submission fit-and-clarity checklist

This checklist is built directly around the causes described above — it's a self-diagnostic pass for the specific ways proposals get rejected, not a general "make sure everything's attached" list. (If you also want the operational side — attachments, formatting specifics, submission logistics — that's a separate checklist covered further down.)

• Re-read the funder's current guidelines and priority language directly, not from memory of a past cycle or a general sense of "what this funder likes" — confirm the specific department or program area you're applying to, not just the foundation's overall mission.
• Hand the first page to someone who has never seen the project and ask them to state, in one sentence, what will change and how you'd know it worked. If they can't, the description isn't clear or complete enough yet.
• Circle every goal or objective in the narrative. For each one, ask "what evidence would prove this happened?" If there's no answer, it's the kind of vague objective reviewers flag.
• Check whether the proposal requests one specific project, or reads like a menu of programs the funder could choose from — the "fishing expedition" pattern Freshley described.
• Have someone with a finance background — not just whoever drafted the narrative — check every budget calculation, and separately ask whether the multi-year growth trajectory (if there is one) is realistic on its own terms, independent of whether the arithmetic is correct.
• Confirm there is exactly one named contact person and one clear way to reach them, and that the proposal isn't being sent as duplicate copies to multiple staff at the same funder.
• Check the actual page or word count against the funder's stated limit, using their stated font size and margins — not margins narrowed to fit more text into the same page count.
• Read the needs statement or background section and ask honestly whether it reflects real, current knowledge of the field, or reads like research that was skipped.
• Do one full read-through as a stranger unfamiliar with the organization, looking only for typos, inconsistent names or numbers, and formatting slips — not content.

What this checklist doesn't cover

Deliberately left out here: attachment lists (990s, board rosters, letters of support), exact formatting specs, submission-portal logistics, and cross-document consistency checks across an LOI, narrative, budget, and executive summary. Those are real, separate failure points — they're just a different kind of check than the fit-and-clarity issues above, and they're the focus of the toolkit's compliance module described below.