← Back to blog

What-If Analysis for Pricing That Protects Cash

Published by Shekl

A 6% price increase can improve gross margin on paper and still leave next month's bank balance lower than plan. The reason is usually timing: a customer delays renewal, a processor holds a larger reserve, a discount is extended to save a deal, or payroll lands before the first higher-priced invoice is collected. What if analysis for pricing is useful only when it models those operating mechanics, not when it applies a percentage change to a revenue line.

For an owner or CFO, pricing is a cash-flow decision as much as a commercial one. The right question is not simply, "What happens if we raise prices?" It is, "What happens to cash by day, margin by customer, collections by cohort, and runway if we change price under realistic customer behavior?"

Why pricing scenarios fail in ordinary spreadsheets

Most pricing models begin with a current monthly revenue figure and multiply it by a proposed price change. That produces a clean answer quickly. It also assumes every customer accepts the change, invoices are issued immediately, collections are unchanged, processor fees scale neatly, and no contract or billing-cycle constraints exist.

Those assumptions are rarely true. A B2B company may have annual contracts that cannot be repriced for nine months. A services business may need to discount an expansion project while increasing standard rates. A subscription company may see upgrades improve average revenue per account but increase churn among price-sensitive monthly customers. Each outcome has a different effect on booked revenue, accounts receivable, and bank cash.

The spreadsheet problem is not that formulas are incapable. It is that the model often becomes detached from the reconciled ledger. Inputs get copied from a prior month, collections are represented as a single percentage, and a scenario cannot be traced back to the invoices, settlements, payroll runs, or vendor bills that make the forecast credible.

A usable model starts with a financial baseline that is reconciled to $0.00. Every projected price change should inherit real payment terms, actual settlement lags, known renewal dates, processor fees, sales-tax treatment where applicable, and the timing of related delivery costs. Without that foundation, a pricing scenario is a forecast-shaped opinion.

What a pricing scenario must model

A pricing decision affects more than the unit price. It changes a connected set of assumptions, and those assumptions need to be explicit, versioned, and replayable.

Price realization, not the list price

Start with the amount customers actually pay. The list price may rise 10%, while realized price rises 4% after grandfathering, negotiated concessions, channel fees, promotions, or credits. Segment the change by customer type, product, contract start date, and billing cadence where those distinctions materially affect the result.

For example, an annual customer renewing in October does not contribute higher cash in April merely because a new price card takes effect in April. A monthly customer billed through a processor may contribute higher gross billings immediately, but the available cash may arrive several days later after processing fees and reserve movements.

Volume and retention response

Demand response is an assumption, not a fixed law. A modest price increase may have no measurable effect in a mission-critical category, while a similar increase can materially reduce conversion in a competitive market. Model a range rather than one definitive churn or win-rate number.

A practical scenario commonly includes a base case, a favorable case, and a downside case. The cases should differ in defined inputs: new-customer conversion, expansion rate, logo churn, downgrade rate, or average units per order. They should not be three unexplained revenue totals.

The cash collection calendar

Revenue recognition and cash receipt are different events. If an invoice is issued on the first of the month with net-30 terms, a price increase affects receivables before it affects bank cash. If customers routinely pay 12 days late, the forecast should use that observed behavior unless there is evidence it has changed.

This is where direct-method cash forecasting matters. Instead of inferring future cash from projected net income, the model projects the expected dates and amounts of cash entering accounts, then places those receipts alongside payroll, rent, debt service, taxes, card payments, and vendor disbursements. The result answers the operational question: can the company fund the transition while the pricing change takes effect?

Costs that move with price or volume

Some price changes increase cash costs. A higher transaction value can increase percentage-based processing fees. More sales may require commissions, onboarding labor, support capacity, inventory, shipping, or usage-based infrastructure. If the new price is paired with a better service tier, the incremental delivery cost belongs in the scenario.

The reverse is also true. A lower price intended to increase volume may improve total contribution margin if fixed costs are already covered and variable costs remain controlled. That is why pricing cannot be judged solely by gross revenue or gross margin percentage.

Build what-if analysis for pricing from the ledger outward

The workflow should preserve a clear distinction between actuals and assumptions. Actuals come from reconciled bank activity, card feeds, payment processor settlements, invoices, bills, and the general ledger. Scenario inputs are controlled changes applied to that baseline. When those layers are mixed, finance teams cannot explain whether a variance came from a real transaction or a planning assumption.

First, establish the starting position: current cash by account, open invoices, expected settlement receipts, scheduled payroll, recurring bills, debt obligations, and the current forecast horizon. Reconciliation is not housekeeping here. It ensures the opening cash balance is real before a pricing decision is evaluated against it.

Next, define the commercial rule. Specify which customers receive the new price, when it begins, whether existing contracts are protected, what discount authority remains, and which products are affected. Then define behavioral assumptions by segment. A CFO may set different renewal probabilities for enterprise customers, monthly self-service accounts, and channel-sold accounts because they have different buying patterns and collection behavior.

Then translate the rule into invoice and cash events. A price effective on July 1 may produce invoices on July 1, August 15, or January 1 depending on billing schedules. Those invoices should flow to projected cash receipts according to contractual terms and observed payment timing. Processor-backed sales should reflect gross charges, fees, reserve activity, and settlement dates rather than a single net-sales estimate.

Finally, compare each case against explicit operating thresholds. The objective may be to maintain a minimum cash buffer, avoid drawing on a line of credit, preserve a target payroll coverage period, or fund a planned hire. A scenario that improves annual EBITDA but breaches the cash floor in week six is not a successful plan without a bridge strategy.

Read the output as a decision, not a chart

A strong pricing model makes trade-offs visible. Consider a company with $180,000 of monthly subscription billings, 3% processor fees, and a recurring payroll of $110,000 twice each month. It proposes an 8% increase for new customers immediately and for renewals beginning in 60 days.

The base case may show realized revenue rising 5% by month three, with cash improving only after the second settlement cycle. The downside case may assume a 3-point increase in monthly churn and slower collections from a subset of larger accounts. If that case pushes cash below the minimum buffer before renewals convert, the decision is not necessarily "do not raise prices." It may mean phase the increase by cohort, tighten collection activity, postpone a discretionary outflow, or secure working capital before launch.

The most useful outputs are usually a day-level cash forecast, a customer-segment view of realized price and retention, a margin bridge, and a variance view that compares scenario assumptions with actual outcomes after launch. Finance should be able to click from a projected settlement to the expected underlying invoices, and from a forecast variance to the transactions that caused it.

That traceability changes the operating rhythm. Rather than debating whether a forecast is "right," the team can ask which assumption failed, whether payment timing changed, and what action is available before the next payroll date.

Controls that keep the scenario credible

Pricing scenarios become unreliable when they are edited freely without an audit trail. Use controlled assumptions with effective dates, owners, and documented rationale. Preserve the original case when a new case is created. Keep actual ledger activity separate from scenario overlays, and ensure the calculation can be replayed from its source transactions and rules.

Shekl applies this discipline by joining reconciled accounting data with direct-method cash forecasting and scenario controls. A pricing assumption can be evaluated against the actual timing of invoices, processor settlements, payroll, and bills, while every result remains traceable to its rows. AI may assist analysis outside the calculation path, but it should never override the deterministic replay that produces the financial answer.

A pricing change is a commitment made before all of its consequences are visible. The right model does not remove uncertainty. It puts uncertainty into named, testable assumptions and shows exactly how each one reaches the bank balance. That gives finance a practical way to set price with evidence, monitor the result, and intervene while there is still time to protect cash.