Prediction Is Not the Decision

The decision begins where the forecast ends

A prediction can estimate demand, cost, risk, or return. It cannot decide how many people to hire, whether to invest in operating flexibility, how to allocate limited cash, or which tradeoff an organization should accept. Those decisions require an objective, an understanding of uncertainty, real constraints, and someone with the authority to act.

That distinction became the central lesson I carried from Week 6 of the AI for Business & Finance Certificate Program at Columbia Business School Executive Education. After several weeks focused on prediction, the course moved into simulation and optimization. The subject sounded mathematical, but the underlying questions were familiar from accounting and finance. What is the economic consequence of being wrong? Which assumptions matter? What limits the available choices? Who is authorized to approve the result?

I have more than seven years of experience in accounting and finance and spent more than five years as a full-time parent. Somewhere along the way, my professional development began to include Jupyter notebooks, Python functions and loops, and optimization tools. That is not the career sentence I would have predicted for myself, which may be why Week 6 felt so satisfying. Beneath the code, I recognized the discipline required in a budget, cash forecast, funding request, or loan draw: define the purpose, respect the constraints, retain the evidence, and understand what happens when an assumption fails.

My main takeaway is that the path from an analytical result to a business action is a controlled process. Simulation helps us examine how a decision behaves across many plausible futures. Optimization searches for the best modeled choice within the rules we provide. Neither method determines whether the model reflects reality or whether the organization should act. People remain responsible for those judgments.

Why the average can be the wrong answer

The first simulation exercise considered staffing for a new call center. Historical demand made the average staffing level look like a sensible answer. The problem was that overstaffing and understaffing did not carry equal economic consequences. Extra employees created labor cost, while too few employees could also mean lost customers and lost revenue.

Once the cost of being short differed from the cost of being long, average demand stopped being the decision rule. The class generated thousands of plausible demand outcomes and evaluated the same staffing choices across them. In the simplified exercise, the lowest expected cost occurred below average demand. The point was not the particular staffing number. It was that the mean of an uncertain input and the economically preferable action can be different.

This was an important learning moment for me because accounting relies heavily on averages, budgets, standard costs, and expected values. Those measures are useful summaries, but they can conceal the shape of the risk. A cash shortfall can be more consequential than the same amount of excess cash. A construction delay can trigger financing costs or a funding problem that an equally early completion does not offset. A forecast that is correct on average can still support a weak decision when the consequences are asymmetric.

The course also used a pension example to illustrate a related problem. When the relationship between an input and its cost is curved rather than linear, applying one average assumption can produce a different result from evaluating individual scenarios and then averaging their costs. In other words, when costs rise faster as conditions worsen, the cost associated with the average input may not equal the average of the costs across individual scenarios. A moderate staffing shortage, for example, may be manageable, while a severe shortage can cause wait times, lost customers, and revenue losses to accelerate. For an accounting and finance professional, the practical question is whether averaging the inputs preserves the economic relationship that drives the liability, cost, or return.

Simulation turns uncertainty into a decision test

Simulation replaces one forecast with many plausible versions of the future. In the call-center exercise, Python generated synthetic demand based on the historical pattern. The same staffing choice was then tested repeatedly, and the model calculated its cost in each simulated scenario. This allowed us to compare decisions across a distribution of possible outcomes rather than rely on one estimate.

That is the practical value for finance. A cash forecast, operating plan, or capital decision usually contains variables that will not move exactly as expected. Collections may arrive late. Costs may exceed the budget. Interest rates, occupancy, or project timing may change. Simulation makes those uncertainties explicit and shows how a proposed decision behaves when several assumptions move.

The course described this as creating a digital twin: a simplified computational version of a real process that can be tested without changing the real operation. The simulated world is not a prediction that one exact future will occur. It is a controlled environment for asking whether a decision remains acceptable across many plausible futures.

The lesson on random seeds added a control perspective I appreciated. A random seed is a setting that lets Python reproduce the same sequence of randomly generated values. During development and review, that reproducibility helps someone determine whether a result changed because the code or an assumption changed, rather than because Python happened to draw a different set of scenarios. The conclusion should also remain reasonably stable when the seed changes. Otherwise, the analysis may rely on too few simulations or too much chance.

The energy storage case made flexibility visible

A classroom energy-storage case extended simulation from one uncertain variable to an interconnected operating system. Energy demand, renewable generation, grid prices, storage capacity, charging limits, and time of day affected one another. A battery could absorb excess energy at one point and make it available when supply was limited or grid power was more expensive.

An analysis based only on average demand and average supply made storage appear less useful because the averages removed the moments in which flexibility mattered. Simulation restored the sequence: periods of excess supply, later periods of scarcity, and changes in price. Under the simplified classroom assumptions, storage reduced expected operating cost even after its modeled cost was included.

That result produced another aha moment for me. The asset's value did not come from improving the average hour. It came from preserving options across different states of the world. The same principle can apply to liquidity reserves, lines of credit, phased investments, staffing capacity, or alternative suppliers. Something that looks inefficient in the average case may have economic value when timing, volatility, and downside exposure are included.

The case also showed why scope matters. A classroom model can simplify strategy, time period, financing, maintenance, permitting, safety, and other real-world considerations to teach one concept clearly. A consequential business decision would require a more complete model, documented omissions, sensitivity testing, and review by people who understand the operation. The simplicity of a teaching model is useful as long as no one mistakes it for a production recommendation.

Python made the analysis practical and inspectable

We performed the Week 6 work in Jupyter Notebook, an interactive workspace that keeps explanatory text, Python code, calculations, charts, and results together. That format helped me follow the reasoning from an assumption to the resulting decision. It also made it easier to identify where professional judgment entered the analysis.

Python changed what was practical. A person could calculate one simulated scenario manually, but the course asked what happened across thousands of possible scenarios and many alternative decisions. Python applied the same rules repeatedly, recorded the results, and allowed us to rerun the analysis when an assumption changed. That combination of speed, consistency, and reproducibility made the analysis possible at a useful scale.

The libraries served different purposes. NumPy generated the random values used in the simulations. SciPy, pronounced sigh-pie, supplied the optimization capability. Matplotlib and ipywidgets helped turn the results into charts and interactive views. Introducing those tools by function matters because the code was not ornamental. Each one performed a specific part of the analysis.

These tools did not make the analysis automatically accurate. Python executed the assumptions quickly and consistently, but people still had to decide whether the data, probability distributions, cost relationships, objectives, and constraints represented the business problem. The code made those choices executable and reviewable. It did not make them correct.

Optimization makes priorities explicit

Simulation asks how a chosen action performs under uncertain conditions. Optimization asks which feasible action best satisfies a defined objective. In the Week 6 marketing exercise, the class considered how to allocate a limited budget across several channels with diminishing returns. Early spending in a channel produced more incremental benefit than later spending, so the preferred allocation changed as the available budget changed.

SciPy is a Python library for scientific computing. Its scipy.optimize.minimize() function allowed the notebook to define what should be minimized, add limits and constraints, and search efficiently for the best modeled allocation. Because the function minimizes by default, the exercise represented a goal of maximizing useful customer acquisitions by minimizing the negative of that outcome.

This is where optimization became a governance question for me. An answer can be optimal only relative to the objective, inputs, and constraints that people selected. If the objective rewards volume but ignores customer quality, the optimizer can pursue the wrong outcome. If the model omits a contractual commitment, minimum service level, liquidity reserve, concentration limit, or implementation capacity, the mathematically preferred allocation may be infeasible or irresponsible.

Finance may care about return, liquidity, resilience, compliance, and operational continuity at the same time. Some considerations can be represented in the objective, which is the mathematical expression of what the model is trying to improve. Others belong in constraints, approval requirements, or human review. Deciding where each consideration belongs is not a minor coding choice. It determines which tradeoffs the model is permitted to make.

The visualization that changed my understanding

My strongest aha moment in the optimization module came from an interactive budget visualization. The notebook used a slider that recalculated the modeled allocation as the budget changed. I could watch the recommended mix move as another dollar became more valuable in one channel than another. Diminishing returns stopped being an abstract curve and became a visible decision process.

I found that extraordinarily useful. A static output can show how to allocate one budget. The interactive view showed how the answer changed across many possible budgets and why. That resembles planning in practice. Budgets are revised, projects move, and funding arrives in stages. Leadership often wants to know what changes when the available amount increases, decreases, or arrives later than expected.

The visualization also creates a better conversation between technical and business teams. A reviewer can see where returns flatten, where a constraint begins to bind, and where a small change causes the model to reallocate resources. Those points should prompt questions about the underlying economics. They should not be treated as instructions to accept the output without challenge.

The multi entity liquidity application I would build

My own application would begin with corporate liquidity across multiple related entities. In previous roles, I worked in both property and corporate accounting, including environments where a central organization monitored cash and supported the accounting and funding needs of several subsidiaries. The decision was more complex than determining whether one property project deserved capital. Finance had to understand which entities needed cash, when they needed it, which obligations had priority, and which funding sources were available.

A simulation could create multiple versions of future cash activity by changing the timing of collections, disbursements, project draws, financing costs, and unexpected expenses. An optimization model could then evaluate how limited liquidity should be allocated among the entities in each modeled environment. The objective might be to reduce borrowing costs and unnecessary idle cash while protecting required operating balances.

The model would also need constraints that reflect the real organization: payment deadlines, payroll and debt obligations, credit limits, approved budgets, funding eligibility, contractual requirements, and any restrictions on transferring cash between entities. A funding plan with the lowest modeled cost would not be usable if it left an entity unable to meet an obligation or relied on a transfer the organization could not make.

Accounting would provide much of the evidence needed to make that model credible. The analysis would require reconciled cash balances, reliable forecasts, clear entity mappings, documented commitments, and support for the restrictions encoded in the model. Treasury and operations would need to validate timing and feasibility. Leadership and the designated decision owners would define the acceptable risk, approve the tradeoffs, and authorize the movement of funds.

This is a hypothetical application inspired by my professional experience, not a claim that a former employer used this particular model. It illustrates why simulation and optimization are relevant to accounting and finance. We already explain where cash went, what remains committed, which restrictions apply, and how actual results compare with plan. These methods add a forward-looking question: given uncertainty and limited liquidity, which funding plan best supports the approved objective without violating the controls that make the decision real?

Portfolio optimization added another caution

The portfolio exercise showed that an asset cannot always be evaluated in isolation. An investment with a lower expected return or higher individual volatility may still improve a portfolio when its returns do not move in the same way as the other holdings. The efficient frontier represented the best modeled combinations of expected return and risk available under the assumptions and allocation rules.

The notebook calculated historical returns and relationships among the investments, then used optimization to minimize portfolio volatility for different target returns. The resulting curve was informative, but it depended on the selected data and period. Past relationships can change. A portfolio positioned on the modeled frontier can therefore become inefficient when market conditions, correlations, or expected returns change.

That limitation reinforced the broader lesson. Optimization can organize a complex tradeoff and identify a mathematically efficient set of choices. It cannot guarantee that the future will resemble the data used to construct the result. The analysis needs sensitivity testing, updated evidence, defined risk limits, and human judgment about whether the modeled relationships remain credible.

What finance and leadership must own together

The decision to rely on simulation or optimization cannot belong only to the people who write the code. Accounting and finance should help define the economic outcome, the cost of error, the time horizon, the data cutoff, and the assumptions that affect cash, earnings, capital, or risk. They should also establish how the inputs will be traced, reconciled where appropriate, and compared with actual results.

Model builders should explain how uncertainty was represented, why the selected distributions and functions were reasonable, how the optimizer was configured, whether it completed successfully, and how sensitive the result is to changed assumptions. Operations should confirm that the modeled choices are feasible. Legal, compliance, risk, tax, or other specialists may need to validate constraints that accounting and finance cannot determine alone.

Leadership and the designated decision owners must approve the objective, risk appetite, and permitted use of the output. They must understand what the model omits and remain accountable for the action. If a model recommends fewer staff, a different funding allocation, or a changed investment mix, the consequences do not transfer to Python. The organization still owns them.

My work in cash management, funding, loan draws, reporting, reconciliations, budgets, and internal controls shapes this view. A calculation becomes ready for a decision when the organization can connect it to evidence, timing, authority, and follow-up. The sophistication of simulation and optimization increases the need for that chain. It does not reduce it.

My practical standard before relying on the result

Before a simulation or optimization model influences a financial or operating decision, I would expect the analysis to answer six questions.

1. What decision is being made? Define the action, decision date, time horizon, level of detail, and person or group authorized to approve it.
2. What outcome is the model trying to improve? State the objective in economic terms and explain what the model rewards, what it ignores, and how success will be measured.
3. How is uncertainty represented? Identify the variables that can change, the evidence supporting their ranges or distributions, the dependencies among them, and the consequences of being wrong in each direction.
4. Which constraints make the solution real? Document budgets, capacity, timing, reserves, contracts, funding eligibility, policy limits, safety requirements, and other rules the decision must satisfy.
5. Can the result be reproduced and challenged? Retain the data sources, assumptions, code version, random seed where relevant, completion checks, sensitivity results, and evidence of independent review.
6. How will the organization monitor the action? Compare expected and actual results, investigate exceptions, approve overrides, revisit assumptions, and define when the model should be recalibrated, limited, or suspended.

These questions do not make every decision safe, and they do not turn an accounting professional into a data scientist. They create a common language for accounting, finance, technical teams, operations, and leadership to decide whether a modeled answer is relevant, feasible, and supportable.

The learning I will carry forward

Week 6 changed how I interpret an analytical recommendation. A forecast, simulated expected value, or optimized allocation is not the end of the analysis. It begins a decision process that must connect uncertainty, economics, constraints, evidence, and authority.

The staffing exercise showed why an average can support the wrong action when costs are asymmetric. The energy-storage case showed that flexibility can create value in the moments an average removes. The marketing notebook showed me how diminishing returns can shift an allocation as a budget changes. The portfolio exercise showed that an efficient answer remains conditional on historical relationships and model assumptions.

The practical question I will bring into accounting and finance work is not simply whether a model can simulate or optimize. I want to know what decision it supports, how the cost of error was measured, which constraints were included, what evidence makes the assumptions credible, and who remains responsible for acting.

Prediction estimates what may happen. Simulation shows how uncertainty changes the economics. Optimization identifies the best feasible choice inside the model. The organization still has to decide whether that modeled choice deserves to become a real one.

The Decision Reliance Framework

The Decision Reliance Framework helps accounting, finance, technical teams, operations, and leadership determine whether a modeled recommendation is relevant, supportable, and ready for authorized action.

The six reliance questions

Companion Practical Resource

Practice Guide No. 006 - The Decision Reliance Review is a practical review for accounting and finance professionals evaluating a simulation or optimization model before its recommendation influences a financial or operating decision.

Sources and learning note

This article reflects my personal interpretation of concepts studied in the simulation and optimization portion of the AI for Business & Finance Certificate Program offered by Columbia Business School Executive Education. It is an independent reflection and does not imply endorsement by Columbia Business School, its faculty, the program's collaborators, NineDot Energy, or any other organization.

The classroom examples discussed include call-center staffing, pension-liability reasoning, an energy-storage case, marketing-mix optimization, and portfolio efficient frontiers. References to Python libraries and functions identify the analytical workflow. Course code, slides, transcripts, datasets, case text, and proprietary instructional language are not reproduced. The multi-entity liquidity application, personal reflections, and Figure 1 are my own interpretations.

Related Knowledge Hub materials

This article continues my exploration of how accounting and finance professionals can use emerging technologies while preserving evidence, governance, controls, professional judgment, and accountability.

About the author

Valentina DuPont, CPA is an accounting and finance professional with experience in financial reporting, month-end close, reconciliations, cash management, internal controls, audit support, and process improvement. Through the Knowledge Hub, she explores how professional judgment, governance, and emerging technologies intersect in modern finance.