PointClickCare® + accounting and payroll
Combining PointClickCare® data with accounting and payroll
Join clinical, financial and labor data on two keys and one period: the resident identity key and the property/entity key, reconciled to a single closed accounting period. Read census, acuity and documented care from the EHR; read posted revenue and expense from the general ledger; read worked, paid and agency hours from payroll and time. Land each read-only with lineage attached, map every field to a canonical entity, then reconcile before deriving anything: clinical census against billed census, documented care minutes against worked hours, and payroll cost against the GL within a written tolerance. Only after those three ties pass should a blended figure such as labor cost per resident day be published. Most operators can produce that number today; far fewer can defend how it was derived.
- Join keys
- Resident identity key · Property/entity key · Closed accounting period
- Authority
- GL for posted amounts · Payroll for hours paid · Clinical system for clinical content
- Direction
- Read-only from all three sources
- Prerequisite
- Three reconciliations pass before any blended metric is published
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.
Architecture
Three sources, one governed record
The EHR, the ledger and payroll are read independently and joined only after each has been reconciled on its own terms.
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
Field-level mapping and the conflict each field creates
The right-hand column is the part most integration projects skip. Every one of these conflicts is normal; the failure is resolving it silently.
| Field | Source | Canonical entity | Conflict and how it is governed |
|---|---|---|---|
| Resident census by day | EHR census / admission-discharge-transfer events | Resident, Property/Unit | Clinical census counts residents present; billing census counts residents billed. Both are retained; the operator declares which drives the published occupancy figure. |
| Level of care / acuity | EHR assessment and service plan | Care Plan | Assessed acuity frequently leads billed level of care. The lag is reported as a variance, not smoothed. |
| Care minutes delivered | EHR task and eMAR documentation | Care Plan, Shift | Documented minutes are compared to scheduled and worked hours; unexplained gaps become exceptions with a named owner. |
| Resident revenue posted | General ledger AR, billing sub-ledger | Ledger | The GL is authoritative for posted amounts. Pre-posting billing activity is retained separately so period comparisons stay honest. |
| Worked and paid hours | Payroll register, time and attendance | Shift, Ledger | Payroll is authoritative for hours paid; the schedule is authoritative for intent. Both are reconciled to the same period. |
| Agency and contract hours | Agency invoices, time system | Shift, Ledger | Invoice hours are reconciled against clocked hours and cause-coded to the open shift that created them. |
| Labor cost per resident day | Derived — payroll cost over reconciled resident days | Ledger, Resident | Published only after both the GL tie and the census reconciliation pass. A derived metric built on two unreconciled inputs is the classic source of a number nobody trusts. |
Implementation
The phased sequence, applied to this join
The shared five-phase sequence from the pillar, with the reconciliation phase carrying the three ties described above.
1.Phase 1 — Definitions
Goal. Settle what each number means before anything is connected.
- Write one definition per contested metric: occupancy, census, level of care, worked hours, agency hours, NOI.
- Name an accountable owner for each definition.
- Record which system the operator expects to be authoritative for each field.
- Capture the questions the board asks and the report each answer currently comes from.
Exit test. A written definition set with named owners, signed off by the operator — not by the vendor.
2.Phase 2 — Read-only connection
Goal. Read the source systems without touching them.
- Stand up read-only credentials or scoped extracts per source system.
- Map each source field to a canonical entity and attribute.
- Land raw source payloads immutably, with lineage metadata attached at ingest.
- Leave every source system as the operator’s own system of record for now.
Exit test. Source data lands with full lineage and no write path back into any source system.
3.Phase 3 — Reconciliation
Goal. Make disagreement visible instead of averaging it away.
- Reconcile period totals to the general ledger and to payroll worked hours within a written tolerance.
- Reconcile occupancy against the unit inventory and the billed roster.
- Route every unmatched or out-of-tolerance item to a named owner as an exception.
- Freeze a dated baseline before any derived metric is published.
Exit test. A reconciliation report the operator would hand to an auditor, with open exceptions listed rather than suppressed.
4.Phase 4 — Authority
Goal. Declare who governs each field when systems disagree.
- Set the authority rule per canonical attribute.
- Record the accepted value, the rejected value and the basis of acceptance.
- Publish the governed views the board and lenders read.
- Retain restatement history so a corrected number never silently replaces the number a decision was made on.
Exit test. One Operator-Controlled Operating Record the operator controls, with conflicts resolved by rule and by name.
5.Phase 5 — Coexistence or replacement, by choice
Goal. Decide the future of each source system on the operator’s timetable.
- Keep the incumbent system and continue reading one direction only, or
- Adopt the SeniorCRE clinical record — its own EHR and eMAR — as the clinical system of record,
- Maintain exactly one authoritative MAR at all times during any transition.
- Re-run reconciliation across the change so history stays comparable.
Exit test. A documented decision per system. Govern first; replace only by choice.
Lineage
What has to be traceable afterwards
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 combine PointClickCare® and accounting or payroll data?
Read census, acuity and documented care from the EHR, posted revenue and expense from the general ledger, and worked, paid and agency hours from payroll and time — all read-only. Join them on the resident identity key, the property or entity key and a single closed accounting period. Reconcile clinical census to billed census, documented care minutes to worked hours, and payroll cost to the GL within a written tolerance before publishing any blended metric such as labor cost per resident day.
Which system wins when clinical census and billing census disagree?
Neither wins automatically. Clinical census counts residents present; billing census counts residents billed, and the two legitimately differ around admissions, discharges, hospital leaves and billing cutoffs. Both values are retained, the difference is raised as a reconciliation item, and the operator declares which definition drives the published occupancy figure. When systems disagree, the operator governs.
Does this require a PointClickCare® data-export license or agreement?
Interface access, permitted uses and any associated fees are governed by the operator’s own agreement with the vendor, and operators should confirm scope with the vendor and their counsel. SeniorCRE reads only what the operator is entitled to make available and does not represent any vendor’s commercial terms.
Is PointClickCare® modified or replaced by this?
No. The default posture is read one direction only; the EHR is left untouched and remains the operator’s clinical system of record until the operator decides otherwise. SeniorCRE clinical record surfaces are built; medication administration and eMAR remain roadmap — not built. Any future clinical system-of-record function requires cleared Production-Entry Gates and operator acceptance.
What can go wrong in a clinical-to-financial join?
The four recurring failures are an ambiguous occupancy denominator, resident identity matched on name alone, care minutes compared against scheduled rather than worked hours, and derived per-resident-day metrics published before the GL tie passes. Each is a definition failure rather than a technical one, which is why definitions come first.
How is a published figure traced back to its source?
Every admitted field carries its source system, source identifier, interface and extraction timestamp, and every published figure references the record version it was computed from. That is what allows a board number to be defended months later, including after a restatement.
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.
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.
Acquisition-day integration
What has to be connected, reconciled and owned before the first close-day board number is defensible.
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.