Month-over-Month Growth in Excel, and the Month That Is Not There

1. Get to one row per month first

Growth compares two numbers, so before anything else you need one number per month. Two routes.

A pivot table. Put the date field in Rows, right-click a date, Group, tick Months and Years, and put revenue in Values. Fast, and covered step by step in the pivot guide, including the part that matters here: a month with no rows never appears.

SUMIFS against a list of month starts, which is more typing and more control. Build the boundaries with DATE and EOMONTH rather than typing them, so the sheet behaves the same on every machine:

=SUMIFS(Orders[Revenue],
        Orders[OrderDate], ">="&A2,
        Orders[OrderDate], "<="&EOMONTH(A2,0))

With A2 holding 1 January 2026 that returns 2,630. The same formula pointed at 1 April returns 0, which is the whole reason to prefer this route, and section four is about why.

Either way, check the aggregate before going further: the months must add back to the total. Here 2,630 + 2,245 + 2,585 + 2,430 = 9,890, which is the table's full revenue, so nothing was lost in the grouping.

2. The growth formula

One row per month, sorted oldest first, and growth is the row above.

=B3/B2 - 1

Format the result as a percentage rather than multiplying by 100, because a cell formatted as a percentage still holds the underlying number and can be averaged, charted and compared. Multiplying by 100 turns it into a number that only looks like a percentage.

On the four months present in the data:

Month   Revenue    Growth
Jan       2630         -
Feb       2245    -14.6%
Mar       2585    +15.1%
May       2430     -6.0%

Check one by hand: 2,245 ÷ 2,630 = 0.8536, minus 1 is −0.1464, which is −14.6%. The equivalent form =(B3-B2)/B2 gives the same answer and reads more like the definition; use whichever you will recognise in six months.

The first row has nothing above it, so leave it blank rather than showing a zero. A zero there claims flat growth in a month where growth is not defined, and somebody will average the column.

3. The month that is not there

Before the explanation: the table above has four rows for a period running January to May. Say which month is missing and what that does to the last figure.

April. There are no April orders, so April never became a row, and the formula on the May row divided by the row above it, which is March.

What the sheet says      May, -6.0%
What it computed         2430 / 2585 - 1
What that measures       May against March
What April was           0, in a month nobody looked at

Every part of that is arithmetically correct. The −6.0% is a real number about two real months. It is simply not the number the column heading promises, and there is nothing on the sheet to indicate the substitution, because the evidence for April was never a row.

It also quietly changes anything computed from the column. Average monthly revenue over the four rows present is 2,472.50. Over the five months that actually elapsed, with April counted as the zero it was, it is 1,978.00. That is a difference of 494.50 a month, from a row that does not exist.

=AVERAGE over the four rows present        2472.50
=AVERAGE over five months, April as 0      1978.00

Say out loud which of those two numbers you would want on a slide titled "average monthly revenue". Both are defensible and they mean different things, and the sheet as built does not let you choose, because it only offers one of them.

4. A calendar table, so a gap becomes a zero

The fix is not a cleverer formula. It is a list of every month in the period, written down independently of the data, with the totals looked up against it.

Build the list once. Put the first month start in a cell and fill the rest with EDATE, which steps by whole months and handles year ends without help:

A2:  =DATE(2026,1,1)
A3:  =EDATE(A2,1)        and fill down

Then total against it with SUMIFS, exactly as in section one. Now every month exists as a row whether or not anything happened in it:

Month   Revenue    Growth
Jan       2630         -
Feb       2245    -14.6%
Mar       2585    +15.1%
Apr          0   -100.0%
May       2430    #DIV/0!

That looks worse and it is much better. The 0 is visible, the −100.0% is a true statement about April, and the error on the May row is Excel refusing to divide by zero, which is the correct response to a question that has no answer. The version without the calendar hid all three behind a tidy −6.0%.

Two details worth having. Base the calendar on the reporting period rather than on the data, so it covers months at the start and end where nothing happened either. And keep it as a proper column of dates, formatted to display as months, rather than as text, so it can still be filtered and compared; that is the same discipline as everything else involving dates.

5. Dividing by zero, and what to show instead

Before the explanation: last month was zero and this month was 2,430. Say what the growth percentage is.

There is not one. Growth is a ratio to a base, and there is no meaningful ratio to nothing: any increase from zero is infinite in percentage terms, which is why Excel returns #DIV/0! rather than a large number.

So do not hide it behind a zero. Three honest options, in order of how much I like them.

=IF(B2=0, "n/a", B3/B2-1)         says growth is undefined
=IF(B2=0, "new", B3/B2-1)         says the series restarted
=IF(B2=0, "", B3/B2-1)            blank, which at least is not a claim

What all three avoid is =IFERROR(B3/B2-1, 0), which reports 0% growth for a month that went from nothing to 2,430. That is not a rounding compromise, it is the opposite of what happened, and it is exactly the trade wrapping an error always offers.

And whichever you choose, report the absolute change beside the percentage. February's −14.6% is also −385, and 2,430 up from 0 has no percentage at all but is plainly 2,430. A number of things and a percentage of things are read differently by people, and the pair together is much harder to misread than either alone.

6. Percent against percentage points

Two different words for two different quantities, and mixing them is the most common wording error in a monthly pack.

If a conversion rate goes from 5.12% to 6.85%, the change is 1.73 percentage points. It is also a 33.8% increase, because 6.85 ÷ 5.12 − 1 is about 0.338. Both are true; they are answers to different questions, and the numbers are not close.

6.85% - 5.12%          1.73 percentage points
6.85% / 5.12% - 1      33.8%

The rule is simple once said: subtracting two percentages gives percentage points, dividing them gives a percentage. Say "points" out loud when you mean the subtraction, and put the word in the column heading, because a column headed "change" containing 1.73 will be read as 1.73% by somebody in a hurry.

This only comes up when the thing you are tracking is itself a percentage: conversion rates, margins, utilisation, market share. Revenue in pounds has no such ambiguity, which is why the confusion tends to arrive later, when somebody adds a margin row to a revenue report.

7. Small bases, and the moving average

Month-over-month growth divides by last month, so the smaller last month was, the wilder the percentage. A region that did 40 last month and 120 this month is up 200%, and a region that did 4,000 and went to 4,400 is up 10%, and the second one moved twenty times more money.

Two habits keep that under control.

Show the base beside the percentage, always. A growth column with no denominator column next to it invites the reader to rank by percentage, which ranks by smallness.

Smooth before you compare, when the series is noisy. A three-month average of the same data flattens the single-month swings and makes the direction readable:

=AVERAGE(B2:B4)      three months ending March, calendar included:  1610.00
=AVERAGE(B3:B5)      three months ending May, calendar included:    1671.67

Note that both of those include April's zero, because they are built on the calendar version. Smoothing over a series with hidden gaps smooths the wrong numbers, which is why the calendar comes first and the moving average second.

8. Against last year instead

Month-over-month answers "is this month better than last month", which for anything seasonal is a question about the season rather than the business. December against November tells you it is Christmas.

Year-over-year, comparing each month with the same month a year earlier, removes that. It is the same formula with a different partner:

=B14/B2 - 1              twelve rows back, on a monthly series with no gaps

Which is another reason the calendar matters: "twelve rows back" is only "twelve months back" if every month is a row. On a table built from the data alone, twelve rows back can be thirteen or fourteen months, and nothing says so.

The usual answer in a real pack is to show both, with the absolute figures beside them, and to say in the heading which comparison each column is making. Two columns and a clear heading beats one number and an argument in the meeting.

Edge cases that break a growth column

Six that get through.

A partial current month. Comparing three weeks of this month with a full last month always shows a fall. Either exclude the current month or scale it and label it clearly as a projection.

Text dates. If the date column is text, the pivot will not group and the SUMIFS boundaries will not match, and both fail in ways that look like a formula problem. Run the =N(A2) check first.

Timestamps at the month boundary. An order at 23:40 on 31 January is a serial number slightly above the end of January, so <=EOMONTH(...) excludes it. Use < the first of the next month instead, which is safe either way.

Sorting the months as text. A column of month names sorts April, August, December. Keep real dates underneath and format them as months, and the sort stays chronological.

A negative base. If last month was −200 and this month is 100, the formula returns −150%, which is arithmetically right and communicates the opposite of what happened. Where values can go negative, report the absolute change and skip the percentage.

Restated history. If last month's figure changes after the fact, this month's growth changes too, and last month's published growth is now wrong. Keep a note of when each figure was taken, or the pack disagrees with itself across two months.