The Transaction Inbox

What this does

Accounting → Transaction Inbox is the holding area between "the bank says money moved" and "it's in the ledger." Each row is a proposed transaction: a date, a payee, an amount, the account it came from, and (when the app could work it out) the expense account it belongs to. Nothing in the inbox is in your books until you approve it. Approving posts a real, balanced transaction; rejecting discards the row and posts nothing.

Rows arrive from three places: bank and card alert emails forwarded to the intake mailbox (see Email intake), receipts and bills the document reader extracted a payment from, and lines from a statement import that weren't already on the books.

Before you start

accounting.manage. The bank or card account the alert refers to must exist with its last four digits filled in, or the row lands with no matched account and can't post until you pick one.

The queue

The default view, Queue, is everything still needing a decision: Pending (new) and Needs review (the app tried something and stopped: no matched account, no category, a possible duplicate, a deposit that needs identifying). Approved, Rejected, and Voided are history. Duplicates is its own list, below. All is everything. Counts on each pill are exact.

Columns: Date, Payee, Amount, Confidence (how sure the app is about the payee and category; under 70% is flagged), Status, and Actions. Sort by any of them. A row with a source document opens that document when clicked; a bank-alert row with no document doesn't.

Actions on a row

Approve opens a confirmation showing exactly what will post: the payee, the amount, the expense account, and the bank or card account it hits. If the row has no category yet, the dialog makes you pick one before the button enables; there is no blind approve. Tick remember on that pick and the app creates a payee rule so the next row with the same payee arrives pre-categorized.

If the row is linked to a vendor bill (the document reader created one), Approve approves the bill instead of posting an expense. Nothing hits the ledger until the bill is paid from Payables, and the dialog says so. If the bill's lines don't add up to its total, Approve refuses and points you at the bill to fix it; the app never invents a balancing line.

Edit and approve (the pencil) lets you correct the date, amount, payee, and account first, then approves in the same step. The original bank text stays visible under Source so you can see what you changed. On a row that came from a document, the pencil opens the document instead; corrections and filing happen there (see Reviewing and filing).

Identify deposit (on money-in rows) replaces Approve. A bank credit can't be approved as an expense; it has to be explained as a customer payment or as other money. See Identifying deposits.

Reject discards the row, with an optional reason that's kept. Rejecting a row linked to a bill marks the bill rejected too. Use it for alerts about personal spending on a shop card, test transactions, or anything you've already entered by hand.

Open the created transaction (after approval) jumps to the check or card transaction the row became.

Bulk. Tick several rows and approve or reject them together. Each one posts exactly as a single approve would, and the confirmation summarizes what's in the batch. Rows with no category aren't posted; they go to Needs review with the reason. Money-in credits and bills that can't post are left out of a bulk approve and counted in the result, because each needs its own decision.

What happens in the books

On a checking or savings account, an approved withdrawal, fee, or check posts Dr the expense account / Cr the bank account, and a check-register row is created with status Cleared. On a credit card, an approved charge posts Dr the expense / Cr the card; a credit or refund posts the reverse; a card payment posts Dr the card / Cr the offset. A deposit on a bank account is never posted by Approve; it goes through Identify deposit.

Every approval runs through the same gates as manual entry: the period lock, the duplicate check, and the refusal to post without a category. A row that fails a gate goes to Needs review with the reason on it rather than posting something half right.

Duplicates

Two tiers. The hard gate is exact: the same alert email, or the same account, amount, date, and time, is the same transaction, and Approve refuses to post the second copy. The soft flag is a row with the same amount and date as an earlier row and a payee name that reads as the same party. That row is marked a possible duplicate, listed under Duplicates next to the row it matched, and Approve refuses it until a person decides. Nothing is ever flagged or blocked on amount and date alone; two customers paying $168.86 the same day are two deposits.

Dismiss as duplicate rejects the flagged copy and keeps the original. There is currently no button for the other answer ("it's real, keep both"); a flagged row that is a legitimate second transaction has to be entered by hand from the Checks or Credit Cards screen and the flagged row rejected.

A statement line that matches something already posted never becomes an inbox row at all; the importer marks it matched.

Common problems

"No matched account." The alert's last four digits don't match any active bank or card account. Fix the account number under Banking → Bank Accounts or CC Accounts, then Edit and approve the row and pick the account.

"No category account on the inbox item." Nobody has said what this purchase is. Approve and pick the account; tick remember if this payee will recur.

A row is stuck in Needs review after I picked an account. Read the reason on the row. A period lock covering the date, or a duplicate flag, each needs its own fix first.

Something posted that I meant to reject. Open the created transaction from the row and void it from the account register. See Editing and voiding posted transactions.

The same purchase shows as a receipt row and a bank-alert row. They came in through different doors and have different keys, so both look legitimate. Approve one and reject the other; if you approve both, the exact-key gate catches the second only when its account, amount, date, and time match the first.