Detect seasonality in revenue and expenses
Compares the same calendar months across multiple years to find the spikes and dips that repeat, and the ones that do not.
Copy and customize
You are an FP&A analyst testing for seasonality before building a forecast.
Context: amounts are in the Amount field, the reporting date is Reporting Month,
and the split is Account Group L2 (or a revenue/expense flag). Use as many full
fiscal years as the data contains.
{financial_data}
Task: compare the same calendar months across years and identify repeating
seasonal patterns, separating them from one-off events.
Output format:
- A table: each calendar month's figure in each year, side by side, with an average.
- The months that are consistently strongest and weakest across years.
- Patterns that repeat in the same month across multiple years, kept separate from
single-year events.
- A confidence note: how many full years the pattern rests on and how consistent
it is. Require at least two full years before calling anything seasonal; with
fewer, say the data is insufficient. Exclude partial or open months and name them.
Run it in four steps
- Export at least two, ideally three or more, full fiscal years from the Amount field on a stable Reporting Month, with non-recurring items flagged.
- Paste it into
{financial_data}. - Run it to compare the same months across years and flag repeating patterns.
- Separate growth from seasonality yourself; a business growing each year shows recent months as strong for reasons that are not seasonal.
When to reach for this prompt
Use this before building a forecast, so the baseline reflects real seasonality rather than a flat line or naive growth. It is also the right tool when someone insists a given quarter is "always" the strongest and you want to test the claim. It is best run once date fields and groupings are clean, and it needs at least two full years; a fiscal-calendar or revenue-recognition change inside the window invalidates it.
What you can expect back
Revenue by calendar month, across years (Amount)
| Month | Yr-1 | Yr-2 | Yr-3 | Avg | Pattern |
|---|---|---|---|---|---|
| Jan | 1,610K | 1,720K | 1,840K | 1,723K | below average, consistent |
| … | |||||
| Mar | 1,510K | 1,640K | 1,760K | 1,637K | weakest month, all 3 years |
| … | |||||
| Nov | 2,180K | 2,310K | 2,470K | 2,320K | strong, building |
| Dec | 2,640K | 2,790K | 2,980K | 2,803K | strongest month, all 3 years |
Consistently strongest: December, highest in all three years.
Consistently weakest: March, lowest or near-lowest in all three years.
Repeating pattern: a Q4 build (Nov-Dec) and a Q1 trough (Feb-Mar), present in all three years.
Confidence: based on three complete fiscal years; the Q4/Q1 pattern holds in all three. Mid-year months are noisier and the seasonal read there is weaker, so those should be treated with some caution.
This prompt has real limitations you should understand.
Seasonality is the most over-claimed pattern in finance, because both human readers and language models are pattern-completion engines. With only two or three years, almost any month can be made to look seasonal, which is exactly why the confidence note exists; the headline finding is often statistically thin, and the number of years behind it should be read before the pattern is trusted.
The deeper issue in the example above is that growth and seasonality are entangled. A business growing 15% a year shows every recent month as above average, which is a trend, not a season, and untangling the two properly requires deseasonalizing rather than comparing raw totals. A single large deal or one-time write-off in a given month also poisons that month for the whole analysis, and the model cannot know which rows were one-offs unless the data marks them.
A dependable seasonality read needs several full years on a stable fiscal calendar, with non-recurring items flagged and the underlying growth trend separated out, all of which are properties of how the historical data is assembled and labeled. No prompt can deseasonalize data that was never structured to support it, which is why this analysis is only as good as the multi-year record beneath it.
What your data needs to look like
- An Amount field spanning at least two, ideally three or more, full fiscal years
- A consistent Reporting Month with no calendar changes inside the window
- A stable revenue and expense classification across all years
- Non-recurring items flagged so they can be excluded from the pattern
See how FinanceOS handles this prompt on real financial data.
Book a 20-minute walkthrough. We’ll run this exact prompt against a sample dataset reconciled through FinanceOS, and show you what changes when the data underneath is right.
Book a walkthrough