Categorizing Transactions: Building a Deterministic Chart of Accounts

Categorisation is where raw transactions become meaningful. "PAYMENT TO XYZ LTD ₹2,499" is just a line until it becomes "Software — Subscriptions", at which point it feeds a spending report, a budget, and eventually a tax return. Get categorisation right and every downstream number gets easier. Get it inconsistent and you spend your reporting time reconciling categories instead of reading them.

The principle that makes categorisation trustworthy is determinism: the same transaction should always land in the same category, for a reason you can see and change. This article is about building that — a rules-based categorisation system you can actually audit.

Why determinism matters for money

There is a temptation to treat categorisation as a guessing game where "close enough" is fine. For personal budgeting, maybe. For anything that touches your books, it is not, for three reasons.

• Consistency. If the same coffee-shop charge is "Food" one month and "Travel" the next, your category totals are meaningless. Trends require that identical inputs produce identical outputs.
• Explainability. When your accountant, or a tax authority, asks why a transaction is categorised the way it is, "because a rule matched this merchant" is an answer. "The system decided" is not.
• Editability. Your business is unique. A generic category may be wrong for you, and you need to be able to override it and have that override stick — not fight a system that re-guesses.

Deterministic, rules-based categorisation gives you all three. Given a transaction, a rule either matches or it does not, and you can read the rule.

The anatomy of a categorisation rule

A practical rule has a few parts:

• A pattern — the text to look for in the description or merchant, such as NETFLIX, UBER, or RENT.
• A match type — how the pattern is compared: exact match, "contains", "starts with", or (carefully) a regular expression.
• A category — the bucket the transaction lands in when the pattern matches.
• A direction — optionally, whether the rule applies only to debits or only to credits. "SALARY" as a credit is income; you would not want it matching a debit.
• A priority — when several rules could match, which wins.

That is enough to express the vast majority of real categorisation. NETFLIX → Subscriptions. SHELL → Fuel (Travel). ACME CORP as a credit → Customer Payment. RENT as a debit → Rent. Each is a small, legible statement of intent.

A starter set of categories

You do not need hundreds of categories; you need the right dozen or so for your business. A sensible general-purpose set:

• Income — general money in.
• Salary — payroll received (or paid, depending on your side of it).
• Sales — customer receipts.
• Refund — money returned to you.
• Transfer — movements between your own accounts.
• Rent, Utilities, Food, Travel, Subscription — common operating costs.
• Bank Fee, Tax, Loan Payment — the easily-missed financial lines.
• Card Payment, ATM Withdrawal, Cash Deposit — payment-method buckets where useful.
• Investment — money set aside or invested.
• Other — the honest catch-all for anything unmatched.

Keep the list short enough to be memorable and long enough to be useful. Every extra category is a decision someone has to make on every ambiguous transaction; only add one when it earns its place.

How matching should work in practice

When a transaction arrives, the rules are checked in priority order, and the first match wins. Consider a transaction described UBER TRIP HELP.UBER.COM:

• A rule UBER (contains) → Travel matches. Done.

Now AMAZON WEB SERVICES:

• A generic AMAZON → Shopping rule would match, but a higher-priority AMAZON WEB SERVICES → Software rule matches first. Priority resolves the ambiguity in your favour.

This is why priority matters: specific rules should outrank general ones, so AWS does not get swept into a broad AMAZON bucket. A well-ordered rule set reads like a series of "if this specific thing, then that; otherwise fall back to the general case" statements.

On regular expressions

Regular expressions are powerful and occasionally the right tool — matching ^SALARY.*(ACME|GLOBEX)$ in one rule, say. Use them sparingly and safely: bound their length, validate them before saving, and never let a malformed pattern crash the pipeline. For most rules, "contains" and "starts with" are clearer and safer, and you should reach for regex only when simpler match types genuinely cannot express what you mean.

Categorise once, in the right place

A subtle but important design point: categorisation rules belong to you and your workspace, not baked into the extraction engine. The parser's job is to read the statement correctly. Your categories are configuration layered on top — which means you can change a rule and have it apply to future statements without touching how transactions are read.

This separation is what makes categories editable and portable. Change how SHELL is categorised once, and every future statement follows the new rule. Override a single transaction, and the override is yours to keep. The extraction stays deterministic; the categorisation stays under your control.

Auditing your categories

Because the system is rules-based, you can audit it, and you should:

• Review the "Other" bucket periodically. A growing "Other" means transactions your rules do not cover. Each one is a candidate for a new rule.
• Check high-value transactions. Confirm the big debits and credits are categorised the way you intend; these move your totals the most.
• Watch for rule conflicts. If two rules could match the same transaction, make sure priority resolves them the way you want.

The audit is fast precisely because everything is explainable. You are not second-guessing a model; you are reading rules and seeing which matched.

No black boxes

The temptation, always, is to hand categorisation to something that "just figures it out". Resist it for financial data. The moment you cannot explain why a transaction is in a category, you have lost the two things that make categorisation useful for accounting: the ability to defend it, and the ability to correct it consistently.

Deterministic rules are not the flashy option, but they are the correct one. They are consistent by construction, explainable by design, and yours to edit. Build a small, well-ordered set of rules, keep them in your workspace rather than in the parser, review the exceptions periodically, and your categories will mean exactly what you decided they mean — every month, on every statement, for reasons you can always point to.