Revenue forecasting is one of the core activities in FP&A. Most planning teams look at historical performance, recent trends, seasonality, and business context before preparing the next forecast cycle. This lab tested a simple version of that planning question: can monthly revenue history be used to train an LSTM model and generate a short-term forecast for the next quarter?
This was not designed as a production forecasting model. It was built as a learning exercise to understand the basic pattern: prepare revenue history, train the model, evaluate the output, and generate a forward-looking forecast.
What Was Built
For this lab, I built a Python model using PyTorch. The model uses an LSTM network to forecast monthly revenue. The input is 12 months of revenue history, and the output is the next 3 months of revenue.
In planning terms, the model is asking a simple question: based on the last 12 months of revenue, what could the next quarter look like?
That structure is similar to how many FP&A teams think about rolling forecasts. They look at recent history, understand the trend, consider seasonality, and then prepare a short-term view of the next planning period.
Dataset Used for the Lab
The lab used generated sample revenue data. The dataset included monthly dates, revenue values, a growth trend, seasonality, and random noise. The sample data started in January 2016 and covered 96 months of revenue history.
Generated data was used intentionally. The objective of this lab was not to prove accuracy against a client dataset. The objective was to test the forecasting workflow in a controlled way. Using generated data made it easier to build the full process without exposing any company-specific information.
In a real EPM or FP&A implementation, this same pattern would need to be tested against actual revenue history, with proper validation and business review.
Preparing the Revenue Data
Before training the model, the revenue values were scaled using MinMaxScaler. This converted the revenue values into a smaller range so the model could train more effectively.
That scaling step is important because neural networks generally work better when input values are normalized or scaled. Revenue values can be large, and large values can make training less stable.
After the model generated predictions, the forecast values were converted back into actual revenue dollars. This step matters because the model may train on scaled values, but finance users need to review the forecast in business terms. A forecast is only useful if it can be read, challenged, and compared in the same units used in the planning process.
Forecast Window Design
The model used a 12-month lookback window. Each training example contained one year of revenue history, and the target was the next three months.
For example, the model could use January 2020 through December 2020 as the input window and January 2021 through March 2021 as the target forecast period. Then the window moves forward by one month, creating another training sample.
This is the basic idea behind time series windowing. A single revenue series can be converted into multiple training examples by moving the historical window across the timeline.
From an FP&A perspective, the design is easy to understand. The model uses one full year of history to produce the next quarter forecast.
Model Design
The model was built with two LSTM layers. The first LSTM layer used 128 hidden units, and the second LSTM layer used 64 hidden units. Dropout was added after each LSTM layer to help reduce overfitting during training.
The final layer produced three output values. Those values represented the forecast for Month 1, Month 2, and Month 3 of the next quarter.
This design kept the model focused. It was not trying to forecast many years into the future. It was solving a short-term forecasting problem that aligns with a rolling planning process.
Training Approach
The model was trained for 80 epochs. Mean Squared Error was used as the loss function, and Adam was used as the optimizer. A learning rate scheduler was also included. When validation loss stopped improving, the learning rate was reduced.
The best model was saved based on validation loss. This is better than simply using the final training epoch because the final epoch is not always the best-performing version of the model. Saving the best validation result helps avoid keeping a model that may have started to overfit or perform worse later in training.
Evaluating the Forecast
After training, the forecast values were compared against actual values from the test data. The model was evaluated using MAE, RMSE, MAPE, and R².
Each metric gives a different view of forecast quality. MAE shows the average absolute error. RMSE gives more weight to larger misses. MAPE shows the error as a percentage, which is useful for business review. R² gives a broader view of how well the model explains the movement in the data.
For this first lab, the evaluation focused mainly on the first forecast month, also known as M+1. That kept the evaluation simple and made it easier to understand whether the model was following the revenue pattern.
Reviewing the Forecast Chart
The chart compared actual revenue against the M+1 forecast. This visual review is important because metrics alone do not tell the full story.
A metric can show the size of the error, but a chart shows whether the model is following the shape of the trend. For planning work, both views matter. Finance users need to know how accurate the model is, but they also need to see whether the forecast behaves in a way that makes business sense.
A forecast that has acceptable error but does not follow the business pattern may still be difficult to trust.
Generating the Next Quarter Forecast
After evaluation, the model used the latest 12 months of revenue history to generate the next 3 months of forecast values. The output included Month 1 forecast, Month 2 forecast, Month 3 forecast, and the total forecast for the quarter.
This is where the lab connects back to EPM and FP&A. A planning model usually needs a forward-looking period that can be reviewed, compared, and included in a forecast cycle. In this case, the model produced a next-quarter revenue forecast based on recent revenue history.
That does not mean the forecast should be accepted automatically. It means the model can produce a starting point that finance can review.
What This Lab Shows
This lab shows the basic workflow for using an LSTM model in a monthly revenue forecasting scenario. The process starts with time series data, scales the values, creates lookback windows, trains the model, evaluates the results, and generates a future forecast.
The value of the lab is not only the model itself. The more important value is understanding the pattern. A forecasting use case should always start with a clear planning question, clean input data, a controlled model design, measurable output, and business review.
This first version is not enough for production. A real EPM use case would need stronger source data, multiple business dimensions, driver-based inputs, validation by finance users, model monitoring, and clear controls around how forecast values are used.
Final Observation
The most useful part of this lab is the process. The lab took a practical planning question, built a small forecasting model, tested the output, and reviewed the result.
That is the right way to approach advanced forecasting in an EPM environment. Start with a small use case. Keep the input clear. Keep the output understandable. Review the result before trusting it.
For this lab, the model forecasted the next quarter using only historical monthly revenue. That is a simple starting point, but it creates a working foundation for future forecasting experiments with business units, drivers, seasonality, and planning assumptions.
Code Reference
Google Colab notebook: https://colab.research.google.com/drive/1swVX7nwLcVLpPcKp-xBNLcD98R2VZYN1