$63 of My $73 Month Had Already Been Refunded

A question first. How does your revenue script count refunds?

I had never asked myself that. The report ran, numbers came out, and I made decisions with them. Past forty apps you stop choosing what to work on by feel and start choosing by revenue — and this script was the input to that.

On 2026-08-26, while re-reading the funnel, I found the 28-day revenue was off by more than 2x.

One filter line

The script reads the sales report row by row and computes:

total = proceeds * units
if total <= 0:
    continue

The intent is clear. Skip zero-value rows — free downloads, trial starts. Most rows are exactly that, so this filter did honest work every day.

But refunds arrive as rows with units = -1. Negative quantity makes total negative, and total <= 0 treats that row exactly like a zero row. So the script wasn't ignoring refunds so much as having no concept of them at all.

The numbers

I re-ran the window 2026-07-28 through 08-24:

reported : $73.28
actual   : $10.29

The gap is $62.99, and all of it is one row. One Sage annual subscription, Australia, 95.45 AUD. Charged on 08-14, refunded on 08-15. One day.

While that row stood, Sage was the top-grossing app in the entire fleet by an order of magnitude. Which naturally reads as "something is working here."

Keep the refund row and the window's real net revenue is:

• Zone 2 monthly, 1 charge — $3.50
• Quieta Pro monthly, 2 charges — $6.79

That's it. Three charges across four weeks, all monthly. It points the same direction as I shipped 42 apps in 113 days. Total revenue: $69.82, only thinner.

What would you do here?

Once you know a figure is 2x wrong, there are two moves:

1. Correct this window's number by hand and move on.
2. Revisit the decisions you made using this script.

Option 1 is far faster, and for reporting it is genuinely enough. But this script's output was not a report — it was a priority order. A false number one is weeks of direction on its own. I had to do option 2.

The fix, and what the fix reveals

The change is one character:

if total == 0:
    continue

Signs are preserved now, and a charge and its refund cancel inside the same window. And once the sign survives, a new reading appears. If an app's row shows zero transactions across two days, that is not "no revenue" — it is a charge paired with a refund. They sum to zero, which is exactly why the old script left no trace of the event at all.

That is the real shape of this trap. Dropping refunds doesn't just inflate revenue; it erases the fact that a refund happened. A charge reversed within 24 hours just stays a charge.

Three things to check

• If your revenue aggregation uses a <= 0 or > 0 filter, can negative rows reach it? (refunds, chargebacks, adjustments)
• Pick your top app from the report and open its rows in the source file. Does the aggregate match the sum of the raw rows?
• When you quote a period total, are you saying whether it is gross charges or net revenue?

The honest part

This defect isn't subtle. Read the code and you see it. The problem is that nobody read it, and there was no reason to: the script succeeded every day, the number looked plausible, and plausible numbers don't get audited. Same shape as My Gate Wasn't Killing the Games — It Was Killing One Impression — the code runs fine and only the criterion is quietly wrong.

The corrected number is also the more honest one. $73 reads as "something is happening." $10.29 does not. Three charges in four weeks is a distribution problem, not a product problem, and that isn't solved with code.

Do one thing right now: find the line in your revenue script that drops rows, and check whether it also drops negatives. One line had me misreading a whole month.