Reading a case: roles, requirements and the client's needs

Most weak case responses go wrong in the first thirty minutes, before a word of analysis is written. The candidate reads the case once, starts writing about the first issue that looks familiar, and discovers two hours later that the client's real concern was somewhere else. This lesson is about those first thirty minutes: how to read a case, how to identify your role and the user, how to distinguish what you are asked from what you should notice, and how to rank the issues so that your time goes where the marks are. Lesson 10 covers writing the response; this lesson covers deciding what to write.

Who are you, and who is reading?

Every case puts you in a role. You may be a CPA employed by the company, a staff accountant at a firm, a senior manager, an advisor engaged for a specific project or a member of a board committee. The role determines what you can do and how you should write. An external auditor cannot design the client's controls or take management decisions, because that would impair independence; an internal controller can. An advisor to a buyer looks at a target sceptically; the target's own CFO presents it favourably but honestly. If you misread your role you will give advice that someone in that role could not properly give.

The user is the person your response is addressed to, and usually there is more than one. The chief executive wants to know what to do; the board wants to understand risks; the bank wants assurance; a partner wants a memo that can go to the client with light editing. Identify the primary user and their decision. Then list the secondary users and what they need from the same information. A financial reporting issue looks different to a lender who tests covenants than to a buyer who is setting a price. Writing for the user is the single best way to keep your analysis relevant.

Cases also tell you about the entity's constraints: its size, its stage of growth, its ownership, its financing and any deadlines. A private company owned by a family that plans to sell in two years has different priorities from a listed company with a new chief executive. Those details shape which accounting framework applies (IFRS Accounting Standards for publicly accountable enterprises, ASPE for many private ones), whether an audit or a review is enough, which tax planning is appropriate and how much risk the owners will accept. Note them as you read; they are the context in which every recommendation must make sense.

Directed and undirected requirements

The case requirements tell you some of what to do. A directed requirement is stated explicitly, often in a memo from a partner or the client: 'Please analyse the accounting for the new contracts and calculate the impact on our covenant ratios.' An undirected requirement is not stated but is clearly signalled by the facts, and the marker expects a competent professional to notice it. If the case mentions in passing that a supplier has stopped shipping because invoices are unpaid, a competent professional would see a liquidity and going concern issue even if nobody asked. Undirected opportunities are part of why cases are realistic: clients do not always know what they should be asking.

Two rules follow. First, always answer the directed requirements; they are where most of the marks are and markers notice when one is missing. Second, look for undirected issues, but give them proportionate time: a short, sharp paragraph that identifies the issue, explains why it matters and recommends a next step is usually enough. Candidates who turn an undirected issue into a long essay often do so at the expense of a directed one.

A reading method

There is no single correct way to read a case, but a disciplined method beats reading from the first page to the last. Many experienced writers start with the requirements, then skim the whole case to understand the business and the role, then read the exhibits closely with the requirements in mind. As they read they make a running list of issues, each with a note of the relevant facts and the exhibit or page where they appear. By the end of the reading they have an issues list, a sense of which issues are directed and which are not, and the numbers they will need. Some writers prefer to read the background first so that the requirements make sense; either approach works if you finish with a complete list.

Write your issues list in a form you can work from. A simple table with columns for the issue, the area, the key facts, the user's concern and a priority score will serve you well. It prevents you from forgetting an issue you noticed early, and it gives you something to check against at the end: every directed requirement should be on the list, and every issue on the list should have been addressed or consciously set aside.

Ranking issues

Not every issue deserves the same time. Rank them using a few questions. How important is it to the user's decision? How large is it, in dollars and in risk? Is it directed? Is it urgent, for example because a deadline or a covenant test is near? Does it affect other issues, so that resolving it changes the analysis elsewhere? A practical scoring system multiplies importance by urgency, each on a scale of one to five, and then adjusts for whether the issue is directed. The program below applies that idea to a case with eight issues and a four-hour time budget, after setting aside 25 minutes for reading and 15 for planning.

# Ranking the issues in a case by importance and urgency, then budgeting time.
issues = [
    # (issue, importance 1-5, urgency 1-5, quantitative?)
    ("Revenue recognition on bundled contracts", 5, 4, True),
    ("Going concern doubt from covenant breach", 5, 5, True),
    ("Capital budgeting for the new line", 4, 3, True),
    ("Control weakness in purchasing", 3, 3, False),
    ("Tax on the planned share sale", 4, 2, True),
    ("Lease or buy the warehouse", 3, 2, True),
    ("Board asks about ESG reporting", 2, 2, False),
    ("Inventory count procedures", 2, 3, False),
]
minutes = 240 - 25 - 15          # total, reading, planning
ranked = sorted(issues, key=lambda r: (r[1] * r[2], r[1]), reverse=True)
score_total = sum(r[1] * r[2] for r in ranked[:6])
print(f"{'Issue':44}{'Score':>6}{'Minutes':>9}")
for name, imp, urg, q in ranked:
    s = imp * urg
    m = round(minutes * s / score_total) if ranked.index((name, imp, urg, q)) < 6 else 0
    print(f"{name:44}{s:>6}{m:>9}")
print()
print("Covered in depth:", sum(1 for r in ranked[:6]), "issues;", "left for a one-line mention:", len(ranked) - 6)

Issue                                        Score  Minutes
Going concern doubt from covenant breach        25       62
Revenue recognition on bundled contracts        20       50
Capital budgeting for the new line              12       30
Control weakness in purchasing                   9       22
Tax on the planned share sale                    8       20
Lease or buy the warehouse                       6       15
Inventory count procedures                       6        0
Board asks about ESG reporting                   4        0

Covered in depth: 6 issues; left for a one-line mention: 2

The scoring gives the going concern and revenue recognition issues almost half the writing time between them, and it leaves two minor issues with no dedicated time. That does not mean ignoring them: a sentence each in an 'other matters' section shows the marker that you noticed them and judged them minor. The numbers in the program are a guide, not a rule. If the revenue issue drives the covenant calculation that drives the going concern assessment, you will analyse them together, and the time will flow between them naturally.

Be careful with issues that look technical and interesting but are small. A complex consolidation question about a subsidiary that represents two per cent of the group, or a clever tax structure for an amount that would save a few hundred dollars, can consume time out of proportion to its value. The best writers ask, before they begin each issue, how much the answer could change the user's decision. If the answer is 'not much', they write a short paragraph and move on.

Reading the numbers

Cases contain financial statements, budgets, quotes, tax data and schedules. Do not treat them as background. Before writing, look for the numbers that matter: totals that look wrong, ratios that are close to covenant limits, trends that change direction, figures in the narrative that do not match the exhibits. A quick ratio calculation, such as current ratio, debt to EBITDA, gross margin and days receivable, often reveals the issue that the case writer planted. Markers reward candidates who use the case numbers to support their points, and they especially reward candidates who notice that an accounting adjustment changes a key number.

Make your quantitative analysis purposeful. Before you calculate, decide what question the calculation answers and how the answer will affect your recommendation. A contribution margin analysis for a special order answers 'does it add profit?'; a net present value answers 'does it create value?'; a covenant recalculation answers 'is the company in breach after the adjustment?'. Then show the calculation clearly, state your assumptions and explain the result in words. Lesson 10 returns to how to present calculations.

The ethics lens

Read every case with an eye on professional ethics. Cases often include a pressure point: a manager who wants a favourable estimate, a client who wants to delay recording a loss until after a financing, a relative who asks for confidential information, a fee arrangement that could threaten independence. Under the CPA Code of Professional Conduct you must act with integrity and objectivity, maintain confidentiality, avoid conflicts of interest and, in assurance roles, remain independent. A competent response identifies the ethical issue, explains which principle is at stake and recommends what to do, such as discussing it with the engagement partner or declining a request. Ethics is an enabling competency, and it is assessed in context rather than in a separate section.