Understanding How the Aggregated Forecast Editor Works
This article explains how to use the multi-unit forecast editor and understand its behavior when editing forecasts at an aggregated level, whether in units, revenue, cost, weight, or any other business unit.
👉 At this stage, you are already familiar with editing forecasts in units at any level of aggregation using the Forecast Edition tool.
We will now explain how editing works in units other than physical units, and why the final result may sometimes slightly differ from the value you enter.
Use case: multi-item forecasts for a customer
In the example below, several items are sold to the same customer, Customer 1.
Each item has master data attributes, including a unit price, which we will use to illustrate how the platform behaves.
Editing forecasts in units
Detailed view (item level)
On the platform, you first see item-level forecasts, expressed in units.
Aggregated view (customer level)
When aggregating the data at the customer level, a single row appears for Customer 1, representing the sum of all item units.
Editing an aggregated value
If you edit the aggregated cell (for example 969 units) and replace it with 1500:
the 1500 units are automatically distributed across the underlying items,
the allocation follows the initial volume structure,
the sum of all items always equals exactly 1500.
💡 You can also enter a percentage (e.g. +110%, 95%) to increase or decrease the original value.
✔️ Key rule
Whatever value you enter at the aggregated level in units, the sum of the underlying items will always exactly match the requested value.
Switching to revenue view
When switching the display to revenue, the platform automatically calculates values based on unit prices and volumes.
In this example:
the total for 05/2025 is $616,400,
this amount is distributed across 4 items.
When aggregating by customer, a single row appears for Customer 1 with this total.
Editing an aggregated revenue value
If you replace $616,400 with $900,000, the platform:
redistributes the $900,000 across the items,
while ensuring that the resulting volumes remain whole (integer) units.
👉 In this example, the final result displayed is $899,496, not exactly $900,000.
Why can the final total differ from the entered value?
This behavior is expected and intentional.
It is related to the allocation algorithm used for any unit that has a multiplier attribute (price, cost, weight, etc.).
How the allocation algorithm works
Each item represents a percentage of the original total (e.g. $616,400).
The platform applies these percentages to the new requested total ($900,000).
The resulting values are converted into units.
Units are rounded to ensure integer quantities.
The final units are converted back into values (revenue, cost, etc.).
The actual coherent total, based on whole units, is displayed at the aggregated level.
📌 Important to note
The difference between the requested value and the final allocated result is highly dependent on your price master data (unit prices, item mix, price dispersion, etc.).
Best practices
✔️ Use unit-based editing when total accuracy is critical.
✔️ Use value-based editing to manage high-level financial targets.
✔️ Interpret small differences as a guarantee of operational consistency, not as an error.
Need help?
If you have any questions or want to explore a specific use case,
👉 contact us via the in-app messenger — our team is here to help.