Properties are the unit of record

This is the deeper companion to How HomeHerald is organized. If you haven’t read that one yet, start there.

The short version: in HomeHerald, the property is the unit of record. Residents come and go. Money attaches to the property. This article gets specific about what that means in the data model and how to handle the trickier real-world cases.

What a property is, in HomeHerald

A property record represents a single billable unit in your community. That can be:

• A house on a lot in a single-family-home HOA
• A unit in a condo association
• A townhome
• A lot nobody has claimed in HomeHerald but that still owes dues
• A commercial unit in a mixed-use community

What it isn’t:

• The clubhouse, pool, or any other shared amenity (those are Amenities)
• A rental contract or lease (HomeHerald doesn’t model those - the property is the same whether it’s owner-occupied or rented)
• A person (people are Users, attached to properties)

Fields on a property

Field	Purpose
Street address	The physical address. Required.
Lot number	Lot number if your community uses them
Block	Block letter/number, when your import includes one
Assessments	The recurring charges billed to this home: Community Assessments it carries, plus any Property Assessments for this home only
Initial balance	Carry-over balance from a previous system, set by import
Current balance	Computed - sum of all financial records on this property
Status	Occupied or Unclaimed (whether a resident account has claimed it), or a Delinquent label from your import - see Property statuses
Primary resident	The User who is the main contact for this property
Co-residents	Additional Users in the household
Pre-approved people	People on the property who haven’t claimed it yet; a signup matching their email or phone auto-approves onto this home

Why money attaches here, not to people

Three reasons:

1. Continuity. Owners change. If you charge a person, you have to migrate their balance every time the property is sold. If you charge the property, the balance just stays put - the new owner inherits whatever was outstanding (or you write it off at closing, but that’s a transaction, not a data migration).

2. Enforcement. HOAs collect against properties, legally. Liens attach to the property, not the homeowner. If a resident skips town, the next owner is on the hook for unpaid dues. The data model has to match the legal model.

3. Households. Multiple residents can share a property - spouses, family, roommates. There’s one balance, paid by whoever pays. If money attached to people, you’d have to figure out which household member “owns” the dues. With property-attached money, the question doesn’t come up.

What “current balance” actually means

The balance shown on a property is computed live from its financial records:

Balance = Initial balance
        + Sum of all charges (dues, fines, assessments, booking fees)
        - Sum of all payments
        - Sum of all credits
        + Sum of all refunds (refunds add back to the balance)

Positive balance = the property owes money. Negative balance = the property has a credit.

If you see a balance that looks wrong, the transaction log is the source of truth. Don’t try to “correct” the balance directly - find the wrong record and fix it (or add a corrective entry).

History attaches here too

The same logic that keeps money on the property keeps the paper trail there. Open a property and click Notes & history, then the Correspondence tab: board notes, tickets and violations, inbound emails and the replies you sent, mailed letters, announcements and notices, in-app messages, amenity bookings, ledger activity, and work orders at that address, merged into one list, newest first. Chips across the top filter it by type.

The toggle above those chips is the part that matters here. This resident shows one person’s trail. This property (all residents) widens it to the home itself, adding co-residents and everyone who lived there before. That is the answer to “has this ever come up at this house?”, and it’s a question only a property-keyed record can answer. If the drainage complaint was filed by an owner who sold in 2023, the current owner’s file doesn’t have it. The property’s does.

On an unclaimed home there’s no resident to toggle between, so the timeline simply shows the property.

See Board notes on a resident or property for writing notes and for the full breakdown of what the Correspondence tab pulls in.

Edge cases worth knowing

Unclaimed lots

Unclaimed means no resident account has claimed the property in HomeHerald; it may or may not be physically vacant. A property with no resident account is still a property. It still owes dues (if your bylaws say so). The balance grows. No one sees it in the resident portal, but the admin side tracks it normally.

When a buyer eventually shows up, you link them as the primary resident, and they inherit the balance (or you settle it at closing with a one-time credit).

Splits - one property becomes two

Some communities subdivide. Original Lot 12 becomes Lot 12-A and Lot 12-B. The right approach in HomeHerald:

1. Keep the original property as one of the two (update its address to 12-A) - don’t delete it, you want the history
2. Create a new property for 12-B
3. Decide how to handle the old balance: leave it on 12-A, write part of it off via a credit, or move a share to 12-B with explanatory transactions on both
4. Re-link any current residents to the appropriate property

This is rare enough that it’s worth emailing support@homeherald.ai if you’re doing more than one - they can do bulk operations faster than the UI.

Mergers - two properties become one

Reverse of a split. Lots 5 and 6 get combined into a single property.

1. Pick which property to keep as the “merged” record
2. Update its address to reflect the merger
3. Move any residents from the disappearing property to the kept one
4. Settle balances - usually combined onto the kept property with explanatory transactions on both
5. Delete the disappearing property only if it has no payment history (HomeHerald won’t delete one that does). Otherwise leave it with no resident and no assessments, as a record

Shared lots (e.g., common-area buildings)

Don’t model the clubhouse, pool, or any shared building as a Property. Those are Amenities - bookable spaces that can have rules, capacity, fees, and reservations.

If your community has something genuinely odd (e.g., a maintenance shed that’s billed separately for some reason), you can create a property for it with no resident. But this is rare.

Owner with multiple properties in the same community

A resident account lives at one home. For an owner’s other units, put them on file as the billing contact on each one (see Residents and contacts on a property). Each property keeps its own balance, its own dues, its own ledger, and the owner’s portal lists every one under Properties You Pay For, each with its own Pay Now.

There’s no concept of a “consolidated bill” - each property’s dues are independent. If a homeowner asks “why do I have two charges this month,” the answer is “because you own two units.”

What you can’t do

A few things admins occasionally try that the system doesn’t support, by design:

• Split a single dues charge between residents. The dues are on the property. If two residents want to split the cost, that’s between them.
• Move a balance to a person without a property. Money has to live somewhere - on a property’s ledger, ultimately. If you really need to collect from someone who has left (e.g., an ex-resident with an outstanding violation fine), the fine stays on the property’s ledger, and the property record stays around until it’s paid.
• Have a property without an address. The address is required. If your community uses lot numbers only, use the lot number as the address (e.g., “Lot 47, Section B”).

Where to go next

• Editing a property - day-to-day changes
• Property statuses - Occupied vs. Unclaimed vs. Delinquent
• Linking residents to a property - household structure
• How the ledger works - the financial side of the property