How to track revenue across multiple apps

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Track revenue across multiple apps by standardizing on one definition of revenue (net, after refunds and taxes), pulling every app's billing data into a single place through its native API — not manual CSV exports — and reconciling at the currency and subscription-period level, not just totals. The moment you have more than two or three apps, or more than one billing provider (Stripe for web, RevenueCat or the app stores for mobile), doing this by hand in a spreadsheet stops being a once-a-month chore and starts eating a real afternoon.

Here's the thing nobody tells you when you ship your second app: the hard part isn't getting the number for one product. Stripe's dashboard already tells you that. The hard part is getting numbers that mean the same thing across five or ten products so you can actually compare them, add them up, and decide where to spend your next month of work.

Why "just check each dashboard" breaks down

Each dashboard was built to answer questions about one product in isolation. That's fine until you're trying to answer portfolio questions like:

• Which of my 8 apps grew MRR this month, and which shrank?
• What's my total revenue net of App Store and Play Store cuts?
• Is my mobile portfolio growing faster than my web portfolio?

Stripe shows gross charges unless you dig into the right report. RevenueCat shows revenue in the currency and cut structure of each app store. App Store Connect and Play Console each have their own reporting lag and their own definition of a "proceeds" period. If you're running a mix — a couple of SaaS tools on Stripe, a couple of mobile apps on RevenueCat — you're translating between three different accounting models every time you want one answer.

This is the exact problem covered in more technical detail in tracking Stripe and RevenueCat together — worth reading if your portfolio spans both.

A method that scales past 2 apps

1. Pick one revenue definition and write it down

Before connecting anything, decide: are you tracking gross revenue, net revenue (after refunds/chargebacks), or net-of-store-fees revenue? Mobile subscriptions already have Apple or Google's cut removed by the time RevenueCat reports them; Stripe revenue does not have Stripe's fees removed by default. If you don't write this down once, you'll silently compare apples to oranges every time you glance at two dashboards side by side.

2. Connect the source of truth per platform, not a spreadsheet copy

Manual CSV exports are the single biggest source of stale portfolio numbers. Someone gets busy in month three, stops updating the sheet, and now "current" data is six weeks old. Whatever tool you use, it should pull directly from:

• Stripe for web/SaaS billing
• RevenueCat for cross-platform mobile subscriptions
• App Store Connect and Google Play Console if you want store-level proceeds detail RevenueCat doesn't surface

3. Normalize currency and billing period

MRR needs to mean "recurring revenue normalized to a 30-day period," consistently, whether the underlying plan is monthly, annual, or (increasingly common) a lifetime deal you're amortizing. Annual plans divided by 12 skew differently than annual plans divided by 10 (SoleOS, for what it's worth, charges annual plans at 10 months of the monthly price — know your own math before you compare it to anyone else's).

4. Reconcile at the app level before you sum the portfolio

Add up the portfolio total only after each app's number looks right on its own. A single mis-mapped product ID or duplicated webhook can silently double-count one app's revenue in the total — and a portfolio total is much harder to sanity-check than a single app's number.

5. Re-check monthly, not just when something feels off

Refund windows, chargebacks, and store reporting lag mean this month's number can still move next month. If you only look at revenue when growth "feels" wrong, you'll miss slow leaks — like a refund rate creeping up on one specific app that's dragging the whole portfolio's net number down.

For exact formulas (what counts as "active," how trials are excluded from MRR, how refunds are timed), see the metrics dictionary — get this wrong once and the wrong definition propagates through every dashboard you build after it.

Spreadsheet vs. a purpose-built tool

A spreadsheet is genuinely fine if you're running one or two apps on a single billing provider and you're comfortable re-pulling exports monthly. It's free, it's flexible, and there's no new tool to learn. We wrote an honest comparison — SoleOS vs. a spreadsheet, with a free template — because plenty of readers don't need more than that.

Where spreadsheets start to hurt is: multiple billing providers, more than ~4 products, or wanting current data without manually re-exporting. That's the point where connecting each app's API to something that keeps a running total starts saving more time than it costs to set up.

Disclosure and where SoleOS fits

SoleOS is built by Quantivo AI, LLC — this is our blog, and we're obviously writing about a problem our own product addresses, so weigh that accordingly.

SoleOS connects to Stripe, RevenueCat, App Store Connect, and Google Play (among other connectors) and rolls revenue up across however many projects you run — 1 to 40, depending on plan. It won't reinvent your revenue definition for you; you still need to decide gross vs. net once. What it does do is keep the per-app and portfolio numbers current without manual exports, and let you see growth or decline per app side by side.

If you're only running one app, or your one billing provider's native dashboard already answers your questions, you don't need this — check SoleOS pricing and the live demo with sample data and judge for yourself whether the portfolio view earns its keep for your specific mix of apps. If you're weighing it against another metrics tool, SoleOS vs. Baremetrics covers the actual differences rather than a marketing comparison.

For a grounded look at what portfolio revenue tracking actually reveals once you've got it set up, real numbers from a 10-app portfolio is a good next read — it doesn't sugarcoat the slow apps.

Frequently asked questions

Should I track gross or net revenue across my portfolio?

Track net revenue (after refunds, chargebacks, and — for mobile — store fees) as your primary number, and keep gross available as a secondary figure. Net is what actually lands in your bank account, and it's the only version that's directly comparable between a Stripe-billed web app and a RevenueCat-billed mobile app, since the mobile number already has Apple/Google's cut removed.

How often should I reconcile revenue across apps?

Monthly at minimum, tied to your billing cycle close. If any of your apps has meaningful refund or chargeback activity, check weekly — refunds processed after the fact can shift last month's "final" number more than people expect, especially on annual plans.

Can I track Stripe and RevenueCat revenue in the same dashboard?

Yes, but you have to normalize them first — different currencies, different fee structures, different definitions of "active" subscriber. Either build that normalization yourself (spreadsheet formulas or a script against both APIs) or use a tool that connects to both natively. See tracking Stripe and RevenueCat together for the specific mismatches to watch for.

What's the minimum number of apps where a spreadsheet stops working?

There's no hard cutoff, but most solo founders feel the pain around 3-4 apps, or as soon as they're mixing two billing providers. Below that, a well-maintained spreadsheet with monthly exports is often the more efficient choice — see SoleOS vs. a spreadsheet for a free template that covers exactly this range.

Does portfolio revenue tracking replace per-app analytics?

No. Portfolio tracking answers "how is my business as a whole doing," but you still need per-app funnels, retention curves, and traffic sources to know why a number moved. Keep your existing analytics (GA4, PostHog, App Store Connect) for the "why," and add a portfolio layer for the "what" across everything at once.