Appendix: The FP&A Operating Model

Standard FP&A practice builds an operating plan from operational drivers rather than from a top-line guess. Revenue starts with units times price, segment by segment. Cost of goods sold is tied to revenue through a cost ratio, so it scales as volume scales. Operating expenses sit below the gross profit line, and operating income falls out as gross profit minus operating expenses. Nothing in the operating statement is asserted directly; each line is assembled from the drivers above it.

Meridian's plan has two segments, and the build makes the logic concrete:

• Industrial Fittings. 480,000 units at a planned $215.25 gives revenue of $103,320,000. At a 62% cost ratio, cost of goods sold is $64,058,400, leaving gross profit of $39,261,600.
• Precision Components. 432,000 units at a planned $200.00 gives revenue of $86,400,000. At a 66% cost ratio, cost of goods sold is $57,024,000, leaving gross profit of $29,376,000.

Summed, the two segments give total revenue of $189,720,000 and total gross profit of $68,637,600, a blended gross margin near 36.2%. Operating expenses of $36,046,800, about 19% of revenue, come off gross profit, so planned operating income is $32,590,800, an operating margin near 17.2%. The structure holds all the way down the chain: each figure traces to a driver above it, and no line is a free-floating assertion.

The operating plan is the top of a larger structure. Its output, operating income, does not stop at the income statement. Operating income flows down to projected net income, net income lifts retained earnings on the projected balance sheet, and the same net income is the starting line of the projected cash flow statement, where working-capital and capital-spending assumptions complete the bridge to projected cash. This is the three-statement logic: the income statement, balance sheet, and cash flow statement are linked, so a change in a revenue or margin assumption in the operating plan tends to ripple through the three statements.

This appendix stays at the operating-plan layer, the income statement built from drivers, because that is where the driver logic lives and where AI assistance is most direct. The fuller picture still matters, though: a plan that foots at the operating-income line is the input the rest of the model depends on, so getting the driver build right is what lets the balance sheet and cash flow projection stand on something solid.

A plan-ready standard fixes the finish line before any tool touches the plan. A plan-ready operating model has the arithmetic tie: revenue equals units times price by segment, cost of goods sold ties to the cost ratio, and operating income equals gross profit minus operating expenses. It carries a driver commentary that names the assumptions doing the most work, and it is stress-tested with a scenario or two rather than presented as a single certain number. It is the plan a leadership team could pressure-test, not a rough sketch.

The task suits AI assistance because the plan splits cleanly into two kinds of work. The arithmetic, multiplying units by price, applying the cost ratio, footing operating income, and reflowing the whole build when an assumption changes, is deterministic: for a given set of drivers there is one correct set of totals. The judgment, which assumptions to make, which scenarios to run, and how to frame the result for leadership, is where the analyst adds value. That split, deterministic machinery on one side and owned assumptions on the other, is what the rest of this appendix is built around.

The most useful thing you can give a model for this task is an example of the destination. Last cycle's validated operating plan is exactly that: it shows how the segments are laid out, how the cost ratios are applied, how the operating-income line foots, and how the driver commentary reads. With that example in the folder, you are not asking the model to guess what a plan should look like; you are asking it to produce more of a known shape. The path runs from a set of drivers to a validated operating model with scenarios, and the worked example anchors the far end.

Building the plan is deterministic work: for a given set of units, prices, and cost ratios, there is one correct revenue figure, one correct cost of goods sold, and one correct operating income. Asking a language model to produce those totals in prose invites small, hard-to-catch errors, and worse, it leaves two versions of the numbers if the model's prose drifts from the build. So the workflow puts the math where it belongs. The model builds the plan as an explicit calculation you can open and check, and then narrates the drivers and scenarios on top of a base that has been validated. The model performs the non-deterministic work, the part with many acceptable phrasings: describing which assumptions matter and how the scenarios read.

This is the single most important design choice in the appendix. When the model holds the arithmetic as a checkable calculation, there is one source of truth for the totals, and validation becomes a tie-out rather than a recalculation done in your head.

A single segment makes the split concrete. Industrial Fittings in the Meridian plan reads 480,000 units at a planned $215.25, with a 62% cost ratio. The workflow carries that segment from drivers to one validated line and a scenario read, with a named owner at each step.

• Build, deterministic. Revenue is 480,000 times $215.25, or $103,320,000. Cost of goods sold is 62% of that, or $64,058,400. Gross profit is $39,261,600. There is one correct answer for each, so the model builds the three figures and holds them as a checkable calculation.
• Assumptions, judgment. The 480,000 units and the $215.25 price are management's bet, not the model's to invent. The analyst owns them, and if the model proposes a number, it is surfaced and adopted or replaced rather than accepted quietly.
• Validate, mechanical. Confirm units times price ties to the revenue shown, cost of goods sold ties to the 62% ratio, and the segment gross profit foots. Only a base that ties earns a scenario.
• Narrate, non-deterministic. The model turns the validated figures and a scenario into a measured read: "Holding price flat rather than taking the planned increase reduces Industrial Fittings gross profit dollar for dollar, since units and the cost ratio do not change."

The lab folder is deliberately small: the driver-based operating plan, and nothing else. A larger pile of schedules would bury the drivers that actually move the plan and raise the chance the model latches onto something irrelevant. Minimum context is the fuel: give the model exactly what the task needs, plus the worked example so it knows the shape of the answer.

The worked example does work here that written instructions tend to miss. It encodes the tacit layout, the level of detail, and the way the driver commentary is framed, things that are hard to spell out as a rule, and the model tends to match a shown example more reliably than it follows an abstract description of one. That is why the folder carries a validated plan rather than a longer style guide.

The five moves are not a one-off. Because planning runs on a cycle, the prompt that carries these instructions is worth saving as a reusable skill or prompt template: the destination example, the build-the-machinery rule, the minimal-folder list, and the driver-commentary guidance, packaged so the next cycle starts from a known shape rather than a blank page. Standardizing the AI step is how you keep the plan repeatable.

Pair it with a short plan-ready checklist the analyst runs before the plan goes anywhere: tie revenue to units times price by segment, tie cost to the ratio, confirm operating income foots, check that each scenario moves the input it is supposed to, and confirm each assumption is one the team chose rather than one the model supplied. The skill makes the build repeatable; the checklist makes the review repeatable. Together they keep the human checkpoint from becoming a rubber stamp.

Download the folder and run the operating-model pattern in whatever AI you use. The folder holds Meridian's driver-based plan by segment, with the totals shown. Have the model build and hold the arithmetic (revenue as units times price, cost of goods sold tied to the cost ratio, operating income footing), confirm it ties, and then narrate the drivers and two scenarios, a price-hold and a volume-miss. Keep the assumptions yours to defend. The company and its numbers are fictional.

The heart of validation is the tie-out of the drivers: confirm revenue equals units times price for each segment, cost of goods sold ties to the cost ratio, and operating income equals gross profit minus operating expenses. A single line that does not foot is enough to send the whole plan back. Confirm, too, that each scenario moves the input it names and nothing else, and that each assumption in the plan is one the team chose to own rather than one the model supplied. Work the checklist below against your plan before you would ever call it plan-ready.

The base is validated, so now the scenarios can be read on top of it. Each moves one input and holds the rest, and to keep the illustration clean, operating expenses are held fixed as a stated management choice. The two scenarios land differently.

Price-hold: price comes in 3% below plan, volume flat. Holding price means units and the cost ratio do not change, so cost of goods sold stays at $121,082,400. Revenue falls 3% to $184,028,400, and the full $5,691,600 of that decline drops through to gross profit, which becomes $62,946,000. With operating expenses held at $36,046,800, operating income falls to $26,899,200, a decline of $5,691,600, or about 17.5% of the base. A 3% price miss is a roughly 17% operating-income miss.

Volume-miss: units come in 5% below plan, price at plan. Fewer units means both revenue and cost of goods sold fall 5%, since cost is tied to volume. Revenue falls to $180,234,000 and cost of goods sold to $115,028,280, so gross profit falls 5% to $65,205,720. With operating expenses held, operating income falls to $29,158,920, a decline of $3,431,880, or about 10.5% of the base.

The lab is clean by design: two segments, clean cost ratios, and operating expenses held fixed. Real operating plans are messier, and the workflow tends to strain in three specific places.

• Operating expenses that are not truly fixed. Holding operating expenses flat keeps the scenario illustration clean, but in practice some operating cost flexes with volume or with headcount decisions, so a volume-miss can move the operating-expense line too. A scenario that holds it fixed without saying so overstates how cleanly the impact isolates.
• Assumptions the model supplies unremarked. Asked to build the plan, a model will sometimes fill a gap with a plausible price increase or a cost ratio no one chose. The arithmetic foots, so the invented assumption hides in a plan that ties. Confirm each driver is a management choice before you accept the plan.
• Scenarios that move the wrong input. A "price-hold" that quietly lowers volume, or a "volume-miss" that also trims price, reports an operating-income impact that answers a different question than the one asked, and gives false comfort about where the plan is exposed.

On top of these, the model will sometimes produce a scenario narrative that is fluent, specific, and built on a base that does not tie, which is exactly why the tie-out and the assumption check are not optional. The workflow does not remove the analyst's judgment; it removes the mechanical build so the judgment has more room.

Rate your own operating model against the rubric below. An honest rating shows which parts of the workflow you have mastered and which still need practice. Your scores roll up to the workflow maturity dashboard on the course hub.