Your estimate stops being a promise and becomes a claim you can test the moment the monitoring platform starts logging, and proving it is a monthly routine rather than one long stare at the annual total. Take the monthly table out of the original quote, compare each month's production against the estimate for that same calendar month, keep consumption and export on separate lines so you never compare one kind of number to another, and wait for three to six genuinely comparable months before you treat a gap as real. If it holds across those months and sits wider than the margin the estimate itself allowed, put the query to the installer in writing with the monthly figures, the weather notes and the downtime log attached.
I learnt that the slow way, at my kitchen table on a Sunday morning, laptop angled so you can read it from where you're standing. The quote is open on its last page, the one with the twelve-month table most people skim past on the way to the price. The July municipal bill is squared up against the edge of the table. On the screen there's one big number in the middle with a small grey label under it, and a fan humming in the garage every time the geyser element clicks on.
You'd assume the big number is what the panels made. Mine wasn't. It was what the house used.
Read the label under the big number first
Dashboard designers put the largest figure on whatever they think the homeowner cares about, and what the homeowner cares about is the bill. So the big figure tends to be consumption, or a rand value, or "solar used". Production is a tab away, and export is usually a line underneath it that nobody scrolls to.
Now go back to the quote. The table on the last page might say estimated monthly yield, or estimated monthly solar used, or estimated monthly saving. Those are three different claims wearing the same heading. If your estimate says yield and you test it against solar used, you will show a permanent shortfall that doesn't exist. If your estimate quietly assumed all the solar gets used in the house and you actually export a third of it, your production can match the estimate to the decimal while your bill savings come in well under, because the export credit is worth less per unit than the retail rate you avoided.
That last one is the mistake I see most often, and it isn't a broken system. It's an estimate written on a lazy assumption, and you can only see it once the platform starts separating the three figures for you.
Consumption is often a calculated number, not a measured one
Before you build any argument on the consumption line, find out how the platform derives it. On a hybrid system it is frequently worked out from what passes through the inverter plus what the meter clamp sees, and if a circuit sits outside that clamp the number is an estimate dressed up as a measurement. Ask the installer how the figure is produced, in writing. I don't open DBs and neither should you, but you're entitled to know whether the number you're quoting back at them is measured or inferred.
The annual total is the least useful number on the page
Everyone wants to compare year against year. Don't, not in year one. A good summer can bury a poor winter inside a respectable annual figure, and a bad week in June can look like a crisis when the twelve months are on track.
The monthly table in the quote is the estimate's own seasonal model, which is exactly what makes it useful. It already has your winter sun angle and your rainy season baked in, so each month is testable on its own without waiting a year for a fair comparison. July actual against July estimate, October actual against October estimate. That's the comparison that tells you something, and you can start it in month two.
What you're looking for is shape, not a single point. Does your production curve bend the way the estimate's curve bends? If both dip in June and both climb in September, the model is broadly right and any gap is a sizing or assumption question. If yours dips in June and the estimate said it wouldn't, the estimate was drawn somewhere else.
Two months of noise before the data says anything
A single poor month proves nothing. Cloud, a cold front, dust after a dry windy spell, a neighbour's new double-storey going up to the north, the sun moving around a tree you'd forgotten about. I've watched people build a whole case against an installer on the strength of one wet February.
Three to six months of comparable data is where I'd start trusting a pattern. Comparable means you're comparing the same calendar months, with the weather notes written down at the time rather than reconstructed afterwards, and with the platform's own record of downtime beside it. Note the weather in a column each month while it's fresh. Two words is enough: "clear, cold" or "heavy rain, four days".
There's a quieter variable nobody logs: your own consumption. A new geyser element, a heat pump, a home office that runs three extra days a week, a teenager with a gaming PC. Consumption going up doesn't make the array underperform, but it does change the ratio between what you make and what you use, and that ratio sits inside every savings claim you were given.
The shortfall that is really downtime
This is the one that saves people the most embarrassment. Monitoring platforms log grid loss, inverter faults, firmware updates and communication gaps, and in South Africa those logs explain a large share of months that look disappointing.
A grid-tied system without backup shuts down during load shedding by design. It isn't producing badly, it's producing nothing, correctly. A hybrid system with a battery keeps the house up, but once the battery is full and export is disabled or limited, the array has nowhere to put the afternoon's yield and curtails. If you ran on a zero-export setting for the first six weeks while the municipal SSEG approval was pending, your export line reads zero for six weeks and it means exactly what it says. None of that is the array.
So before you write anything to anyone, pull the outage log for that month and put the hours in the spreadsheet next to the production figure. Half the queries I've talked people out of writing were explained by stage 6 and a two-day firmware update.
Prove kilowatt-hours before you argue about rand
Ignore the app's rand savings figure while you're doing this. It is a computed number sitting on a tariff assumption, and South African municipal tariffs are block-structured and time-of-use, which means the marginal unit you avoided at 7pm is priced differently from the one you avoided at 11am. The rand figure can drift while the kilowatt-hours are perfectly fine, and arguing about it puts you on ground you can't defend.
Prove the units. Production against the estimate's production. Self-consumed against the estimate's self-consumption. Export against what the meter actually credited. The municipal meter is the referee for import and export, but it can't referee production at all, because production only exists on the inverter. That's a real limitation of your evidence, and it's worth knowing before someone points it out to you.
What the written query looks like
When three to six comparable months show a consistent gap beyond the estimate's own margin, write it down. Not a phone call, not a WhatsApp voice note. A short email with a table attached and a question at the end.
The table has a row per month and columns for the estimate, actual production, self-consumed, export, grid import, logged downtime hours and a weather note. Attach the platform's CSV export if it has one, and the monthly municipal bill figures. Then ask three specific things: which figure on the platform corresponds to the basis of your estimate, what specific yield and self-consumption ratio the estimate assumed, and whether the configuration as commissioned matches those assumptions.
Keep it flat. "I'm trying to reconcile the estimate with actual data and these months don't line up. Can you confirm the basis?" gets a better response than anything with an exclamation mark in it, and it puts the numbers in front of someone who can actually check the settings.
Then accept that the answer may be that the estimate was optimistic, or that your consumption grew, or that the winter shape was modelled for a sunnier part of the country. That's worth knowing too. What I've never seen work is going in demanding money back on the strength of one month and a gut feeling. The point of the exercise is to know whether the thing you bought is doing what it said it would, and to have a defensible answer either way.
One last habit that has served me well. On the same date each month, screenshot the month view, export whatever the platform lets you export, and write the meter reading in the same notebook. It takes four minutes. In month seven, when you're trying to remember what August looked like, you'll have it, and the difference between a vague complaint and a documented claim is entirely made of those four minutes.
