Each criterion, explained
REIT qualification test monitoring
Asset tests under IRC §856 are measured at statutory quarter-end; the 95% and 75% gross-income tests are annual tax-year tests, but the positions that fail them build up during the quarter. Monitoring between closes lets finance and tax teams see drift before it becomes a qualification problem. The calculation supports the tax team; it does not replace their determination.
What to compare: Asset and gross income tests tracked per entity between quarter closes, with drift alerts.
Ask every vendor: Show the asset and income test calculations for one entity, the inputs behind each, and how often each input refreshes.
Design intent (not built or validated)SeniorCRE today: §856 qualification support is under evaluation — not confirmed, not built. Tax classification and computation require product-owner scope and tax-counsel review; not a tax determination.
TRS and RIDEA / SHOP income classification
In senior housing, RIDEA and SHOP structures mix rents from real property with operating income earned through taxable REIT subsidiaries. Classification decides which bucket each dollar falls into, so the rule and its approver should be visible, not buried in a spreadsheet.
What to compare: Rent and operating income classified by source, with TRS income isolated.
Ask every vendor: Show how one lease or management agreement is classified, who approved the classification, and how a change is recorded.
Design intent (not built or validated)SeniorCRE today: Designed so each classification rule is a governed definition with a named approver. Not built as a working classification workflow.
Distribution requirement tracking
The annual distribution requirement is a year-long obligation. A tracker that shows progress by tax year, with its sources, reduces year-end surprises. The final figure remains a tax-adviser determination.
What to compare: Distributions tracked against the annual requirement by tax year, with supporting evidence.
Ask every vendor: Show the distribution tracker for one tax year and the source of every figure in it.
Design intent (not built or validated)SeniorCRE today: Specified as a tracker on the governed record. Not built.
Covenant monitoring (DSCR, lease coverage)
Covenant ratios decide defaults and cures, so the definition of each input matters as much as the math. Where a number decides who gets paid, owner and operator should agree the definition in advance.
What to compare: Coverage ratios computed per property against lender and lease thresholds, with alerts.
Ask every vendor: Show one coverage ratio, the definition of each input, and who agreed that definition.
Design intent (not built or validated)SeniorCRE today: Designed so coverage inputs use definitions agreed jointly by owner and operator. Jointly agreed contract numbers are not yet built or validated.
Multi-operator portfolio rollups
A portfolio rollup is only as good as the definitions beneath it. Two operators reporting "occupancy" differently produce a rollup that looks precise and is not. Comparisons across operators should also require each operator’s consent.
What to compare: Portfolio views that roll up across operators with property-level drill-down.
Ask every vendor: Show a rollup across two operators and how the solution handles operators that define the same metric differently.
Design intent (not built or validated)SeniorCRE today: Designed around governed definitions, with cross-operator comparison only with each operator’s consent. Not validated with operators.
What "real-time" means, source by source
"Real-time" rarely applies to every source. A general ledger may close monthly while census updates daily. A good solution shows the timestamp and freshness of every figure so a reviewer knows what they are looking at.
What to compare: Refresh timing disclosed for every data source, not claimed once for the whole product.
Ask every vendor: For each source system, how is data received, how often, and how is a stale value shown?
Design intent (not built or validated)SeniorCRE today: Freshness and source timestamps are specified for governed values. No live source feed runs in operator production.
Source authority, reconciliation, and lineage
When trusted systems disagree, someone decides which one governs. A solution that records that decision, keeps the alternate value, and traces the figure to its source makes the number defensible in a review.
What to compare: Every figure traceable to its governing source, with the reconciliation rule and alternate values kept.
Ask every vendor: Trace one reported number back to the source rows, and show which system governs it and why.
Design intent (not built or validated)SeniorCRE today: The Operator-Controlled Operating Record is designed and not yet implemented in any community. Source authority, reconciliation, and field-level lineage are not operator-validated.
Entity and tenant isolation
Portfolio monitoring puts several operators’ data near each other. Isolation enforced at the database level, and tested, is what keeps one operator’s data out of another’s view.
What to compare: Isolation between organizations and entities enforced in the database, with tests.
Ask every vendor: Show the isolation policies and the automated tests that check them.
Design intent (not built or validated)SeniorCRE today: Designed to be enforced at the database row level. That isolation is being hardened and will be verified before any second organization is onboarded.
Audit trail a reviewer can use
Auditors and tax reviewers ask how a number was produced and who approved it. An append-only history answers that directly. Whether it meets a specific audit standard is for your auditors to decide.
What to compare: Append-only history of changes, calculations, and approvals.
Ask every vendor: Show the history of one figure: who changed it, when, and what it was before.
Design intent (not built or validated)SeniorCRE today: Change and approval history is specified for the designed operating record. No operator-production audit trail or auditor attestation is claimed.
Privacy and resident health information boundaries
Senior housing monitoring can pull from clinical systems. Owners rarely need resident-level health data, so the boundary between operating data and health information should be explicit.
What to compare: Clear boundaries for resident health information, with signed agreements where required.
Ask every vendor: Which fields contain resident health information, where are they stored, and which agreements cover them?
Design intent (not built or validated)SeniorCRE today: Boundaries are specified. No operator production data or resident health information is processed today.
Integration with existing systems
Monitoring depends on the systems operators already run. Ask vendors to separate live integrations from tested ones, because the difference decides your timeline.
What to compare: Documented paths to the property, clinical, accounting, and payroll systems already in place.
Ask every vendor: Which integrations are live with a customer today, and which are tested only on sample data?
Design intent (not built or validated)SeniorCRE today: Operator-exported intake is a planned proof gate. No third-party integration is live in operator production.
Dated, sourced claims
Monitoring software is bought on trust in its numbers. A vendor that labels its own maturity plainly is easier to evaluate than one that describes plans as features.
What to compare: Every capability claim labeled with its build state and date.
Ask every vendor: For each capability in your proposal, is it running in production, tested, or planned — and as of what date?
Design intent (not built or validated)SeniorCRE today: This page labels every SeniorCRE capability with its status and date.