How is this different from the spend-audit playbook?

The categorization rulebook is the reference the spend audit uses. The audit scans a month for anomalies and categorizes the loose ends; this playbook builds the categorization-rules.md that tells it which bucket each vendor belongs in. Build the rulebook once (it's a Stage 1 foundation) and feed it into every audit, budget, and close so categorization is consistent instead of re-decided each month.

Why not just tell Claude my categories in each prompt?

Because you'll describe them slightly differently every time, and the same vendor will drift between buckets month to month — which quietly breaks every month-over-month comparison. A written rulebook you attach makes categorization deterministic: the same input produces the same categories, so your totals actually compare.

Will the rulebook make my categorization correct?

It makes it consistent, which is most of the value, but not automatically correct. The rules guarantee a vendor always lands in the same bucket — you still review the mapping itself to confirm that bucket is the right one, and update it when your business changes. Consistency is what the rulebook buys you; correctness is still a human call.

What happens when a brand-new vendor shows up?

The rulebook's most important rule is that an unknown vendor gets left uncategorized and flagged for review — never force-fit into the nearest bucket. You make the call, then add the new vendor to the mapping so it's settled for next month. Flagging the unknown rather than guessing it is what keeps a confident wrong category out of your totals.

Build the categorization rulebook every report inherits

when to reach for this

"Categorize this" means nothing to Claude — and barely more to a new analyst — unless the rules are written down. So every month the same vendor lands in a slightly different bucket: AWS is Hosting one month and Infrastructure the next, and now your category totals don't compare to last month's. The fix isn't to re-explain your chart of accounts in every prompt; it's to extract the rules once into a categorization-rules.md you feed into every spend task. This is the Finance equivalent of a brand-voice doc: build it once and the spend audit, the budget review, and the close all categorize the same way — because "our categories" finally points at a real document instead of each month's guess.

gather this first

Your chart of accounts — the actual category buckets you report on (Payroll, Hosting, Software, Travel, Contractors, Marketing, Professional Fees) — not generic ones.
A few months of already-categorized exports — transactions-q1.csv and similar — so Claude can learn from how you've actually been categorizing, not how you think you have.
The judgment calls only you know: which vendor is capex vs opex, where a blurry vendor (a consultant who's sometimes Marketing, sometimes Contractors) belongs, and any vendor that should always be split across categories.

the workflow

Reverse-engineer the rules from how you already categorize

It's far easier to recognize your categorization logic in real data than to write it from a blank page. In Claude Desktop, open the folder with your past categorized exports and ask in the chat — no terminal needed. Have Claude infer the vendor→category mapping you've been using rather than you trying to list every vendor by hand.

you ask

Read these 3 months of categorized transactions. Reverse-engineer the rules I've been using: build a vendor→category mapping (every vendor I've categorized and the bucket it landed in), note any vendor that appears in more than one category, and list the categories I actually use. Don't invent new categories — just report the rules my own data already follows.

what you get back A draft rulebook grounded in your real history: a vendor→category table ("AWS → Hosting; Notion → Software; Delta Air → Travel"), a flag list of vendors you've categorized inconsistently ("Acme Consulting: Marketing in Jan, Contractors in Feb — pick one"), and your real category list. The inconsistencies are the gold — they're exactly the rules you never wrote down.

The vendors you've categorized two different ways are the whole reason to build this. Resolving each one is what makes next month's totals comparable to last month's.
Pin the judgment calls and the edge cases

A mapping handles the easy 80%. The rulebook earns its keep on the ambiguous vendors — the ones a human keeps re-deciding. Settle each one now, in writing, so it's decided once, not re-argued every close.

you ask

For each vendor you flagged as inconsistent, ask me which category is correct and why, and write the decision as a rule. Then add rules for the edge cases: which vendors are capex vs opex, any vendor whose charges should be split across two categories (and the split logic), and what to do with a vendor that's never appeared before. Make each rule specific enough that someone else would categorize it the same way I would.

what you get back A set of explicit, testable rules — "Acme Consulting → Contractors (they're project labor, not media spend); AWS reserved instances → split 70% Hosting / 30% Infrastructure; any new vendor → leave uncategorized and flag for review, never auto-assign." The judgment that used to live in your head is now on the page.
Assemble the reusable rulebook

Pull it into one clean artifact Claude can apply directly. When Claude writes the file, Desktop shows it as an accept/reject diff first — review it, then save the version of record.

you ask

Assemble everything into a clean categorization-rules.md: a one-line purpose, my category list with a one-sentence definition of what belongs in each, the vendor→category mapping, the judgment-call rules, and a final 'when unsure, flag — never guess' instruction. Keep it skimmable. Show it to me as a diff before saving.

what you get back A single, paste-ready categorization-rules.md — category definitions, the vendor map, the edge-case rules, and the honesty clause — saved as the version of record after you accept the diff.

Save this file. It becomes the first thing you attach to every spend audit, budget review, and close from here on — feed it in and categorization stops being a per-month re-guess.
Battle-test it on a fresh export

Prove the rulebook works by applying it to an export it hasn't seen, then check that it flags rather than guesses on anything genuinely new.

you ask

Using only categorization-rules.md, categorize this fresh transactions.csv. Apply the rules exactly, leave anything the rulebook doesn't cover as uncategorized with a note on why, and give me a count of auto-categorized vs flagged-for-review. Don't change the file — show me the result so I can confirm the rules hold.

what you get back A categorized preview plus a tally — "312 rows auto-categorized by the rulebook, 7 flagged for review (5 new vendors, 2 ambiguous)" — proof the doc is specific enough to apply consistently and honest enough to flag what it can't place.

make it your own

Sync it to your accounting tool: once the buckets are stable, mirror the rulebook's categories to your accounting software's chart of accounts so the mapping is the same everywhere — Claude, your books, and your reports all speak one language.
Multi-entity or multi-currency: if you run more than one entity, add a per-entity section (or a separate rulebook) and a currency rule (which rate, which date) — a single mapping across mismatched entities silently mixes apples and oranges.
Bilingual statements: if vendor names or reports come in both Arabic and English, record the canonical name and its variants in the mapping so "شركة الاستضافة" and "Hosting Co" don't become two vendors. Author the Arabic side from real Arabic statements, don't just transliterate.
Make it a skill (Power Track): advanced teams can load categorization-rules.md as a reusable skill or /categorize command so it's always applied — every spend file is checked against the rulebook automatically (see the Features tab).

watch out for

*Rules make categories consistent, not correct.* The rulebook guarantees AWS always lands in Hosting — it can't tell you Hosting was the right call. Review the mapping itself, and re-verify when your business changes shape.
One canonical rulebook, one owner. A categorization file that everyone edits drifts back into the inconsistency it was built to fix. Keep a single source of truth, version it, and treat changes as a reviewed update — not a quiet edit every month.
Never let it auto-apply to a new vendor. The most important rule in the doc is the honesty clause: an unknown vendor gets flagged, not force-fit into the nearest bucket. A confidently miscategorized row distorts every total downstream.
Keep sensitive vendor and account detail in your approved workspace, and swap anything truly private for a [placeholder] before sharing the rulebook — it's a reference doc, but it still describes your real spend.

you'll end up with A one-page `categorization-rules.md` that makes "our categories" a concrete, testable thing — so the same vendor lands in the same bucket every month, your totals stay comparable, and every other Finance playbook starts from a settled chart of accounts instead of a monthly guess.

Questions people ask

How is this different from the spend-audit playbook?: The categorization rulebook is the *reference* the spend audit *uses*. The audit scans a month for anomalies and categorizes the loose ends; this playbook builds the `categorization-rules.md` that tells it which bucket each vendor belongs in. Build the rulebook once (it's a Stage 1 foundation) and feed it into every audit, budget, and close so categorization is consistent instead of re-decided each month.
Why not just tell Claude my categories in each prompt?: Because you'll describe them slightly differently every time, and the same vendor will drift between buckets month to month — which quietly breaks every month-over-month comparison. A written rulebook you attach makes categorization deterministic: the same input produces the same categories, so your totals actually compare.
Will the rulebook make my categorization correct?: It makes it *consistent*, which is most of the value, but not automatically *correct*. The rules guarantee a vendor always lands in the same bucket — you still review the mapping itself to confirm that bucket is the right one, and update it when your business changes. Consistency is what the rulebook buys you; correctness is still a human call.
What happens when a brand-new vendor shows up?: The rulebook's most important rule is that an unknown vendor gets left uncategorized and flagged for review — never force-fit into the nearest bucket. You make the call, then add the new vendor to the mapping so it's settled for next month. Flagging the unknown rather than guessing it is what keeps a confident wrong category out of your totals.