Stripe Revenue Doesn't Match Your Database or Analytics? A SaaS Revenue Reconciliation Guide

Most founders describe the problem as "Stripe says X, my dashboard says Y." That sentence hides three separate ledgers. The provider ledger is what Stripe holds: charges, payment intents, invoices, refunds, disputes, and balance transactions. The receipt ledger is what your own database wrote when webhooks arrived. The analytics ledger is what your attribution or revenue tool derived from those receipts, often after joining them to sessions and visitors. Any two of these can disagree for different reasons, so the first job is to name the pair you are comparing.

The second job is to freeze the comparison. Pick one window by the provider's payment time rather than by your own insert time, one currency, and one live-or-test mode. Then decide on an amount basis. Stripe's dashboard totals and your database may both be correct while reporting different things: one counts gross charges, the other counts net of processing fees; one includes refunded and disputed amounts, the other excludes them; one counts one-off payments alongside subscriptions, the other only recurring invoices.

Only after the pair, window, currency, and basis are fixed does a difference become evidence. Without that discipline, teams chase a gap that shrinks or grows every time someone changes the date picker, and the real defect stays hidden underneath a definition mismatch.

The order matters because the causes hide each other. A missing webhook makes a definition gap look bigger than it is. A duplicate can mask a missing event by coincidence. Working from the provider outward, one cause at a time, keeps the evidence clean.

This procedure works with a spreadsheet and takes about an hour for a few hundred payments. It also produces the evidence you need if you later decide to automate it.

• Freeze a window: the last 30 days by the provider's paid time, one currency, live mode only.
• Export the provider side. For Stripe, the charges list or the balance transactions report both work; balance transactions give you fees and net amounts. Use a restricted key with read permissions if you export through the API rather than the dashboard.
• Export your side: every stored payment in the window with its provider object identifier, amount, currency, status, refunded amount, and the webhook event identifier that created it.
• Join on the provider object identifier, never on amount and date. Two payments of the same amount on the same day are common in SaaS.
• Classify each difference: present in provider but missing locally, present locally but missing in provider, amount or currency mismatch, status mismatch, refund or dispute mismatch, fee or net mismatch.
• For every provider-only row, open the event in Stripe and check its delivery attempts. Resend it, or list undelivered events with delivery_success=false and replay them through your handler with idempotency guards in place.
• For every local-only row, check the livemode flag and look for duplicates. A local-only live payment that Stripe does not know about should not exist.
• Fix the root cause before re-running: raw-body signature verification, a webhook URL that does not redirect, a handler that stores the event before doing slow work, and a uniqueness constraint on the provider identifier.
• Re-run the same window after the fix and record the result with the date, the window, the definitions used, and the remaining unexplained amount.

The spreadsheet procedure above is a one-off version of independent reconciliation: you took the provider's list of money movements and compared it with your own. The payment webhook audit checklist explains why a healthy webhook pipeline still needs this second path. Every check inside the pipeline starts from an event that arrived. The events that never arrived leave no trace inside the pipeline at all.

Metrivo's Revenue Assurance is a continuous version of the same comparison, and its code is specific about what it does. For Stripe it accepts only a restricted key beginning with rk_live_ or rk_test_; an unrestricted sk_ secret key is rejected with an explicit message that secret keys cannot be used for read-only reconciliation. It validates the key by probing list endpoints for charges, payment intents, invoices, invoice payments, refunds, disputes, balance transactions, and subscriptions, and reports any permission that is missing. It then reads those streams in bounded windows and compares three views: the provider's canonical money units, the signed webhook receipts Metrivo stored, and the revenue projection Metrivo materialised from them.

Every difference is stored as a reason code rather than a narrative. The current code defines twelve of them, and they map closely to the manual categories above. A mismatch that is specific to one provider object produces a decision of measurement broke, with the affected amount summed across the objects involved. Missing or stale evidence produces insufficient evidence. Only when the evidence is complete, fresh, and large enough does Metrivo report that the business changed, with a direction of up, down, or stable.

Once payment totals reconcile, the remaining gap is almost always in how recurring revenue is derived. Metrivo's documented approach is to classify each recurring payment against the customer's previous monthly amount as new, renewal, expansion, contraction, churn, or reactivation, and to sum the active monthly amounts. Each recurring payment is normalised to a monthly amount using its billing interval, so an annual payment does not appear as twelve months of MRR in one month. Churn is detected by absence: a subscription that stops producing payments within its expected billing window is classified as churned, whatever the subscription record says, which also means very recent churn is provisional until the billing window has elapsed.

A provider dashboard that reports MRR from plan configuration will disagree with a payment-derived figure whenever a customer is on a plan but not paying, or paying but not on a plan. Neither is wrong. They answer different questions: what customers are subscribed to, and what customers actually paid. The SaaS metrics guide covers the definitions, and the failed payments and subscription metrics documentation describes the classification in detail, including that derived metrics can be recomputed after missing payments are backfilled.

If you connected a provider late or imported history, recompute after the backfill and compare again. A gap that persists after payments reconcile and definitions match is rare and worth a support conversation with whichever tool is producing it.

Verify the signature on the raw request body before anything else, and reject on failure. Store the event durably before returning a 2xx response, and do the slow work afterwards from that stored record. Enforce uniqueness on the provider's stable object identifier, not on the event identifier alone, because Stripe notes that two separate event objects can be generated for the same change. Apply state transitions in provider occurrence order, never in arrival order.

Then schedule the comparison. A daily job that lists provider records for the trailing window and diffs them against stored receipts catches the events that never arrived while they can still be replayed. If you use Stripe, the undelivered-events filter makes that job short. If you would rather not build and maintain it, a tool that performs the comparison from read-only credentials and reports absence explicitly is the alternative; the Revenue Assurance page describes the incident categories Metrivo reports, and the payment verification documentation describes how signed evidence is accepted in the first place.

If you want Metrivo to run this comparison for one website and one payment path, use the Add my website flow on the homepage. It starts real onboarding and connects a provider through signed webhooks first, with reconciliation added afterwards from a read-only credential. The separate demo is a no-signup seeded product sample, not a live comparison against your Stripe account.