SeniorCRE® · October 2026
Operational Data Governance as the Precursor to Portfolio Intelligence in Senior Housing & Care
Make sure the number is right. Then tell me what it means. A field-validated two-step framework for operators running 8 to 12 systems across 10 to 40 communities.
The New Standard for Portfolio Intelligence — slide deck
The fifteen-slide companion to this paper: the fragmented stack, the six governed metrics, the two-step sequence, and the field validation at a single community.
1. Executive context & core thesis: from data debates to proactive management
Regional operators managing portfolios of 10 to 40 senior housing & care communities routinely run 8 to 12 disparate, specialized software systems — clinical eMAR records, property management ERPs, billing engines, sales CRMs, labor scheduling, payroll, third-party agency portals, maintenance modules, and business intelligence suites. This multi-vendor fragmentation is rarely an intentional enterprise architecture. It is an artifact of growth through acquisition — what we call acquisition stack debt. With every property or sub-portfolio acquired, operators inherit disparate technology stacks, legacy data definitions, and unaligned operational workflows.
The typical operator software landscape
Seven operational domains, each commonly served by its own vendor. Vendors are listed for identification only, based on publicly available product materials; any given operator's stack will differ.
| Domain | Systems commonly found |
|---|---|
| Clinical & eMAR | PointClickCare, MatrixCare, ALIS |
| Property & billing | Yardi Voyager, RealPage, Sage Intacct |
| Maintenance | TheWorxHub, UpKeep |
| Sales & CRM | Aline, Welcome Home |
| Scheduling | OnShift, Smartlinx |
| Agency labor | ShiftKey, IntelyCare |
| Payroll | ADP, UKG |
None of these systems were chosen together. The conflicts are not a property of the industry — they are a property of the stack.
A finite problem
In the field review behind this paper, roughly twenty apparent system disagreements reduced to only six genuine, moving conflicts. The rest were one-time policies, sync lag, or unconnected systems. Data governance is a finite, solvable foundation — not an endless IT project.
When executive leadership, asset managers, and capital partners convene for monthly operating reviews, discussions routinely degrade into unproductive debates over baseline metric discrepancies. Because separate platforms calculate key indicators using conflicting logic, executive teams waste valuable time reconciling competing numbers rather than analyzing performance drivers.
The way out is a strict sequential architecture: operational data governance (Step One) must precede portfolio intelligence (Step Two). In crisp executive terms, the non-negotiable directive is:
“Make sure the number is right. Then tell me what it means.”
STEP 1 — DATA GOVERNANCE
Automated standardization of the six material metric discrepancies.
▼
STEP 2 — PORTFOLIO INTELLIGENCE
Trailing variance analysis (T-3/T-6), GL deep dives, and EBITDAR focus.
A common pitfall among executives is the illusion that data governance is a problem already solved — typically by issuing a policy directive or manually declaring a metric definition in a spreadsheet. Manual executive declarations fail to survive the daily realities of multi-vendor stack friction. Without an automated, governed data foundation, true portfolio intelligence remains impossible.
Establishing automated data governance eliminates low-value metric debates, freeing leadership to focus on high-value strategic work: analyzing trailing operational history (T-3, T-6 baselines), conducting deep dives into general ledger line items, arresting NOI erosion, mitigating EBITDAR volatility, and closing monthly operational feedback loops.
Key takeaway
Operational data governance is not a standalone strategic objective; it is the non-negotiable prerequisite (Step One) that makes portfolio intelligence (Step Two) actionable and trustworthy. Leading with governance alone fails because decision-makers operate under the illusion that baseline reporting is already functional; leading with intelligence powered by quietly governed numbers transforms monthly financial reviews into proactive operational management.
2. Disambiguating system discrepancies: a strategic taxonomy
To implement effective data governance, operators must distinguish true metric conflicts from administrative choices, operational timing delays, and unlinked system silos. Many apparent data discrepancies do not require recurring executive rulings, but rather targeted technical or workflow configurations.
| Kind | What it looks like | What fixes it | Strategic priority |
|---|---|---|---|
| Real conflict | Two systems report a different value for the same measure and purpose, and the answer moves dynamically month to month. | Recurring governance rulings by a designated authority rule. | High — demands active, visible data governance |
| One-time policy | A genuine structural choice, but once decided, it becomes a permanent software setting. | A single executive policy decision followed by system configuration. | Medium — settle once via executive policy |
| Sync lag | An operational update occurred in one system, but a downstream system has not yet updated. | Automated alerts, API refresh triggers, or defined operational workflows. | Operational — workflow execution |
| Disjointed systems | Two independent systems store separate operational data that is never combined or cross-referenced. | System integrations and API pipeline connections, not governance rulings. | Technical — data engineering and integration |
Disjointed systems vs. governance conflicts
Disjointed systems represent unbuilt software connections where no conceptual disagreement exists between systems; the systems simply do not talk to one another. Fixing these silos is high-return automation, but it requires integration engineering rather than metric governance. Core operational examples:
- Sales CRMs and scheduling systems: the CRM tracks four incoming move-ins for the upcoming week, but the workforce management system remains unlinked, leaving labor scheduling unaware of impending care load surges.
- Clinical assessments and billing software: a clinical care assessment records a resident's increased acuity level, but the billing module is never updated, resulting in uncaptured care revenue.
- Work order maintenance and capex planning: a facility management tool logs multiple related HVAC repair orders for a single asset, but the capital expenditure budgeting system tracks no aggregated asset history.
- Payroll and flash financial reporting: payroll systems record real-time agency labor utilization, but flash financial reports close on preliminary, un-invoiced estimates, hiding agency cost leaks until weeks later.
- Marketing spend and CRM conversions: marketing platforms report cost per lead, but that spend is never linked to CRM tour and move-in conversions, so the true cost to acquire a resident stays invisible.
The “occupancy fallacy” and the five settled policy metrics
Industry literature frequently cites occupancy as the primary metric requiring data governance. In practice, occupancy is an occupancy fallacy — it is the easiest and least complex metric to resolve, taking ten minutes of executive alignment to define. Metrics such as available units, move-in dates, and agency labor hours carry far greater financial risk and multi-vendor technical complexity.
Five core metrics can be permanently eliminated as operational conflicts through a single executive policy decision:
- Occupancy: settled permanently by defining occupancy strictly as resident unit days (total billed unit days divided by available unit days).
- NOI and EBITDAR: settled via contractual definitions drafted directly into management agreements, owner underwriting models, and lender compliance packages.
- Community fees, concessions, and bad debt: settled by enforcing standard GAAP principles applied consistently during routine monthly accounting closes.
- Hours worked and full-time equivalents (FTEs): settled by establishing payroll system data as the sole authoritative source, as it represents actual disbursed monetary compensation.
- Resident counts vs. occupied units: settled by recognizing that clinical systems track individual human care recipients while billing systems track rentable units and second-person fee structures. Operators must compute and explicitly label both metrics independently.
3. The six material metric discrepancies demanding data governance
When evaluating multi-vendor software stacks, exactly six material metric conflicts require dynamic, ongoing data governance. These six represent real operational conflicts where values move month to month across competing platforms, directly impacting financial performance, labor modeling, and revenue capture.
3.1 Available units (the denominator problem)
The baseline unit denominator for calculating occupancy, revenue per occupied room (RevPOR), and per-patient-day (PPD) metrics shifts constantly based on how units are categorized across clinical, billing, and maintenance systems. Field analysis at one community demonstrated how a property with a physical capacity of 149 units yields four distinct available-unit denominators depending on system definitions:
- 149 units: total licensed units recorded in state compliance filings.
- 143 units: billed unit capacity on the rent roll after removing 6 units taken offline for capital expense renovations.
- 141 units: available capacity in the clinical system after subtracting 2 model units used for sales tours.
- 140 units: true operational unit inventory after accounting for 1 unit permanently converted into an administrative office.
Because capex renovations and office conversions occur outside property management billing systems, this denominator variance creates floating financial metrics across every downstream calculation.
| Version of the number | Source / system | Commonly seen platforms |
|---|---|---|
| Licensed units | State license record | Compliance filings / state regulatory documentation |
| Units on rent roll | Billing & property management | Yardi Voyager, RealPage, MRI |
| Units configured for care | Clinical record & eMAR | PointClickCare, Eldermark, MatrixCare, ALIS |
| Units out of service | Maintenance & work orders | TheWorxHub, UpKeep, Facilgo |
3.2 Move-in and move-out dates
If a resident signs a lease on the 3rd of the month, physically moves into the building on the 8th, and begins financial billing on the 1st of the following month (via a prorated agreement), three distinct move-in dates exist across the software stack. Every length-of-stay calculation, absorption metric, and move-out velocity analysis inherits whichever date the reporting platform selects.
| Version of the number | Source / system | Commonly seen platforms |
|---|---|---|
| Lease signed / deposit taken | Sales CRM conversion | Aline, Yardi CRM, Welcome Home |
| Admission & care start | Clinical intake record | PointClickCare, Eldermark, MatrixCare |
| Rent commencement | Financial billing record | Yardi Voyager, RealPage |
3.3 Agency and contract labor
Contract agency labor represents one of the most severe financial leaks in senior housing operations, directly driving EBITDAR volatility. Evaluating it requires a sharp technical distinction:
- Single-suite setup (configuration issue): running scheduling and timekeeping inside a single vendor's suite allows scheduled hours to be validated against worked timecard punches natively. Discrepancies here stem from improper administrative settings rather than data governance failures.
- Multi-vendor stack (data governance leak): when an operator schedules in one system, tracks timecard payroll in another, manages vendor staffing via third-party agency portals, and pays invoices through an enterprise accounting ERP, a major financial leak opens. Unapproved hours, shift minimum overrides, and vendor rate markups bypass operational controls, surfacing only weeks later as negative GL variances.
| Version of the number | Source / system | Commonly seen platforms |
|---|---|---|
| Hours scheduled | Operational labor plan | OnShift, Smartlinx, UKG |
| Hours worked | Timecard punch records | ADP, Paycom, Paylocity, UKG |
| Hours submitted | Third-party vendor portals | ShiftKey, IntelyCare, Clipboard Health |
| Dollars invoiced | Accounts payable | Yardi Voyager, Sage Intacct |
3.4 Resident days as a labor denominator
Operators manage daily staffing efficiency using labor hours per resident day (PPD). Utilizing different census denominators yields vastly different conclusions about whether a community is operating over or under target staffing ratios. Comparing clinical resident counts against billed resident days or static budget targets creates conflicting staffing variance metrics across regional leadership reviews, masking root-cause labor inefficiencies.
| Version of the number | Source / system | Commonly seen platforms |
|---|---|---|
| Clinical resident days | Daily clinical census | PointClickCare, Eldermark, MatrixCare |
| Billed resident days | Monthly billing ledger | Yardi Voyager, RealPage |
| Budgeted census | Underwriting financial target | Budget workbook model (Excel) |
3.5 Quoted vs. contracted vs. charged rates (RevPOR)
Revenue discrepancies emerge at distinct transition points across the sales funnel and billing cycle:
- Cross-vendor conflict (governance requirement): the gap between the quoted rate in the sales CRM and the contracted rate on the rent roll is a true cross-vendor governance gap. Unaligned pricing tables allow sales teams to offer non-standard rates that are incorrectly ingested into the property management engine.
- Single-vendor gap (configuration issue): the gap between the contracted rate and the final charged rate (which reflects unmonitored concessions, care add-ons, and second-person fees) typically occurs within separate modules of a single product suite. While this is a software workflow configuration issue, unmonitored concessions can quietly run for months without executive visibility, eroding community RevPOR.
| Version of the number | Source / system | Commonly seen platforms |
|---|---|---|
| Quoted rate | Sales pipeline quote | Aline, Yardi CRM |
| Contracted rate | Residency agreement rent roll | Yardi Voyager, RealPage |
| Charged rate | Final billed ledger | Yardi Voyager Billing, RealPage Billing |
3.6 Regulatory care levels vs. operator pricing tiers
A persistent misconception in senior housing data strategy is that multi-state operators fail because state regulatory frameworks differ. In reality, operators enforce their own standardized internal care-level pricing rate sheets across their entire portfolio, regardless of geographic footprint. The actual operational collision occurs between state-mandated regulatory clinical assessments sitting in clinical software and internal pricing tiers sitting in billing systems:
- Regulatory framework disconnects: state laws establish distinct clinical vocabularies. Arizona statutes mandate supervisory, personal, and directed care categories. Maryland's COMAR 10.07.14 framework mandates Level 1, Level 2, and Level 3 scores, which must be formally assessed using a state tool by an independent licensed practitioner within 30 days of move-in. Because Maryland's regulatory score depends on an external practitioner assessment during an initial 30-day window, the clinical assessment record inherently lags behind initial billing setup.
- The operational collision: clinical software tracks state regulatory categories, while property billing software tracks internal pricing tiers. A custom mapping structure must be maintained for every operating jurisdiction to bridge clinical care scores to operator billing matrices, preventing uncaptured care revenue.
| Version of the number | Source / system | Commonly seen platforms |
|---|---|---|
| State regulatory category | Practitioner clinical assessment | PointClickCare, Eldermark, MatrixCare |
| Operator care tier | Internal pricing rate sheet | Yardi Voyager, RealPage |
4. The two-step operational framework & field validation
To eliminate data ambiguity and establish actionable portfolio intelligence, senior housing organizations must execute a strict, sequential two-step framework.
| Dimension | Step 1 — Data governance | Step 2 — Portfolio intelligence |
|---|---|---|
| Primary objective | Standardize metrics, assign authoritative source systems, and maintain visible audit trails. | Conduct operational variance reasoning, evaluate financial performance, and drive C-suite accountability. |
| Core activity | Governing the six material metric discrepancies quietly as an automated platform setup. | Analyzing trailing history (T-3, T-6), investigating GL line-item variances, and enforcing operational feedback loops. |
| Executive value | Establishes baseline data integrity and operational trust across portfolio reporting. | Protects portfolio NOI, mitigates EBITDAR volatility, and drives direct asset value creation. |
| Time / value profile | Low cost / setup step — minimal recurring labor once authority rules are codified. | High value / strategic activity — the core capability asset managers and leadership pay for. |
Empirical field validation: a single-community exercise
The practical execution of this two-step model was validated through a manual field exercise conducted by an independent consultant at a single community, measuring the exact time-to-value ratio:
FIELD EXERCISE — EXECUTION TIME
Step 1: Data governance (standardizing resident unit days)
█ 1 hour — low-cost setup
Step 2: Portfolio intelligence (T-3/T-6 analysis & GL deep dives)
████████████████████████████████████████ 2 days — high-value return
- Step 1 execution (data governance): the consultant extracted raw resident unit day data from the property management system and established a standardized occupancy calculation in a spreadsheet. This required exactly 1 hour to establish a single, authoritative rule for resident unit days.
- Step 2 execution (portfolio intelligence): upon receiving the monthly financial package on the 10th of the month, the consultant constructed trailing T-3 and T-6 operational baselines, isolated core cost variances, conducted deep-dive analyses into general ledger line items, and identified actionable root causes behind EBITDAR movement — then met with community operations to execute corrective action plans. This strategic analysis required 2 days.
Day 10 to Day 11: where the calendar goes
Monthly financial packages typically land around the 10th. Done by hand, the reconciliation and trailing analysis take roughly three full days per building, so across a multi-community portfolio the findings reach operators well after the month they describe. When the six discrepancies are governed automatically before the package arrives, the design target is intelligence in operators' hands on Day 11 — the day after the package lands — rather than days or weeks later.
Executive strategic takeaway
The field exercise reveals a critical operational truth: manual spreadsheet governance is low-cost but completely unscalable across a 20+ community portfolio. Automated platform governance is the essential, low-cost setup step that enables high-value GL deep dives and monthly close feedback loops across multi-community portfolios.
Note: these timings come from a single-community manual exercise, not a measured production deployment. They indicate the shape of the effort, not a guaranteed result.
A foundation is necessary, but the superstructure is what the operator actually buys. Step One must happen quietly so Step Two can shine.
Governance is step one. Intelligence is the destination.
5. Strategic value & market positioning for portfolio operators
When presenting data strategy and platform architectures to executive leadership, asset managers, and capital partners, strategic positioning must focus on financial variance intelligence rather than abstract technical governance.
Executive positioning imperatives
- Avoid leading with “governance”: pitching data governance in isolation fails because executive buyers operate under the illusion that their operational teams have already solved metric definitions.
- Lead with operational variance intelligence: frame the value proposition directly around solving executive monthly review challenges — “Make sure the number is right, then tell me what it means.” Position the platform as an intelligence engine that automates baseline setup in order to focus entirely on performance optimization and EBITDAR protection.
- Target mixed software stacks (acquisition growth): operators running single-vendor software suites experience fewer cross-system conflicts; operators managing inherited, multi-vendor stacks face severe acquisition stack debt and operational data friction across every community.
- Establish modern deployment benchmarks: evaluate platform performance using a clear operational speed benchmark — does the technology automatically resolve the six core metric discrepancies and deliver actionable operational intelligence by the 11th of the month, replacing manual spreadsheet reconciliation that drags on until the 20th?
Strategic execution imperatives for senior leadership
- Codify policy rules for the five settled metrics: formulate a concise executive policy establishing explicit, static rules for occupancy (resident unit days), NOI/EBITDAR definitions, community fees/concessions, payroll hours/FTEs, and resident counts vs. occupied units.
- Automate system authority rules for the six material metrics: configure platform data pipelines to apply authoritative source rules automatically across available units, move-in/move-out dates, agency labor hours, labor denominators, RevPOR transitions, and regulatory care level mappings.
- Institutionalize trailing variance analysis (T-3 / T-6): re-engineer monthly executive operating reviews to eliminate metric reconciliations and focus entirely on GL line-item shifts, budget variances, and labor efficiencies measured against trailing T-3 and T-6 performance baselines.
- Enforce timely monthly close feedback loops: accelerate reporting cycles to deliver governed portfolio intelligence by the 11th of each month, establishing rapid operational feedback loops that drive executive accountability and protect portfolio asset value across all communities.
Vendor and platform names appear for identification only, to describe the systems operators commonly run. Their presence does not assert or deny any capability of those products; product capabilities change, and descriptions here reflect publicly available materials as of October 2026. All trademarks remain the property of their respective owners.
See where the gap lives in your portfolio.
The operating truth gap page walks through the six discrepancies with worked examples — and what a governed operating record does about each one.