Sensitivity register for budget approval

Nothing here is financial advice, and none of it replaces your own checks.

Use this process to turn an operating budget and financial model into one short register of assumptions that could change an approval decision. It is for FP&A teams and budget holders reviewing annual plans, rather than rebuilding every formula in the model.

Nothing here is financial advice, and none of it replaces your own checks. Use the register to focus review conversations, retain ownership of the underlying numbers, and record what must be approved.

1. Set the review boundary

Before uploading or pasting anything, write the decision you need to support. Put it at the top of your working note, for example: Approve the annual operating budget subject to named assumptions and downside actions.

Then collect only the documents that establish the budget case:

• The approved planning guidance or budget narrative.
• The operating budget, preferably with monthly revenue, cost, headcount and cash schedules.
• The financial model, including the base, downside and upside cases.
• The assumptions tab, driver tabs and scenario-control sheet.
• Any existing commentary on risks, dependencies or management actions.

Remove customer names, employee details and other material the reviewer does not need. Keep document names and sheet names. They let you trace each finding back to a source.

If you use file upload or other product features, availability and supported formats can vary. Check the relevant guidance in the xAI documentation overview before you begin.

2. Extract assumptions into a single list

Start with the operating budget narrative and the assumptions sheet. Ask the model you are using to extract stated assumptions without judging them yet. Give it the documents and use a bounded request:

Extract every explicit operating and financial assumption from the attached budget documents.

For each assumption, return:
- assumption name
- value or stated direction
- unit and time period
- source document, sheet and cell or section where available
- owner named in the document
- whether it affects revenue, cost, headcount, working capital, cash or financing

Do not infer missing values. Mark unclear wording as "ambiguous" and quote the source text.

Copy the result into a spreadsheet or review table. Do not leave it as chat output. Your register needs a stable owner, status and source reference.

Use these fields:

Field	What to enter	Why it matters
Assumption ID	A short identifier, such as REV-03	Lets reviewers refer to one item clearly
Input and baseline	The driver and its budget value	States what the plan relies on
Source	File, sheet, cell or narrative section	Makes the item traceable
Case values	Base, downside and upside treatment	Shows whether scenarios actually test it
Output affected	Revenue, EBITDA, cash, covenant headroom or another approval metric	Connects input to decision
Owner and evidence	Named accountable person and supporting evidence	Assigns follow-up work
Approval status	Accept, revise, evidence required or escalate	Records the decision

3. Reconcile the budget with the model

Now test whether the narrative, budget workbook and model are describing the same plan. Ask for a comparison that separates evidence from interpretation:

Compare the attached operating budget, assumptions sheet and scenario model.

Create a discrepancy list. For each discrepancy, show:
- the assumption or metric
- the value in each source
- whether the difference is timing, definition, unit, formula logic or an unexplained conflict
- the likely affected output
- the exact source references

Do not choose a correct value. Do not fill gaps with assumptions.

Review the list against the workbook. Common false discrepancies include monthly versus annual values, gross versus net revenue, average versus period-end headcount, and percentages entered as decimal values. Correct the source documents or mark the conflict for the budget owner. Do not quietly normalise a conflict in the register.

4. Test the stated downside and upside cases

A scenario is useful only if it changes a plausible driver and carries that change through the relevant outputs. Read the scenario-control sheet first. Identify which inputs actually differ between base, downside and upside.

Use this request after you have identified the controls:

Review the base, downside and upside cases in the attached model.

For each scenario, list changed inputs and unchanged inputs. For each changed input, show the base value, scenario value, direction of change, and affected outputs.

Flag:
- a stated scenario change that is not reflected in outputs
- an output change with no identifiable input change
- a downside case that improves a related assumption without explanation
- an upside case that requires capacity, hiring, funding or delivery actions not stated in the documents

Use only evidence in the files. Label any conclusion as a question where evidence is incomplete.

Then test a small number of combinations that management could face together. For example, if volume is lower and customer payment is slower, assess whether both changes are represented in the downside case. Do not create a long catalogue of remote combinations. Prioritise combinations that alter cash availability, profitability, funding needs, delivery capacity or another stated approval threshold.

5. Rank decision-sensitive inputs

Rank each input by its effect on the approval decision, not by whether it is easy to measure. Use three practical tests:

1. Impact: does a reasonable movement change a key output or threshold?
2. Uncertainty: is the value supported by current evidence, or mainly by judgement?
3. Response time: can management act before the impact becomes difficult to reverse?

Mark an item as decision-sensitive when it scores high on impact and uncertainty, or when it has a short response time. For each such item, write one management question. Examples include whether demand evidence supports the planned run-rate, whether planned hiring can occur in time, or whether working-capital assumptions match current collection patterns.

Do not ask the model to assign final risk ratings without your criteria. Give it your scoring definitions and ask it to apply them consistently. The budget owner should challenge the ranking before it goes to an approval meeting.

6. Produce the approval register and pack extract

Keep the final register short enough to read in the meeting. For each decision-sensitive input, include the baseline, scenario movement, effect, evidence, owner, action and approval status. Attach a separate appendix for the complete assumption list and all reconciliation differences.

Ask the model to draft, not decide:

Draft a one-page approval summary from this sensitivity register.

Use these headings: decision requested, three to five decision-sensitive assumptions, downside exposure, upside dependencies, unresolved evidence, and actions required before approval.

State source references for each claim. Use neutral language. Do not recommend approval or rejection.

Check the output is not misleading

The register is wrong if it is internally tidy but cannot be traced back to the budget and model. Sample every high-ranked item before circulation. Open the cited cell or section, confirm the unit and period, and check that the scenario value feeds the claimed output.

Use this review table when you find a problem:

If you see this	Likely problem	What to do
A large output movement with no changed driver	Hidden formula, manual override or broken link	Trace precedent cells and ask the model owner to explain the logic
A driver has different values across documents	Timing or definition conflict	Record both values, identify the source of truth and obtain an owner decision
Downside changes revenue but not cash	Incomplete scenario propagation	Test receivables, inventory, payables and financing assumptions
A register item has no source reference	Unsupported interpretation	Remove it or relabel it as a question for the owner

When the process does not work

Stop if the model cannot show which cells control each scenario, if key outputs are hard-coded without explanation, or if the budget owner cannot identify the source of a material assumption. Do not compensate by asking the model you are using to guess the missing logic.

Return to the model owner with a short issue list: the missing control, the affected output, the source reference and the decision it blocks. Update the register only after the owner has corrected the model, supplied evidence, or formally accepted the uncertainty. This keeps the approval record useful when the plan is revisited.