Pigment version management gives finance teams a way to organize plans, forecasts, and what-if cases so they can compare possible outcomes without confusing a working forecast with an approved plan. The key is not to create as many versions as possible. It is to define what each version means, keep the assumptions comparable, and make it clear who can change or approve it.

Talk with Amvent about your planning model

For a finance leader, the practical question is: how can the team compare scenarios in Pigment and still know which figures are current, which assumptions changed, and which version should guide a decision? The answer starts with a simple operating design. Establish a controlled baseline, create scenarios for specific decisions, compare them on shared dimensions, and record what changed and why.

This article focuses on the planning approach and governance behind version management. Actual functionality depends on how your Pigment environment is configured, your data, and the access rules your organization establishes. Treat the steps below as a design framework, then validate the implementation details in your own model.

What does version management mean in a planning model?

A version is a named set of planning values and assumptions that represents a particular state or purpose. Common examples include an approved budget, the current forecast, a prior forecast snapshot, and a scenario created to test a specific decision. A scenario is a purposeful alternative, such as slower hiring or a different sales outlook. Teams may represent these concepts through versions, scenario inputs, or another model design; the important part is that everyone understands the distinction.

Version management is the set of rules that keeps those states usable. It covers naming, ownership, time periods, source data, assumptions, change history, review, and how a version is selected for reporting. Without those rules, a planning tool can hold multiple sets of numbers while leaving people unsure which one is authoritative.

It helps to separate three ideas:

• Baseline: the approved or otherwise agreed reference point against which alternatives are assessed.

• Scenario: a deliberate variation used to answer a business question. It should identify the assumptions that differ from the baseline.

• Snapshot: a preserved view of a plan at a defined point in time, useful for explaining how the outlook changed between review cycles.

A scenario is not automatically a forecast, and a snapshot is not automatically an approved plan. State these distinctions in plain language before building the model. For additional background on selecting a planning platform and defining its role, see Amvent’s guide to EPM platform evaluation and its EPM selection criteria.

Which planning question should each scenario answer?

Start with the decision, not the version name. A useful scenario responds to a question a leader might act on: What if hiring is delayed by one quarter? What if renewal rates soften? How much cash runway remains if planned investment rises? A scenario with no decision attached can become another competing forecast that adds work without helping the business choose.

Write a short scenario brief before adding it to the model. Include the decision owner, the question, the assumptions that change, the assumptions that remain fixed, the period covered, and the review date. If two scenarios answer different questions, give each a distinct purpose rather than combining them under a broad label such as “downside.”

For example, a finance team may need to assess whether a delayed hiring plan changes the expected cash position. One case could shift start dates for a defined group of open roles. Another could test a lower bookings assumption. If the team changes both hiring and bookings in a single case, the output may show a larger cash impact, but it will be harder to identify which assumption drove it. Separate cases first; combine them later if leadership needs a compounded downside view.

Scenarios work best when they are tied to the planning domains and workflows the business actually uses. Amvent’s planning use cases provide a starting point for considering where a model might support finance and adjacent teams. For a broader look at how use cases can expand across functions, read about a gradual path to connected planning.

How should teams structure versions and scenario names?

A naming convention should make a version’s purpose and status visible without forcing users to inspect its contents. Include only the details people need to identify it. A practical pattern could combine the planning cycle, version type, scenario driver, and date or review round. For example: “FY27 Forecast – Base – October” and “FY27 Forecast – Hiring Delay – October.” The exact format matters less than applying it consistently.

Do not make a scenario name carry every piece of context. Keep a short description alongside it that states the question, owner, assumptions changed, and status. Agree on a controlled vocabulary for status terms such as working, in review, and approved. Avoid names like “New,” “Final,” or “Final v2,” which become ambiguous as soon as another update arrives.

Define how the team will handle recurring cycles. Decide when a new forecast cycle starts, what happens to the previous working forecast, and whether the prior view needs to be preserved for comparison. Also decide how long temporary scenarios remain active. Retire or archive them according to a clear rule, rather than leaving every experiment available as if it were a current planning option.

These choices affect model design, reporting, and user access. They should be included in requirements gathering rather than settled informally after the model is built. See Amvent’s EPM requirements-gathering guide for ways to turn planning needs into explicit design decisions.

How can finance compare scenarios on a like-for-like basis?

A comparison is only useful when the versions share a clear basis. Before reviewing the results, confirm that the scenarios use the same reporting period, currency treatment, organizational structure, metric definitions, and relevant source data. If one case covers a different time horizon or uses a different definition of revenue, a simple side-by-side display can create false confidence.

Then separate the assumptions that change from those that stay constant. The team should be able to explain what was held equal and what was varied. If a case changes hiring, pricing, and churn at once, mark that explicitly. If leaders want to understand the effect of each driver, test one change at a time before considering the combined impact.

Choose a short list of outcome measures that connect to the decision. Depending on the question, that might include revenue, expense, headcount, margin, cash, or another agreed planning measure. Avoid comparing every available metric by default. A focused view helps decision-makers see the consequences that matter and follow the assumptions behind them.

When the model produces a difference between two versions, do not stop at the headline variance. Trace it to the driver or combination of drivers that caused it. Confirm whether the result is an intended consequence or a sign of inconsistent inputs. A useful review view makes it possible to move from the outcome to the assumption and then to the person who can explain it.

Teams considering how to assess model dimensions and detail may also find Amvent’s article on multi-dimensionality in planning systems useful. The goal is not maximum detail. It is enough structure to answer the decisions the business needs to make.

What governance keeps scenarios trustworthy?

Version governance should fit the risk and pace of the planning process. A small set of named owners can maintain definitions and approve changes to the baseline, while operational users contribute inputs within agreed boundaries. The same person does not need to approve every working assumption, but the organization should know who has authority to change an official plan and who can publish or share a reviewed result.

Make these responsibilities explicit:

• Scenario owner: frames the question and explains the proposed assumptions.

• Input owners: provide or validate assumptions for their functional area.

• Finance reviewer: checks consistency, model logic, and interpretation of outputs.

• Decision owner: evaluates the trade-offs and decides whether the result changes a plan or action.

• Model administrator: maintains the configured structure and access according to the organization’s controls.

Use access rules that match those responsibilities. Users should be able to contribute the inputs they own without unintentionally changing shared assumptions or an approved reference. Make review and approval steps clear, and document how exceptional changes are handled. Do not assume that a label such as “approved” is sufficient control by itself; establish the process and permissions that give the label meaning in your environment.

Keep a record of material decisions. At minimum, capture the scenario’s purpose, assumptions changed, owner, review date, decision, and any follow-up action. Where your environment supports relevant history or audit information, decide what needs to be retained and who reviews it. The precise controls depend on your configuration and internal policies.

Version controls also need to fit the way people work. A process that requires too many approvals for every small update may encourage users to work outside the model. A process with no clear checkpoints can make it difficult to trust an output. Establish a light, repeatable path for ordinary planning changes and a more deliberate review for changes that affect a formal forecast or decision.

Because clear responsibilities influence adoption, include them in rollout planning. Amvent’s guide to EPM change management discusses how teams can make new planning practices usable, not just technically available.

How can teams run a repeatable scenario review?

A consistent review meeting turns a set of model outputs into a decision. Use the same sequence each cycle so participants can focus on what changed instead of relearning the process.

1. Confirm the baseline. State which approved or current forecast is the point of comparison and when its underlying data was refreshed.

2. Restate the question. The scenario owner explains the decision the case is intended to inform.

3. Review changed assumptions. Identify the inputs that differ, their owners, and the rationale for each change.

4. Check comparability. Confirm that timing, scope, metric definitions, and other shared inputs are aligned.

5. Discuss outcomes and trade-offs. Focus on the agreed measures and trace material changes back to their drivers.

6. Record a decision and next step. Capture whether to act, gather more information, revise assumptions, or close the scenario.

For example, if a downside case shows lower cash than the baseline, the group should ask what caused the difference, whether the driver is plausible, and whether management has an action that could change the outcome. If the answer depends on an unverified assumption, record that uncertainty instead of presenting the case as a precise prediction.

Prepare the review view before the meeting. Show the baseline and scenario using the same measures and period, then highlight only the material variances. Add a concise note beside each major variance that points to its underlying driver. If the reason for a difference cannot be explained from the model or the documented assumptions, flag it for follow-up rather than asking the group to infer the cause. This preparation keeps discussion on decisions, not on reconciling competing spreadsheets during the meeting.

Close the review by assigning an owner and due date to each follow-up. If an assumption needs validation, record who will confirm it and whether the scenario should remain open while that work happens. If a leader chooses an action, state whether that action changes the formal forecast, creates a new scenario, or remains a separate operational response. These small distinctions make it possible to understand later why the plan changed and which decision led to the change.

Separate scenario exploration from formal forecast submission when the two serve different purposes. Exploration allows teams to ask “what if?” A formal forecast communicates the team’s current view under agreed assumptions and review. The distinction helps prevent every exploratory case from being mistaken for a commitment.

What common version-management mistakes should finance avoid?

• Creating a version for every conversation. Keep scenarios tied to named questions and owners. Otherwise, the model becomes a list of unexplained alternatives.

• Overwriting the only reference point. Preserve a clear baseline or snapshot when the business needs to explain how an outlook changed.

• Comparing unlike periods or definitions. Align the comparison basis before interpreting a variance.

• Changing several drivers without documenting them. Record what moved and why, or the result cannot be explained with confidence.

• Treating a scenario as a promise. Label exploratory cases clearly and distinguish them from an approved plan or forecast.

• Leaving ownership implicit. Name the person accountable for assumptions, review, and decisions.

• Keeping stale cases indefinitely. Define how scenarios are reviewed, retired, or retained for reference.

• Designing controls only for administrators. Make the process understandable to contributors and decision-makers who use the outputs.

These risks are easier to address when version rules are designed alongside the wider model, integrations, and operating process. For a view of the implementation work involved, explore Amvent’s Pigment implementation methodology and its overview of Pigment implementation consulting.

How should finance teams put version management into practice?

Begin with a short workshop involving finance, planning contributors, and the leaders who use the forecast. Map the current planning cycle and list the situations where teams need alternatives: a formal forecast, a prior-cycle comparison, a sensitivity test, or a cross-functional decision. For each, describe the owner, purpose, relevant inputs, decision date, and expected output.

Next, agree on a small set of version types and names. Define the baseline, the scenarios the team expects to create, and the circumstances that justify a new one. Establish which assumptions are shared and which belong to a scenario. Then decide what access and review checkpoints the organization needs. These agreements should be specific enough to guide configuration, but simple enough for users to follow.

Test the design with a realistic example before scaling it across planning domains. Ask a planner to create a scenario, another user to review it, and a decision-maker to compare its impact with the baseline. Note where users cannot tell what changed, where the comparison is misleading, and where permissions or handoffs are unclear. Adjust the process and model design based on those observations.

Finally, set a recurring review rhythm. At the end of each cycle, identify which scenarios informed a decision, which assumptions proved useful, and what should be retained or retired. That keeps the model focused on active planning questions rather than accumulating versions simply because the technology permits them.

Organizations planning a broader Pigment rollout can also review Amvent’s guide to a Pigment implementation kickoff and its article on implementation timelines. For a broader professional resource for finance practitioners, visit the Association for Financial Professionals.

Frequently Asked Questions

Should every planning scenario become a separate version?

No. Create a distinct version or scenario when it has a clear business question, an owner, and assumptions worth comparing. Small exploratory changes may not need a permanent named version. Agree on a process for preserving cases that inform decisions and retiring temporary work.

How many scenarios should a finance team compare?

There is no useful universal number. Start with the alternatives needed to answer the decision at hand, such as a baseline and one or two defined cases. Add complexity only when it gives leaders a clearer choice. A large scenario set can obscure the main trade-offs.

Should teams compare a working forecast with an approved budget?

They can, if both are clearly identified and the periods, dimensions, and metric definitions are comparable. The comparison answers how the current outlook differs from the approved plan. It does not mean that the working forecast has replaced the budget or received approval.

What should a scenario review document?

Record the question, owner, assumptions changed, baseline used, review date, key outcomes, decision, and follow-up actions. Include material caveats or unresolved inputs so readers do not mistake an estimate for a settled commitment.

Discuss your Pigment planning design with Amvent

Well-designed Pigment version management lets finance test alternatives while preserving a clear, trusted reference point. Define the decision each scenario supports, compare consistent inputs, and make ownership and review rules visible before the model grows more complex.