post_journal_entryWritesPost a manual adjustment that didn't come from your bank
You need to record something that never showed up as a bank transaction — depreciation on a piece of equipment, an owner putting personal cash into the business, an accrual for a bill you haven't paid yet.
Not everything in a set of books comes from a bank feed. Depreciation is a paper entry. An owner's personal contribution might move as cash but needs to land in equity, not just checking. An accrual records an obligation before money moves at all. post_journal_entry is the direct route for exactly this category of adjustment — the same double-entry mechanism categorize_transactions uses under the hood, just without a bank transaction driving it.
The rule is unforgiving in the way accounting itself is unforgiving: every entry needs at least two lines, debits as positive amounts and credits as negative, and they must sum to exactly zero. There's no partial-entry mode and no rounding tolerance — an entry that doesn't balance is rejected before it ever reaches the database, whether you're previewing or confirming.
Like every other tool that writes to the ledger, this previews before it posts. The preview shows the balance check has passed and exactly what would be written, but it does not yet check that every account named still exists and is active — that check happens at the moment you confirm, so a preview that looks clean can still fail on confirm if an account was archived in between.
One more thing worth knowing up front: once posted, an entry cannot be edited or deleted, ever. If you catch a mistake after the fact, the fix is reverse_entry, not a second attempt at editing this one.
What this does not do
- Lines must balance to exactly zero — there is no partial or unbalanced entry, even temporarily.
- The preview confirms the arithmetic balances but does not verify every account still exists and is active; that's checked only when you actually confirm the post.
- Once posted, an entry can never be edited or deleted — only reversed.
Arguments
| Name | Type | Required | What it is |
|---|---|---|---|
bookId | uuid | Required | — |
date | string | Required | — |
memo | string | Required | What this entry is for; the user will read it. |
lines | object[] | Required | At least two lines, summing to zero. |
confirm | boolean | Required | — |
Generated from the tool definition, so it cannot describe arguments the tool does not accept. Unrecognised arguments are rejected rather than ignored.
Common questions
- What's the difference between this and categorizing a transaction?
- categorize_transactions is for something that came in on a bank statement. post_journal_entry is for adjustments that never touched a bank account at all — depreciation, accruals, and similar entries.
- Can I fix a mistake in an entry I already posted?
- Not by editing it — entries are permanent once posted. Use reverse_entry to post its mirror image, then post a corrected entry if needed.
- Why did my entry get rejected even though the preview looked fine?
- The preview only checks that the amounts balance to zero. Account existence and active status are checked at confirm time, so an account archived between preview and confirm can cause a rejection the preview didn't catch.