Avoid NSF SBIR Rejection: Phase I Compliance Guide

Administrative rejection is the most preventable — and most frustrating — outcome in the NSF SBIR process. When a proposal is administratively rejected, it never even reaches peer reviewers. Instead, it’s flagged and returned by NSF staff for noncompliance with formatting, structural, or portal requirements. This outcome is final: NSF does not allow resubmissions within the same solicitation cycle, which can delay a project’s progress by a full year.

Unlike technical or commercial merit issues, administrative rejections often stem from avoidable errors. These include submitting a Project Summary as a PDF instead of entering it directly into Research.gov’s text fields, leaving required sections blank, or attaching documents to the wrong module. Even exceeding a section’s page limit by one line can trigger rejection — Research.gov automatically truncates files that exceed the limits, and reviewers won’t see anything beyond the cap.

NSF’s process is strict by design. The agency publicly states that its merit review system depends on standardized formats so that reviewers can fairly assess diverse proposals. Because of this, NSF SBIR staff are instructed to enforce formatting and structural rules without exceptions.

For applicants, this means understanding the difference between scientific merit and administrative compliance — and knowing that a strong proposal can still be disqualified before it’s ever read if basic submission rules are not followed.

Submit only when every field is compliant
NSF doesn’t allow resubmissions in the same cycle. Administrative rejection = missed year.

Critical Format & Submission Rules You Must Follow

NSF has zero tolerance for deviations from its format rules — and Research.gov is programmed to enforce them strictly. Every applicant must comply with detailed standards for font, spacing, file structure, and system-specific instructions. Even minor oversights, like including a hyperlink or using an unapproved font, can trigger administrative rejection.

Start with formatting. All uploaded PDFs must follow NSF’s guidelines: use only approved fonts (Arial, Courier New, or Palatino Linotype at ≥10pt; Times New Roman or Computer Modern at ≥11pt). Margins must be at least 1 inch on all sides, and no more than six lines of text per vertical inch are allowed. Project Descriptions are capped at 15 pages — and Research.gov enforces this by automatically truncating any over-length PDF. Anything beyond page 15 will not be visible to reviewers.

Spacing is equally important. Single-spacing is permitted, but if you compress text to squeeze in more content (e.g., by shrinking line height), that violates the six-lines-per-inch rule. Remember, NSF reviewers are reading dozens of proposals — clarity and readability matter.

Some formatting rules are portal-specific. The Project Summary must be entered directly into three separate text boxes in Research.gov: “Overview,” “Intellectual Merit,” and “Broader Impacts.” If you upload a PDF or fail to populate all three fields, your proposal will be returned without review.

You also cannot embed live URLs or hyperlinks in your Project Description. NSF explicitly forbids this, stating that all essential information must be included directly in the document. Don’t rely on external sources — even if you’re pointing to your own company’s website or a public dataset. Instead, include summaries or screenshots, as long as they fit within the page limit.

Finally, never attempt to bypass formatting rules by embedding text in images or tables. The system may reject these files outright, and even if accepted, reviewers may question their integrity.

Stay within system constraints
Do not exceed the 15-page limit. The upload system truncates longer PDFs automatically.

Components That Must Be Present (No Exceptions)

A compliant NSF SBIR Phase I proposal requires a precise set of documents — and each one must be formatted, labeled, and submitted exactly as NSF dictates. Missing even a single required document will lead to administrative rejection. This section provides a structured guide to what must be submitted, where to submit it, and in what format.

Mandatory Components Overview:

• Project Summary: Entered directly into three fields in Research.gov. PDF uploads not accepted.
• Project Description: PDF upload, 10–15 pages. Must include required headings such as Intellectual Merit, Broader Impacts, and Technical Approach.
• Budget: Completed using Research.gov’s budget module. Must include PI effort (≥1 month per 6 months).
• Budget Justification: Up to 5 pages. Must explain each line item (A–G), with calculations and justification.
• Biographical Sketch(es): Must be generated in SciENcv and uploaded as NSF-compliant PDFs (2 pages each).
• Current & Pending Support: SciENcv-generated document listing all active/pending funding sources.
• Collaborators and Other Affiliations (COA): Excel spreadsheet using NSF template. Upload as a “Single Copy Document.”
• Synergistic Activities: Separate 1-page PDF per senior person. Up to 5 activities, each distinct.
• Data Management Plan: ≤2 pages. Required even if no data will be produced; must say so explicitly.
• Facilities/Equipment/Other Resources: Descriptive narrative (no cost figures). Required even if response is “None.”

Conditional Components:

• Letters of Commitment: Required if using subawardees or consultants. Each must state their role and confirm participation and budget. Upload as a supplementary PDF.
• Human Subjects/Vertebrate Animals Docs: Required if applicable.

Easily Avoidable Red Flags That Trigger Rejection

Many administrative rejections are caused not by complex missteps, but by small, well-intentioned errors that violate NSF’s Phase I rules. These rejections are entirely avoidable — and understanding what not to include is just as important as knowing what is required.

The most common trigger? Submitting letters of support in a Phase I proposal. While other agencies allow or even encourage customer letters early in the process, NSF explicitly prohibits them at this stage. Including a letter of support — even one that seems valuable — will result in your proposal being returned without review.

Another frequent mistake is submitting biographical sketches that are not generated through SciENcv. NSF mandates the use of SciENcv’s template, and deviations — such as resumes or modified bios — are not accepted. If you don’t use SciENcv, your application will be rejected outright.

Proposal formatting violations also remain a top cause of administrative rejections. Embedding hyperlinks in the Project Description, exceeding page limits, or submitting figures that contain unreadable text all risk triggering the system’s automated or manual rejection flags.

Applicants also sometimes fail to respect budget constraints for consultants and subawards. NSF caps consultant rates at the equivalent of $2,000 per day (or ~$250/hour). Exceeding this rate or misclassifying subaward roles can disqualify your budget — and by extension, your full proposal.

Finally, if you include proprietary data without following NSF’s specific instructions for marking such content (which must follow the solicitation guidelines precisely), your proposal may be deemed noncompliant and removed from consideration.

Do not include support letters in Phase I
Including letters of support in a Phase I NSF SBIR proposal will cause immediate rejection.

Action Checklist to Pass Administrative Review

By the time you’re ready to hit “Submit” on Research.gov, your technical and commercialization arguments are likely polished. But unless every administrative detail is locked down, even the strongest proposal risks rejection. Use this final checklist to ensure your submission is fully compliant — and Review-ready.

1. Check all mandatory sections are uploaded. Cross-reference against NSF’s solicitation and confirm no required component is missing — including the less obvious ones, like the Data Management Plan or Synergistic Activities PDFs.
2. Use the correct formats. Are your biosketches and current/pending support documents generated from SciENcv? Is your COA uploaded as a .xlsx file, not PDF? Have you removed any hyperlinks from the Project Description?
3. Validate budget integrity. Ensure your budget aligns with NSF’s caps, and your justification clearly explains each line item. Confirm that the PI has ≥1 month of effort per 6 months of project duration.
4. Run a full preview in Research.gov. Use the “View” function before submission to ensure every section uploaded properly and appears as intended. Errors caught here are still fixable.
5. Assign a compliance reviewer. Have one person — not the proposal’s primary author — perform a final audit of the entire application package.
6. Leave time for technical issues. NSF strongly recommends submitting at least 48 hours before the deadline. Research.gov occasionally experiences upload delays, PDF corruption, or validation errors — especially close to the cutoff.
7. Know when to ask for help. If the portal flags unexpected issues, contact the NSF helpdesk or your cognizant Program Director well before the deadline. They can’t fix errors after the submission window closes.