A three-location pediatric group replaced its practice management system in 2024. The physicians loved the new EHR side: cleaner notes, better templates, a portal parents actually used. Eight months later the billing manager was exporting claims to a spreadsheet to find out which ones had been rejected, because the new system's rejection queue showed the clearinghouse message but not the claim it belonged to. Days in AR had gone from 31 to 47. Nobody on the selection committee had been a biller.
That is the most common story we hear when a practice asks us how to choose a practice management system (PM system, the software that handles scheduling, registration, eligibility, charge entry, claims, payment posting, statements and reports, as distinct from the EHR that holds the clinical record). The clinical side gets the demo time because physicians sign the contract. The billing side inherits whatever was chosen and spends the next five years working around it.
We are going to leave the clinical evaluation to others and describe what the billing team needs from the system: the specific features to test with your own data during the demo, the reports that have to exist on day one, the contract terms about your data that matter more than the monthly fee, and a simple scoring sheet so the decision is made on evidence rather than on the salesperson's manner.
Key takeaways
- Test the system with your own real workflows during the demo: an eligibility check, a claim with a modifier, a rejection, an ERA posting and a secondary claim.
- Reports are the deciding factor for billing; if the system cannot produce AR by payer and aging, denials by reason code and unbilled encounters without a custom report request, keep looking.
- Contract management, meaning loaded fee schedules and an expected-versus-paid variance report, separates systems that find underpayments from systems that hide them.
- Ask in writing who owns the data, what format you get it in at termination and what it costs to get it.
- Score every candidate on the same sheet, weighted toward the daily tasks your billers do most, and let the billing manager's scores count as much as the physicians'.
Start with what your billers do all day
Before any demo, have the billing team write down the ten tasks they perform most and how long each takes in the current system. In most independent practices the list looks the same: checking eligibility, entering or reviewing charges, scrubbing and submitting claims, working the rejection queue, posting electronic remittances, working denials, billing secondaries, sending statements, answering patient balance questions and running month-end reports. Then have them list the five things about the current system they would fix if they could. That second list is the real requirements document, and it is worth more than any vendor's feature matrix.
Bring both lists to every demo, and insist that the vendor perform each task in front of you using a test patient with your payer mix.
The billing features to test live
Eligibility first. Ask the vendor to run a real-time 270/271 eligibility check on a test patient with Medicare and with your largest commercial payer, and to show you where the response lands: deductible remaining, copay, coinsurance, plan effective date, and whether it can be run in batch for tomorrow's schedule automatically. Ask what it costs per transaction, because eligibility fees are often billed separately and add up quickly.
Claims next. Watch a claim built from a visit with an E/M plus a procedure and modifier 25, and a second with two procedures and an XS modifier. Ask to see the scrubber catch a missing modifier and an NCCI edit before submission, and ask whether the edit rules are updated quarterly and by whom. Then ask for a rejected claim: how does the 277CA rejection reach the biller, does it link to the claim, can the biller fix it and resubmit from the same screen, and does the system keep the history of the original submission date (which matters for timely filing appeals).
Remittance posting is where the pediatric group's new system fell apart, so test it hard. Have the vendor post a sample 835 electronic remittance and show you how it handles a denial with a CO-197, a PR-1 deductible transfer to patient responsibility, a CO-45 contractual adjustment, a takeback, and a secondary crossover indicator. Then ask what happens to a line the system cannot auto-post: where does it go, who sees it, how is it flagged. Finally, ask to see a secondary claim generated automatically from the primary remittance, with the primary payment information carried onto the claim.
| Area | Test to run in the demo | Pass looks like | Fail looks like |
|---|---|---|---|
| Eligibility | Batch check for tomorrow's schedule | Runs automatically, flags inactive coverage and unmet deductible on the schedule view | Manual one-at-a-time lookups, response buried in a PDF |
| Claim scrubbing | Submit a claim with a missing modifier | Edit fires before submission with a plain-language message | Claim goes out and comes back rejected days later |
| Rejections | Show a 277CA rejection | Linked to the claim, fixable and resubmittable in place, history retained | Message in a separate report with no claim link |
| ERA posting | Post an 835 with a denial and a deductible transfer | Auto-posts, routes exceptions to a work queue, transfers PR balances correctly | Everything posts as paid or everything needs manual review |
| Reporting | Run AR by payer and aging bucket | Standard report, exportable, filterable by provider and location | Requires a custom report request or a paid add-on |
| Contracts | Load one fee schedule and run a variance report | Expected versus paid by CPT, by payer, with variance flagged | No contract module or spreadsheet only |
Reports: the deciding factor
A billing team runs on reports, and the reports that matter are boring and specific. Accounts receivable by payer and by aging bucket, as of a date you choose. Denials by claim adjustment reason code, by payer, by provider, for a date range. Unbilled encounters: visits with a signed note and no claim, or a claim on hold, by provider and days since service. Charge lag by provider. Payments by payer by month. Adjustments by adjustment code. Patient balances by aging with statement history. Credit balances. Claims submitted and rejected by day.
Ask the vendor to run each of these live, with filters, and export one to a spreadsheet. If the answer to any of them is "we can build that for you" or "that is in our analytics package," find out what the package costs and whether the report exists in the base product. In our experience, a system that requires a custom report for AR by payer is going to require a custom report for everything, and the billing manager will be back to spreadsheets within a year. A monthly reporting habit like the one described in our RCM audit work depends entirely on these reports existing without a ticket.
Contract management and underpayment detection
Most practice management systems can post whatever the payer pays. Far fewer can tell you whether the payer paid what the contract says. That requires a contract module where you load each payer's fee schedule by CPT code, and a variance report comparing the expected allowed amount to the actual allowed amount on each remittance line. Without it, a payer that loads the wrong fee schedule in January (which happens every year) pays you 6 percent less on every claim and nobody notices until an audit.
Ask whether the contract module is included, how fee schedules are loaded (by file import or by hand), whether it supports percentage-of-Medicare contracts that recalculate when the Medicare schedule changes, and whether the variance report can be run as part of remittance posting so underpayments are flagged the day they arrive. This is one of the few features where we would tell a practice to pay more for a system that has it. The money it finds tends to exceed the price difference.
Data ownership, conversion and the exit
You will leave this system someday. Plan the exit before you sign. Ask, in writing, who owns the data, whether you can export a complete copy of patient demographics, insurance, charges, payments, adjustments and claim history at any time, in what format, and at what cost. Ask what the vendor charges for a data extract at termination, and how long after termination you retain read-only access to the old system, because you will be working AR from the old system for six to twelve months after the switch. Vendors that answer these questions vaguely are telling you something.
Ask the same about the conversion in. What comes over from your current system: demographics and insurance, certainly; open AR balances, usually as summary balances rather than claim-level detail; historical claims, often not at all. Understand that you will most likely run two systems in parallel for a period, billing new charges in the new one and working old claims in the old one, and budget the staff time for it. The pediatric group did not, and the AR spike came partly from the conversion rather than the software.
A scoring sheet that makes the decision
List the features and reports above as rows. Weight each row by how often the task is performed: daily tasks weighted three, weekly two, monthly one. Score each vendor from zero to three on each row based on what you saw in the demo, not what the brochure said. Have the billing manager, the front desk lead and one physician score independently, then compare. Multiply, sum and look at the total, and then look at any row where a vendor scored zero on a daily task, because a zero on ERA posting is disqualifying regardless of the total.
Then check references, and ask specifically for a practice of your size and specialty that has been live for more than a year. Ask that reference the five-fixes question from the beginning: what would you change about the system if you could? The answer will be more useful than anything in the demo.
Questions we hear
Should the practice management system and the EHR come from the same vendor?
Usually yes for a small practice, because the integration between the clinical note, the charge and the claim is where most manual work and most lost charges happen. Separate systems can work well with a solid interface, but every interface is a point of failure, and someone has to own it. If the best clinical system has a weak billing side, ask hard questions about the interface to a separate billing system before assuming it will be fine.
How long does a switch take?
It depends on the practice and the vendor, but plan for three to six months from contract signature to first claims out of the new system, and another six to twelve months of working down AR in the old one. Anyone who promises a six-week switch for a multi-provider practice is describing the software installation, not the transition.
Can we let the billing company choose the system?
If you outsource billing, the billing company's preferred system matters because their staff know it. But the contract, the data and the exit should be yours, not theirs. A practice that bills through a vendor's proprietary system and then changes billing companies can find itself without access to its own history. Own the license and the data, and let the billing company work inside it.
What to do this week
- Have the billing team write the ten most frequent tasks and the five things they would fix in the current system.
- Build the scoring sheet from the test table above, weighted by task frequency, before scheduling any demo.
- Prepare three test patients with your real payer mix and the claim scenarios you want each vendor to perform live.
- Draft the data ownership and exit questions and send them to each vendor in writing ahead of the demo.
- Ask each vendor for a reference practice of your size and specialty that has been live for at least a year.
