All 190 journal entries balance: debits equal credits across the whole ledger.

For every CC payment leaving a bank account, we look for a CC account with at least one transaction that month. No CC data → the deductible-level detail behind that payment is missing; you'll lose tax visibility into what was actually charged.

Months between an account's first and last imported transaction that contain zero rows. Most likely a missing CSV/PDF import.

Rows with amount = 0. Usually a parser glitch: the source file had a blank or unparseable amount column. Worth deleting or re-importing.

Rows dated after today. Almost always a date-format parsing bug, e.g. an MM/DD/YY file mistakenly read as DD/MM/YY swapped a 2024 date into the future.

Rows pointing at a vendor, customer, job, cost code or account that no longer exists. The database enforces its declared foreign keys, but a lot of these links can't be declared, because they were added by a later migration, they're polymorphic (a sibling column says which table), or the id is buried inside another value. Nothing checked them until now, so they could accumulate silently and survive a backup/restore. None of this loses money; it shows up as a blank payee, an uncosted job line, or a recurring template that fails when it next runs.

Every change to a product's quantity or unit cost is written to an append-only movement ledger at the moment it happens, so an item's history has to add back up to the item. This check is here because that should be impossible to break: anything that moved stock without recording it leaves a perfectly ordinary-looking quantity behind, and before the movement ledger existed there was nothing that could notice. If a row appears here, the quantity on the stock list is not the one the postings can explain, so the Balance Sheet and the inventory report will disagree, and a valuation true-up would quietly turn the difference into an expense.

Rows tagged transfer_internal whose counterpart exists nowhere in the book: no row on another account within ±5 days at the matching amount. Usually the other account's statement was never imported, or the row isn't really an internal transfer.
These will not appear in the Transfer Matcher. It pairs up two legs that both exist, and these have only one. Fix them here: pair by ID if you know the counterpart, send it back to Review to re-categorise, or import the missing account.