In the first forecasting lab, the model was trained using a single revenue series. That was a useful starting point, but it was also a simplified scenario. Real planning environments rarely forecast one revenue stream in isolation. Different business units have different growth rates, revenue scales, seasonality patterns, customer behavior, and market exposure.
For this lab, I wanted to move one step closer to how forecasting works in a real FP&A model. Instead of forecasting one revenue stream, I created five business units: Enterprise, SMB, APAC, EMEA, and Public Sector. Each business unit was given its own revenue scale, growth profile, and seasonality pattern.
The objective was to test whether one forecasting model could learn from all business units together while still recognizing that each business unit behaves differently.
Why Business Unit Context Matters
When multiple business units are combined into one forecasting model, the first challenge is scale and behavior. Enterprise revenue may be significantly larger than Public Sector revenue. APAC may grow faster than EMEA. SMB may have a different seasonal pattern than Enterprise.
If all revenue history is combined without context, the model has no clear way to know which pattern belongs to which business unit. That creates a design issue. The model may learn the overall trend, but it may not properly separate the behavior of each business unit.
To address this, I added a business unit identifier. Each business unit received a numeric ID, and that ID was passed into the model as a static feature. This allows the model to treat business unit identity as part of the forecast context, instead of assuming every revenue series follows the same pattern.
This was one of the main reasons for moving beyond the simple LSTM structure used in the first lab.
Adding Known Future Information
Many forecasting examples only use historical values. Prior revenue goes in, and the forecast comes out. That is useful, but it is not how planning teams think about a forecast.
In a planning process, some future information is already known before the forecast is generated. The team already knows the future months, quarters, fiscal calendar, and whether a period falls in Q4. Those values do not need to be predicted. They are part of the planning calendar.
For this lab, I added future calendar features such as month, quarter, and whether the month falls in Q4. These features were passed separately from historical revenue. This made the setup more realistic because the model was not only learning from prior revenue. It was also using future period context that would already be available in a normal planning cycle.
Forecast Window Design
The model was designed to use 12 months of historical data to forecast the next 3 months. In planning terms, the model looks back one full year and predicts the next quarter.
This was a practical design choice. Twelve months gives the model enough history to observe seasonality. A three-month horizon aligns well with quarterly planning and rolling forecast processes. It also allows the forecast to be reviewed by month, rather than only as one total number.
This structure is closer to how FP&A teams usually work. They need a monthly forecast, but they also need to understand the quarterly impact.
Why I Used a TFT-Style Design
The main change in this lab was replacing the basic LSTM approach from the first lab with a simplified Temporal Fusion Transformer-style design.
The model still uses an LSTM encoder to process historical revenue patterns. However, additional components were added to make the model more suitable for a multi-business-unit planning use case. Static business unit information is included in the model. Future calendar features are processed separately. An attention layer allows the forecast periods to reference useful parts of the historical sequence.
That last point is important. In a basic LSTM design, the forecast depends heavily on the final encoded state of the historical sequence. With the attention layer, the model has a better way to look back across the historical window when generating the forecast. This is useful when seasonality, prior spikes, or recent trend changes matter.
The goal was not to build a production forecasting engine. The goal was to test whether a more structured design could handle multiple business units and future planning context in a better way than a simple single-series model.
Using Huber Loss
Another change from the first lab was the loss function. The first model used Mean Squared Error. In this lab, I used Huber Loss.
The reason was practical. Forecasting data often contains unusual periods, one-time spikes, timing differences, and reporting noise. Mean Squared Error can be heavily influenced by large errors. Huber Loss provides a middle ground because it is less sensitive to large individual errors while still penalizing forecast misses.
For a planning use case, that behavior is useful. A model should not overreact to every unusual period, especially when some historical values may reflect one-time events rather than recurring business behavior.
Evaluating Forecast Performance
After training, the model was evaluated using standard forecasting metrics: MAE, RMSE, MAPE, and R². These metrics give different views of forecast quality. MAE helps show the average absolute error. RMSE gives more weight to larger errors. MAPE shows error as a percentage, which is useful when comparing business units with different revenue scales. R² gives a broader view of how much of the variance is being explained.
The lab also calculated MAPE separately for Month +1, Month +2, and Month +3. This was important because forecast quality usually changes as the forecast horizon extends. A model may be strong one month ahead but less reliable by the third month.
Looking at each forecast month separately gives a better view of how the model behaves across the planning horizon. That is more useful than only reviewing one blended accuracy number.
Generating the Next Quarter Forecast
The final step was to generate a three-month forecast for each business unit. For each business unit, the model used the latest 12 months of revenue history, combined that with future calendar information, and produced the next three monthly forecast values.
The output included monthly forecast values, quarterly totals, and business unit-level comparisons. At that point, the result started to look more like a planning deliverable and less like a technical experiment.
That distinction matters. A useful forecast should not stop at model output. It should be structured in a way that finance teams can review, compare, challenge, and use in the planning process.
What Made This Lab Useful
The most useful part of this lab was not the architecture by itself. The value came from combining different types of planning information into one forecasting process.
The model used historical revenue, business unit identity, and future calendar context. These are the same types of inputs that planners consider when building a forecast manually. The difference is that the model learned the relationships from the data instead of relying only on manually defined assumptions.
This is where the experiment became more relevant to FP&A. Forecasting is not only about predicting the next number. It is about understanding patterns by business unit, applying known planning context, and producing an output that can support decision-making.
Where This Could Go Next
This lab still used synthetic revenue data, so it is not a production-ready forecasting approach. The next logical step would be to introduce real business drivers.
Useful drivers could include headcount, pipeline, bookings, marketing spend, customer counts, renewal rates, or sales capacity. These drivers could be added alongside the future calendar features, especially when the values are known or planned before the forecast period.
That would move the design closer to how rolling forecasts are built in real planning environments. Revenue is rarely forecast from history alone. It is usually connected to operational drivers, business assumptions, and management judgment.
For this lab, the goal was focused: move beyond a single time series, add business unit context, include future calendar information, and evaluate how the forecast behaves across a three-month horizon.
That made the exercise more practical than simply replacing one model structure with another. It started to connect the forecasting method back to how FP&A teams actually plan.