The pitch
The pitch is appealing, and largely true at small scale:- One vendor, one contract, one support number
- Integrated posting, card payments reconcile to the patient ledger automatically
- Faster setup than sourcing a processor and a payroll provider separately
- Bundled pricing that can beat separately negotiated rates at low volume
- One data model, payments, payroll, and clinical data in one place
The tradeoffs
Pricing opacity
Bundled pricing hides the components. A platform quoting “3.5% + 30¢” for card processing is quoting a flat blended rate that may be well above what interchange-plus pricing would cost you at volume. Because the software and the processing are one invoice, you cannot easily benchmark either. What to ask: what is the effective rate by card type, is interchange-plus available, and what is the software price if I bring my own processor?Data lock-in
The more of your operations run through one vendor, the harder leaving becomes. Payment history, payroll records, and clinical data in a single system means a migration is a simultaneous replacement of everything. What to ask: what can I export, in what format, at what cost, and how quickly? Get it in writing.No multi-entity support
This is the most important tradeoff for an MSO-PC group. Bundled financial services are usually built around one business, one EIN, one bank account, one payroll. An MSO-PC group has:- Two employers: the PC employs clinicians, the MSO employs everyone else
- Multiple PCs, each its own employer with its own EIN
- Per-PC bank accounts that payments must settle into correctly
- A management fee flowing between entities
The “who employs whom” mismatch
Bundled payroll is where the MSO-PC structure and the platform’s model collide directly. Your clinicians are PC employees. Your front desk, billers, and administrators are MSO employees. Sometimes they sit in the same room. A payroll product that assumes the practice employs everyone will either:- Put non-clinical staff on the PC’s payroll, creating a CPOM and cost-allocation problem, and putting the wrong people on the wrong entity’s books, or
- Require two separate accounts, which is fine but is not “bundled”
Settlement destination
Where card payments land is a compliance question. Patient payments are the PC’s revenue and must settle into the PC’s account. A platform that settles all payments to one configured account will settle your Colorado PC’s patient payments into whichever account you set up first.The evaluation rubric
Where bundling wins
Bundling is a reasonable choice in these cases:- Single-entity, single-location practices where the integration saves real time and the volume doesn’t justify negotiating separately
- Very early stage, where speed to launch matters more than optimized economics
- Small teams with no finance function to manage multiple vendors
- Where the integration is deep, automatic posting of card payments to the correct patient ledger entry is real work you’d otherwise do manually
Where it typically loses for MSO-PC groups
- Multi-entity groups, where the single-entity assumption breaks the model
- Groups with meaningful card volume, where blended pricing costs more than negotiated interchange-plus
- Groups planning a raise or sale, where per-entity financial clarity matters to valuation
- Groups that want their own analytics, where data portability matters more than integration
Financial services fall into two categories regardless of vendor: bank-integrated financial services and platform-bundled ones. Financial services attached to the bank account itself follow the entity structure natively: each entity has its own account, its own settlement, its own payroll. Financial services attached to the practice software follow the software’s model, which is usually one practice. For a multi-entity MSO-PC group, that difference determines whether the structure is supported or worked around. Lemma builds in the former category; named here under our mention policy, and the distinction holds regardless of vendor.