Budget requests

Change requests with team-by-team proposals, approvals, and a full audit trail. This is how budgets actually get amended between snapshots.

A budget request is the formal mechanism for changing the active budget. When the team needs more headcount or budget than the current snapshot allows, you raise a request. Affected team managers get the request in their inbox, write proposals, the proposals get reviewed and approved, and when everything is approved the request finalises into a new snapshot.

The request lifecycle

DRAFT          (request being prepared)
   -> IN_PROGRESS    (sent to team managers, proposals being collected)
   -> IN_REVIEW      (proposals in, awaiting the final accept)
   -> ACCEPTED       (new snapshot created, supersedes the previous active)
   -> CLOSED         (request closed without acceptance; preserved for audit)

Requests list on the Budget requests tab of the Budgets tool (/plan/[planId]/finance/budgets/requests), grouped by fiscal year. Closed requests stay queryable via the API.

The request detail page

Lands at /plan/[planId]/finance/budgets/requests/[requestId]. The request is a tabbed record. Two persistent elements frame every tab:

• Ticker bar, pinned to the top. Title, fiscal year, status, the headline deltas (cost, FTE, employees, contractors, vacancies) against live, and the single next action in the request's state machine: Send to teams on a draft, Accept once proposals are in review. Accepting creates the new snapshot and links you straight to it. An overflow menu offers Close and Delete to budget owners, plus an XLSX export.
• Tab bar, floating at the bottom. Four route-linked tabs.

Tab	Route	What it shows
Overview	.../requests/[requestId]	The approval control centre. Every team in scope, its proposal status and assignee, and per-team Review and Approve actions. Review opens the team's change list in a drawer
Changes	.../requests/[requestId]/changes	The aggregate change list for the whole request: the base plan plus every approved or merged team proposal, each compared with live. Row actions: revert, discuss, open the entity
Initiatives	.../requests/[requestId]/initiatives	The fiscal year's initiatives grouped by objective, showing each initiative's budget against its forecast cost and committed FTE
Forecast	.../requests/[requestId]/forecast	The per-team quarterly cost forecast for the request's fiscal year, fed by the request's base plan. A scope control switches between approved proposals only and including pending ones

My budget

Team managers work on their own proposal in the My budget view at .../requests/[requestId]/my. It is the same view as the My Budget sidebar destination. Managers make their changes there, discuss them in the comment thread, and submit. Approvers then act from the Overview tab. Comments are first-class. Proposals get reviewed in conversation, not just by status changes.

What proposals can change

A proposal can adjust:

• Headcount per team (add vacancies, remove planned hires).
• Contractor budget per team.
• Project allocations.
• AI agent seat counts.

What it cannot do directly: change salaries, geographies, or job role definitions. Those are workforce-engineering changes — make them in Workforce first, then raise a budget request to amend the budget around the new shape.

Permissions

• View a request: any user with access to one of the teams in scope.
• Submit a proposal: the team's manager or one of the configured proposal writers (see cost review workflow for the budget approval config).
• Approve, reject, accept, close, delete: configured per org via the budget approval config — typically a small group of finance leads.

Related

• Variance overview — the full variance loop.
• Budget snapshots — where finalised requests land.
• Cost review workflow — review cadence and budget approval setup.