Trial Balance Versioning: Reopening a Close Without Losing Its History

A close doesn’t always end when the trial balance is uploaded. An auditor asks a question, a late invoice turns up, a reclass gets booked after the numbers already went to management, and the close gets reopened. The question that follows is always the same: what did the numbers look like before, and what exactly moved? If the old trial balance was simply overwritten by the new one, that question has no answer.

Every upload becomes a version, not a replacement

When a trial balance is uploaded to Rexfin, it isn’t saved over whatever came before it. It’s captured as its own immutable version, anchored into a hash chain specific to that entity or engagement. Each new version links back to the one before it through a chained hash, so the sequence of trial balances behind a close can be verified structurally rather than taken on trust. Uploading a corrected TB after the fact doesn’t erase the version that came before it; it adds a new link to the chain, and the old one is still there.

Diffing one version against another

The reason this matters day to day is the diff, not the snapshot itself. Version N of a trial balance, compared against version N-1, shows exactly which accounts moved, by how much, and (because every version is attributed) whose upload caused it. That’s the difference between “the balance changed” and “we know which account, which amount, and which upload changed it.” The same diff discipline that powers the “what changed since last board” line in the board pack applies here too: comparing two versions of anything in Rexfin works the same way, whether it’s a model or a trial balance.

Reopening a close without losing the old one

Reopening a closed period follows the same promotion discipline Rexfin applies to any version change: the new state is diff-reviewed before it’s treated as authoritative, the resulting version is chain-anchored like every other snapshot, and it’s rollbackable if the restatement needs to be walked back. A closed period that gets reopened and restated isn’t a silent overwrite of what the board or the auditor already saw: it’s a new, reviewed version sitting next to the old one, with an exact record of what moved between them. That’s the “time travel” part: you can always step back to any prior version of the close and see precisely what it looked like at that point, not just what it looks like now.

Not the same problem as a restated filing

Trial balance versioning is about your own re-uploads during your own close: it has nothing to do with whether an external company’s filed numbers changed between two annual reports. That’s a different check: cross-filing corroboration compares a prior period as originally filed against how the next filing later restates it, and classifies the gap as an extraction error or a genuine issuer restatement. If you’re on the receiving end of that kind of restatement (a filing you relied on changes underneath you), here’s how to tell the two apart and what to do next. Trial balance versioning solves the internal half of the problem: keeping your own close’s history intact as it gets reopened, corrected, and closed again.

Where this fits

Every trial balance version, and the diff between any two of them, sits on the same hash-chained, attributable footing as the rest of Rexfin’s version history. Nothing about a close’s past gets lost when the close moves forward: you can always go back and see exactly what the numbers looked like at any point along the way, and exactly who changed what to get from one version to the next.

See the full trust chain on the Rexfin product tour.