Acquisition-day integration
Acquisition-day integration
An acquisition is the moment an operator inherits someone else’s definitions. Handle it in four windows: in diligence, capture every source system and the seller’s written definitions — or record that none exist; on close day, freeze a dated pre-close baseline, take read-only custody of the clinical, payroll, billing and property systems, and leave the authoritative MAR exactly where it is; through the first close period, reconcile census to the unit inventory, payroll hours to the period, and revenue and expense to the general ledger, then restate the underwriting figures against the reconciled record and report the variance; and in steady state, declare authority per attribute and decide each inherited system’s future deliberately. The first post-close board number is either traceable to source or it is an assertion.
- Sequence
- Diligence · Close-day custody · Stub-period reconciliation · Authority
- Clinical rule
- The authoritative MAR does not move on close day
- Default access
- Read-only on every inherited system
- Deliverable
- A first reported period traceable to source, with variance to underwriting stated
Evidence posture. Connector coverage below is stated at its Product Record state — the third-party source-system connector framework is BUILT as a framework and exercised against vendor-documented interfaces and synthetic fixtures. No third-party integration runs in an operator production environment. Read every connector row as scope, not as a deployment. Last reviewed August 30, 2026.
Sequence
Four windows around the close
Each window has a single objective. Attempting the next one before the current objective is met is how a portfolio acquires an unreconcilable first period.
1.Before close — diligence
Objective. Know which numbers you are inheriting and which of them are contested.
- List every source system in the target’s stack, its owner, and whether interface access survives the transaction.
- Capture the seller’s written definition of occupancy, level of care, worked hours and agency hours — or record that none exists.
- Identify the trailing-twelve-month figures the deal was underwritten on, and the report each came from.
- Confirm what data may be transferred, under which agreement, and with which business-associate coverage in place.
2.Close day — custody
Objective. Take custody of the record without interrupting care.
- Freeze a dated pre-close baseline of census, unit inventory, payroll period and open AR.
- Establish read-only access to the clinical, payroll, billing and property systems as they exist on close day.
- Confirm the authoritative MAR for every community and leave it authoritative. Clinical continuity outranks reporting convenience.
- Record the entity structure: every property mapped to exactly one operating entity as of the close date.
3.First close period — reconciliation
Objective. Produce a first reported period you can defend.
- Reconcile census to the unit inventory and to the billed roster for the stub period.
- Tie payroll worked hours and agency invoice hours to the same period, cause-coding every agency shift.
- Tie revenue and expense to the general ledger within a written tolerance and list open exceptions rather than suppressing them.
- Restate the underwriting figures against the reconciled record and report the variance explicitly to the investment committee.
4.Steady state — authority
Objective. Decide the future of each inherited system, deliberately.
- Set the authority rule per canonical attribute for the acquired portfolio, aligned to the rest of the platform.
- Retain the acquired history with its lineage so pre-close and post-close periods stay comparable.
- Decide, system by system, whether to keep reading it or to consolidate — govern first, replace only by choice.
- Keep restatement history so a later correction to a close-period number does not silently rewrite the board record.
Architecture
Inherited systems, governed record
Layer 1 — Source systems (unchanged)
Layer 2 — Immutable landing and lineage
Raw payloads retained as received, each field tagged with source system, source identifier, interface and extraction timestamp.
Layer 3 — Canonical entities
Layer 4 — operator-controlled operating record
Accepted value, rejected value, basis of acceptance and restatement history. When systems disagree, the operator governs.
Layer 5 — Consumers
Board and lender reporting, operating reviews, BI tools, and AI workflows that read the governed record rather than the raw sources. Govern the truth before you automate the decision.
Source to operator-controlled operating record
What custody actually means, field by field
The acquisition case adds one requirement to the standard mapping: every row carries an effective date, so pre-close and post-close periods stay comparable. See also the acquisition integration checklist.
| Canonical entity | Typical source fields | Authority rule | Reconciliation test |
|---|---|---|---|
| Resident | EHR resident master, CRM prospect record, billing account, unit roster | Clinical system of record for clinical identity; operator-declared identity key for the governed record | Deterministic match on name, date of birth and admission date; unmatched records surface as an exception, never a silent merge |
| Care Plan | EHR assessments, service plans, MAR, acuity scoring | One authoritative MAR. The clinical system of record governs clinical content | Acuity level and service minutes reconciled to the billed level of care; variance is reported, not resolved by preference |
| Ledger | General ledger, AR sub-ledger, billing system, payroll register, agency invoices | General ledger is authoritative for posted amounts; source systems are authoritative for pre-posting activity | Period totals tie to the GL within a written tolerance before any derived metric is published |
| Shift | Scheduling system, time and attendance, payroll worked hours, agency invoice detail | Payroll worked hours are authoritative for hours paid; the schedule is authoritative for intent | Scheduled, worked and paid hours reconciled to the same period; agency hours cause-coded |
| Property/Unit | Property management system unit table, occupancy roster, CRM move-in pipeline | Property management system is authoritative for the unit inventory | Physical, licensed and available unit counts held as distinct fields so census is never computed from an ambiguous denominator |
| Entity | Chart of accounts, legal entity register, ownership and management agreements | Operator-declared entity structure | Every property maps to exactly one operating entity per effective date, with history retained |
Lineage
Why the first board number needs lineage
DATA
Where did this value come from?
Every field carries its source system, source identifier, extraction timestamp and interface used. A value with no traceable origin is not admitted to the record.
TRUTH
Which value does the operator accept?
When two systems disagree, both values are retained, the conflict is raised, and the governed record shows the accepted value plus the rule or the named person that accepted it.
DECISION
What was decided on this number?
Decisions reference the record version they were made against, so a later restatement does not quietly rewrite the basis of a past decision.
EXECUTION
What happened next, and who confirmed it?
Actions taken from the record are logged with the confirming human. Nothing writes back into a source system without an explicit, scoped, operator-authorised write.
Frequently asked questions
How do I integrate an acquired community’s systems on day one?
Take read-only custody rather than attempting migration. Freeze a dated pre-close baseline of census, unit inventory, payroll period and open receivables; establish read-only access to the clinical, payroll, billing and property systems as they exist at close; leave the authoritative MAR where it is; map each property to one operating entity as of the close date; then reconcile the stub period to the general ledger and to payroll before publishing any post-close figure.
Should we migrate the clinical system at close?
Clinical continuity comes first, so the authoritative medication administration record should not move on close day. Any consolidation is a separate, sequenced decision made after the record is reconciled — govern first, replace only by choice, with exactly one authoritative MAR at every point in a transition.
What happens when actuals disagree with the underwriting model?
The variance is reported rather than absorbed. The underwritten figures are recomputed from the reconciled record, and the difference is presented to the investment committee with its lineage — which source, which definition, which period. That is usually a definitional difference rather than a performance surprise, and it is only visible if the definitions were captured in diligence.
How long does acquisition-day integration take?
SeniorCRE does not publish an implementation duration. Timing depends on how many source systems survive the transaction, what interface access the operator’s agreements provide, and whether written definitions exist for the contested metrics. Any operator-specific sequence would be scoped in a briefing rather than asserted here.
What about data-transfer and privacy obligations at close?
Permitted transfers, business-associate coverage and retention obligations are governed by the transaction documents and the operator’s agreements with each vendor, and should be confirmed with counsel. SeniorCRE reads only what the operator is entitled to make available and states no legal conclusion about a specific transaction.
Does this work across a portfolio acquired in stages?
Yes, because the entity model carries effective dates. Each property maps to exactly one operating entity per effective date with prior structure retained as history, so staged acquisitions and mid-period transfers remain comparable instead of collapsing into a single ambiguous roll-up.
Evidence behind the evaluation
These pages carry the governance and clinical evidence a shortlist cannot: source authority rules, escalation controls, data limits, and survey-ready evidence.
- senior housing & care data governance for multi-state portfolios
How differing state definitions and survey regimes are governed in one record.
- human review and escalation controls for clinical AI
Mandatory human review, escalation paths, and what the system may never do.
- clinical AI data sources and limitations
What the signals are computed from, and where the evidence stops.
- how to evaluate senior housing & care software for 10+ locations
Six-criteria, vendor-neutral evaluation frame for multi-state portfolios.
Continue in this cluster
Data integration for senior housing & care
The pillar: canonical entities, connector coverage, lineage and the phased sequence every page here shares.
Combining PointClickCare® with accounting and payroll data
How clinical census and acuity from an EHR reconcile against the general ledger and worked payroll hours in one governed record.
Connecting EHR, CRM, payroll and general-ledger data
The four-system join: which system is authoritative for which field, and how conflicts are resolved rather than averaged.
Integration with your EHR retained — replacement optional
Read-one-direction coexistence: govern the operating record above the systems you already run, and replace only by choice.
Multi-state data governance
One authoritative source per field across states that define census, acuity, staffing and incidents differently — without forking the record.
Integration implementation checklist
The stage-gated checklist: definitions and entitlement, read-only connection, reconciliation, then authority — each item with an owner and an evidence test.
Data integration platform buyer’s guide
Nine evaluation criteria instead of connector counts, the categories of approach and where each one structurally stops.
Operator-controlled operating record and integration architecture
Six entities with declared grain and identity rules inside a five-layer read-only architecture, from landing and lineage to governed consumers.
- Connector inventory: Integration ecosystem · Integration posture
- Canonical model: One Operator-Controlled Operating Record · The operating record · What is a senior housing & care operating infrastructure?
- Comparisons: SeniorCRE vs PointClickCare® · SeniorCRE vs Yardi® · Hosting versus governing
Bring your own systems to the conversation
The useful version of this discussion is your actual stack, your actual contested numbers, and the reconciliation you cannot currently produce on demand.
PointClickCare® is a registered trademark of PointClickCare Technologies. MatrixCare® is a registered trademark of ResMed. Yardi® is a registered trademark of Yardi Systems, Inc. DocuSign® is a registered trademark of DocuSign, Inc. Salesforce® and Tableau® are registered trademarks of Salesforce, Inc. Power BI® and Microsoft® are registered trademarks of Microsoft Corporation. QuickBooks® is a registered trademark of Intuit Inc. ADP® is a registered trademark of ADP, Inc. Oracle® is a registered trademark of Oracle Corporation. All other product names, logos, and brands are property of their respective owners. SeniorCRE is an independent platform and is not affiliated with, endorsed by, or sponsored by any of the aforementioned companies. Comparisons are based on publicly available information and may not reflect all product capabilities.