What Happens When the Client Changes the Books After You've Started?
An engagement is rarely a single, frozen snapshot of the books. The client posts a late entry, corrects a misclassification, or the bookkeeper simply keeps working while the audit is underway — and at some point the auditor pulls a fresh export, or resyncs from Tally, and now there are two versions of the trial balance in play. This isn't an edge case; it's close to the default. The question that actually matters is what happens to the work already done on the first version when the second one arrives — and it's a question we hear often enough that it's worth answering directly rather than assuming it away.
The failure mode: starting over, silently
A tool that treats every new upload as simply "the current state of the books" has a hidden cost: whatever review, flagging, or commentary the audit team attached to the first version doesn't travel forward automatically, and worse, there's often no visible record that anything changed at all. An auditor who flagged an anomalous journal entry on Monday's export, only to have Wednesday's resync silently supersede it with no diff shown, has no way of knowing whether that entry is still there, was corrected, or was quietly removed. "Identify changes versus the previous upload" isn't a nice-to-have feature request — it's asking for the audit trail to actually behave like an audit trail.
What a resync should actually preserve
Two things need to survive a books update, and losing either one is a real problem: the audit team's own work product (flags, comments, classification decisions already confirmed), and visibility into what changed between versions. A ledger reclassification the team confirmed shouldn't need to be reconfirmed from scratch just because the client added an unrelated journal entry — and conversely, the team needs to actually see what's new, not just trust that nothing important shifted.
This connects directly to cut-off testing, which is one of the places a books update matters most in practice. If a client's books change close to period-end, the auditor needs to know precisely what moved and when — a resync that doesn't surface the delta makes cut-off testing a matter of re-scanning everything from scratch rather than reviewing what specifically changed.
What CORAA does today, and where to keep asking
On CORAA, ledger classification is confirmed once and persists — year over year, "Copy from prior FY" carries confirmed mappings forward so the next audit opens with the same ledgers already mapped and the auditor reviews only what changed, and a "Re-suggest" action re-runs classification specifically after a re-sync or a materiality change, rather than silently re-deriving everything from scratch. That's the verified, shipped behavior.
What we'd say to any firm evaluating this, CORAA included: don't take "it handles updates" as a satisfying answer on its own. Ask specifically whether a mid-engagement resync (not just a year-over-year rollover) preserves in-progress flags and comments, and whether it shows you a visible diff of what actually changed — and ask the vendor to demonstrate it live on a real resync, not describe it in the abstract. That's the standard worth holding every vendor to, including us.
Why this is worth asking about before you commit to a tool
This is exactly the kind of gap that doesn't show up in a demo — a demo runs on one dataset, once. It shows up three weeks into a real engagement, when the client's bookkeeper does what bookkeepers normally do and keeps entering transactions while the audit is underway. Ask any vendor directly: if I pull a fresh export from this client next week, does the work my team already did survive, and can I see exactly what changed? A vague "yes, it handles updates" isn't a real answer — ask them to actually show a before/after diff on a resync during the evaluation.
Frequently Asked Questions
Does re-syncing a client's books during an audit lose the work already done?
It shouldn't — flags, comments, and confirmed classifications should stay attached to what they were confirmed against, with a new data pull layered in as a versioned comparison rather than a silent overwrite.
How do I know what actually changed between two trial balance pulls?
A properly versioned system surfaces the delta explicitly — what's new, what moved, what was removed — rather than requiring the audit team to manually diff two exports to find out.
Why does this matter specifically for cut-off testing?
Cut-off testing depends on knowing precisely what moved near period-end. If a books update doesn't surface what changed and when, cut-off testing degenerates into re-scanning the whole ledger rather than reviewing a specific, known delta.
What should I ask a vendor to demonstrate before trusting their version handling?
Don't take "it handles updates" at face value — ask them to actually resync a dataset live during the evaluation and show you the before/after diff, including whether previously confirmed work survives the update.
Related: Engagement Setup module · Start a free trial