Why does the assembly and naming of a grant package matter so much?

Because funders process volume under deadline, and a package that is hard to handle — attachments out of order, files named ambiguously, a missing required document — creates friction exactly when a reviewer is least patient, and some portals reject non-conforming submissions automatically before a human ever reads your case. The content wins the grant, but sloppy assembly can get you screened out first. Treating the package as a deliverable with its own rules — correct order, spec-compliant names, complete attachments, within size limits — is the cheapest insurance you can buy on work you have already done.

In what order should the application documents go?

Follow the funder’s stated order exactly — the RFP, NOFO, or application guidelines almost always specify the required sequence and the exact attachments, and that specification overrides any general convention. A common pattern is: cover letter or application form, narrative/proposal, budget and budget justification, then supporting documents (board list, 501(c)(3) determination letter, financial statements, letters of support). But the funder’s list is authoritative; if they number their required attachments, match that numbering. When in doubt, mirror the order in which the guidelines list the requirements, and never add unrequested documents that bury the ones they asked for.

How should I name grant application files?

Use the funder’s naming convention if they give one — many RFPs specify exact filenames or prefixes, and matching them is part of compliance. If they do not, use a clear, consistent scheme like Organization_Program_DocumentType_Date (GreenValley_YouthFund_Narrative_2026.pdf) so every file is self-identifying and sorts sensibly. Avoid spaces and special characters that some portals reject, keep names reasonably short, and be consistent across the whole package. Good naming helps the reviewer and helps you find the exact file a year later when reporting on the grant.

The portal has a size limit and my package is too big — what do I do?

Compress the images, which are usually the bulk — scanned letters of support, the determination letter, financial statement scans. Re-compress those scans to a readable resolution (around 150–200 DPI is fine for text documents) rather than flattening the whole package, so the narrative and budget stay crisp. Where the funder allows separate attachments, keep large supporting documents as their own files instead of one giant merge. Always re-check the total against the stated cap after compressing, and confirm the compressed scans are still legible before submitting.

Should I submit one merged PDF or separate attachments?

Do whatever the funder’s portal requires — this is not your choice to optimise. Some systems want a single merged package; others provide labelled upload slots for each required attachment and expect separate files named to spec. Read the submission instructions carefully: uploading one merged file where they wanted separate labelled attachments (or vice versa) is a common, avoidable rejection. When the format is genuinely up to you, a single bookmarked, page-numbered package is easiest for a reviewer to navigate, but the funder’s instruction always wins.

Is it safe to assemble grant documents with an online tool?

Grant packages can contain financial statements, personnel information, and other non-public organisational data, so prefer client-side tools. Server-side tools upload your files to a third party where they may be cached; client-side (in-browser) tools merge, compress, and bookmark locally so files never leave your computer — ScoutMyTool’s PDF tools work this way. Confirm a tool processes client-side before uploading sensitive organisational documents, or use offline software.

6 min read

PDF for non-profit grant applications (assembly + naming)

By ScoutMyTool Editorial Team · Last updated: 2026-05-21

I once watched a strong grant application nearly get screened out for the dumbest reason: the attachments were out of the funder’s required order, two files had cryptic names, and the merged package was just over the portal’s size limit. The program was fundable; the package was a mess. A grant proposal is judged on its substance, but it has to clear the assembly and submission rules first, and those rules are unforgiving under deadline. This guide covers putting a non-profit application package together the way funders expect — required order, spec-compliant naming, size limits, and a final checklist so nothing is missing when you hit submit. (Always defer to the specific funder’s instructions.)

The application-package toolkit

Item	Tool	Note
Order the attachments	Merge order	Follow the funder’s required sequence exactly
Combine to one package	Merge-PDF	When the portal wants a single file
Name to spec	Consistent naming	Org_Program_Document_Date — match RFP rules
Number the package	Add page numbers	So reviewers can reference pages
Hit the size cap	Compress-PDF	Most portals reject oversized uploads
Navigate long packages	PDF bookmarks	Bookmark each required section for reviewers

Step by step — assemble a compliant package

Read the submission rules first. Pull the required attachment list, order, naming convention, size limit, and whether the portal wants one merged file or separate labelled uploads. These rules override every general convention.
Gather and order the attachments. Collect each required document as a clean PDF and arrange them in the funder’s stated sequence — typically form, narrative, budget, then supporting documents.
Name every file to spec. Use the funder’s naming rules, or a clear Organization_Program_Document_Date scheme with no spaces or special characters that a portal might reject.
Merge or keep separate, as required. If a single file is wanted, merge in order, add page numbers, and bookmark each required section for reviewers. If labelled uploads are wanted, keep the named files separate.
Compress to the size cap. If over the limit, compress scanned supporting documents to a readable resolution while keeping the narrative and budget crisp; re-check the total against the cap.
Run a final completeness check. Tick every required attachment off the funder’s list, confirm order and names, verify the size, and open the package once end to end before submitting.

The funder’s instructions are the spec

The recurring theme — and the thing that prevents the avoidable rejections — is that the funder’s submission instructions are the authoritative specification, not a suggestion. Required order, exact filenames, page limits, size caps, and merged-versus-separate format are compliance items, and some portals enforce them automatically. So build your assembly checklist directly from the RFP or application guidelines rather than from habit or a previous funder’s rules, because conventions vary and last year’s pattern may not match this year’s funder. The work of writing a compelling proposal deserves to be judged on its merits; following the assembly spec to the letter is what ensures it gets the chance. Make the funder’s checklist your final gate, and submit only when every box is ticked.

FAQ

Why does the assembly and naming of a grant package matter so much?: Because funders process volume under deadline, and a package that is hard to handle — attachments out of order, files named ambiguously, a missing required document — creates friction exactly when a reviewer is least patient, and some portals reject non-conforming submissions automatically before a human ever reads your case. The content wins the grant, but sloppy assembly can get you screened out first. Treating the package as a deliverable with its own rules — correct order, spec-compliant names, complete attachments, within size limits — is the cheapest insurance you can buy on work you have already done.
In what order should the application documents go?: Follow the funder’s stated order exactly — the RFP, NOFO, or application guidelines almost always specify the required sequence and the exact attachments, and that specification overrides any general convention. A common pattern is: cover letter or application form, narrative/proposal, budget and budget justification, then supporting documents (board list, 501(c)(3) determination letter, financial statements, letters of support). But the funder’s list is authoritative; if they number their required attachments, match that numbering. When in doubt, mirror the order in which the guidelines list the requirements, and never add unrequested documents that bury the ones they asked for.
How should I name grant application files?: Use the funder’s naming convention if they give one — many RFPs specify exact filenames or prefixes, and matching them is part of compliance. If they do not, use a clear, consistent scheme like Organization_Program_DocumentType_Date (GreenValley_YouthFund_Narrative_2026.pdf) so every file is self-identifying and sorts sensibly. Avoid spaces and special characters that some portals reject, keep names reasonably short, and be consistent across the whole package. Good naming helps the reviewer and helps you find the exact file a year later when reporting on the grant.
The portal has a size limit and my package is too big — what do I do?: Compress the images, which are usually the bulk — scanned letters of support, the determination letter, financial statement scans. Re-compress those scans to a readable resolution (around 150–200 DPI is fine for text documents) rather than flattening the whole package, so the narrative and budget stay crisp. Where the funder allows separate attachments, keep large supporting documents as their own files instead of one giant merge. Always re-check the total against the stated cap after compressing, and confirm the compressed scans are still legible before submitting.
Should I submit one merged PDF or separate attachments?: Do whatever the funder’s portal requires — this is not your choice to optimise. Some systems want a single merged package; others provide labelled upload slots for each required attachment and expect separate files named to spec. Read the submission instructions carefully: uploading one merged file where they wanted separate labelled attachments (or vice versa) is a common, avoidable rejection. When the format is genuinely up to you, a single bookmarked, page-numbered package is easiest for a reviewer to navigate, but the funder’s instruction always wins.
Is it safe to assemble grant documents with an online tool?: Grant packages can contain financial statements, personnel information, and other non-public organisational data, so prefer client-side tools. Server-side tools upload your files to a third party where they may be cached; client-side (in-browser) tools merge, compress, and bookmark locally so files never leave your computer — ScoutMyTool’s PDF tools work this way. Confirm a tool processes client-side before uploading sensitive organisational documents, or use offline software.

Citations

Assemble your grant package privately

ScoutMyTool Merge PDF combines your attachments into one ordered package — entirely in your browser, so organisational documents never leave your computer. Then number, bookmark, and compress to the funder’s limit.

Open Merge-PDF tool →