How to Evidence Client Objectives in an SoA

Of all the elements in a Statement of Advice, the documentation of client objectives is one of the most frequently called out in adviser reviews. Not because advisers fail to ask clients about their goals - but because the goals that end up in the SoA are often so vague that they cannot do the job the law requires them to do.

This article explains what the law requires when it comes to evidencing client objectives, how to capture them in a way that actually supports your advice, and the pitfalls that turn a well-intentioned SoA into a compliance problem.

Why Evidencing Objectives Matters Under the Law

Under s961B(2)(b) of the Corporations Act 2001, one of the steps an adviser must take to satisfy the best interests duty safe harbour is to identify the objectives, financial situation and needs of the client that the adviser reasonably considers are relevant to the advice. Those objectives must then appear in the SoA under s947B(2)(a).

The objectives recorded in the SoA serve a critical function: they are the benchmark against which the adviser's recommendation is assessed. If the objectives are generic, the recommendation cannot be meaningfully assessed against them. If the objectives are specific but the recommendation does not address them, a gap is visible. In both cases the SoA fails - for different reasons.

What 'Relevant' Objectives Means

Section 961B(2)(b) uses the phrase "relevant circumstances", which includes only the objectives, financial situation and needs that the adviser reasonably considers relevant to the advice being given. This means:

• You do not need to record every goal the client has ever mentioned - only those relevant to the subject matter of the advice.

• You do need to record all objectives that are relevant - omitting an objective because it is inconvenient or conflicts with the recommendation is not acceptable.

• Where a client has conflicting objectives, both should be documented and the SoA should explain how the recommendation navigates that tension.

The Difference Between Generic and Specific Objectives

The single most common documentation failure is generic objective statements. Compare the following:

Generic (not compliant): "Susan wants to grow her wealth over the long term and protect her family."

Specific (compliant): "Susan's primary objective is to accumulate sufficient superannuation to retire at age 60 with income of approximately $65,000 per year (today's dollars). She also wants to ensure her mortgage is covered if she becomes unable to work, as her husband does not work and they have two dependent children."

The second version allows a reviewer to assess whether the advice actually addresses Susan's objectives. The first version could be written about almost any client, which means it cannot serve as a meaningful benchmark for the advice.

How to Capture Objectives Effectively

Good objective documentation starts in the fact-find, not the SoA. The quality of what appears in the SoA depends on what was actually captured in the client conversation. Some practical approaches:

• Ask for numbers where possible: retirement income targets, specific amounts, target dates. Quantified objectives are more specific and easier to link to recommendations.

• Distinguish between primary and secondary objectives: not all objectives carry equal weight for the client, and that hierarchy should be reflected in the SoA.

• Record the client's own words where they are precise: if a client says "I want to be mortgage-free before my kids start secondary school", that is more useful than "reduce debt".

• Include needs that the client may not have articulated: a client focused on investment returns may not have mentioned life insurance needs - but if the need exists and is relevant, it should appear.

Connecting Objectives to Recommendations

Recording specific objectives creates an obligation that must be discharged: the recommendations in the SoA must actually address those objectives. When reviewing a draft SoA, read the objectives section and then read the recommendations section and ask:

• Does each objective have a corresponding element in the recommendations? If not, either the objective is not relevant (and should not be in the SoA) or the recommendation is incomplete.

• Does the recommendation explain how it addresses each objective? The connection should be stated, not left for a reviewer to infer.

• Where objectives conflict or cannot all be fully met, does the SoA acknowledge this and explain how the recommendation navigates the competing priorities?

Are your client objectives doing their job in your SoAs?

RegiReview checks whether the client objectives in your SoAs are specific enough to support the recommendations made and connected to the advice in a way that satisfies the s961B best interests duty framework. Start with a sample review and see where your documentation stands.

---

Not sure if your SoAs are compliant?

RegiReview assesses your advice documents against current requirements and gives you a clear picture of where the gaps are and what to do about them.

Claim your free credits now

No obligation. Results in under 30 minutes.