Grant-Restricted Technology Budgets and Allowable Expenses

Is the technology an administrative expense, or part of delivering the funded work? The answer determines what a nonprofit can recover, but a persuasive description alone is not enough. More of an organization’s real technology needs can be funded when the program connection, cost allocation, and supporting records all tell the same story.

Why technology costs keep landing in the wrong budget line

Funders often treat technology as an overhead expense, while nonprofits spend money and staff time to keep systems running that help them deliver services. That mismatch begins before anyone reviews a software invoice. If the budget places all technology under administration, a program’s essential tools compete with general operating costs and lose their place among the costs of the work itself. Classification contributes to the funding difficulty alongside a shortage of money.

The distinction has a real budget consequence. Technology spending can be squeezed against an indirect-cost cap or rejected even when the system does direct program work. Meanwhile, staff hours spent working around inadequate tools rarely appear as a separate expense. A software line gets annual scrutiny, but the time lost to workarounds does not receive the same challenge. This makes the visible purchase easier to question than the hidden cost of going without it.

Changing that outcome requires more than a better label. The same organization, using the same tools, may fund more of its needs by describing and documenting what those tools actually do. But which costs genuinely belong to a program? That question has to be settled before the application language can improve.

How funders actually distinguish allowable from overhead technology costs

2 CFR Part 200 sets the federal framework for costs that are necessary, reasonable, allocable to the program, and consistently treated. It does not require all IT spending to be indirect. Allocable” asks whether the expense can be traced to the funded work. A program connection establishes the basis for direct treatment, while the other allowability conditions still apply.

Dedicated cloud hosting for a single program’s data platform is a direct cost. So is a software license used exclusively for case management in that program. By contrast, a general IT help desk and organization-wide productivity software default to indirect costs because they support the organization as a whole. The product category does not decide the treatment. Its use does.

That distinction determines how the expense is recovered. Direct costs are reimbursed line by line, while indirect costs are recovered through a negotiated rate or the 15% de minimis rate. Many funders cap or exclude indirect recovery. Private foundations use the same conceptual split but set their own rules, which may be stricter or more flexible than federal guidance. The Notice of Award or grant agreement controls in each case.

OMB proposed revisions in May 2026 that would tighten allowability and increase certain documentation and prior-approval requirements. The proposal is not a final rule. H.R. 6500 paused it as of September 2, 2026, and no final rule has been issued. Even so, the proposal suggests that cost descriptions will face closer review and that vague ones will be less welcome.

What documentation actually makes a technology expense defensible

A budget line that says “software” identifies a purchase but leaves its relationship to the grant unexplained. A documented line identifies the case management software used for the funded program and connects the charge to a project-tagged invoice. Usage logs or access records then support exclusive use, or the proportion charged to that program.

Shared technology needs a further step. A cost allocation plan explains how the organization splits the expense across programs, rather than assigning the whole bill to whichever grant can pay it. Treating a shared platform as a direct cost without that plan is a common route to disallowance. When the organization claims indirect recovery through a negotiated rate, its records include its Negotiated Indirect Cost Rate Agreement, or NICRA, letter.

These records serve both the application and the audit. A reviewer looking at a planned expense needs to see the same link to the grant that an auditor will later check. Establishing that connection before accepting the award avoids having to reconstruct it after spending begins. Reviewing the terms can expose matching requirements, caps on particular costs, and reporting timelines that change whether the project is fundable under that grant. Good records cannot undo an expense that the agreement excludes.

How to frame technology expenses in a grant application so funders approve them

The application should explain how infrastructure supports mission delivery. A case management database is fundable because it tracks program outcomes. This is not a cosmetic distinction. When the tool directly supports the funded work, describing that role is more accurate than presenting it as a general efficiency purchase.

For example, “cloud hosting” can become an explanation of the platform that stores and processes participant data for the program. A software license can be described as the tool staff use to track service delivery milestones and generate the grant’s required outcome reports. IT support can be presented as managed services tied to specific program infrastructure, provided that is genuinely its scope. The qualification is essential to the claim. Support for the whole organization stays indirect even when the description mentions a program.

Outcome records, cost-per-participant figures, and multi-year trends ground the request to modernize in demonstrable work. What will this tool help the program deliver? The budget narrative should answer that question and explain how the organization will show that the expense belongs to this grant. Neither answer guarantees approval, but together they give the funder a defensible basis for it.

Which technology grants are open now and what each one actually covers

The nonprofit technology funding landscape in September 2026 includes open in-kind programs and a cash-and-credit grant whose application cycle has closed. These options serve different budget needs. Some replace a software expense, while others support a defined technology project. Their fit depends on the cost being funded.

Google Ad Grants is open and provides in-kind advertising on Google Search. Its support is limited to digital outreach. To qualify, an organization must have valid charitable status and a working website, register with Google for Nonprofits, and follow Google’s policies.

Google Workspace for Nonprofits is also open and covers productivity and collaboration software at no cost. It is separate from Ad Grants. Both use the same Google for Nonprofits account, but each product must be activated separately, and the charitable-status requirements are similar. Workspace meets a software need that might otherwise fall in the indirect budget, but it provides no cash to build a tool for a specific program.

Canva for Nonprofits is open and provides design software for graphics, presentations, social content, and print. It provides no money to fund a project. Canva uses Goodstack to verify eligibility. Ineligible organizations include government agencies, political organizations, educational institutions, for-profit companies, most other 501(c) types, and grant-making foundations.

The AWS Imagine Grant’s 2026 cycle is closed, with the next round opening in March 2027. Awards reach up to $200,000 in cash plus up to $100,000 in AWS credits. The tiers fund different kinds of work. Pathfinder supports innovative AI applications, Momentum to Modernize supports foundational infrastructure with a cash award plus up to $20,000 in credits, and Go Further, Faster supports expansion of existing capabilities.

The grant accepts domestic 501(c) nonprofits, including 501(c)(3) organizations, credit unions, public utility organizations, and other 501(c)-designated entities. Projects must show how AWS solutions help them work more efficiently and deliver services. Its financial support is unrestricted. That flexibility does not resolve the post-grant budget, however, because sustaining costs after the grant cycle must be secured separately.

Why the build-versus-sustain gap is the grant problem nonprofits least plan for

Most technology grants pay for the build over a set period. Almost none pay for all the hardening, maintenance, and infrastructure needed from the time real users arrive onward. A project can therefore fit an award’s allowable uses perfectly and still have too little in its budget to keep running. The mismatch is between the funded period and the life of the system.

AI has made software faster and cheaper to build, which can widen that gap. The same grant can now buy more code more quickly, but the cost of running and maintaining it from year two onward has not changed. More software does not mean more sustaining funds. In a concrete example, two nonprofits applied for a technology grant in 2025, and one was declined. The other received funding and spent more than a year building a tool, but ultimately returned to paper registers and Excel, as the declined nonprofit had, because the programme ended before adoption.

Okta for Good’s multiyear structure reduces the budget-cliff risk by extending the funded period. The planning implication starts at application stage. Sustaining costs need a place in the funding plan before the build begins, rather than becoming a new question after the award ends.

How grant-funded builds accumulate technical debt and what that costs in practice

When the award funds delivery but not the hardening that follows, shortcuts taken to meet its deadline become structural liabilities. This is technical debt in the grant-funded setting. The organization pays through staff effort and system fragility, often without a distinct invoice to bring the expense into budget review. The apparent saving on the build can therefore conceal work that has only been postponed.

Skipping automated tests makes every future change a manual verification task. Without care in how database migration is done, schema changes become emergencies, and without deployment automation, releases need work by hand and are more likely to fail. Missing monitoring leaves users to report problems. When authorization boundaries are weak, security fixes can mean reworking the architecture. Each shortcut lowers the initial effort while adding a different kind of obligation after launch.

Staffing churn makes those obligations harder to resolve. Tight budgets can lead nonprofits to hire administrators who lack the experience in architecture to push back when changes make a system more complex. Each administrator inherits a system they did not design and responds with tactical fixes, leaving broader improvement undone. The next handoff compounds the problem. What looks like a series of separate support tasks can become debt that grows with every change of staff.

Technical debt is not a moral failing. In this setting, it follows predictably from a grant structure that rewards a completed build without fully funding its operation. Addressing it when real users arrive avoids a delay of two years in production. That timing makes hardening part of bringing the system into service, before it becomes hard to change and needs a rescue project.

How nonprofits can use grant applications to fund the re-engineering work, not just the original build

The AlleyCorp ENG(INE) Grant explicitly covers re-architecture and replatforming of existing core infrastructure. That gives the gap between an initial build and a production-ready system a named funding vehicle. New software is not the only fundable work. Re-engineering can qualify as a direct program cost when the resulting system delivers a specific program outcome and the expense meets the award’s rules.

The application should therefore name the service constraint the work will remove. A project has a clear link to a program when it involves replatforming a case management system to handle an expanded program, with monitoring and automated deployment to cut the hours staff spend on manual workarounds. “Upgrading IT infrastructure” does not establish that connection. The budget still needs project-tagged evidence and an allocation method to split costs when more than one program benefits.

Airtable’s acquisition by Bending Spoons in September 2026 accelerated nonprofit interest in alternatives because migration costs had not been budgeted. Building on open, portable infrastructure reduces the risk that a future move becomes an unfunded emergency. The Nonprofit Open Source Partnership 2026 helps get software ready for open-source use, which is one way to reduce vendor lock-in. The fundable request is not simply to improve technology, but to make a particular service sustainable through work the nonprofit can define, allocate, and prove.