When a QuickBooks Checkpoint Goes Stale (and How to Refresh It)

A reconciliation checkpoint proves that URBI and QuickBooks agreed for a fiscal period at the moment you ran it. But books keep moving: a late entry gets posted, or a closed period gets reopened. When that happens, the old proof no longer reflects reality, so URBI marks the checkpoint Stale. This short guide explains why a checkpoint goes stale, what the Stale banner is telling you, and how to get back to a trustworthy result.

Who this is for: Property managers and board members on the Premium accounting plan whose property has an active QuickBooks Online connection. Read the main "Period Reconciliation Checkpoints" guide first if you have not run a checkpoint before.

What "stale" means

Fresh means the checkpoint still matches the current state of your ledger, its result can be trusted. Stale means something changed in the ledger after the checkpoint was computed, so the stored result is no longer guaranteed to be correct. URBI is explicit about this: when a checkpoint is stale, "the prior stamp is not trusted."

Crucially, going stale does not rewrite or delete your previous result. The tie-out numbers from the last run are preserved; URBI only flips the status flag from Fresh to Stale and tells you the result is out of date. Think of it as a "this proof has expired, please re-run" notice rather than a loss of data.

Why a checkpoint goes stale

URBI watches for two kinds of change, on a regular schedule, and marks affected checkpoints stale:

1. A late posting into the period. If a journal entry is posted with an entry date that falls inside the checkpoint's period, but the posting happened after the checkpoint was computed, the checkpoint no longer accounts for that entry. This is treated as a standing condition: as long as that later-posted entry sits inside the period without a fresh recompute, the checkpoint stays stale. A period-close event will not override it, only a recompute clears it.

2. The period was reopened. If a previously closed period is reopened (an override action), any checkpoint for that period is marked stale, because reopening a period signals that its numbers may be about to change.

There is a related, positive case too: when a period is closed, URBI can stamp the current checkpoint as freshly reconciled at close, provided none of the "stale" conditions above are in effect. So closing a clean period locks in its result, while a late posting or a reopen unlocks it as stale.

What the Stale banner tells you

When a checkpoint is stale, the report shows a distinct warning strip:

This checkpoint is stale The ledger changed after this checkpoint was computed (a period reopen or a late posting). Re-run reconciliation to refresh it. The prior stamp is not trusted.

That is the whole message: the ledger moved, so re-run to get a result you can rely on.

How to refresh it

Refreshing a stale checkpoint is exactly the same action as running one:

1. Open the Reconciliation checkpoint report and select the affected fiscal period.
2. Decide whether you need Deep reconcile on (turn it on if you need a certified tie-out, see the main checkpoint guide).
3. Click Re-run reconciliation.

Re-running recomputes the tie-out against the current ledger and QuickBooks, replaces the old result, and returns the checkpoint to Fresh. A recompute is the only way to clear a stale status and, in the late-posting case, to clear the standing condition that keeps it stale.

A walked example

1. On April 2 you run a deep checkpoint for March. Everything ties out; the header shows Fresh and Reconciled.

2. On April 5 your bookkeeper posts a March-dated adjustment they had missed. URBI's periodic watch notices a March-dated entry posted after your April 2 checkpoint and flips the March checkpoint to Stale. Your old numbers are still visible, but the header now shows the Stale badge and the warning strip.

3. You open the March checkpoint, keep Deep reconcile on, and click Re-run reconciliation. URBI recomputes with the new adjustment included. The checkpoint returns to Fresh, and its verdict (Reconciled or not) now reflects the corrected March books.

Edge cases and good to know

• Stale does not lose your data. The prior tie-out result stays intact; only the status flag changes. You can still see the last numbers, you just should not trust them until you re-run.
• A late posting keeps it stale until you re-run. Because a late posting is a standing condition, the checkpoint will not quietly return to Fresh on its own, and even closing the period will not stamp over it. Only a re-run clears it.
• Reopening a period marks its checkpoint stale. That is expected: reopening signals the numbers may change, so the old proof is set aside until you re-run.
• Closing a clean period can lock in a fresh result. If nothing has gone stale, closing the period stamps the checkpoint as reconciled at close.
• The watch runs on a schedule, not instantly. URBI checks for staleness on a regular cycle, so a checkpoint may take a short while to flip to Stale after a late posting or reopen. If in doubt at period-end, just re-run to be sure.

FAQs

My checkpoint says Stale but I did not touch it. What happened? Something changed the ledger for that period after you last ran it, either a journal entry was posted into the period after your checkpoint, or the period was reopened. Re-run reconciliation to refresh it.

Does going stale erase my previous reconciliation? No. The prior result is preserved. URBI only marks it out of date so you know not to rely on it until you re-run.

How do I clear a stale checkpoint? Re-run reconciliation for that period. A recompute is the only thing that returns a checkpoint to Fresh.

I re-ran it and it went stale again quickly. Why? There is likely still a late-posted entry sitting inside that period, or the period was reopened again. Re-running with the current ledger should account for it; if it keeps recurring, check for ongoing postings into that period.

Will closing the period fix a stale checkpoint? Not if a late posting is the cause, that standing condition keeps it stale until you recompute. Closing a period that is not stale can lock in a fresh reconciled result, but it cannot stamp over a late-posting staleness.