Connect the Funding Ask to the Work the Company Will Do
Connect the Funding Ask to the Work the Company Will Do
A deck usually shows two things about money: a number, and a split. The number is what the company is asking for. The split says product 40 percent, team 35, growth 25. Neither one tells a reader why that amount, over that period, is the right amount for the work in front of the company.
The short answer is that a funding request reads clearly when it describes a named body of work over a named period, taken from a plan the company's finance owner has approved. The work explains why the amount is the size it is. The amount shows the work is funded. Neither can do that job alone.
The repair is not a nicer chart. It is a plan in which the amount, the period, the work, and the uncertain parts sit close enough together that a reader can follow one line from what is being requested to what it would let the company do, and to what would change the picture. When that line is intact, the ask stops being a figure you have to take on faith and becomes a claim someone can examine.
State the ask and its planning basis
Four pieces of information belong on the page before any line about spending.
The amount: what is being requested. The period: the stretch of time the plan covers. The plan version: which dated model the numbers came from. And the resources the company already has, which the new request is meant to sit alongside rather than replace.
Keep three things separate while you write, because a reader will be checking for exactly this. Cash the company already holds. Operating receipts it expects over the period. New funds being requested. Blur them and the ask looks smaller or larger than it is.
"Expected receipts" deserves a second look every time. A signed order and a promising conversation are both real, and they are not the same kind of money. If a receipt depends on a customer signature that has not happened, say so in the same breath. A conditional inflow presented as secured cash is the fastest way to lose a careful reader.
The period is the planning window, not automatically the length of time the funds last. Those are different questions, and the plan should answer both. If the request covers twelve months of work but the model shows the money running out in month nine under its own assumptions, that is worth knowing now, in the room where questions can be asked, rather than in a later conversation with no good answer available.
Which version of the plan? A reader who has seen one deck and then another cannot tell whether the numbers changed on purpose or by accident. Date the plan. If the amount moved because a hire got more expensive or a renewal came due, that is a reason, not an embarrassment.
Translate spending categories into actual work
Categories are a summary. Work is the thing the money buys. The job in this section is to walk from one to the other without making every line sound like a triumph.
"Two engineers" is a category. "Two engineers, working with the partner's API team, to complete the integration by the end of month four" is work, with an owner and a date attached. The second version lets a reader ask whether two is enough, whether month four is realistic, and what happens if the partner's team is slow. The first version lets them ask nothing, which is a problem, because it also tells them nothing.
A hire is worth describing in terms of what it enables and when it starts. Someone joining in month four cannot do month two's work, however impressive the résumé. If the plan assumes the new person will be productive quickly, that assumption is doing real work in the numbers and should be visible as an assumption rather than folded into a salary line.
Ongoing obligations belong here too, and this is where a lot of funding explanations quietly go wrong. A plan that spends the entire request on new development implies that the existing business costs nothing to run: no salaries already committed, no hosting, no support load, no renewal dates, no compliance work, no insurance. None of those pause while the company builds the new thing. If existing operations genuinely fund themselves, say so, because that is a claim with evidence behind it. If they don't, their cost is part of what the request is for, and hiding it in an unlabeled line makes the ask look arbitrary.
Watch for categories that are really several budgets wearing one name. "Growth" often means a mixture of marketing spend, sales travel, conference fees, and partner costs, each with its own timeline and its own evidence. Name the activities. "Six months of paid acquisition at a rate we have tested" is a plan. "Growth: 25 percent" is a placeholder.
Connect the work to dependencies and intended progress
Work does not happen in the order it appears on a page, and the amount usually depends on that order.
Write the chain out. A hire enables the build. The build enables a test. The test enables a pilot. The pilot produces information. The information informs a commercial decision. Each link has a precondition, and each precondition can fail. If the integration has to be finished before the pilot can start, then the pilot budget is not doing anything until the integration is done, and a plan that assumes both proceed at once should say why that is true: extra hands, a second workstream, a partner who can start earlier than expected.
Then separate the two kinds of outcomes.
A deliverable is something the company controls. The integration passes the test suite under production load. The pilot runs with a set number of participants for a defined period. The team publishes what it learned. A commercial outcome is not controlled: those participants choosing to convert, the market accepting the price, a competitor not moving. Shipping a tested feature does not prove anyone will buy it. It proves the feature works.
Language carries this distinction whether you intend it to or not. "The platform will be live with three enterprise customers by Q3" promises a market result. "The pilot is designed to test whether the integration holds up under three customers' production traffic; a decision on broader launch follows the results" describes a deliverable and its purpose. Both are confident. Only one is checkable in the period it names.
Preserve the timing and capacity assumptions that could change the amount. How long does hiring take? Is a partner's API access already granted, or is that conversation still open? Can the same three people carry the integration and support the pilot, or does one of those slip? These are the places where the plan is most likely to be adjusted later, and a reader who knows them can see the ask as a live estimate rather than a fixed promise.
Check the request against the financial explanation
Now go back through the numbers with the person who owns them.
The request, the existing cash, the expected receipts, and the period's uses should reconcile with the model they came from. That model belongs to the company's finance owner, not to whoever is writing the deck. If you are drafting the explanation and do not have access to it, that is the gap to close before the explanation gets polished, because a well-written paragraph built on numbers nobody has checked is worse than a rough paragraph with a note attached.
Three specific limits of the percentage split are worth stating plainly. First, the categories add to 100 by construction, so the chart shows proportions of a number rather than whether that number is enough. It cannot show that the plan is affordable. Second, it carries no timing and no overlap. Two categories can each be a quarter of the total and draw on the same month's cash, which matters a great deal when payroll and a license renewal land in the same week. Third, the labels are not mutually exclusive: one hire can sit in "team" and be the reason the "product" line moves at all, so the chart can read as two efforts where there is one. A plan can look fully funded as a pie chart and still miss a date.
So put the timing in writing. When does the large money leave, and when does the incoming money arrive? Are there significant outlays that fall in a single month rather than spreading across the period — hardware, a data license, a legal bill, a deposit? Those are the places where the amount and the schedule are really decided.
The SBA's business-planning guidance, "Plan your business" (sba.gov, checked September 2026), lists a funding request alongside financial projections. The pairing is the part worth keeping: what you are asking for and the numbers behind how you would use it belong in the same account. That guidance describes a full business plan with its own suggested horizon, which is not a rule for how long an investor deck should cover or what shape it should take.
Then put the consequential dependency near the ask rather than in an appendix. If the pilot cannot start until the integration ships, and the integration depends on a partner whose timing is not the company's to set, that belongs in the same passage as the request. A reader who reaches an appendix has already formed an impression, and the point of a funding explanation is to give them the right one early.
Where information is missing, the answer is to get it, not to estimate it. If you do not know whether the enterprise receipts are signed, ask. If the coverage period has not been calculated, calculate it. A plausible figure invented by the writer will survive the deck and fail the meeting.
A worked example, in outline
The illustration below is fictional, built to show the shape of the thing rather than a real company's numbers. No amount appears in it, because the amount should come from the fictional company's finance owner, not from whoever is drafting the explanation.
Suppose a company is raising money to do three connected things: finish an integration with a partner platform, prepare a pilot with a small set of design partners, and support the team while both happen. Existing commitments continue throughout — salaries, hosting, customer support, one data-processing renewal.
The version to avoid labels the request product 45 percent, sales 30 percent, operations 25. The labels do not say what the money does, when it is spent, or what it depends on.
The version to write connects four elements.
- Work. Engineering time to complete the integration. Product and support time to prepare the pilot. The continuing cost of running what already exists.
- Dependency. The integration has to be finished and stable before pilot participants can be brought on, and those participants have to accept an invitation that has not yet been issued.
- Intended progress. A working integration and a completed pilot round, plus what the team expects to learn from it: whether the setup holds up under real traffic, and what participants do when asked to continue.
- What would change the plan. A slow partner, a hire who starts later than planned, participants who decline, or expected receipts that do not arrive on schedule.
The request is then described through the period it covers and the inputs behind it: the plan's period, the cash already available, the receipts the plan expects, the material uncertainty, and how the owner arrived at the amount. If the request is larger than the gap between the period's uses and the resources on hand, the plan should say what the excess is for — a cushion, an acceleration, protection against timing — because a reader who cannot see a reason will assume there isn't one.
The success condition here is not that the pilot succeeds. It is that a reader can trace a line from the amount to the work, see where the work could slip, and understand what the company intends to learn. A pilot result is a later fact. Traceability is available now.
What the request supports, and what could change it
Close by naming three things together: the work the request supports, the period it covers, and the assumption most likely to move either one.
"This request covers the [period] plan dated [date]. It funds the integration and the pilot preparation described above, alongside the operating costs that continue in the same months. The assumption that would change it first is [dependency] — if that slips, the schedule changes and the amount is likely to change with it."
Then keep two kinds of statement apart in the closing as carefully as in the middle. Evidence of progress is what the company did: the integration shipped, the pilot ran, the team learned something specific. An assurance about commercial outcome is a claim about the market, and the funding does not deliver it on its own. A reader who is told exactly which of the two they are getting will trust the plan more rather than less, because the number, the period, and the work all point at the same thing.
Frequently asked questions
What four pieces of information belong before any spending line in a funding request?
The amount requested; the period the plan covers; the plan version or date the numbers came from; and the resources the company already has, which the new request sits alongside rather than replaces. Also keep cash on hand, expected operating receipts, and new funds requested separate.
How can a spending category like growth: 25 percent be made useful?
Replace the placeholder with named activities, timelines, and evidence. Six months of paid acquisition at a rate we have tested is a plan. A category often covers several budgets—marketing spend, sales travel, conference fees, partner costs—each with its own timeline and evidence.
Why separate deliverables from commercial outcomes in a funding plan?
Deliverables are things the company controls: the integration passes the test suite, the pilot runs with a set number of participants, the team publishes what it learned. Commercial outcomes are not controlled: participants choosing to convert, the market accepting the price, a competitor not moving. Shipping a tested feature proves it works, not that anyone will buy it.
What are three limits of a percentage split chart for a funding ask?
The categories add to 100 by construction, so the chart shows proportions of a number rather than whether the number is enough or affordable. It carries no timing or overlap; two categories can each be a quarter of the total and draw on the same month's cash. The labels are not mutually exclusive; one hire can sit in the team category and be the reason the product line moves.
What should be done if expected receipts are unsigned or the coverage period has not been calculated?
Get the missing information, not estimate it. Ask whether the enterprise receipts are signed; calculate the coverage period. A plausible figure invented by the writer will survive the deck and fail the meeting. Also put a consequential dependency near the ask rather than in an appendix.