NIH Grant Pre-Submission Checklist: What to Review in Your Final Week

Why the Final Week Is When Applications Break

The science in most NIH applications is strong by the time the final week arrives. The aims are written, the research strategy is drafted, the biosketches are in shape. What falls apart in the final days is almost always procedural: a required section left blank, a font that slipped past twelve-point after pasting from a different document, a human subjects exemption that doesn't match what the approach section describes, a PDF that fails to render in grants.gov.

These are not mistakes smart people should make. They're mistakes tired people make when they're working against a submission clock and assume someone else has checked something that nobody actually checked. The way to avoid them is to separate the content pass from the compliance pass. Once you believe the science is as good as you can make it, switch modes. Stop writing and start auditing.

The structure below works best when you run it starting seven days before the deadline. If you're coming in with four days left, it still works — just compress the timeline and don't skip the system checks, which take longer than most people expect the first time.

Formatting and Page Limits: The Instant Disqualifiers

NIH enforces formatting requirements through automated checks at submission, and some violations trigger an immediate administrative withdrawal. Others get flagged after review assignment, which means you may not find out until your application is already under review — and by then, the only fix is a resubmission cycle. Start here.

One pass through the NIH application guide's format requirements list, cross-checked against your actual PDFs, takes about 90 minutes. That 90 minutes has saved more than a few applications from administrative withdrawal. Do it while you're still fresh enough to notice what you're looking at.

Required Sections: What Reviewers Flag When It's Missing

Every NIH application has a set of required attachments that reviewers are explicitly instructed to flag if absent or inadequate. Some of these — like the Authentication of Key Biological and/or Chemical Resources — are still routinely missing because they were added to the requirements after most investigators wrote their first grant and never quite made it into the standard template.

Human Subjects and Vertebrate Animals: The Compliance Check

Mismatches between the Human Subjects section and the approach are a reliable source of reviewer critique. The most common version: the approach section describes recruiting a patient cohort, but the Human Subjects section is coded "No Human Subjects Research Involved." This can happen when a previous template is reused without updating the compliance forms, or when the scope of the project changes after the initial setup.

Run through this list explicitly, for both human subjects and vertebrate animals:

• Does the Human Subjects designation (Exempt, Non-Exempt, or No Human Subjects) match what the approach actually describes?
• If exempt, is the correct exemption category cited, and does your project actually qualify for that category?
• Is the inclusion of women, minorities, and children addressed? Does the enrollment table match the approach section?
• If vertebrate animals are used, is the Vertebrate Animals section present and complete — covering species, approximate number of animals, rationale, minimization of pain, and method of euthanasia?
• Does the Vertebrate Animals section match the aims? If Aim 2 adds a new animal model that wasn't in the original outline, it needs to be in the section.

These checks feel bureaucratic. They are. But review panels have standing criteria for both, and a gap creates an official weakness in your score, not just a comment.

System Checks: Grants.gov, ASSIST, and eRA Commons

The NIH submission pipeline involves at least three systems: grants.gov (receipt), ASSIST or your institutional system-to-system (S2S) connection (assembly), and eRA Commons (tracking after receipt). Each one can fail independently, and each failure looks different.

The Day-Before Read-Through Protocol

On the day before submission, after all the checklists are complete, do one final read-through of the assembled application as a PDF — not the source documents, but the actual submission package. This sounds redundant. It is not. Assembly errors — pages from a previous version, figures that shifted during PDF conversion, a section that was accidentally deleted in the final merge — only show up when you look at the combined package. I've seen biosketches from a collaborator's previous grant appear in someone else's final submission because of a file-naming collision.

The day-before read-through has a specific goal: not to improve the science (that window is closed), but to confirm that what you wrote is actually in the document. Work through it in this order — Specific Aims, Research Strategy (Significance, Innovation, Approach), each attachment (Human Subjects, Vertebrate Animals, Authentication, Data Management, etc.), Budget and Justification, Biosketches for each senior/key person. Give each section about 30 to 60 seconds. You're not proofreading. You're confirming the document matches your intent.

If you find something wrong at this stage, the correction window on the submission is your buffer. That's why you submitted 48 hours early. Fix it, resubmit the corrected package, and confirm that the corrected version shows as the active submission in eRA Commons. Then stop. Making additional changes to submitted applications after this point is something reviewers can notice and flag.

Frequently Asked Questions