Hidden Risks
Why Your HOA's Books Change After They're "Closed"
We approved the annual financials in March. In July, numbers from January looked different. Here's why most HOA software doesn't actually close periods—and what real period integrity looks like.
The board approved the financial statements at the March meeting. The treasurer presented clean numbers. Everyone signed off. The books for the prior year were officially "closed."
Six months later, the new property manager pulls a report for January. The numbers are different. Not dramatically different—a few hundred dollars here, a reclassified expense there. But different.
What happened?
The "Soft Close" Problem
Most HOA accounting software offers a "close period" function. It sounds authoritative. It suggests finality. It doesn't mean what you think it means.
In many systems, "closing" a period simply:
- Runs a report
- Sets a flag in the database
- Maybe generates a warning when someone tries to post to that period
But warnings can be dismissed. Flags can be overridden. And administrative users often have permission to post anywhere they want.
This is called a soft close. It's a suggestion, not a barrier.
Why Retroactive Changes Happen
Changes to closed periods usually aren't malicious. They're operational:
- Late-arriving invoices: A vendor bill dated December arrives in February. Staff posts it to December "where it belongs."
- Bank reconciliation corrections: Matching errors are "fixed" by adjusting old entries.
- Auditor adjustments: Audit entries are posted to the year under review.
- Reclassifications: An expense was coded wrong; someone corrects it months later.
- Data imports: Migrating systems brings in historical data with different dates.
Each change seems reasonable in isolation. Together, they destroy the integrity of closed periods.
What Boards Actually Need
When the board approves financial statements, they're certifying a specific set of numbers as accurate. Those numbers should never change again.
This is why proper accounting systems distinguish between:
- The period being reported (historical)
- The period in which corrections are made (current)
If you discover an error in January during April, the correction should post in April as a "prior period adjustment"—not modify January's data.
This preserves: - Board approvals: What they signed off on stays signed off - Audit trails: The original state is preserved - Legal defensibility: No question of whether records were altered - Financial comparisons: Year-over-year analysis remains valid
Learn more about why time is the hardest problem in accounting
Real period locking requires architectural decisions that most HOA software vendors avoid because they complicate operations.
Hard Locks vs. Soft Locks
A soft lock shows a warning. A hard lock makes posting physically impossible.
Hard locks require: - Database-level constraints on posting dates - No administrative override (period must be reopened formally) - Audit trail when periods are reopened - Separate workflow for prior-period adjustments
Soft locks require nothing—just a checkbox in settings that anyone can ignore.
The Immutability Requirement
Even within open periods, entries should be immutable. To "change" an entry, you: 1. Post a reversing entry (debiting what was credited, vice versa) 2. Post a new correct entry
This creates a complete history. The original entry, the reversal, and the correction all exist. An auditor can see exactly what happened.
Systems that allow direct edits to journal entries cannot be legally defensible because the original record is destroyed.
Historical Query Requirements
A proper system can answer: "What did the balance sheet look like as of the March board meeting?"
This requires storing not just what happened, but when each entry was recorded. Queries must filter by both: - Transaction effective date (when the event occurred) - System entry date (when it was recorded)
Without this, you cannot prove what the board actually saw when they approved the statements.
Prior-Period Adjustment Workflow
When someone legitimately needs to correct a prior period, the system should: 1. Reject posting to the closed period 2. Offer to create a prior-period adjustment in the current period 3. Link the adjustment to the original entry 4. Flag the adjustment for board notification
This maintains period integrity while allowing corrections.
The ability to correct errors without breaking period integrity is what separates accounting software from spreadsheets wearing a database costume.
Explore how CommunityPay enforces journal entry integrity
What Boards Should Demand
When evaluating HOA software, ask these questions:
-
Can anyone post to a closed period? If yes, your "closes" are meaningless.
-
What's the process to reopen a period? It should require board approval or at least be logged prominently.
-
How do prior-period adjustments work? The answer should involve current-period entries, not historical modification.
-
Can you show me period state at a point in time? The system should reconstruct exactly what existed when statements were approved.
-
Are journal entries editable? If yes, your audit trail has gaps.
The Cost of Unstable History
Books that change after closing create real problems:
- Board distrust: "Didn't we approve this? Why is it different?"
- Audit complications: Auditors must test that nothing changed since last year
- Legal exposure: Financial representations made to buyers could differ from current records
- Reconciliation chaos: Which version of history is correct?
The solution isn't better processes for managing changes. It's software that doesn't allow unauthorized changes in the first place.
See how CommunityPay enforces real period closes with immutable entries and proper prior-period adjustment workflows.
How CommunityPay Enforces This
- Period locks enforced at database level, not just UI
- Journal entries immutable after posting—corrections require reversal entries
- All historical queries return data as-of that period's close
- Adjustment entries clearly marked and auditable
CommunityPay · HOA Accounting Platform