Collapsing run rate movements

Your billing system records every change exactly as it happened, and some of those changes don’t describe what happened to your business. A customer who moves to a bigger plan by canceling one subscription and starting another shows up as a large churn followed by a large new customer, when really they upgraded. Collapsing smooths out edges like that: several changes close together count as one run rate movement.

What collapsing does

When changes are collapsed, they count as one movement, on the date of the first of them. What kind of movement it is comes from where the customer stood before the first change and after the last:

What your billing system recorded	What Summerbase counts
Signed up at $100 per month, upgraded to $500 the next day	New, $500
Canceled Starter at $50 on January 30, subscribed to Growth at $50 on February 2	No change
Canceled at $200 on March 3, subscribed again at $200 on March 5	No change, and no gap in MRR

The changes themselves aren’t hidden. A customer’s page lists every one of them under Run rate movements, beneath the movement they count in.

Outside the collapsed stretch, a customer’s MRR is exactly what your billing data says. Inside it, they count at what they ended up paying, from the date of the first change.

The project’s collapse window

Every project collapses changes made within a few days of each other. You set how many in Settings, then Metrics, under Collapse window. The default is 7 days, and it can be anything from 0 to 90.

• Changes within that many days of a customer’s first change count as one. Seven days means 168 hours, wherever your reporting timezone is.
• With 0, every change counts on its own, exactly as billed.
• Because a movement is dated at its first change, a closed month can still move for a few days into the next one, until its last changes are outside the window.
• Changing it recalculates every customer in the project. A banner shows while that runs, and figures are mixed until it finishes. There’s a limit on how often you can change it.

The window applies to every customer alike, which is what makes it fair, and also what limits it. Raising it to catch one slow plan migration also swallows real churn and early upgrades for everyone else. For one customer whose history needs it, collapse their movements by hand instead.

Collapsing one customer’s movements

Sometimes one customer’s billing history isn’t what happened, and the project’s window doesn’t reach far enough to fix it. For example:

• A sign-up that was never a real customer, such as a test account or a duplicate that paid once.
• A lapse that ended in a return, such as a failed payment that canceled the subscription before the customer came back.
• A deposit that was refunded before the real subscription began.
• A plan migration that took three weeks, with the old plan ending well before the new one started.

To collapse them:

1. Open the customer’s page.
2. In Run rate movements, open the menu and choose Collapse movements into one.
3. Click the first movement to collapse, then the last.
4. Say why, and choose Collapse.

Everything from the first movement through the last then counts as one, on the date of the first, in every report and shared view. In the examples above, the sign-up becomes nothing at all, a customer who never paid. The lapse becomes one contraction on the day it began, if the customer came back on a smaller plan, with no gap in their MRR. The deposit becomes nothing, and the real subscription counts as their New.

Writers, admins and the owner can collapse movements. Anyone in the project can see them: each collapsed movement is marked Collapsed, with the reason when you point at it, and the customer’s page lists them under Collapse windows, with who collapsed them and when.

A few things to know:

• The project’s window stops at the edges. It doesn’t join a collapsed stretch to a change just before or after it. So collapsing a single change keeps it apart from a neighbor the project’s window would otherwise have joined it to.
• Collapsed stretches can’t overlap. One customer can have several, as long as they cover different dates.
• To change one, remove it and collapse again. Choose Remove from its row in Collapse windows. The customer’s history goes back to what your billing system recorded.
• Collapsing can’t move revenue to a date nothing happened on. If a subscription started on the wrong date, correct it in your billing system.

Why you can’t edit MRR

Summerbase has no way to type in a different MRR or ARR for a customer, and that’s on purpose. Your MRR is read by your team, your board and investors, sometimes through a shared view. Everyone reading it should be able to trust that it’s what your billing data says, not what someone wished it said.

Collapsing never changes that. It decides how changes are grouped and on which date they count, and every figure still comes from something your billing system recorded. Each collapsed stretch says who made it and why, and can be removed to see the history exactly as billed.

If an amount itself is wrong, the fix belongs in your billing system. Once it’s corrected there, Summerbase picks it up.