How Propio Determines When a Reconciled Period Becomes Stale
Reconciling a period in Propio creates a verified snapshot: the bank balance and ledger balance matched at a point in time. But bookkeeping isn't always linear — transactions arrive late, categories get corrected, imports bring in historical data. Propio uses two precise rules to determine when a past reconciliation is still valid and when it needs to be revisited.
If a reconciled period suddenly shows as stale, one of two things happened: either a transaction in that period isn't in a final state, or a categorization change affected a balance sheet account. These two rules explain exactly what triggers it — and what doesn't.
The Two Staleness Conditions
Condition 1 — Transaction Status Rule
A reconciled period becomes stale if you — or an incoming bank feed — leave any transaction in that period in a state other than Posted or Excluded.
In practice: if you unpost a transaction that belongs to a closed period, or if a late-arriving transaction lands there and sits in Review, that month's reconciliation is no longer valid.
What triggers it:
- You unpost a transaction in an already-reconciled period
- A late-arriving transaction appears in a closed period and sits in Review
What doesn't trigger it:
- A transaction that arrives and is immediately posted or excluded
Condition 2 — Balance Sheet Impact Rule
A reconciled period becomes stale if you recategorize a transaction in a way that affects a balance sheet account balance.
| Change | Staleness triggered? |
|---|---|
| Expense → different expense | ✗ No — P&L only, balance sheet unchanged |
| Income → different income | ✗ No — P&L only, balance sheet unchanged |
| Capital → different capital account | ✗ No — balance sheet unchanged |
| Expense → asset / liability / equity account | ✓ Yes — balance sheet account affected |
One thing to watch for: when you recategorize a transaction from a P&L account to a balance sheet account, that transaction will disappear from the reconciliation table — it's no longer a P&L entry. If you see a transaction vanish after a recategorization, this is why. The reconciliation will be marked stale and will need to be redone.
The Cascade Effect
When either condition is triggered, the affected month and all subsequent months go stale simultaneously.
This is intentional. Reconciliation periods are linked — each month's closing balance is the next month's opening balance. A change in February doesn't stay in February.
Example: You recategorize a March transaction from an expense account to a loan payable account. March goes stale. April, May, and every reconciled month after it also go stale — because their starting balances are now built on a changed foundation.
Two Types of Locks
Propio distinguishes between two lock tiers for historical periods:
Soft lock — Reconciled periods within the accounting start date.
These periods are protected but not frozen. You can still recategorize transactions, but Propio shows a warning before you proceed. The two staleness conditions then determine whether the reconciliation breaks. Safe changes (expense-to-expense) leave the period intact. Balance sheet changes or unresolved transactions trigger staleness.
Hard lock — Periods before the accounting start date (imported historical data).
These periods are fully frozen. No transactions or journal entries can be created in them — enforced at the UI level. This data came from your source ledger and is treated as immutable historical record.
The Edit Flow for Locked Periods
When you attempt to edit a transaction in a soft-locked period, Propio surfaces a prompt before the change goes through:
- You initiate the change on the transaction
- A warning appears: "This change may or may not affect your reconciliation for this period and subsequent periods."
- If you proceed:
- Change is category-only with no balance sheet impact → the period stays reconciled
- Change violates Condition 1 or 2 → the period and all subsequent reconciled periods go stale
Stale periods remain visible and their historical data is preserved — they simply need to be re-reconciled before you can close the books on them again.
Tips
💡 Expense-to-expense recategorizations are safe. Correcting a miscategorized operating expense won't break a reconciliation. Only changes that touch balance sheet accounts — assets, liabilities, equity — trigger staleness.
💡 Late-arriving transactions are the most common trigger. Bank feeds occasionally deliver transactions days after their post date. If Plaid delivers a transaction dated in a closed period, review and post or exclude it promptly to keep that period clean.
💡 The cascade is a feature, not a bug. It would be worse to have March show as reconciled while its starting balance is silently wrong. Staleness surfacing downstream is Propio protecting the integrity of your entire ledger history.