Compliance & Reality
The Difference Between Tracking Money and Governing It
The software tracked every dollar perfectly. It just didn't stop us from spending reserve funds on operating expenses. Here's why tracking isn't enough.
The board gets the monthly financial report. Every transaction is recorded. Every dollar is accounted for. The books balance perfectly.
The report also shows that operating expenses were paid from the reserve fund last month. The association's governing documents prohibit this without a special resolution. No resolution was passed.
The software tracked the improper payment perfectly. It recorded every detail. It generated a clean report.
It also let it happen.
Tracking vs. Governing
Most accounting software is designed to track: record what happened, categorize transactions, produce reports.
What HOAs need is software that governs: enforces rules, prevents violations, blocks unauthorized actions.
| Tracking | Governing |
|---|---|
| Records transactions | Validates transactions before recording |
| Categorizes spending | Restricts spending by category and rules |
| Reports on fund balances | Prevents prohibited inter-fund transfers |
| Shows what happened | Blocks what shouldn't happen |
| Audit evidence of violations | Prevention of violations |
Tracking tells you what went wrong after the fact. Governing prevents wrong things from happening.
The Fund Accounting Problem
HOAs don't just have money. They have funds—pools of money with specific purposes and restrictions.
Operating Fund: Day-to-day expenses, assessments, utilities, management Reserve Fund: Major repairs, replacements, capital projects Special Assessment Fund: One-time levies for specific projects
These aren't just accounting categories. They're legal restrictions. Reserve funds exist because state law or governing documents require them. Using reserve money for operating expenses may violate: - State HOA statutes - The association's CC&Rs - Fiduciary duty to members - Lending covenants
Software that lets you "categorize" a transaction after the fact doesn't help. You need software that blocks the transaction before it happens.
How Governance Failures Happen
Scenario 1: The Check Run
AP processes weekly checks. A landscaping invoice is coded to the reserve fund (wrong—it's operating). The software accepts it. The check prints. The vendor cashes it.
Two months later, the reserve study shows an unexpected shortfall. Investigation reveals the miscoded payment. By then, correcting the books requires board action, and the cash has already moved between bank accounts.
Scenario 2: The Transfer "Loan"
Operating funds are short. The treasurer authorizes a "temporary" transfer from reserves to cover payroll. The software processes the transfer. No one documents the board authorization that should have been required.
A year later, a new board member asks why reserves are lower than expected. The transfer is discovered. Was there board approval? The minutes don't show it. Was it repaid? The records are unclear.
Scenario 3: The Emergency Repair
A water main breaks. The manager writes an emergency check from the reserve account. It's a legitimate reserve expense, but it exceeds the manager's spending authority.
The software processed it. The repair was done. But the authorization wasn't obtained. When the board finds out, trust is damaged—not because the expense was wrong, but because controls weren't followed.
Learn more about what fund accounting actually means
What Governance Actually Looks Like
Software that governs money implements posting rules—configuration that determines what transactions are allowed.
Fund Transfer Rules - Operating → Reserve: Blocked without board resolution - Reserve → Operating: Blocked without board resolution + repayment plan - Within fund: Allowed
Spending Authorization Rules - $0-$1,000: Manager authority - $1,001-$10,000: Board approval required - $10,000+: Board approval + two signatures
Reserve Spending Rules - Must match registered component - Must be within component budget - Must have supporting documentation
These aren't suggestions. They're constraints enforced at the moment of transaction creation.
Building software that governs requires treating business rules as first-class data, not hardcoded logic.
Rules as Configuration
Every association has different requirements: - Different spending thresholds - Different approval chains - Different fund restrictions - Different documentation requirements
Instead of building each association's rules into code, governance software stores rules as configuration: - Fund transfer rules (which transfers need what approval) - Spending limits (who can spend how much) - Component restrictions (what reserve funds can pay for) - Period restrictions (when certain transactions can post)
The same software serves different associations with different rules.
Rule Evaluation at Posting
When a user attempts to create a transaction: 1. System evaluates all applicable rules 2. Rules return: Allow, Block, or Require Approval 3. If Block: Transaction rejected with explanation 4. If Require Approval: Transaction queued for authorized user 5. If Allow: Transaction proceeds
The user doesn't choose whether to follow rules. The system enforces rules automatically.
Approval Workflows
Some transactions aren't automatically allowed or blocked—they require approval: - User submits reserve expenditure - System identifies: "This exceeds manager limit of $5,000" - Transaction enters approval queue - Board treasurer reviews and approves - Transaction posts with approval chain recorded
The approval is part of the transaction record. Auditors can verify authorization.
Component Registry Integration
Reserve spending shouldn't just be "reserve fund." It should be linked to specific components: - "Roof Reserve - Building A" - "Elevator Reserve - Main" - "Pool Equipment Reserve"
When a reserve payment posts, the system validates: - Does this vendor do this kind of work? - Is this component in the reserve study? - Does this exceed the component's remaining funding?
Miscoded expenses are caught at entry, not at audit.
Violation Logging
When rules block transactions, the attempt is logged: - Who tried what - Which rule blocked it - Timestamp and context
This creates visibility into governance pressure. Are users frequently hitting spending limits? Maybe thresholds need adjustment. Are fund transfer attempts common? Maybe there's a cash flow problem.
Blocking violations is step one. Understanding patterns is step two.
Configuration-driven posting beats hardcoded logic because every association's rules are different, and those rules change.
Explore how CommunityPay enforces fund integrity
The Fiduciary Question
HOA boards have a fiduciary duty to members. This means: - Acting in the association's best interest - Following governing documents - Protecting association assets
Software that tracks violations creates evidence of breach. Software that prevents violations protects board members from inadvertent breach.
When a board member asks "Did we follow proper procedures?", the answer should be: "The software wouldn't let us not follow procedures."
What Boards Should Demand
From your HOA accounting software:
-
Are fund transfer rules enforced? Not suggested—enforced. Can the system be configured to block unauthorized transfers?
-
Are spending limits real? Can a user exceed their authority? The answer should be "no" without exception.
-
Is reserve spending validated? Can you pay a general contractor from reserves? Only if it's coded to a registered component.
-
Are approvals tracked? Every authorized transaction should show who approved it and when.
-
What happens when rules are violated? The transaction should be blocked, not just flagged.
The Difference in Practice
Tracking software says: "Here's a report showing that $15,000 was spent from reserves on operating expenses last quarter."
Governing software says: "That transaction cannot be posted. Reserve-to-operating transfers require board resolution. Upload resolution or request approval."
The first creates work for auditors. The second prevents work for everyone.
See how CommunityPay governs money with configuration-driven posting rules—not just tracking, but enforcement.
How CommunityPay Enforces This
- Fund transfers require explicit authorization rules
- Reserve spending validated against component allocations
- Posting rules prevent cross-fund violations at entry time
- Governance violations blocked, not just logged
CommunityPay · HOA Accounting Platform