Ask Claude for a number without asking for the working, and you get a number you have to trust blind. Ask for the working alongside it, and you get something you can actually check, correct, and defend if a client or an auditor asks where it came from. This is the single highest-value prompting habit for anyone using Claude on financial or operational figures.
Why 'show your working' changes the output quality
Models reason more reliably when asked to lay out steps explicitly rather than jump straight to a final figure, a pattern well documented across reasoning tasks generally. Practically, this means a prompt like 'calculate the effective hourly cost, showing each input value and the formula used' produces a more checkable and often more accurate result than 'what's the effective hourly cost,' even when the underlying calculation is identical. The extra few seconds of generation time is a trivial cost against the value of being able to spot an error before it reaches a client.
A practical structure for number-heavy prompts
State every input value explicitly in the prompt rather than assuming Claude will infer it from context
Ask for the formula or method to be stated before the final number, not just the answer
Request a sanity check: does this number look reasonable given the inputs, flagged explicitly if not
For anything client-facing, ask for the calculation in a format you can paste directly into a spreadsheet to verify independently
A worked example from an accounting practice
A Melbourne bookkeeping firm uses this pattern to check GST calculations on complex invoices with mixed taxable and GST-free line items. Rather than asking 'what's the GST payable on this invoice,' their standard prompt asks Claude to list each line item, its GST treatment, the sub-total for each category, and the final calculation showing the formula. This turned a black-box number into a two-minute review task for the bookkeeper, catching an incorrectly categorised $2,400 GST-free line item in its first month of use that would otherwise have gone straight into a lodgement unchecked.
Where this matters most
This habit matters most for numbers that feed into something consequential: a quote, an invoice, a compliance figure, a board report. For a quick internal estimate where being roughly right is good enough, the overhead of asking for full working isn't worth it. The judgement call is proportional to the cost of the number being wrong, not a rule to apply universally to every calculation Claude touches.
If you're using Claude for financial or operational figures and want help building this kind of checkable-output habit into your team's prompts, get in touch through /contact.
Building this into a reusable prompt template
Rather than re-writing the 'show your working' instruction every time, save it as a standing template: state the calculation required, list every input explicitly, request the formula before the answer, and ask for a plain-language sanity check at the end. Reusing the same structure across similar tasks means the team doesn't have to remember to ask for working every single time, and the habit becomes the default rather than something only the most careful staff member remembers to request.
This same structure works well beyond finance. A logistics coordinator checking a delivery-time estimate, or an ops manager checking a staffing-ratio calculation, benefits from the identical pattern: state the inputs, show the method, flag anything that looks off. The specific numbers change, the discipline of asking for checkable working doesn't.
The habit also pays off in an unexpected place: training new staff. A junior team member reading Claude's shown working on a calculation learns the underlying method faster than they would from a bare answer, because the reasoning is right there to study rather than hidden inside a number they're expected to trust without understanding how it was reached.
There's a broader lesson underneath this specific technique: transparency in AI output isn't a nice-to-have feature, it's a cost-control mechanism in its own right. An error caught during a two-minute review because the working was visible costs almost nothing to fix. The same error, discovered three weeks later in a client's own reconciliation, costs a great deal more, in both time and trust, to unwind.
A small caveat worth naming: asking for working doesn't make Claude infallible, it makes errors visible. The value is in the visibility, not a guarantee. Treat a shown calculation as something to skim-check, not as proof the number is automatically correct simply because the method looks reasonable on the page.
Start with your highest-stakes recurring calculation, whatever it is for your business, and build the habit there first. Once it's second nature for that one workflow, it spreads naturally to the rest without needing a formal policy document to enforce it.
