An expense categorization preview is useful when you need to inspect proposed categories before transferring reviewed transactions. The result should make the underlying records easier to inspect and the next decision easier to explain. This guide develops a specific expense categorization preview with a source schema, operating rules, a fictional example, and observable review checks. It is intended for someone who already has the underlying material and needs a dependable way to organize it.
Product references checked: 7 October 2026. The examples and implementation specifications below are original editorial guidance. They illustrate expected behavior and have not been presented as a benchmark or as a completed tool tested inside another product.
Define the deliverable and its scope
This is an import preview using supplied category rules. It does not determine tax treatment, accounting policy, or initiate a financial transaction.
Write the acceptance standard before asking Claude for a draft. A reviewer should be able to identify the transaction id, inspect the original description, and understand the export preview without guessing what a blank field means. Decide which records belong in the deliverable, which are out of scope, and who can confirm the final interpretation. Keep those choices visible in the working specification rather than leaving the assistant to supply convenient defaults.
Prepare the source package
Gather sanitized transaction rows, the destination import schema, and an approved category dictionary. Assign source IDs and preserve original wording wherever a small difference could change the outcome. Record the collection date and the version of each source. If two files disagree, keep both references and mark the conflict. Do not replace a disputed value with whichever one produces the cleanest display.
Use a small representative subset for the first draft. Include one ordinary record, one incomplete record, and one record that challenges an important rule. For this task, use the following as the incomplete-record check: An unknown merchant remains unresolved and is excluded from approved-only export. Preserve the original package separately from the assistant's transformed output. A polished result is easier to audit when its IDs still lead back to the original supplied material.
Define the record schema
| Field | Required meaning |
|---|---|
| Transaction ID | Stable original row ID, never derived from a changing display order. |
| Original description | Unmodified merchant text and date from the supplied export. |
| Suggested category | A dictionary category proposed from an explicit matching rule. |
| Review state | Approved, disputed, or awaiting review; confidence alone is insufficient. |
| Rule reference | The rule ID and phrase responsible for the category suggestion. |
| Export preview | Only approved rows in the exact destination schema. |
Treat transaction id as a deliberate part of the data model. Stable original row ID, never derived from a changing display order. Keep its representation consistent when you sort, filter, or revise the output. The original description field has a different job: Unmodified merchant text and date from the supplied export. Combining these fields into one sentence can hide the distinction the reviewer needs to inspect.
Pay particular attention to suggested category and review state. The former means: A dictionary category proposed from an explicit matching rule. The latter means: Approved, disputed, or awaiting review; confidence alone is insufficient. Store them separately and label both in the detail view or report. This makes disagreements visible at the exact point where they affect the result instead of burying them in a general note at the bottom.
Apply the task rules
Rule 1. Leave unmatched transactions uncategorized; never create a category from the merchant name.
Rule 2. Keep duplicate transaction IDs visible and block export until the owner resolves them.
Rule 3. Apply exact rules before broad keyword rules and show which rule matched.
Rule 4. Treat negative amounts, reversals and transfers according to supplied policies, retaining their signs.
Make these rules inspectable alongside the expense categorization preview. Ask Claude to describe how each rule affects a record and what should happen when the supplied data does not establish an answer. A rule written in prose still needs a defined output state. Use an explicit missing, disputed, or not-applicable label where appropriate, and reserve a valid zero or an empty result for cases where it has a defined meaning.
Work through a fictional example
A fictional export contains T01, a 40-unit printing purchase, and T02, a 40-unit refund with the same merchant description. Rule R1 maps ordinary printing purchases to office supplies but provides no refund policy. T01 receives a proposed office-supplies label, while T02 stays unresolved. The preview displays original signs and IDs. Reviewing T01 does not approve T02. If another row repeats T01, the exporter reports the duplicate rather than deleting it. The reviewer supplies the reversal policy before the refund enters the export. The source export remains intact and the destination receives nothing during this preview exercise.
Use the example as a review fixture rather than as real operational data. Before generating the output, write down which fields should be populated and which should remain unresolved. Then compare the generated result with that expectation. If Claude supplies an unsupported value, correct the underlying instruction or calculation rule instead of merely editing the one visible record. Otherwise, the same error may return when the next record is processed.
Build the first version
Ask for the simplest interactive artifact that displays the schema and supports the specific review task. Start with the fictional example and an obvious detail panel. Keep the source data separate from display labels and interaction state. A selected row, a filter, or an open panel should change what the reviewer sees, not silently rewrite the underlying evidence. Add editing only to fields that the specification explicitly identifies as user inputs.
For the first interaction pass, prioritize rule reference: The rule ID and phrase responsible for the category suggestion. Then add the export preview behavior: Only approved rows in the exact destination schema. Use visible text labels for both. Test the core logic before spending time on animation or visual polish. Provide a keyboard path through the controls and preserve a readable empty state when the selected view has no records.
A reusable prompt
Create a expense categorization preview from the supplied source package. Goal: inspect proposed categories before transferring reviewed transactions. Use these fields: Transaction ID: Stable original row ID, never derived from a changing display order.; Original description: Unmodified merchant text and date from the supplied export.; Suggested category: A dictionary category proposed from an explicit matching rule.; Review state: Approved, disputed, or awaiting review; confidence alone is insufficient.; Rule reference: The rule ID and phrase responsible for the category suggestion.; Export preview: Only approved rows in the exact destination schema.. Preserve source IDs. Rules: Leave unmatched transactions uncategorized; never create a category from the merchant name. Keep duplicate transaction IDs visible and block export until the owner resolves them. Apply exact rules before broad keyword rules and show which rule matched. Treat negative amounts, reversals and transfers according to supplied policies, retaining their signs.. First explain the proposed data model and unresolved inputs. Then build the smallest usable version. Use only supplied facts; label the demonstration fictional. Do not invent approvals, thresholds, owners, or external integrations. Include an empty state and explain the expected result for these checks: An unknown merchant remains unresolved and is excluded from approved-only export. A repeated ID blocks export and identifies both source rows. A negative amount keeps its sign through categorization and preview.
Review behavior and edge cases
Check 1. An unknown merchant remains unresolved and is excluded from approved-only export. Record the observed result beside the expected result. If the check fails, isolate the affected rule and request a focused correction before rerunning the same case.
Check 2. A repeated ID blocks export and identifies both source rows. Record the observed result beside the expected result. If the check fails, isolate the affected rule and request a focused correction before rerunning the same case.
Check 3. A negative amount keeps its sign through categorization and preview. Record the observed result beside the expected result. If the check fails, isolate the affected rule and request a focused correction before rerunning the same case.
Repeat the checks after adding another source record or changing the presentation. A working first example does not prove every record is handled correctly. Pay attention to retained selections, stale derived values, and unexplained changes in the number of displayed records. For expense categorization preview work, the reviewer must be able to tell whether a difference comes from new evidence, an edited rule, or merely a changed view.
Maintain the reviewed version
Keep a version label, source cutoff, and short change record with the finished expense categorization preview. Record who approved the rules and which demonstration cases were reviewed. When the source package changes, preserve record IDs and revisit the checks affected by the change. Do not treat yesterday's verified result as evidence that today's replacement input is complete.
Before handing the output to another person, review its audience and the material it contains. Use a sanitized demonstration for general feedback when the real source package is confidential. Explain whether changes are saved, whether the output is a preview, and which source remains authoritative. If persistence or sharing is required, verify that behavior in the actual account and intended environment instead of assuming it from a successful preview.
Frequently asked questions
Can Claude fill missing information automatically?
For this task, missing values should remain visible. Leave unmatched transactions uncategorized; never create a category from the merchant name. Ask for the evidence needed to complete the record instead of letting a plausible substitute become an apparent fact.
What should happen when the source records disagree?
Keep the conflicting records with their identifiers. Keep duplicate transaction IDs visible and block export until the owner resolves them. Ask the responsible owner to resolve the discrepancy or leave the affected outcome unavailable when it depends on the disputed information.
What is the smallest useful review example?
A fictional export contains T01, a 40-unit printing purchase, and T02, a 40-unit refund with the same merchant description. Add the missing or conflicting case described above so the review covers more than a clean successful record.
How do I know the first version is ready?
The required fields are present, the rules are visible, and the three listed checks produce their expected outcomes. In particular: A negative amount keeps its sign through categorization and preview. Review the result in the intended reading or interaction environment.
Should the assistant replace the original source?
Keep the source authoritative and review the transformed output separately. This is an import preview using supplied category rules. It does not determine tax treatment, accounting policy, or initiate a financial transaction. Save revisions with a source cutoff so another reviewer can reconstruct which material produced the current result.
Sources and related reading
Consult the current primary references for account-specific availability and controls: Current Claude artifact documentation, Claude sharing documentation. The schema, examples, prompts, and review checks here are editorial recommendations rather than documented built-in features.
For broader context, read the related Claude workflow guide.
