Budget variance review is one of the most common activities in an FP&A process. Every month, finance teams compare budget to actuals by department, account, and period. Most variances can be explained through timing, business activity, known decisions, or normal operating movement. Some rows, however, need closer review because they do not follow the expected pattern.
This lab tested a simple question: can we learn the normal pattern of budget variance behavior and use that pattern to flag rows that look unusual?
The goal was not to replace the FP&A review process. The goal was to create a practical review aid. Instead of asking an analyst to scan every row manually, the model produces a focused list of transactions or variance rows that may need attention.
What Was Built
For this lab, I built an autoencoder model using PyTorch. The model was trained only on normal budget variance rows. After training, all rows were passed through the model and reconstructed. Rows with higher reconstruction error were flagged as possible anomalies.
The concept is straightforward. If the model has learned what a normal budget variance row looks like, it should be able to reconstruct normal rows with low error. When a row does not follow the normal pattern, the model has a harder time reconstructing it. That difference creates a higher error score, which can be used to identify rows that may require review.
This is a useful pattern for EPM use cases because finance teams often do not need a system to make the final decision. They need a better way to prioritize the review.
Dataset Used for the Lab
The lab used synthetic FP&A budget variance data. The dataset included department, month, budget, actuals, variance, variance percentage, and an anomaly flag. The sample departments were Sales, Marketing, R&D, Operations, G&A, and HR.
Most rows represented normal variance behavior, with actuals generally falling within a reasonable range around budget. A small portion of the rows were created as anomalies. These included large overruns, large underruns, and misposting-style spikes.
This was not client data. The synthetic dataset was used so the full workflow could be explained clearly without exposing company-specific information. The purpose was to test the design pattern, not to prove production accuracy on a real finance dataset.
Why Synthetic Data Was Used
Synthetic data made the lab easier to share and easier to control. In a real implementation, the model would need historical actuals, budget data, department and account detail, period controls, and clear business definitions for what should be treated as unusual.
For a first test, synthetic data is enough to validate the workflow. The process is what matters: prepare the data, create useful features, train on normal rows, score all rows, flag outliers, and review the results.
That workflow is close to how this type of solution would be introduced in an EPM environment. It should start small, prove whether the pattern is useful, and then expand only after finance users can validate the output.
Feature Preparation
The model could not use department names directly, so the department field was converted into dummy variables. Month was also transformed into two cyclical features: month sine and month cosine.
That month treatment matters because calendar periods are cyclical. December and January are close to each other in the planning cycle, even though their month numbers are 12 and 1. A simple month number does not represent that relationship well.
The numeric inputs included budget, actuals, variance, and variance percentage. After the features were created, the full dataset was scaled using StandardScaler. Scaling is important because budget and variance values can be much larger than encoded department or month values. Without scaling, the model may give too much weight to large numeric fields and not enough attention to other useful features.
Why the Model Was Trained Only on Normal Rows
The key design choice was to train the autoencoder only on normal variance rows. The model was not trained on known anomaly examples.
That approach is useful when the business has a good understanding of normal behavior but does not have a complete set of labeled historical exceptions. In many finance environments, this is common. Teams know what normal variance patterns look like, but they may not have a clean historical record of every misposting, unusual event, or review exception.
By training only on normal rows, the model learns the shape of expected variance behavior. After training, every row is scored. Rows that look similar to normal behavior should have lower reconstruction error. Rows that are harder to reconstruct receive a higher error score and can be flagged for review.
This does not mean the row is automatically wrong. It means the row does not look like the normal pattern the model learned.
Autoencoder Design
The autoencoder has two main parts. The encoder compresses the input features into a smaller representation. The decoder then tries to rebuild the original row from that compressed version.
In this lab, the bottleneck size was set to four. That means the model had to compress all input features into four values before reconstructing the row. This compression is what makes the design useful for anomaly detection. Normal patterns can usually be compressed and rebuilt with less error. Unusual patterns are harder to represent in the same compressed structure.
The model was trained for 100 epochs using Mean Squared Error as the loss function and Adam as the optimizer. A learning rate scheduler was also used so the learning rate could be reduced when the loss stopped improving. The best version of the model was saved during training and then loaded again before scoring the full dataset.
How Rows Were Flagged
After training, reconstruction error was calculated for every row. The threshold was set using the 95th percentile of reconstruction errors from normal rows. Any row above that threshold was flagged as a potential anomaly.
This is an important distinction. The model was not saying, “This row is incorrect.” It was saying, “This row does not look like the normal variance rows used during training.”
That is the right way to position this type of output in an FP&A process. The result should be used as a review queue, not as an automatic accounting decision.
Evaluation Approach
Because the lab used synthetic data, the true anomaly labels were already known. That made it possible to calculate a classification report, ROC-AUC score, and predicted anomaly count.
In real EPM work, those labels may not exist. A company may not have a clean historical record of which rows were truly unusual and which rows were only normal business movement. In that case, the first implementation should be treated as a controlled review workflow. Finance users would review flagged rows, confirm whether the flag was useful, and build feedback over time.
That review history becomes valuable because it helps improve the process, tune thresholds, and define what “unusual” actually means for that organization.
Reviewing the Output
The lab produced several charts to understand model behavior. The training loss chart showed whether the model was learning during training. The reconstruction error distribution showed how normal rows compared against anomaly rows. The ROC curve was useful because the synthetic dataset had known labels. The anomaly rate by department helped show whether flagged rows were concentrated in specific areas.
The final output was the most practical part of the lab. It printed the top flagged budget variance rows with department, month, budget, actuals, variance percentage, and reconstruction error.
That output is close to how this could be used in a real FP&A process. The system does not need to explain every variance. It needs to help the analyst find the rows that deserve attention first.
What This Lab Shows
This lab showed a simple and useful pattern for anomaly detection in EPM data. Train the model on normal variance behavior, reconstruct all rows, calculate reconstruction error, apply a threshold, and send high-error rows to review.
This pattern could be useful for budget variance review, unusual actuals review, misposting checks, department-level expense monitoring, and account-level variance analysis. The value is not in full automation. The value is in reducing noise and helping finance teams focus their review effort.
Production Considerations
This lab is not production-ready. A real implementation would need stronger data design and governance. It would need actual ERP or EPM history, account-level detail, department and cost center structure, period controls, materiality thresholds, and approval logic.
It would also need explainability. Finance users need to understand why a row was flagged, what changed, and what action is expected. A review workflow would also be required so users can confirm whether the flag was valid, mark false positives, and capture comments.
Thresholds should not be treated as purely technical settings. They should be agreed with FP&A and accounting stakeholders based on volume, risk, materiality, and review capacity.
Final Observation
This lab is not about removing human review from the budget variance process. It is about making the review process more focused.
In many planning and reporting cycles, analysts spend too much time scanning rows that are already explainable. A model like this can help create a shorter, more targeted review list. The analyst still owns the interpretation. The system only helps prioritize where to look first.
That is a practical starting point for advanced analytics in EPM: clear data, clear logic, clear output, and human review where judgment is still required.