|
EXPLAINER |
AI FOR ACCOUNTANTS · PART 10 OF 16
Why structured output beats a paragraph in accounting work
A schema turns a model into a form filler you can check; a paragraph gives you something you can only read.
The core problem with asking an LLM to 'summarize this invoice' or 'pull the key numbers from this lease schedule' is that the answer comes back as prose. Prose looks correct. It reads fluently. But you cannot run a formula against it, route it to a downstream field, or flag a missing value automatically. Structured output - asking the model to return a JSON object, a CSV row, or a fixed schema - changes what the output actually is: a form you can validate, not a paragraph you have to re-read.
The mechanism is straightforward. Instead of prompting 'describe the accrual,' you define a schema: vendor name, period end date, accrual amount, GL code, supporting-document reference. The model fills each field or leaves it null, and null is information. A blank 'GL code' field tells a reviewer something went wrong before the workpaper even gets opened. A prose response that omits the GL code looks like a complete answer until someone catches it three steps later. Structured output surfaces the gap at the point of generation, not at the point of review.
This bites hardest in reconciliations and client-data intake. A reconciliation workpaper has a predictable shape: beginning balance, additions, deductions, ending balance, variance explanation. If you let the model return that as a narrative, every downstream step - tying it to the trial balance, checking the variance threshold, archiving the file - requires a human to re-parse the prose. If the model returns a five-field object, a script or even a simple spreadsheet formula can do those checks in seconds. The same logic applies to client intake: a schema that requires 'entity type,' 'fiscal year end,' and 'prior-year carry-forward amount' will expose a missing field instantly; a paragraph describing the client's situation will not.
The practical shift is small but it has to happen at the prompt level. You define the schema before you write the prompt. Most general-purpose models can be instructed to return valid JSON if you include the target structure in the system prompt or the user turn - paste the field names, their types, and any constraints (for example, 'amount must be a number, not a string with a dollar sign'). Then your validation logic - whether that is a Python script, a Power Automate step, or a manual spot check against a field list - has something to work with. The discipline is treating the schema as the deliverable, not the text that surrounds it.
Worth noting on the broader direction: KPMG announced a new Client Technology and Innovation group this week, formed to build AI-native businesses at speed. Whatever the firm-level strategy, the underlying accounting work still lives in fields, not paragraphs - and that is where structured output earns its keep. For a practitioner modernizing a single workflow, the entry point is not a new group or a new platform; it is writing the schema first, then writing the prompt.
WORKED EXAMPLE
In practice
A staff accountant is building a prepaid-expense amortization schedule. She has twelve vendor invoices in a folder and wants to extract the key fields into a workpaper table without re-keying each one.
What came back. The model returned a twelve-element JSON array. Ten objects were complete. Two had null for gl_code, and one had a prepaid_period_end that fell in the prior period rather than the current month - a likely copy-paste error in the source invoice text. The null gl_codes surfaced immediately in the workpaper review step rather than during the manager review.
How it was checked. The accountant tied each returned invoice_amount back to the scanned invoice total and confirmed prepaid_period_start and prepaid_period_end spanned the correct months against the contract terms on file.
A constructed example. The prompt is usable as written; the figures show the shape of a result, not a measured one.
WHEN TO USE IT
| WHEN NOT TO
|
WHAT TO TAKE FROM THIS
| Define your schema - field names, types, constraints - before writing the prompt. | |
| A null field in structured output is a signal; a missing fact in prose is invisible. | |
| Validate the returned object against expected fields before any downstream step runs. |
SPONSORED
QUESTIONS THIS ANSWERS
What is structured output in the context of accounting AI?
It means instructing a model to return a fixed schema - JSON fields, CSV columns, a defined object - instead of prose. The result can be validated against expected fields, routed to downstream tools, and checked for missing values automatically.
Can I get structured output from a general-purpose model without special tooling?
Yes. Most general-purpose models will return valid JSON if you include the target schema in the system prompt or user turn, specify field names and types, and instruct the model not to wrap the output in explanatory text.
Where does structured output help most in accounting workflows?
Reconciliation workpapers, client-data intake, and accrual schedules - anywhere the output has a predictable shape that needs to tie to a downstream field or formula rather than being read by a human and re-entered.
SOURCES
Where this comes from
What the accounting job market is actually asking for.
GO DEEPER
Go deeper
IN THIS SERIES
Previously: What a token is and why it sets the price of AI work
Next: Why the same prompt gives a different answer twice (coming)
An explainer, not a study: it carries no statistics on purpose. Examples are illustrative.
How accountants are using AI, automation and smarter workflows to close faster, audit cleaner, and free up time for real work.
Accounting Stack · Audit Friendly Data · Accounting & Finance Jobs
Audit Friendly · modernaccounting.ai