Skip to main content
Bundling is when a software platform sells adjacent financial services — card processing, payroll, lending, banking — alongside its core product. In healthcare, EHR and practice management vendors increasingly do this, and for a single-location practice it is often a reasonable trade. For an MSO-PC group it frequently is not, for a structural reason: these platforms assume one business with one employer and one bank account.

The pitch

Genuinely 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
For a solo practice, the time saved is real and the tradeoffs are mostly theoretical.

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

The critical one for this audience. 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
Platforms that assume a single entity handle this by making you run separate instances, which defeats the integration benefit while keeping the pricing and lock-in costs. Test the multi-entity case in the demo, with your actual structure. Ask: can card payments taken at one location settle into that PC’s account while a different location settles into a different PC’s account? Can you run two payrolls under two EINs? If the answer involves separate logins per entity, you have the same problem you had before, plus a bundle.

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”
Neither is a disaster. Both need to be understood before you buy, not discovered in implementation.

Settlement destination

Where card payments land is a compliance question, not a configuration preference. 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

“What does the software cost without the payments?” is the highest-signal question on that list. A vendor that cannot or will not answer it is subsidizing software with processing margin, which means you are paying for the software in a line item you cannot see or benchmark.

Where bundling genuinely wins

Being fair, it is not always the wrong call:
  • 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 genuinely 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
There is a distinction worth naming that isn’t about any particular vendor: bank-integrated financial services versus 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.