Your dashboard says 2,400 and Stripe says 2,271: closing the gap

It is the first Monday of the month and you are doing the small ritual. Open the store.fan dashboard, write down the revenue figure for last month, then open Stripe and find a different number looking back at you. One screen says 2,400. The other says 2,271. Nobody has taken anything and nobody has miscounted. The two screens are answering two different questions, and until you can name which is which, you will keep re-adding the same month and feeling vaguely robbed.

Two screens, two jobs

The analytics inside store.fan exist to answer a merchandising question. They show views, buyers and revenue per product, plus where the traffic came from, so you can see that the 39 workbook outsold the 89 template three to one and that most of it arrived from one link. That figure is gross by design. If it were net of card fees you could not compare two products fairly, because a product sold as ten small orders carries more fixed per-charge cost than the same money taken in two large ones. You can read more about what those screens cover on the analytics feature page.

Stripe is doing something else entirely. It is the settlement record: the actual history of money moving. Because payments on store.fan go straight into your own Stripe account and we never hold funds at any point, Stripe is the authority on what exists. If the two disagree, Stripe is describing your bank and store.fan is describing your shop.

The genuinely awkward part is that processing cost is charged per transaction rather than per month, so the effective percentage moves around. A month of twelve tips and a month of twelve course sales can produce identical gross revenue and noticeably different fee totals. That is not an error to chase. It is a reason to stop expecting one tidy percentage to explain every month.

What each number is actually counting

Most creators end up with a spreadsheet that has one column, copied from whichever screen they opened first. Here is what you get instead when you read both properly, each doing the job it is built for.

The five-minute reconciliation

Do this once a month, on a fixed day, and it stops being an investigation. The order matters more than the arithmetic: most failed reconciliations fail at step one, comparing a calendar month against a rolling thirty days.

1. 1Choose one range and set the identical start and end date on both screens. Month to date against last 30 days will never agree, and no amount of staring will fix it.
2. 2Write down the gross revenue total from your store.fan analytics for that range, with the per-product breakdown underneath if you want to know where it came from.
3. 3In Stripe, look at gross volume for the same range rather than your balance. Your balance is a snapshot of what happens to be sitting there today, which is a different question again.
4. 4Subtract Stripe's total processing fees for the range from the gross figure. The two numbers should now be within pennies of each other.
5. 5Handle refunds as their own line rather than folding them in, so you can see whether a soft month was a sales problem or a returns problem.
6. 6If a residue is left and it is roughly the size of one order, go and find that order. It is nearly always a sale on the boundary date, sitting on different sides of midnight in the two systems.

A worked month, end to end

Say your store.fan analytics show 2,400 in revenue for July across 62 orders, spread over a digital download, a bundle and four coaching calls. Stripe's processing for the same 62 charges comes to 129, which is a shade over 5% because roughly a third of the cards were international. That takes you to 2,271 net, which is the number sitting in Stripe. Your own rate will be different from this one, so read it off your own Stripe dashboard rather than borrowing the example.

Then your bank shows 2,088 for July, and the panic starts again. The missing 183 is the last payout of the month, still in transit because it was initiated on the 31st and lands on the 2nd. Nothing has gone anywhere. You have three true numbers describing the same money at three stages of its life: charged, settled, banked. Once you can say that sentence out loud, the monthly ritual takes five minutes and produces no adrenaline at all.

The mistake nearly everyone makes first

The classic error is reconciling the dashboard against your bank account rather than against Stripe. Bank deposits are batched on a payout schedule, so they lag, they merge several days together, and they will never line up with a calendar month. The second error follows from the first: a creator decides fees are far higher than they are, and puts every price up by 15% to compensate for a shortfall that was really just a payout in transit. Check the middle number before you touch your pricing, and if you are unsure what your plan includes while you are at it, the pricing page spells out where analytics start.

Reconciliation is not accounting. It is a habit that keeps you from making decisions on a number you have misread. Pick a day, use one date range, and let the two screens do the jobs they were built for. Anything still unexplained after that is worth an email, and the FAQ covers most of what people ask before they send one.