Recognize required Day 3 issues and choose the competency cue before writing technical analysis.
Required issue recognition is the first Day 3 skill. Before applying a rule, performing a calculation, or drafting a recommendation, identify what the case actually requires. A short case can contain several business facts, but only some of them create answerable issues. The task is to separate the client request from the surrounding narrative and choose the professional lens that fits.
Weak Day 3 responses often start with a familiar technical topic instead of the required issue. For example, a contract may look like financial reporting, but the request may be about pricing, tax treatment, assurance evidence, or risk communication. The issue is not the topic that appears first in the case. The issue is the decision the reader needs help making.
| Client cue | Likely competency lens | What the response should do |
|---|---|---|
| “How should this be recorded?” | Financial reporting | Identify recognition, measurement, presentation, or disclosure treatment. |
| “Is this option profitable or efficient?” | Management accounting or finance | Use relevant costs, cash flows, constraints, or performance measures. |
| “Can we rely on this information?” | Assurance | Discuss evidence, controls, procedure design, or reporting implications. |
| “What are the tax consequences?” | Taxation | Identify taxpayer, transaction, timing, compliance, and support needed. |
| “Should we proceed?” | Strategy, governance, or finance | Compare alternatives using risk, feasibility, objective, and constraints. |
| “What should we tell them?” | Communication and professionalism | Write a concise, audience-specific conclusion with caveats. |
The decision maker tells you how to frame the issue. A board may need governance risk and strategic implications. A controller may need accounting treatment and documentation. An owner-manager may need tax, cash-flow, and implementation advice. A partner may need professional risk, evidence, and communication implications.
When reading the case, ask: who is asking, what decision are they facing, and what would make the response useful? This prevents a common error: writing a technically accurate paragraph that does not help the intended reader.
The issue statement should be short. “The issue is whether the contract revenue can be recognized this year” is more useful than “Revenue recognition is relevant.” It names the decision and points to the analysis required.
A competency cue is the fact that turns a business concern into accounting, assurance, tax, finance, management accounting, strategy, or governance work. The cue may be a phrase in the request, a number in an exhibit, a transaction date, a missing document, a risk factor, or a stakeholder constraint.
Do not rely on keywords alone. A case mentioning “budget” might require variance analysis, pricing advice, cash-flow planning, or governance discussion. A case mentioning “CRA” may require tax compliance, documentation, dispute response, or financial statement provision analysis. The surrounding facts decide the competency lens.
When two competency areas appear possible, choose the one that directly answers the request first. If a secondary implication matters, mention it briefly after the main issue is addressed. This protects the answer from drifting into a broad memo.
Background facts help the case feel real, but they do not all require analysis. A company history, market description, management preference, or operational detail matters only if it changes the conclusion. Required issues are created by a request plus a fact that demands professional judgment.
Useful facts usually affect one of these areas: recognition, measurement, tax classification, cost behavior, cash flow, control reliability, evidence quality, risk, governance, stakeholder impact, or implementation. If a fact does not affect one of those areas, it may be context rather than an issue.
Day 3 rewards coverage across required issues. If the case has several issues, address the most direct required issue first, then move through the remaining required items in a controlled order. Do not spend disproportionate time on the first technical idea simply because it is familiar.
Prioritization should consider significance, client request, available facts, and response efficiency. A small issue may need only a sentence and recommendation. A larger issue may need a short calculation, rule application, and caveat. The response should be long enough to support the conclusion, not long enough to show everything you know.
| Pitfall | Better approach |
|---|---|
| Writing about a topic before naming the required issue. | Convert the client request into a one-sentence issue statement. |
| Treating keyword recognition as issue recognition. | Check whether the facts and decision maker support the chosen competency lens. |
| Retelling the case. | Use only facts that change the answer. |
| Ignoring secondary required issues. | Keep the first response proportionate and move to the next issue. |
| Giving a conclusion with no professional lens. | State whether the issue is reporting, tax, assurance, finance, strategy, or communication. |
Use an issue-cue-action pattern. State the required issue, identify the case cue that points to the competency area, then apply only the rule, calculation, or framework needed to support the recommendation. This pattern keeps the answer focused and prevents a short case from becoming an unfocused technical essay.
The goal is not to spot every topic in the case. The goal is to answer every required issue with enough professional support that the reader can see the judgment behind the recommendation.