AI Usage Policy

BalanceMCP is built to be operated by an AI assistant

That's the point of the product: 19 tools an assistant calls over MCP to read your books, import a statement, categorize transactions, post entries, and run reports. This page is about what that arrangement actually allows and forbids — and, critically, what enforces those limits.

What an assistant can never do, because the database won't allow it

These aren't instructions we've given a model and asked it to follow. They are constraints enforced by the ledger engine and the database underneath it, so they hold regardless of what an assistant is told, how it's prompted, or whether it misbehaves.

• It can never post an unbalanced entry. Every journal entry's lines must sum to exactly zero, checked at the moment it commits — not just in the preview.
• It can never edit or delete a posted entry, or a bank transaction record, or anything already written to the audit log. History is append-only; the only way to correct a mistake is to post a new entry that reverses it, leaving both visible.
• It can never post into a locked period. Once a book is locked through a date, nothing can be written on or before that date by any tool, and a lock can only move forward.
• Every action it takes is logged. There is no tool call — successful or failed — that doesn't produce an audit row tied to the key that made it.
• It can never see or touch a book that isn't yours. Row-level security enforces that at the database layer for every tool call, the same way it does for the web app.

What an assistant can do, and where the checking actually happens

An assistant can read every report, list and search transactions, create a book, import a statement, categorize transactions into accounts, post manual journal entries, reverse a posted entry, reconcile an account, and lock a period. Every one of the tools that writes to the ledger previews the exact effect first and requires an explicit confirmation before it writes anything — read that preview, because it is the real description of what is about to happen, not a summary of it. The one exception is create_book: creating and seeding a book happens on the first call, with no preview step, since there is no ledger effect a preview would need to check.

One honest gap in that pattern: the preview for a manual journal entry checks that the lines balance, but it does not check that every account named actually exists, is active, and belongs to the right book — those are checked only when the entry is actually posted. A preview can look clean and the confirm can still fail. That is disclosed in the tool itself, and it is worth knowing before you treat a preview as a full guarantee.

What today's access model does not give you

An API key is all-or-nothing. There is no way today to hand an assistant a key that can only read your books and never post, reverse, or lock anything — every valid key can call every one of the 19 tools. If you want an assistant to have narrower access than "everything," the only real control available today is not giving it a key at all, or revoking one as soon as you're done with a session.

What an assistant is not

Nothing an assistant connected to BalanceMCP says is tax, legal, or accounting advice. A tool result can tell you your trial balance doesn't foot or that a charge repeated within five days — it cannot tell you what to file or whether a deduction is allowed. Treat its output as accurate arithmetic over the data you gave it, not professional judgment.

A note on what the tools deliberately do not claim

Some tool descriptions are written to say less than they could, on purpose. The anomaly scanner reports what it observed, not what it concludes, because the arithmetic genuinely can't tell a legitimate repeated charge from a duplicate. A saved categorization rule is described as stored only, because nothing currently reads it back. That restraint is deliberate: a tool description is read by a model that will act on it, so it is held to the same standard as the database constraints above — it should never claim more than the code underneath it can actually prove.