Decide whether to buy finance software that needs an unreleased feature

A product roadmap can be useful evidence of a vendor's direction, but it is a weak substitute for a capability the finance team needs at launch. When a proposal depends on an unreleased feature, describe the exact work that cannot be completed today. Avoid accepting a broad label such as advanced reporting when the requirement is a specific allocation or export.

Ask the vendor to show the currently available workflow. Record the version, plan and configuration used. If the presenter switches to a prototype or a special demonstration environment, identify that change explicitly. The prototype may be informative, but it does not establish what your company can buy and operate now.

Define the consequence of the gap. It might add a manageable manual step, prevent a required report or make the proposed launch impractical. The purchase decision should depend on that consequence rather than on how compelling the future demonstration appears.

Ask what the vendor means by planned, preview, early access and generally available. Confirm who can use the feature, in which regions and plans, and under what support terms. Similar labels can have different meanings across vendors and even across products from the same vendor.

Microsoft's Power Platform guidance says its preview features can have restricted functionality, separate terms and no production support, and are not intended for production use. That is a specific example of why a preview should be reviewed on its own terms. It is not a definition that can be applied automatically to another vendor's program.

Request the documentation associated with the exact feature, not a general roadmap presentation. Note any limits on data, users, integrations or continuity when the preview ends. Those limits may matter more to the finance process than the feature's expected release month.

Ask whether the eventual feature is included in the quoted plan or whether its price remains undecided. Availability and affordability are separate conditions. The company should not assume that a feature shown during selection will be usable under its existing commercial package.

Create a short requirement record and ask the vendor to review it. A requirement can be met by existing functionality, an agreed implementation task or a future product change. Keep those categories visible when comparing quotes, since their delivery risk and ownership differ.

For a future feature, specify the acceptance example that would demonstrate the requirement. A promised consolidation capability, for instance, may still leave your particular currency, ownership or elimination needs unresolved. The example should describe the business output rather than prescribe an unsupported technical design.

Record the date on which the team must decide whether the feature is usable. That decision date should precede any irreversible project dependency. Waiting until the planned launch to discover that the released feature is narrower than expected can make a modest gap expensive.

If the company can operate without the feature temporarily, describe that process in enough detail to estimate it. Identify the people, files, reviews and reconciliations required. Ask whether it creates data that can later move into the released feature or whether staff will need to rebuild the history.

In a hypothetical example, an interim report takes four hours each week to prepare and review. Over thirteen weeks, that is 52 hours. If the feature is delayed by another quarter, the same workload adds another 52 hours. Treat those hours as a capacity requirement before translating them into a cost using your own approved assumptions.

Include the effort to retire the workaround. A spreadsheet used for several months can become part of a critical reporting process. The transition needs a comparison of results, clear ownership and a date after which staff stop updating both versions.

Reject an interim process that depends on unsupported access, unexplained adjustments or a person whose capacity has not been agreed. A workaround can be reasonable, but it must be a process the company is prepared to own.

The practical choices are often to buy now with an acceptable fallback, defer the purchase until the capability is demonstrated, or select an alternative. Compare them using the same business requirement and timing. Deferral also has a cost if the current system creates continuing problems.

Ask the vendor which commercial commitments it is willing to make in the actual agreement. A salesperson's forecast, a published target and a contractual delivery obligation are different forms of evidence. Have the appropriate commercial or legal reviewer assess material terms rather than assuming a roadmap slide creates a remedy.

Avoid making the whole decision depend on a precise release date when the business can frame a more useful condition. For example, the company might proceed only if the current product supports a documented manual process and the cost remains acceptable for six months. That is an internal buying rule, not a prediction of the vendor's release.

If no workable option meets the deadline, make that finding explicit. The attractive parts of the product do not remove a missing capability that is essential to the company's operation.

When the feature becomes available, run the original acceptance example on the purchased configuration. Check its limits, permissions, outputs and support status. A release announcement establishes availability; it does not prove the feature satisfies your particular requirement.

Update the decision record with the observed result and any remaining manual work. Assign the transition from the interim process, including the treatment of historical data and the removal of obsolete files or integrations through the company's normal controls.

The roadmap should inform the purchase without concealing what is missing today. A clear fallback, a decision date and a concrete acceptance example make the uncertainty manageable.