Review controls and audit trail

Every ledger line is draft, approved, or excluded. Draft is machine output nobody has checked. Approved means a person looked at it and stands behind it. Excluded means it was deliberately kept out, which is different from a line that was never dealt with and is the distinction that matters during a review.

The ledger filters by state, so a reviewer can work the unreviewed queue rather than scrolling a mixed list. Bulk actions cover the routine cases where a batch is clearly fine.

Edits are recorded per field, with a diff of the previous and new value. If a vendor was corrected, a category changed, or a business-use percentage adjusted from a hundred to sixty, the history shows it. This makes review conversations concrete: instead of arguing about whether a figure was always that way, you can look.

Alongside the ledger history, platform activity is recorded as audit events, including sensitive operations such as revealing a stored secret in the admin interface.

The month-end checklist combines items the platform can determine for itself with items your firm adds by hand, so the parts of your process that live outside the software are still tracked in the same place. When the work is done the period is closed, and closing is reversible for the case that a late document turns up, which it will.

Staff can query a client's books in plain language, grounded in that client's ledger, allocations, runs, and version history. It is useful for the questions that are tedious to answer by filtering, such as what changed on a client's file after a given date, or where a category total came from. Answers are a starting point for review, not a substitute for opening the ledger.