> ## 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.

# All-in-one platforms (payments/payroll bundling) reference

> Platforms bundling card processing and payroll with practice software: what's bundled, pricing transparency, multi-entity support, and data portability.

Platforms that sell financial services alongside practice software. This page is the neutral inventory; the tradeoff analysis is in [When platforms bundle payroll and card processing](/concepts/banking/bundled-payroll-and-processing).

**Checked August 2026.** Bundling arrangements change frequently: vendors add and remove financial services, and partner relationships shift. Verify what is actually included and who provides it.

## What gets bundled

| Service                               | Commonly bundled with practice software  |
| ------------------------------------- | ---------------------------------------- |
| **Card processing**                   | Very commonly                            |
| **Patient financing / payment plans** | Commonly, via a partner                  |
| **Text-to-pay and e-statements**      | Commonly                                 |
| **Payroll**                           | Sometimes, usually via a partner         |
| **Banking / deposit accounts**        | Increasingly, usually via a partner bank |
| **Lending / working capital**         | Sometimes                                |
| **Insurance products**                | Occasionally                             |

## The inventory

Representative of the pattern rather than exhaustive. Verify current offerings directly.

| Platform                  | Core product                      | Payments | Payroll | Multi-entity       |
| ------------------------- | --------------------------------- | -------- | ------- | ------------------ |
| **athenahealth**          | Medical EHR/PM + RCM              | Bundled  | Partner | Supported, test it |
| **Tebra**                 | Small-practice medical            | Bundled  | Partner | Limited            |
| **AdvancedMD**            | Independent practice              | Bundled  | Partner | Supported          |
| **NextGen**               | Ambulatory                        | Bundled  | Partner | Supported          |
| **SimplePractice**        | Behavioral                        | Bundled  | —       | Limited            |
| **Jane**                  | Multi-discipline clinic           | Bundled  | Partner | Limited            |
| **WebPT**                 | PT                                | Bundled  | Partner | Supported          |
| **Zenoti / Boulevard**    | Med spa and wellness              | Bundled  | Partner | Varies             |
| **Denticon** (Planet DDS) | DSO-oriented dental               | Bundled  | Partner | **Built for it**   |
| **Curve Dental**          | Dental                            | Bundled  | Partner | Limited            |
| **ezyVet**                | Veterinary                        | Bundled  | Partner | Supported          |
| **Weave**                 | Communications + payments overlay | Bundled  | —       | Varies             |

## The evaluation rubric

| Dimension                  | Ask                                                                                         | Good answer                               |
| -------------------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------- |
| **Multi-entity**           | Can I run N entities with separate EINs and separate settlement accounts, in one interface? | Yes, natively                             |
| **Settlement destination** | 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 and itemized                    |
| **Unbundled price**        | What does the software cost **without** the financial services?                             | A real, disclosed number                  |
| **Data portability**       | What can I export, how, how fast, at what cost?                                             | Full export, standard formats, free       |
| **Reconciliation**         | Do settlements reconcile to both the patient ledger and the bank?                           | Both                                      |
| **Fee handling**           | Netted from deposits, or billed separately?                                                 | Either, but you must know which           |
| **Contract**               | Term, termination, price escalation?                                                        | Short term, clean exit, capped escalation |

<Tip>
  **"What does the software cost without the payments?" is the highest-signal question.** A vendor that cannot or will not answer is subsidizing software with processing margin, which means you are paying for the software in a line item you cannot see or benchmark.
</Tip>

## The MSO-PC-specific failures

Three ways single-entity assumptions break in this structure:

**1. Settlement destination.** Patient payments are the **PC's** revenue and must settle into the PC's account. A platform that settles everything to one configured account will settle your Colorado PC's payments into whichever account was set up first. That is commingling, not a configuration preference.

**2. Two employers.** Clinicians are **PC** employees; everyone else is an **MSO** employee. A payroll product assuming one employer will either put non-clinical staff on the PC's payroll, a CPOM and cost-allocation problem, or require two separate instances, which is fine but is not the integration that was sold.

**3. Reporting per entity.** A bundled platform reporting only at the practice level cannot produce the per-entity financials an MSO-PC group needs. See [Produce investor-grade reporting](/guides/banking/produce-investor-reporting).

**Test all three in the demo, with your actual structure.** Not with the vendor's sample data.

## Bank-integrated vs platform-bundled

A distinction worth naming, independent of any vendor:

|              | **Platform-bundled**                       | **Bank-integrated**                                                                |
| ------------ | ------------------------------------------ | ---------------------------------------------------------------------------------- |
| Attached to  | The practice software                      | The bank account                                                                   |
| Follows      | The software's model, usually one practice | The **entity structure**, each entity has its own account, settlement, and payroll |
| Multi-entity | Worked around                              | Native                                                                             |
| Switching    | Replace everything at once                 | Replace one component                                                              |

For a single-entity practice, platform-bundled is often the better trade — the integration saves real time. For a multi-entity MSO-PC group, the software's single-practice assumption is the thing that breaks, and financial services attached to the account structure rather than the software follow the entities natively.

<Tip>
  When evaluating a **bank-integrated** option, apply the same rubric above that you would to a platform-bundled one — per-entity settlement, two-employer payroll, pricing transparency, and data portability are the questions regardless of which category a vendor sits in. See [Why MSO-PC banking is different](/concepts/banking/why-healthcare-banking-is-different) for the underlying multi-entity problem.
</Tip>

## When bundling is the right call

Being fair, it often is:

* **Single-entity, single-location practices** where integration saves real time
* **Very early stage**, where speed 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 by hand

## When it typically loses

* **Multi-entity groups**, where the single-entity assumption breaks
* **Meaningful card volume**, where blended pricing costs more than negotiated interchange-plus
* **Groups planning a raise or sale**, where per-entity financial clarity affects valuation
* **Groups wanting their own analytics**, where portability beats integration


## Related topics

- [When platforms bundle payroll and card processing](/concepts/banking/bundled-payroll-and-processing.md)
- [Why MSO-PC banking is different](/concepts/banking/why-healthcare-banking-is-different.md)
- [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)
- [EHR/PM directory by segment](/reference/vendors/ehr-directory.md)