# Real-time REIT monitoring evaluation scorecard (senior housing)

Scorecard as of September 2026 · last updated 2026-09-17

Score every vendor the same way: **operator production**, **built**, **demonstrable**, **configurable**, or **roadmap**. Score from demonstrated evidence, not from a slide.

| # | Tier | Feature | What to ask | Evidence to request | Score |
| - | ---- | ------- | ----------- | ------------------- | ----- |
| 1 | Core | IRC §856 income and asset tests, computed per entity with freshness and lineage | Can the system recompute the 75% asset test and the 95%/75% gross income tests at the entity level from accepted source evidence with lineage, while showing freshness and exception state? | Ask to see one entity recomputed on a period the vendor did not choose, with each test tracing back to the underlying rows. | |
| 2 | Core | Rule-based alerts with named owners and escalation paths | Can tax, compliance, finance, and asset-management teams set thresholds by entity, metric, and reporting period, with a named owner, acknowledgment state, and escalation path? | Change one threshold, trigger it with test data, and ask the vendor to show notification, acknowledgment, escalation, and closure history. Treat predictive forecasting as a separate capability. | |
| 3 | Core | Portfolio-level visibility with entity and property drill-down | Can the same governed definition roll from portfolio to fund, entity, operator, property, and source record without changing calculation logic between views? | Select one portfolio KPI and drill to the entity, property, definition version, source rows, and freshness state without leaving the governed record. | |
| 4 | Core | Role-appropriate dashboards without definition drift | Can tax, finance, compliance, audit, and asset-management teams configure their views while all surfaces retain the same approved definitions and access boundaries? | Ask the vendor to show two role-specific views of one metric and prove that both reference the same definition, authority rule, and calculation record. | |
| 5 | Core | RIDEA / SHOP structures modeled as first-class, not as an exception | How does the system treat a RIDEA structure where resident revenue flows through a TRS and the REIT participates in operating results, versus a triple-net lease? Are SHOP-segment results reported on the same basis the REIT discloses? | Ask for the field-level mapping between the operator record and the SHOP-segment reporting the REIT publishes. | |
| 6 | Core | TRS exposure tracked with tax-counsel review boundary | Is TRS-flagged income isolated at the transaction level with owner, threshold, and review state visible to Tax and Finance, while the legal conclusion remains with tax counsel? | Ask which transaction attribute sets the TRS flag, and who can change it. | |
| 7 | Core | Rents-from-real-property classification at the clause level | Are impermissible-service and personal-property questions evaluated per lease clause under §856(d), or is the classification set once at the lease level and inherited by every period after it? | Ask to see two leases with different service bundles produce different classifications. | |
| 8 | Core | Tenant and entity isolation enforced in the data layer | Is isolation between operators, entities, and funds enforced by database row-level policy, or by application-layer filtering that a misrouted query or an integration credential can bypass? | Ask for the isolation control described in writing, plus how it is tested on each release. | |
| 9 | Core | Append-only audit trail spanning the calculation, not just the report | For any published figure, can you retrieve the source rows, the classification applied, the version of the logic that ran, the timestamp, and the approver — after the fact, without vendor assistance? | Pick a figure at random from a prior period and ask them to reconstruct it live. | |
| 10 | Core | Accounting, asset-management, and operator integrations with lineage | Can the platform connect the retained GL, asset-management, property-management, clinical, workforce, and census systems while preserving source authority, extraction time, and failure state? | Request a source-by-source integration matrix showing direction, method, data owner, expected latency, stale-feed behavior, reconciliation rule, maturity stage, and termination export. | |
| 11 | Core | Reporting accuracy governed by definitions, reconciliation, and freshness | For any reported figure, can the system show the approved definition, source authority, reconciliation rule, extraction time, exceptions, approvals, and prior versions? | Choose a disputed prior-period figure and require a live reconstruction. Do not accept an accuracy claim without a dated Evidence Record defining the population, method, and result. | |
| 12 | Core | Covenant and coverage rollups on operator data, at portfolio and entity grain | Are lease coverage, DSCR, and occupancy covenants computed from operator-submitted data on the REIT’s definitions, and can definitions differ by entity, state, and acuity without forking the model? | Ask to define one covenant two different ways for two entities in the same rollup. | |
| 13 | Core | Distribution-requirement evidence packaged beside §856 qualification tests | Does the evaluation package distinguish IRC §856 asset and income qualification tests from distribution requirements that tax counsel evaluates separately, and can the board see the evidence trail behind both? | Ask for a sample board-pack schedule that separates qualification-test calculations from distribution evidence and labels the tax-counsel review boundary. | |
| 14 | Core | Board-pack outputs with drill-back to source evidence | Can the system produce a board or LP reporting package where every figure links back to its approved definition, source authority, freshness state, exception history, and reconstruction path? | Request one board-pack page, then choose a figure and ask the vendor to drill back to source rows, logic version, approver, and timestamp. | |
| 15 | Core | Implementation maturity stated by feature, source, and operator-production status | Which rows are running in named operator production, built, demoable, configurable, or roadmap? Which data sources are historical exports, operator-supplied files, or live connectors? | Require a dated feature-by-feature maturity register, named production references where claimed, and a no-inference statement where production evidence does not exist. | |
| 16 | Verify | Operator-data continuity across transitions and operator change | If an operator is replaced, does the history — census, acuity mix, labor, coverage — survive in the REIT’s record, and who owns the derived data? Is a machine-readable full export available at termination without a fee? | Ask for the export and data-ownership language in the contract, not the sales deck. | |
| 17 | Verify | 1031 like-kind exchange workflow with date discipline | Does the system track 45-day identification and 180-day completion windows against a named qualified intermediary and attorney of record, with the identification list versioned? | Ask to see a versioned identification list with the timers attached. | |
| 18 | Verify | A written definition of "real-time" in the contract | What is the actual data latency per source — nightly, hourly, event-driven — and what happens to the monitoring view when an upstream operator feed fails or arrives late? | Ask for a latency table by source and the documented behavior on feed failure. | |
| 19 | Verify | Deployment evidence, stated without inference | Which capabilities are running in an operator production environment today, which are validated in a reference environment, and which are roadmap? Which integrations are live in production, named by counterparty? | Ask for the answer in writing, dated. | |

## Why it matters

**1. IRC §856 income and asset tests, computed per entity with freshness and lineage** — Drift in senior housing revenue mix is an operating event, not an accounting event. If it only surfaces when the ledger closes, the quarter it affects is already over.

**2. Rule-based alerts with named owners and escalation paths** — A portfolio view that only reports exceptions after close does not help a team intervene while the underlying condition can still be investigated.

**3. Portfolio-level visibility with entity and property drill-down** — A portfolio average can conceal a compliance exception inside one entity. Institutional teams need the rollup and the exception path at the same time.

**4. Role-appropriate dashboards without definition drift** — Flexible presentation is useful; independently rebuilt metrics are not. Customization must not create multiple versions of the same covenant or compliance measure.

**5. RIDEA / SHOP structures modeled as first-class, not as an exception** — Generic REIT monitoring products classify senior housing as "other healthcare." That classification is where the RIDEA-specific work actually lives.

**6. TRS exposure tracked with tax-counsel review boundary** — TRS capacity is consumed gradually by ordinary operating decisions — ancillary services, therapy, transitional care — long before anyone re-runs the test.

**7. Rents-from-real-property classification at the clause level** — Service-bundled senior housing rent is precisely where lease-level classification breaks. The clause is the unit that matters.

**8. Tenant and entity isolation enforced in the data layer** — A REIT reading operator data across multiple tenants inherits every one of those tenants’ confidentiality obligations. Application-layer filtering is a control you cannot show an auditor.

**9. Append-only audit trail spanning the calculation, not just the report** — An exportable PDF is an artifact. Evidence is the ability to reconstruct a number a year later when someone disputes it.

**10. Accounting, asset-management, and operator integrations with lineage** — Disconnected feeds delay monitoring and make teams rebuild the same report manually. An integration without lineage only moves the ambiguity downstream.

**11. Reporting accuracy governed by definitions, reconciliation, and freshness** — Accuracy is not a vendor percentage. It is the ability to explain why a number was accepted, which source controlled it, and whether the underlying data was current.

**12. Covenant and coverage rollups on operator data, at portfolio and entity grain** — One blended definition across a multi-state, mixed-acuity portfolio produces a number that is defensible nowhere.

**13. Distribution-requirement evidence packaged beside §856 qualification tests** — A buyer asking for “§856 asset, income, and distribution tests” is usually asking for one board-ready evidence package. Software should not blur statutory sections or imply tax advice.

**14. Board-pack outputs with drill-back to source evidence** — A board pack that cannot be reconstructed becomes a presentation layer rather than evidence. Institutional reporting needs the output and the proof path together.

**15. Implementation maturity stated by feature, source, and operator-production status** — Maturity is not uniform across a product. A credible buyer matrix separates shipped workflow, validation evidence, connector status, and operator-production proof.

**16. Operator-data continuity across transitions and operator change** — Continuity of the record is the difference between an asset with a history and an asset that starts over each time management changes.

**17. 1031 like-kind exchange workflow with date discipline** — Exchange deadlines are absolute. A calendar reminder is not a control, and the identification list is the document people later argue about.

**18. A written definition of "real-time" in the contract** — "Real-time" is the least-verified word in this category. Latency is a per-source property, and stale-data behavior is what determines whether you can act on the screen in front of you.

**19. Deployment evidence, stated without inference** — This is the question that separates a product from a demo. Every vendor should be able to answer it in writing, including SeniorCRE.

## Disclaimer

Not tax, legal, or investment advice. Confirm all Internal Revenue Code positions with your tax counsel. Pre-production as of September 2026. No operator runs SeniorCRE in an operator production environment; no operator workflow has been validated; no measured operator outcome or independently validated result is published; no third-party integration is live in operator production; and no PHI is processed in operator production.
