P×Q (Price × Quantity)

The P×Q module forecasts sales revenue by modelling the two drivers behind it: the number of units sold (quantity, or Q) and the selling price per unit (price, or P). You configure these assumptions by product, sales channel and month. Monitr calculates monthly revenue as:

Revenue = Quantity × Price

Use P×Q when revenue can be explained as units multiplied by a unit price. Typical examples are products, licences sold per seat, billable packages, tickets, subscriptions that are not contract-based, and services sold in standard units.

Do not use P×Q for contract-level recurring revenue with customer starts, churn and billing schedules; use Recurring Revenue for that. P×Q and Recurring Revenue are separate modules. They can feed the same reporting structure through their mappings, but a product sale in P×Q does not automatically create or activate a recurring contract.

What the module produces

For every month, Monitr calculates:

• revenue for each product × channel combination;
• total revenue for each product across all assigned channels;
• the P&L impact through the mapping selected for each product × channel combination.

If the scenario also needs variable cost and inventory planning, P×Q is the first module in the chain:

P×Q → COGS → Inventory

COGS uses P×Q quantities as its sales-volume input. Inventory then uses the connected COGS model as its source. This is a required structural chain for those downstream modules, but it is not a continuous synchronisation. See Working with COGS and Inventory before changing an existing model.

Before you start

Prepare the following inputs:

• the scenario in which the budget belongs;
• the first and last month of the forecast;
• a unique, recognisable name for the P×Q budget version;
• the products or product categories to forecast;
• the sales channels used for those products;
• monthly quantities and prices, or the assumptions needed to generate quantities;
• the correct P&L mapping for every active product × channel combination;
• analytical-axis values where product or channel revenue must be split by department, business unit, project or another axis.

Decide the modelling level before creating the module. A highly detailed product/channel structure improves analysis but also creates more monthly inputs and mappings. Use the lowest level that supports the decisions and reporting the business actually needs.

Create or reuse a P×Q budget

1. Open Forecasts and expand the required forecast.
2. Select the scenario in which you want to work.
3. Click Add a budget inside that scenario.
4. Monitr opens Add a new or existing budget. Choose one of the available approaches:
   • Link — reuse an existing budget version while keeping the scenarios connected to that shared version;
   • Copy — use an existing version as an independent starting point;
   • Create a new budget — create a new P×Q module.
5. When creating a new budget, confirm the selected scenario and choose PxQ under the scenario-budget modules.
6. Monitr opens the four-step wizard: Introduction, Model, Mapping and Result.

Use Link only when the same version should remain shared. Use Copy when you want to preserve the current assumptions but allow the new scenario to evolve independently.

Step 1 — Introduction

The Introduction explains that P×Q calculates product revenue from selling price and sales quantity. There are no detailed model inputs on this screen.

Confirm that you opened the module in the intended scenario, then click Next.

Step 2 — Model

The Model step contains the budget range, the product catalogue, global revenue channels and the monthly quantity/price grids.

Set the Budget Range

Choose the first and last month of the forecast under Budget Range. The range determines:

• which months appear in the product/channel grids;
• the available period in Advanced calculation;
• the months displayed on the Result chart;
• the period passed to a downstream COGS module when it is created from this P×Q version.

Review the range before entering data. When an existing or copied model contains values outside the intended range, verify which values are retained or removed before saving.

Choose a starting point

The Model screen provides three practical starting approaches:

1. Enter products manually — use Add Product and give each product a meaningful name.
2. Start from a previous budget — load a previous P×Q version as a starting point and then review its products, channels, range, quantities, prices and mappings.
3. Use an available product integration — where the environment supports this, import the product catalogue from the connected source. Integrated product names may be controlled by the source and therefore not editable in Monitr.

Starting from another version is a copy of assumptions into the working model, not evidence that the values remain synchronised with the source version. Review every imported or prefilled value before finishing the wizard.

Manage products

Use the Products tab to add and maintain the items being forecast.

• Add Product creates another product card.
• Delete Products enables bulk removal of products from the working model.
• Each product needs a recognisable name.
• A product can use one or more of the global channels defined in the Channels tab.
• The overflow menu on a product provides Copy channels to other products, which is useful when several products use the same channel structure.

Before deleting a product, check whether the product already feeds COGS or Inventory. Removing or replacing an upstream product can break the intended product match in downstream modules.

Manage channels

Revenue channels are global within the P×Q budget version. Define them once in the Channels tab and assign the relevant channels to each product.

Examples include:

• Direct Sales;
• Reseller;
• Online;
• Retail;
• Belgium / Netherlands when geography is treated as a sales route.

Use Add Channel to create a channel and give it a clear name. A product may subscribe to any number of channels. Monitr retains at least one channel in the model, so the last remaining channel cannot be deleted.

Avoid using channels as a substitute for analytical axes when the business already reports the split through departments, projects or entities. A channel should describe how the product is sold; the mapping can add the reporting and analytical classification.

Enter quantity and price

For every active product × channel combination, the monthly grid shows:

• Quantity — units sold in the month;
• Price — selling price per unit for the month;
• Total — Quantity × Price, calculated by Monitr and read-only.

Enter or review both Quantity and Price. The Result chart can look plausible even when one driver is wrong, so always validate the drivers separately.

Recommended checks:

• quantities use a consistent business unit across the product;
• prices exclude or include VAT consistently with the organisation's accounting setup;
• zero quantities are intentional rather than missing inputs;
• price changes begin in the correct month;
• every channel shown on a product is genuinely used;
• product names and channel names remain stable between forecast versions when downstream comparisons depend on them.

Generate quantities with Advanced calculation

Advanced calculation is available on each product-channel row and calculates quantities. It does not replace the need to review or enter monthly prices.

The modal shows the current monthly Quantity row and lets you apply one of four methods.

Absolute value

Use this when quantity changes by a fixed number of units each month.

Fields:

• Start value — quantity in the first month of the selected range;
• Absolute growth — units added to or subtracted from each following month;
• Date range — months to which the schedule applies;
• Pre-fill start value (average) — use the average of the current values as the proposed starting value.

Conceptual calculation: next month = previous month + absolute growth.

Example: start at 100 units and add 20 units per month to produce 100, 120, 140, and so on.

By percentage

Use this for compound monthly growth or decline.

Fields:

• Start value;
• Monthly growth in percent;
• Date range;
• Pre-fill start value (average).

Conceptual calculation: next month = previous month × (1 + monthly growth rate).

A negative percentage models contraction. Check whether the resulting decimals match the operational meaning of the product; round or overwrite individual months when quantities must be whole units.

Seasonal

Use this when annual or period volume is known but demand follows a recurring monthly pattern.

Fields:

• Total value over period — total quantity to distribute;
• Yearly growth — growth applied when the schedule extends into later years;
• Seasonality — a percentage for each month from January to December.

The twelve seasonal percentages should total 100%. Monitr distributes the entered total over the months using that pattern. Review partial first or last years carefully when the budget does not cover complete calendar years.

Fixed value

Use this when the same quantity should repeat throughout a period.

Fields:

• Fixed value for all months;
• Date range;
• Pre-fill start value (average).

This method is suitable for stable run-rate volumes or for establishing a baseline that will be adjusted manually in exceptional months.

Apply and review generated quantities

1. Choose the growth method.
2. Complete its fields.
3. Click Apply to preview the generated Quantity row.
4. Review the monthly values and total.
5. Click Save in the calculation modal only when the preview is correct.
6. Return to the product grid and verify that revenue totals changed as expected.

Do not confuse these four P×Q quantity methods with Linear, Equally spread and Seasonality in the Simple Budget Quick Start flow. They are different screens and calculations.

Step 3 — Mapping

The Mapping step connects every active product × channel combination to the financial reporting structure.

For example, one product sold through B2B and Online produces two separate mapping rows. This is more granular than one mapping per product or one mapping per global channel.

For each row:

1. identify the product and channel shown;
2. choose the correct revenue mapping;
3. select an analytical value where the reporting structure requires one;
4. verify that the mapping belongs to a P&L revenue line;
5. repeat until no active combination remains unmapped.

Use a shared revenue account only when the business does not need financial separation. Use distinct mappings when product lines, channels, entities or analytical dimensions must be reported separately.

Mapping names are entity-specific. Never copy an account number from an example without checking the selected entity and reporting structure. An apparently valid but incorrect mapping can place revenue on a discount, contra-revenue or unrelated income line.

Step 4 — Result

The Result screen shows Revenue by product as a monthly stacked chart. It is a final reasonableness check before saving.

Verify at least:

• all expected products are present;
• the month range is correct;
• no product unexpectedly drops to zero;
• peaks and step changes correspond to the quantity and price assumptions;
• the chart scale is plausible;
• product totals reconcile to quantity × price across their channels;
• the mapping step is complete.

Use Previous to correct the model or mappings. Click Finish only after the checks pass. Finishing saves the P×Q budget version in the scenario.

Working with COGS and Inventory

P×Q, COGS and Inventory form a dependency chain, but the downstream modules do not continuously synchronise after every upstream edit.

Create COGS from P×Q

After a P×Q version has been saved, a COGS module can be created from it. COGS imports the products and monthly quantities and adds cost-per-unit assumptions. Without a saved P×Q version, the COGS option is unavailable for the scenario.

Important: later P×Q changes do not automatically update COGS

When you change quantities, products, channels or range in an existing P×Q version, do not assume that COGS and Inventory have changed with it.

To refresh the volume basis, COGS must be reopened and initialised again from the required P×Q version. This action can reset existing COGS cost assumptions to zero or otherwise replace downstream inputs. Inventory must then be reviewed and, where required, refreshed again from COGS.

Before reinitialising:

1. record or export the current COGS assumptions;
2. identify the exact P×Q changes and affected periods;
3. confirm which COGS values will be replaced;
4. reinitialise COGS from the correct P×Q version;
5. restore and validate the intended unit costs;
6. review or reinitialise Inventory;
7. reconcile revenue, COGS, gross margin, stock and cashflow.

Never describe this chain as automatic cascading or real-time synchronisation.

Copying, linking and rolling the model forward

For a new rolling forecast:

1. duplicate or create the target scenario;
2. copy the P×Q version when independent assumptions are required, or link it only when shared assumptions are intended;
3. set the new budget range;
4. validate products and channels;
5. update quantities and prices for the new actual/forecast cut-off;
6. verify all product-channel mappings;
7. update or recreate COGS from the intended P×Q version;
8. update Inventory from the intended COGS version;
9. check P&L, Balance Sheet and Cash Flow together.

Preserve stable product and channel names where they are used for operational reconciliation, but do not keep obsolete items merely to maintain visual continuity.

Output and reporting

P×Q posts forecast revenue to the mapped P&L lines. The scenario forecast and revenue analysis can then be reviewed by month and, where supported by the reporting view, by product, channel and analytical axis.

P×Q itself models revenue only. COGS supplies the associated variable cost; Inventory supplies stock movements, Balance Sheet impact and purchase cashflow. Gross margin and cashflow therefore depend on the complete module chain and its mappings.

Troubleshooting

COGS or Inventory is not available

• Save a valid P×Q budget version first.
• For Inventory, a valid connected COGS version is also required.
• Confirm that the modules belong to the intended scenario.

Result chart is empty or unexpectedly low

• Check Quantity and Price separately.
• Check the Budget Range.
• Confirm the product has at least one active channel.
• Check whether the quantity generator was applied to the intended date range.

Revenue appears on the wrong P&L line

• Reopen Mapping.
• Check the exact product × channel row.
• Confirm the account/reporting line and analytical value for the selected entity.

Seasonal results look wrong

• Confirm the twelve month percentages total 100%.
• Check the entered total and yearly-growth percentage.
• Review partial-year behaviour month by month.

A refreshed COGS model lost unit costs

• This can happen when COGS is reinitialised from P×Q.
• Restore the verified unit-cost assumptions from the pre-change record.
• Recheck Inventory after COGS is corrected.

Copied or imported values do not match expectations

• Confirm the source P×Q version and date range.
• Review all prefilled products, channels, quantities, prices and mappings before Finish.
• Do not assume a copied model remains linked unless Link was explicitly selected.

Final validation checklist

Before clicking Finish or approving a P×Q change, confirm:

• ☐ Correct entity, forecast and scenario
• ☐ Correct budget range
• ☐ Clear and unique budget-version name
• ☐ Complete product list
• ☐ Complete global channel list
• ☐ Correct channel assignments per product
• ☐ Quantity reviewed for every product × channel × month
• ☐ Price reviewed for every product × channel × month
• ☐ Advanced calculations applied only to the intended ranges
• ☐ Seasonal percentages total 100% where Seasonal is used
• ☐ Mapping complete for every active product × channel combination
• ☐ Analytical values checked where applicable
• ☐ Result chart reconciled to the driver assumptions
• ☐ Downstream COGS and Inventory impact assessed
• ☐ Any reinitialisation risk recorded before changing an existing chain

Guidance for support teams and AI assistants

An AI guiding a user through P×Q should follow this order:

1. Resolve the entity, forecast, scenario and intended period.
2. Ask what the products are and what one unit means for each product.
3. Ask which channels genuinely require separate prices or reporting.
4. Ask for the monthly price and quantity basis, or choose one of the four supported quantity methods.
5. Show a compact dry-run by product, channel and month or repeated range.
6. Calculate revenue as quantity × price only for explanation and validation; use Monitr's result as the saved source of truth.
7. Ask for the mapping for every active product-channel combination.
8. Warn explicitly if a downstream COGS or Inventory version already exists.
9. Never state that downstream modules update automatically.
10. Before any write, show old versus new quantities, prices, revenue and affected months and obtain final confirmation.
11. After saving, reopen or reread the module and verify the changed assumptions and result.

The assistant must preserve untouched products, channels, periods and mappings when editing an existing version. It should never invent product, channel, account, analytical-axis or budget-version identifiers.