Categorization
Categorization is the decision of which account absorbed the other side of a bank transaction's money, turning a raw imported fact into a real, balanced journal entry.
In short
Naming the other half of a transaction. The bank side is already known; categorizing says "this $120.50 was Materials," and BalanceMCP posts the balanced entry automatically. It can be split across several accounts, previews before it writes anything, and skips (rather than fails) a whole batch over one bad line.
Also called: categorizing a transaction, coding a transaction
Categorizing a bank transaction is the step that turns a raw fact — on this date, this much money moved, with this description — into an actual journal entry. It's really one decision made per transaction: which account absorbed the other side of the money? The bank side is already known from the transaction itself; categorizing names the rest, and BalanceMCP posts the balanced double-entry automatically, crediting or debiting the bank account by the transaction's own amount.
One transaction can split across several categories at once, as long as the pieces sum exactly to the total — a $310 charge that's really $280 of Materials and $30 of Supplies categorizes as a single transaction with a split, rather than something broken into separate entries by hand.
Categorizing is built for batches, and it's worth knowing what happens when a batch isn't perfectly clean: anything wrong with one specific transaction — already posted, a mismatched account, splits that don't add up, an archived account, a locked period — gets skipped individually with a specific, named reason, while every other transaction in the batch still goes through. One bad line doesn't block the rest.
Like every tool that writes to the ledger, categorizing previews before it commits — the exact journal lines it would post, transaction by transaction, before anything is actually written. A real, current gap worth knowing: a saved categorization rule is not automatically applied here. Rules are stored for reuse, but nothing today reads one back and categorizes a matching transaction on its own.
What people get wrong
- Assuming a saved rule will auto-categorize the next matching transaction — rules are stored but not applied automatically in the current version.
- Assuming split amounts don't need to add up exactly — they're checked arithmetically and rejected if they don't sum to the transaction's total.
- Approving a large batch's preview reflexively without a glance — catching an obviously wrong pattern in the preview costs nothing; catching it after confirming means reversing entries instead.
Common questions
- What happens if a saved rule matches a new transaction?
- Nothing automatic — in the current version, saved rules are stored but not applied. The transaction still shows up unposted and still needs to be categorized directly.
- Can one transaction be split across multiple accounts?
- Yes, as long as the split amounts sum exactly to the transaction's total — categorized as one entry with multiple lines, not several separate transactions.
Machine-readable: /api/knowledge/concept:categorization