Evidence you can check, decisions your team makes

Queue design: three lanes, not one long list

A reviewer opening the workspace doesn’t see one undifferentiated pile of work. The queue splits into waiting-on-client, waiting-on-you, and exceptions, and that split does real work: waiting-on-client is a status check, not a task — there’s nothing for a reviewer to do until the client acts. Waiting-on-you is the lane that actually needs attention: a submission has arrived and a decision hasn’t been made yet. Exceptions are pulled out separately again, because a mismatch or an unreadable source needs a different kind of attention than confirming a number that already matches — it needs someone to make a judgment call, not just glance and approve.

Keeping exceptions in their own lane also protects the routine work from getting stuck behind the hard cases. A reviewer can clear ten straightforward acceptances in the time it takes to think through one payroll mismatch, and the queue design means they’re not forced to hit that mismatch first just because it happened to arrive earliest.

Anatomy of the evidence panel

Opening a requirement shows the evidence panel: the extracted candidate value, the source file it came from, the page it was found on, and a version marker if the same document was resubmitted. A reviewer can open the source directly from the panel — there’s no separate step of hunting down the original file in a different tool. If the client’s answer and the extracted document disagree, or if nothing in the source supports a value at all, the panel shows that plainly as an unresolved item rather than picking one number and hoping it’s right.

Three decisions, and a reason library behind two of them

Every requirement resolves through exactly one of three actions: accept, request a correction, or waive. Accepting confirms the evidence is right as shown. Requesting a correction reopens that single requirement for the client with a note explaining what’s wrong, without touching anything else already accepted. Waiving records that this requirement doesn’t apply this period — a seasonal closure, a client who switched processors mid-year — and a waiver always needs a reason, either picked from a reusable reason library or typed fresh if nothing in the library fits. That library grows with a firm’s actual practice: a reason used once becomes available to select again, so a recurring pattern doesn’t need retyping every month.

Deterministic close: no partial handoff

An engagement can be handed off only when every required item has a recorded decision and every required kickoff task is done. There’s no percentage-complete shortcut and no way to mark a month closed with three items still genuinely unresolved. This is a deliberate constraint: a "mostly done" close is exactly the kind of ambiguity that leads to a missing statement surfacing during tax season instead of during the month it actually belonged to.

What’s inside the manifest

Handoff produces a bundle, not just a status flip. It includes a PDF summary readable by anyone — who accepted, corrected or waived each requirement, and their stated reason — a CSV export of the same decisions for anyone who wants to work with the data directly, and the original source files themselves, unaltered. Nothing in that bundle is regenerated or rewritten after the fact; it’s a fixed record of exactly what was decided at the moment the month closed.

Pushing the close into your ledger

For firms connected to QuickBooks Online or Xero, handoff doesn’t stop at generating the bundle — the manifest and originals attach directly to the matching client and period in the ledger. A closed month shows up where the actual bookkeeping work happens next, rather than sitting in a separate portal someone has to remember to check.