An investment fund buys a first veterinary clinic, then a second, then ten. Each clinic runs its own practice software, its own chart of accounts, its own suppliers and its own discounting habits. Twelve months later, the group CFO has to answer a simple question: what is the drug margin at each site, and how much does each vet actually contribute? If the answer takes three weeks of Excel rework, the problem is not the clinic software. It is the lack of a management foundation at group level.
This article is written for executives, CFOs and CIOs of veterinary groups in a buy-and-build phase, and for the funds backing them. It deliberately contains no market statistics: the consolidation trend is well known. What matters here is the architecture that lets you steer it.
A consolidating sector: why the PMS is not enough at group level
A clinic’s core software, known in the industry as a PMS (Practice Management System), does what it was designed to do very well: patient medical records, consultation scheduling, hospitalisation, point-of-sale billing of procedures, prescriptions, vaccination reminders. It is built around the clinic as the unit of work.
A group has a different need. It steers a portfolio of clinics, and its questions are of a different nature:
- What purchasing terms have been negotiated for all sites, and are they actually applied?
- What is the consolidated cash position, and how are shared services (management, HR, procurement, IT) recharged?
- How do you compare two clinics whose charts of accounts, item families and discount rules differ?
- How do you finance and track acquisition debt, earn-outs and commitments to partner vets?
A PMS, however good, is not meant to answer these questions. Its financial statements are rarely multi-entity, its accounting is often limited to cash collection, and its data model varies from one vendor to the next. When the group has acquired clinics running different PMS platforms, consolidation becomes a manual reconciliation exercise repeated every month.
The ERP is not there to replace the PMS. It becomes its complement: it receives the financial and logistics flows from each clinic and turns them into group-level management information.
Splitting the roles: clinic PMS, finance/procurement ERP, group BI
The central question is not “which ERP?” but “where do you draw the boundary?”. A split that works well in practice:
| Domain | PMS (clinic) | ERP (group) | Group BI |
|---|---|---|---|
| Patient record, schedule, prescription | Master | No | No |
| Billing of procedures and products to the client | Master | Receives postings | Reads |
| General ledger, cost accounting, consolidation | No | Master | Reads |
| Purchasing, item listing, supplier orders | Read-only | Master | Reads |
| Pharmacy stock: movements | Master (issue at dispensing) | Master (valuation, replenishment) | Reads |
| Fixed assets, treasury, payroll | No | Master | Reads |
| Vet and clinic dashboards | Source data | Financial data | Master |
The principle: each piece of data has a single master. The stock issue at the moment of dispensing originates in the PMS, because that is where the act takes place. Valuing that stock, replenishing it and matching it to the supplier invoice belong to the ERP. Cross-cutting indicators (margin per vet, for example) are built in the BI layer, which reads both sources.
Two architectures compared
Option 1: a single ERP that also covers the clinical core. One system, one master data set. Attractive on paper but rarely realistic: few general-purpose ERPs cover veterinary medical records and scheduling, and vets quickly reject a tool that slows down the consultation. This route requires a specialist vendor or costly custom development, and locks the group into a strong dependency.
Option 2: keep the PMS platforms + a lightweight finance/procurement ERP + BI. Each clinic keeps the tool it knows, at least during the integration phase. The ERP covers accounting, purchasing, treasury and consolidation. An integration layer synchronises the flows. The trade-off: you have to maintain interfaces and a common item master.
Our recommendation for most growing groups: option 2, with a roadmap that gradually converges PMS platforms towards a smaller number. Option 1 only makes sense if the group has already standardised on one PMS and the vendor offers group-level financial modules.
Purchasing and pharmacy: central buying, drug margins, traceability
Pharmacy is often the first value lever for a group, and the first blind spot when purchasing is decentralised.
Central buying. The group negotiates framework terms with manufacturers and wholesalers. For the negotiation to have an effect, the ERP must:
- hold a single item master (internal code, supplier code, pack size, dispensing unit) mapped to the codes in each PMS;
- check that every clinic order applies the negotiated price, and flag deviations;
- match order, receipt and invoice (three-way match) to prevent undue payments.
This is a data governance topic before it is a software topic: our guide to master data governance in ERP details the roles and processes needed for a shared item master.
Drug margin. To track margin, you need to combine the true purchase cost (valued by the ERP, including back-end rebates and volume discounts) with the dispensing price (from the PMS). Without that link, the margin reported by the clinic is approximate, because the PMS often knows only the last purchase price.
Traceability and regulatory registers. In France, the dispensing of veterinary medicines requires a regulated record. Under article R5141-112 of the French Public Health Code, the register may be kept on paper or electronically and records, among other things, the medicine supplied, the quantity, the batch number, the prescriber and the date. For an electronic register, the text requires the history to be retained, backed up on separate media and printable at any time for the authorities. That page reproduces the text of the article; we recommend checking the current version on Légifrance with the vet responsible for the pharmacy. Other countries have their own rules, so check the local regime for each entity in the group.
Architectural consequence: the regulatory register stays attached to the PMS, where dispensing takes place, with batch number and prescriber. The ERP does not need to duplicate it, but it must receive the movements to value stock and trigger replenishment, and the annual inventory comparing receipts, issues and physical stock must rely on consistent data across both systems. A group that plans for this consistency from the design stage avoids inventory discrepancies that otherwise resurface during inspections.
Multi-entity finance: acquisition integration, common chart of accounts, consolidation, intercompany
Each clinic acquired is generally a separate legal entity, sometimes sitting behind a professional practice company, with its own accountant and conventions. The group’s financial foundation has to resolve four points.
- Common chart of accounts and analytical dimensions. Define a group chart with a mapping table to each entity’s local chart. Minimum analytical dimensions: clinic, vet, business line (consultation, surgery, imaging, pharmacy, product sales, hospitalisation).
- Consolidation. Monthly, with elimination of intra-group transactions, currency translation if entities are outside the euro area, and treatment of goodwill.
- Intercompany. Recharging shared services, intra-group loans, stock pooling between clinics. Each flow must be referenced on both sides so it eliminates cleanly. Our article on multi-site, multi-entity ERP (in French) describes these mechanisms in detail.
- Transfer pricing. As soon as the group expands across several countries, management-service recharges must be documented. See our article on ERP and transfer pricing documentation.
One point often overlooked: period-end closes. A group waiting for the packs from local accounting firms closes late, often after several weeks. With an ERP fed directly by PMS flows, the close can be tightened, which is valuable for fund reporting.
What the fund and the bank expect from group finance
Financial stakeholders demand regular, comparable reporting: EBITDA per clinic adjusted for non-recurring items, tracking of acquisition debt and covenants, cash forecasts. These statements must be built without re-keying. An adjusted EBITDA indicator per clinic is only credible if the adjustment rules (owner-vet remuneration before the buyout, rent, management fees) are documented in the ERP and applied identically to every new entity.
Also plan for the management of partner vets and minority shareholders: variable pay, earn-outs, non-compete clauses and share buybacks. These commitments should be tracked in a schedule fed by the ERP, not in files scattered across legal advisers.
Profitability per clinic and per vet: KPIs
This is the most visible part for management, and the most sensitive for teams. Some key indicators:
- Average ticket: revenue per consultation or per client, with the split between procedures and products.
- Utilisation rate: time spent on billed procedures relative to the available time of the vet and the rooms. It comes from the PMS schedule.
- Procedure / product margin: the ERP provides costs (drug purchases, consumables, allocated payroll), the PMS provides sales.
- Revenue per vet and per FTE, complemented by a quality or client-retention indicator so you don’t manage on volume alone.
- Pharmacy stock turnover and write-downs, especially products nearing expiry.
- Discount frequency: gap between list price and invoiced price by clinic.
Three precautions. First, define each indicator in a shared data dictionary: without a common definition, “average ticket” does not mean the same thing from one clinic to another. Second, treat comparisons between vets with care: a referral surgeon and a general practitioner do not have the same mix of procedures, and a poorly calibrated dashboard demotivates your best people. Finally, respect employment law and data protection rules (GDPR in the EU and the UK): individual indicators on employees must be justified, proportionate and presented to employee representatives where the law requires.
From dashboard to action
An indicator is only worth something if it triggers a decision. For each KPI, define an owner (clinic director, pharmacy lead, CFO), a review frequency (weekly for pharmacy, monthly for profitability) and an alert threshold. For example: a drug margin that drifts from the group average should first prompt a check of the prices applied and the discounts granted, before blaming the team. A low utilisation rate may point to a scheduling, recruitment or room-management issue, not necessarily to individual productivity.
Integrating an acquired clinic in 90 days: the IT integration plan
A realistic three-phase plan, to be adapted to the size of the clinic:
Days 1 to 30: secure and map.
- Take over access, backups, licences and IT contracts.
- Map the estate: PMS in use, hardware, imaging, laboratory, payment terminal connection, bank.
- Extract opening data: suppliers, items, stock, balances.
- Open the company in the ERP with the group chart and mapping table.
Days 31 to 60: connect.
- PMS-to-ERP interface: sales invoices (or daily aggregated postings), pharmacy stock movements, receipts.
- Map the item master to the group item master.
- Move purchasing to central buying: orders now go through the ERP.
Days 61 to 90: steer.
- First monthly close in the ERP and reconciliation with local accounting.
- Go-live of the clinic and vet dashboard.
- Review of the pharmacy regulatory register with the responsible vet and first cross-checked inventory.
To keep this pace, prepare a standard integration kit (checklist, mapping templates, interface test sets). The tenth acquisition should not cost more to integrate than the second.
Target architecture and mistakes to avoid
The target architecture comes down to four building blocks: PMS in the clinic, finance/procurement ERP at the centre, an integration platform (scheduled flows or APIs), and group BI fed by a single data warehouse. The most common mistakes:
- Buying the ERP before fixing the boundary with the PMS. The result is overlapping functions and endless debates with the vets.
- Not naming an owner for the item master. A pharmacy holds thousands of items, and duplicates pile up quickly.
- Duplicating the regulatory register in two systems, with the risk of discrepancies.
- Underestimating the cost of one interface per PMS. The more heterogeneous the PMS estate, the more convergence must appear in the roadmap.
- Managing profitability per vet without consultation. The scheme must be explained before it is rolled out.
- Over-sizing the ERP. For a group of a few dozen clinics, a well-configured mid-range ERP is often enough. The challenge is adoption, not the number of modules.
Going further
If you are preparing to structure a veterinary group, an architecture audit (PMS, ERP, BI, interfaces, registers) lets you set the boundary between systems before launching a tender: get in touch to discuss it. To dig into the finance side, read our guide on multi-site, multi-entity ERP, consolidation and intercompany (in French).
