When platforms bundle payroll and card processing

Bundling means that a software platform sells financial services such as card processing, payroll, lending, and banking alongside its core product. Dental practice management system (PMS) vendors increasingly use this model. It can be a reasonable trade for a single-location practice, but it often fits a dental support organization (DSO) poorly because many platforms are designed around one business, one employer, and one settlement account.

​

The pitch

The benefits can be meaningful at a small practice:

• 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, scheduling, and clinical charting 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 interchange-plus pricing at volume. Dentistry’s large patient-pay share also makes card volume a bigger expense than it is in many medical practices. When software and processing appear on one invoice, neither is easy to benchmark. 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 it becomes to leave. If payment history, payroll records, and patient charts all sit in one system, a migration means replacing everything at once. PMS migrations are already among the hardest system changes a dental group makes. See Choose a PMS. 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. A DSO group has:

• One or more actual employers, determined by state law, entity governance, contracts, licensure requirements, and actual supervision rather than a universal clinical-versus-nonclinical rule
• Multiple legal entities, often with separate EINs and payroll obligations
• Receipt destinations matched to the enrolled billing provider under payer and program terms, merchant and bank documents, state law, and approved transition or reassignment mechanics
• 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 each enrolled billing or merchant entity route receipts to its authorized account while the platform preserves the correct entity ledger? Can it run payroll for every actual employer and EIN in your structure? 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 DSO-PC structure and the platform’s model collide directly. Which entity employs each person is a state- and fact-specific question. Many groups employ licensed clinicians through a professional entity and administrative personnel through a DSO, but state law, licensure rules, contracts, actual supervision, and the worker’s duties determine the answer; hygienists, assistants, and shared personnel cannot be allocated by a national default. A payroll product that assumes one employer may:

• Put a worker on an entity’s payroll without matching the legally responsible employer, creating corporate-practice-of-dentistry (CPOD), employment, tax, benefits, or cost-allocation risk, or
• Require separate payroll instances for the actual employers, which may be workable but is not the integration that was sold

Neither is a disaster. Both need to be understood before you buy, not discovered in implementation.

​

Settlement destination

The applicable law and contracts determine where card payments may land, so the settlement account cannot be treated as a configuration preference. Route patient receipts to the account authorized for the enrolled billing or merchant entity under state law, payer and program terms, merchant and bank documents, and any approved transition mechanics. A platform that forces every location into one settlement account can misroute funds and obscure entity ownership unless the structure is expressly authorized and maintains complete per-entity ledgers.

​

The evaluation rubric

​

When bundling may work well

Bundling can still make sense in a few 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
• Products with useful workflow integration, such as accurate automatic posting of card payments to the correct patient ledger entry

​

Where it typically loses for DSO 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