Where advice software should refuse to answer

Every planning software I’ve tried has the uncanny ability to produce a decent-looking whole-of-wealth projection even without a super balance entered in for the client… Unfortunately, this is not new-age AI genius – the tool just assumed a zero balance, used the last figure it saw, or it quietly dropped the account out of the calculation. The resulting chart looks no different to one with correct entries.

That is the problem we’re looking at here. Not that the numbers are wrong necessarily, but that a wrong number is presented with the same confidence as a right one.

What ASIC found

In November 2025, ASIC published a review of 100 advice files relating to SMSF establishment. 62 of them failed to demonstrate compliance with the best interests duty, and 27 raised significant concerns about client detriment1.

A particularly concerning finding was buried further in. 47 of those 100 files had actually been pre-vetted by an adviser, but 33 of them failed best interests duty obligations anyway1.

So the checks ran and passed, but the advice was still deficient.

A control that always returns “fine” is not a control, it’s just a receipt.

The law already assumes your data is incomplete

Here is a part that I found genuinely interesting, but took me a second to appreciate properly:

The Corporations Act does not treat incomplete client information as an edge case. Section 961H imposes a standalone obligation on the adviser to warn the client where advice is based on incomplete or inaccurate information, and ASIC gives it its own guidance at RG 175.303 to RG 175.306. It sits alongside the best interests duty in s 961B, the appropriate advice requirement in s 961G and the conflicts priority rule in s 961J, and a licensee has to take reasonable steps to ensure its representatives comply with all four2.

As a design brief that’s pretty unambiguous. The legislation expected advisers to be working with partial information often enough to write a specific duty about it. Incompleteness is the normal state of a client file, not a failure of the adviser or their fact-finding process.

Almost no software seems to behave as though that is true. The typical modelling tool has no representation for “I don’t know this”. It has a zero, and a zero is a number, and numbers flow through formulas without complaint.

What we do instead

When Aether is missing a figure required for a calculation, it stops in its tracks and states the exact missing input(s).

It’s not as simple as it sounds to arrange that, especially since there are tempting shortcuts everywhere… If a client’s unused concessional cap history is not on file, we don’t try to estimate it from their salary, we stop the carry-forward calculation entirely and throw a warning. An estimate may be defensible in some cases (where it’s not measurably relevant to the client or their strategies), but the damage of getting it wrong when it matters is just not worth it.

The same rule runs through the Age Pension calculation, the tax position table, and the contribution modelling, for example. If the official figure for the year is not available and approved, the calculation stops rather than falling back to a hardcoded number from last year. A figure that has gone stale looks identical to a current one on the page, and that is the whole danger.

We also refuse in a specific way, because “cannot calculate” on its own isn’t very helpful. After naming the missing input, the next action is implied: go and get the client’s contribution history or whatever it might be, then run it again.

The cost of this approach

This could make the software more annoying to use, at first. The trade-off for being told “not yet” – potentially multiple times – before it will generate your chart, is that the output becomes something you can really start to trust. It could be compared to using deterministic scripts or functions in an app or process, instead of relying solely on AI to produce an output, which, without the perfect harness and instructions and context management, has a risk to hallucinate or drop data points.

When Aether (or Vesper) does give you a number, you can trace the inputs and be confident there were no hidden assumptions in there that you did not make or agree to. Every figure on the page either came from the client file or from an officially published rate for that financial year, and if neither was available, you were told then and there, rather than in a footnote somewhere.

I’ve watched people cross-check a platform’s output to their own spreadsheets before daring to trust it for a client communication (I did this a lot myself), and often they did have to make adjustments or fixes. This wasn’t always described as a design failure, it was kind of expected. But really, if you have to verify the tool’s arithmetic by hand, the tool is no longer pulling the weight that you pay it to, and the responsibility at the end of the day for an incorrect figure sent to a client still falls in your lap.

The rule

This is the logic that gets applied to every calculation we add:

If an output can’t be traced back to a client fact or an official rate, then it’s not only a weak link in a delicate chain of calculations, but potentially a different kind of thing entirely to how it appears on the surface. Once it’s on the page, there is nothing about it that explicitly tells you what you are really looking at.

So we prevent that situation from arising in the first place.