sumwerk

Kitchn.io is moving its revenue numbers and its customer work off ChartMogul

Kitchn.io automates paid social for agencies and brands. Its MRR chart was often wrong after plan changes, and nobody could say why. So the team checked every number against Stripe, then moved the rest of their daily work over too.

100 %
of active subscriptions match Stripe's own invoices to the cent
6 minutes
to import five years of customers, contacts, notes, calls and tasks
1 place
for MRR, payment risk, notes, tasks and automations

The problem

Kitchn changes a customer's plan in place: Stripe updates the subscription and writes a prorated invoice for the rest of the period. A tool that reads MRR from invoice amounts turns that proration into a jump in one month and a drop in the next. The chart was wrong most visibly in the months with many plan changes, and nobody could say by how much.

At the same time the sales team lived in the same tool all day: the team had written thousands of notes and call logs and worked through thousands of tasks there. Replacing the chart meant replacing their workplace.

Proving the number first

sumwerk computes MRR from the state of each subscription: price times quantity, normalised to a month, minus active discounts. To check it, the gross monthly value of every active subscription was compared with what Stripe's latest regular invoice bills for the same items. Every single one matched, to the cent.

That check found two real bugs on the way - subscriptions in US dollars on prices whose default currency is the euro, and discounts that ended weeks early - which is the point of checking against the source instead of against another tool.

“We pay for a subscription analytics tool every year and the chart is still often wrong, especially when customers change plans. How hard can it be?”
Stefan Maier, founder of Kitchn.io (and the person who then built sumwerk)

Customers that are not in Stripe

Since 2026, a Kitchn trial no longer creates a Stripe subscription, and new leads start as a booked call. A large share of Kitchn's customers and leads have no Stripe customer at all. In sumwerk a customer exists on its own: a lead under an email address, the organisation that follows, and the Stripe customer at the end are one record with one revenue history.

Moving five years of work in six minutes

The import brought over every customer with all their ids, dozens of custom attributes, tags and owners, their contacts, and years of notes, call logs and tasks. MRR did not move by a cent, because revenue is never imported. Colleagues who had no sumwerk login yet kept their notes and tasks under their email address; the day they join, the work is theirs.

Rebuilding what ran by itself

Most of those tasks had never been typed by anyone: automations created them seconds after a lead signed up or a cancellation was scheduled. The same automations now exist in sumwerk, on triggers that come straight from Stripe, with a log that says what each one did and why not.

Where it stands

Both tools run side by side while the team switches. The import can be repeated at any time and leaves alone whatever was changed in sumwerk since. Next, Kitchn's product will send new leads, trials and product usage to sumwerk's API.

More on what is described here: MRR you can prove, Customers, Import from ChartMogul, Automations.

Connect Stripe and check your own numbers

A restricted, read-only key is all it takes. The first import runs in a few minutes; every number you see opens into the customers and Stripe references behind it.

Start free