Deleting properties and bookings — and why some deletes are blocked

Nexxus lets you delete mistakes freely, but blocks deletes that would rewrite financial history. The rule of thumb: if real money touched it, it doesn't delete — it retires.

Deleting a property

Property → Settings → Danger zone. Allowed only when the property has no financial history: no bookings (their ledgers would cascade away with them), no payout lines, no recorded owner payments.

Stopped managing a property? Don't delete it — mark it "No longer managed." Its history stays (your reports and 1099s still need it), it stops counting toward occupancy capacity, and its listing unpublishes. This is the right way to offboard: a departed property is part of your trailing-twelve-month story, not a mistake to erase.

Deleting a booking

From the booking page. Blocked when real money exists:

• Stripe-confirmed payment rows — confirmed rail money can't be orphaned.
• Approved or sent payout lines — severing those would make the next run double-pay the owner.

A clean test or mistake booking deletes fully, taking its ledger rows, deposit record, and payment schedule with it. Tenants (contacts) are never deleted with a booking — the person stays, only the stay goes.

Deleting a test tenant entirely

Removing a tenant end-to-end — contact, portal login, applications, lease — is currently a support task. Once done, the same email becomes reusable. Reach out through the support chat or NexxusHub if you need one cleaned up.

Why so careful?

Every delete guard maps to a real disaster it prevents: a cascaded ledger silently shrinking your income reports, or an owner paid twice because the line connecting money to a prior run vanished. When Nexxus blocks a delete, it names the reason — that reason is the thing being protected.