Prompts for finding problems in your books
This page is for the moment something feels off, or you just want a second set of eyes before you trust a number. BalanceMCP has one tool built specifically to look for trouble, and several others that are useful for tracing a specific number back to what caused it.
Read the note at the bottom before you rely on any of this: the anomaly scanner is deliberately conservative, and an empty result from it means "nothing matched its narrow patterns," not "your books are clean."
Scanning for known patterns
The one tool actually built to look for trouble, and its honest limits.
Scans for three specific patterns: a vendor and amount charged twice within five days, a charge far larger than typical, and a recurring charge whose price went up. It reports what it observed, not a conclusion.
Uses: find_anomalies
Same scan, narrowed to a date range — the duplicate-charge pattern is one of the three it looks for specifically.
Uses: find_anomalies
The price-increase check, which is deliberately strict — it only fires when earlier charges matched exactly in amount and description, so a subscription that varies by a cent won't trigger it.
Uses: find_anomalies
The large-charge pattern, flagged relative to what's typical for the book — it's a flag to look at, not a claim that the charge is wrong.
Uses: find_anomalies
Tracing a specific number back
When you already suspect where the problem is and need to see the trail.
Lists every posting to that account with a running balance, so a jump in the number points straight at the entry that caused it.
Uses: general_ledger
Compares the ledger balance to the statement's ending figure and, if they differ, lists uncategorized transactions that might explain the gap.
Uses: reconcile_account
Lists both posted and unposted transactions so you can spot a duplicate posting, then traces the account it landed on if something looks doubled.
Uses: list_transactions, general_ledger
Entries can never be edited or deleted, only reversed. The reversal posts the mirror image and both stay visible in the history, side by side.
Uses: reverse_entry
Before you trust this month's numbers
A quick gut-check pass before presenting a report as final.
A spending or category total silently excludes anything not yet posted — this is the check for how much is missing before you believe the number.
Uses: list_transactions
Debits and credits should always match. If "balanced" ever reads false, that's a sign something is wrong underneath and worth reporting, not something to explain around.
Uses: trial_balance
Worth knowing before you run these
- find_anomalies checks three specific, narrow patterns. An empty result means none of those three patterns matched — it is not a general clean bill of health, and it will not catch a mistake outside its patterns, including a manual entry posted to the wrong account.
- Nothing here can silently rewrite history. Every fix is either a new entry (a correction, a reversal) or a preview you have to confirm — the record of the mistake stays visible even after it's corrected.
- A reconciliation mismatch or an anomaly flag both describe an observation, not a diagnosis. Read the detail before assuming you know the cause.
Common questions
- If find_anomalies comes back empty, are my books clean?
- Not necessarily — it only means none of its three specific patterns matched. A wrong account on a manual entry, or a mistake outside those patterns, won't show up here at all.
- Can my assistant just delete a bad entry instead of reversing it?
- No — there is no delete or edit for a posted entry, by design. Reversing is the only correction path, and it leaves both the mistake and the fix visible in history.
- What should I do if a reconciliation and an anomaly flag point at the same transaction?
- That's worth a closer look with general_ledger or list_transactions before deciding anything — two independent signals agreeing is a stronger lead than either alone, though still not proof.