How to Categorize a Bank Statement

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 in your books. It's really just a single decision, made once per transaction: which account absorbed the other side of this money? The bank side of the entry is already known; categorizing names the rest.

Before anything can be categorized, a statement has to be imported. Every row needs a date, an amount, and a description, and BalanceMCP checks the statement's own beginning and ending balance against the sum of everything you extracted — if they don't agree, the import is flagged rather than silently accepted, because a mismatch like that usually means a row got missed or duplicated during extraction, which happens most often with a transaction that spans a page break in a PDF. One practical rule worth knowing: import a whole statement in a single call rather than splitting it across several. Deduplication relies partly on where a transaction falls within the batch, so a group of genuinely identical charges (say, three separate $9.99 subscription charges on the same day) that gets split across a chunk boundary can be misread as duplicates and silently dropped.

Categorizing itself is concrete. A $120.50 charge from "HOME DEPOT #4021" gets categorized to Materials expense — you're naming that one account, and BalanceMCP fills in the bank side of the entry automatically, crediting the bank account the money left from the transaction's own amount.

One charge can be split across several categories at once, as long as the pieces add up exactly to the transaction's total. A $310.00 charge might genuinely be $280.00 of Materials and $30.00 of Supplies — categorized as a single transaction with a split, rather than something you'd have to break into separate line items by hand.

Categorizing is built for batches, and it's worth knowing exactly what happens when a batch isn't perfectly clean, since that's the realistic case with two hundred transactions rather than two. Anything wrong with one specific transaction — it's already been posted, the account you named doesn't belong to this book, the splits don't add up to the amount, the account is archived, the transaction falls inside a locked period — gets skipped individually, with a specific, named reason, while every other transaction in the same batch still goes through normally. One bad line doesn't block the rest of the batch, and you're told exactly which transactions were skipped and why, rather than the whole request failing or silently doing less than it claimed.

Like most things that write to your books, categorizing previews before it commits — you (or your AI assistant) see exactly what would post, transaction by transaction, before anything is actually written, and nothing changes until that preview is explicitly confirmed. There's no accidental posting hiding behind a single ambiguous instruction.

In practice, this often looks like handing your AI assistant a batch of uncategorized transactions and a plain instruction — categorize anything from a hardware store as Materials, and flag anything you're not confident about instead of guessing. The assistant applies that instruction transaction by transaction, shows you the preview of exactly what it would post for each one, and only writes anything once you confirm. A vague-sounding merchant description is exactly the kind of thing worth flagging rather than guessing at, and a clear instruction up front makes that more likely to happen.

Before confirming a large batch, it's worth actually reading through the preview rather than approving it reflexively — not line by line necessarily, but enough to catch an obviously wrong pattern, like a whole run of restaurant charges heading to Office Expense instead of Meals. Catching that in the preview costs nothing; catching it after confirming means reversing a batch of entries instead of reviewing one preview.

One honest limitation worth stating plainly: you can save a categorization rule — for instance, "Home Depot charges go to Materials" — but in this version, saved rules are not automatically applied to new transactions as they come in. They're stored, and can be reused explicitly when asked, but don't expect a rule you saved last month to silently categorize a new matching transaction on its own without being invoked. That's a real, current gap, not a hidden feature waiting to be discovered.