> ## Documentation Index > Fetch the complete documentation index at: https://mso.getlemma.com/llms.txt > Use this file to discover all available pages before exploring further. # When platforms bundle payroll and card processing > EHR and vertical SaaS platforms increasingly sell payments and payroll alongside software. The pitch, the tradeoffs, and an evaluation rubric, with the MSO-PC-specific mismatch. **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 | Dimension | What to ask | Good answer | | ------------------------ | ------------------------------------------------------------------------- | ----------------------------------- | | **Multi-entity** | Can I run N entities with separate EINs and separate settlement accounts? | Yes, natively, in one interface | | **Settlement control** | Can each location settle to a different account? | Yes, configurable per location | | **Payroll entities** | Can I run two employers under one login? | Yes | | **Pricing transparency** | Interchange-plus available? Rate by card type? | Published, itemized | | **Unbundling** | What does the software cost without the financial services? | A real number, disclosed | | **Data portability** | What can I export, how, at what cost? | Full export, standard formats, free | | **Reconciliation** | Do settlements reconcile to the patient ledger *and* the bank? | Both | | **Fee handling** | Are fees netted from deposits or billed separately? | Either, but you must know which | | **Contract** | Term, termination, and price-increase provisions? | Short term, clean exit | **"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](/reference/appendix/about-lemma), and the distinction holds regardless of vendor. ## Related topics - [Set up card payments](/guides/payments/set-up-card-processing.md) - [Set up payroll (two employers, one team feeling)](/guides/banking/set-up-payroll.md) - [Choose an EHR/PM system](/guides/billing/choose-an-ehr.md) - [Payment rails 101 (ACH, checks, wires, RTP, cards)](/concepts/banking/payment-rails-101.md) - [Why MSO-PC banking is different](/concepts/banking/why-healthcare-banking-is-different.md) - [Clearinghouse vs RCM vs EHR (vs biller)](/concepts/payments/clearinghouse-vs-rcm-vs-ehr.md) - [All-in-one platforms (payments/payroll bundling) reference](/reference/vendors/all-in-one-platforms.md) - [EHR/PM directory by segment](/reference/vendors/ehr-directory.md)