Hospital reports disagree because each practice system counts differently.
A group that grows by acquisition inherits the practice information management system each hospital already ran. One hospital uses ezyVet, another Cornerstone, a third AVImark, and each system has a different idea of what a visit, an active client, or a transaction is. When every hospital sends a standard report, leadership receives numbers that look comparable but are built on different rules, so a hospital can appear stronger or weaker simply because its software counts differently.
The differences are rarely obvious. One system counts a recheck as a visit and another does not. One treats a client as active after any invoice, another only after an exam. Revenue may include or exclude pharmacy, boarding, grooming, or online store sales, and discounts and refunds may be recorded at different points. Each choice is reasonable in isolation, but together they make a group comparison unreliable.
The usual workaround is an analyst who downloads exports from each hospital and adjusts them in a spreadsheet. That works for a handful of hospitals, but it depends on one person’s knowledge, it takes a long time, and nobody else can explain how a number was produced. Every acquisition adds another system and another set of adjustments, and the monthly report becomes harder to trust as the group grows.
Agree on definitions before connecting any systems.
Consistent reporting starts with a short written dictionary that finance, operations, and medical leadership sign off on. It should define a visit, a new client, an active client, a lapsed client, doctor production, and each revenue category the group reports on. For each definition, note which fields in each practice system supply it and any exceptions, such as emergency hospitals that handle transfers or specialty hospitals that bill referral work differently.
This step settles arguments that would otherwise surface later as disputes over numbers. It also exposes decisions leadership has never made explicitly, such as whether a hospital should be credited for a patient referred to the group’s specialty hospital, or how shared doctors who work at several locations should be counted. Resolving those questions on paper is far cheaper than rebuilding reports after they have been circulated.
Keep the first dictionary small. A group rarely needs every possible metric in the first reporting release. Pick the handful of measures leadership actually uses to run the business, usually revenue by category, visits, active clients, average invoice, and doctor production, and get those right across every hospital. Additional measures can be added once the foundation is trusted and people stop checking the spreadsheet behind each report.
Connect each practice system to one reporting layer.
Once the definitions are agreed, each practice system needs a connection that brings the relevant data into a single reporting database. Some cloud systems provide APIs that can be read on a schedule, while older server-based systems may only offer database access or scheduled exports. The connection method differs by system, but the result should be the same: invoices, visits, clients, and patients arriving regularly in one place with a record of where each came from.
In the reporting layer, each system’s data is mapped to the shared definitions. Service codes and categories are translated into group categories, doctors are matched across hospitals, and duplicate clients who visit more than one location are linked where the group wants them counted once. The mapping rules live in the reporting system, where they can be reviewed and changed, rather than in one analyst’s spreadsheet formulas.
Plan for acquisitions from the start. A new hospital on a system the group already connects to should only need its settings added. A hospital on a new system needs a new connection and a mapping, which is a contained piece of work. Designing the reporting layer this way means the group can report on a hospital soon after it joins, instead of waiting for a system migration.
Reconcile reports against accounting and publish one view.
Practice system revenue and accounting revenue will never match exactly, because of timing, adjustments, and items posted directly in accounting. The reporting layer should reconcile the two for each hospital and period, show the difference, and explain the known causes. When finance can see that the gap is small and understood, leadership stops asking which number is right and starts discussing what the number means.
Publish the results in one place that everyone uses, whether that is a dashboard, a scheduled report, or both. Group leaders should see every hospital on the same definitions, regional leaders should see their hospitals, and hospital managers should see their hospital’s performance against the group. Access should follow roles, so client and patient details are only visible to the people who need them.
Show data freshness and exceptions openly. If a hospital’s connection failed overnight or a new service code has not been mapped, the report should say so rather than quietly showing lower revenue. A small exceptions list for the reporting administrator keeps the numbers trustworthy, and it helps hospital teams correct data entry habits that distort results, such as invoicing under the wrong doctor or category.
Start with a small set of hospitals and measures.
A practical first release connects the practice systems used by a few representative hospitals, applies the agreed definitions to a handful of measures, and reconciles revenue against accounting. Choose hospitals that cover each system the group runs, including at least one general practice and one specialty or emergency hospital if the group has both, so the design is tested against real differences before it expands.
Once leadership trusts the first view, add the remaining hospitals and extend the measures to areas such as inventory spend, referral volumes between hospitals, reminder compliance, and staffing. Each addition follows the same pattern: agree on the definition, map it from each system, reconcile it, and publish it. The discipline matters more than the reporting tool, and it keeps the reporting reliable while the group continues to change.
If the group plans to move every hospital onto one practice system eventually, the reporting layer still pays off, because it gives leadership consistent numbers during the migration and makes it easy to compare hospitals before and after the switch. Baybloom builds this kind of reporting for multi-hospital groups, and the same approach applies whether a group runs three practice systems or several more.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project