RCM Software: Build or Buy, and Why Most Should Buy

I should declare an interest before anything else in this article: I run architecture for a company that builds custom healthcare software, so if you build, we would like it to be with us.

That is exactly why I want to be careful here. A build-versus-buy article written by a build shop that concludes “build” is not analysis, and you would be right to discount it. So I will give you the conclusion first and spend the rest of the article defending it.

Most organizations evaluating revenue cycle management software should buy a platform. Building is the right call in a narrow set of circumstances, those circumstances are testable, and I will give you the test. If your situation does not clear all four parts of it, buying will serve you better than anything we could build, and I would rather tell you that now than eighteen months into a project.

If you want the general shape of the revenue cycle before the software question, our revenue cycle management services covers it, and the 13 steps of the revenue cycle is the plainer version.

What Revenue Cycle Management Software Actually Does

Worth grounding, because “RCM software” describes a wide range of products that overlap unevenly.

The functional scope runs from patient scheduling through to account reconciliation: eligibility verification, prior authorization, charge capture, coding support, claim scrubbing and submission, remittance posting, denial work queues, patient billing and collections, and reporting over all of it. A platform may cover the whole span or a slice of it, and the slice boundaries differ by vendor in ways their marketing pages do not make obvious.

That variation matters for the decision, because the first honest question is not “build or buy.” It is which parts of this span do you actually need, and does any single product cover that combination. A surprising number of build projects begin because someone compared one product against the whole span rather than against the subset they needed.

Where Bought Platforms Genuinely Stop

This is not a list of vendor weaknesses. Established platforms are good, and they encode more accumulated payer knowledge than any single organization could rebuild. The useful question is where their flexibility ends, because that boundary is where the build case begins.

Three categories, and they behave differently:

1. Configurable: Rules, work queues, user permissions, report layouts, claim edits. Changing these is what the product expects you to do. If your requirement lives here, you do not have a software problem, you have a configuration project.
2. Extensible: Anything reachable through an application programming interface or a supported integration point. Slower, needs engineering, but it does not fight the product. A great deal of what organizations believe requires a new platform actually lives here.
3. Fixed: The product’s underlying data model and its assumptions about how an encounter, a claim and an episode relate. You cannot change these, and if your operating model genuinely disagrees with the vendor’s, no amount of configuration reconciles it.
4. Only the third category justifies building: In my experience the majority of “the platform cannot do it” conversations turn out to be category one or two, discovered late because nobody asked the vendor a specific enough question early.

Why Every Cost Estimate You Will Find Is Unreliable

Search for what a custom revenue cycle platform costs and you will find confident ranges. I am deliberately not reproducing them, and the reason is the useful part.

Every published figure I could locate comes from a firm that sells the build. That includes us, which is why I am not adding another number to the pile. And they do not agree. The ranges I found differ by more than ten times at the lower bound, from figures that would fund a small integration project to figures that would fund a department. Two of them do not overlap at all.

That is not because anyone is lying. It is because “custom RCM software” describes projects that genuinely differ by an order of magnitude, and each firm quotes the shape of project it typically does. A range is only meaningful alongside a scope, and a scope is exactly what a marketing page cannot give you.

What actually drives the variance, in rough order:

1. How many external systems you must integrate with, and how well documented they are: This dominates. It is routinely underestimated because integration is invisible in a feature list.
2. Whether you are replacing a working process or inventing one: Replacing is bounded. Inventing is not.
3. How much regulatory surface the software touches: Anything holding protected health information, anything computing a payment, anything producing an audit trail carries obligations that do not shrink with project size.
4. Whether the data has to move: Migration from an existing system is frequently larger than the new build.

So when someone asks me what it costs, the honest answer is that I cannot tell them from the question, and neither can anyone else who has not looked at those four things in their environment. Treat any cost figure offered before that inspection as a marketing artifact rather than an estimate.

Should You Build Or Buy RCM Software? A Four-part Test

Here is the test I actually use. It is deliberately hard to pass.

Build only if all four are true:

1. The workflow is genuinely unusual, not merely unusual-feeling.
2. The unusual part is core to how the organization makes money.
3. It cannot be reached by configuring or extending a bought platform.
4. You can maintain software for its whole life, not just build it.

If any one of these fails, buy. Not “consider buying.” Buy.

The asymmetry is intentional, and it is worth substantiating rather than asserting, because the whole test rests on it.

A wrong buy is recoverable because the exit is someone else’s problem to make possible. Platform vendors compete for switchers, which means data export exists, migration partners exist, and the market has done this before. It is expensive, it takes a year, it is genuinely unpleasant, and it has a known shape. You can price it before you commit, which is why the “what happens to our data if we leave” question below matters more than it looks.

A wrong build is worse in a specific way that people underestimate. There is no vendor competing to help you leave your own software, no migration partner who knows it, and no reference case. The exit cost is unknown until you attempt it. Worse, the failure mode is rarely dramatic: the software works, roughly, and the maintenance quietly loses ground to the changes coming at it. Payer rules move, a code set gets restructured, the integrations drift, and each year the system fits a little less well than the year before. Nobody makes a decision to abandon it, because on any given quarter it is cheaper to patch than to replace.

That is the position the four-part test is designed to keep you out of. Not a spectacular failure, a slow one you cannot easily notice or cost.

Tests One And Two: Unusual, And Does It Make You Money

The first two tests fail more often than people expect, and they fail for different reasons.

1. Unusual-feeling is not unusual: Every organization believes its workflows are distinctive, and at the level of daily experience they are: the sequence of screens, the local vocabulary, who hands what to whom. What matters for a software decision is whether the underlying model is unusual, and it usually is not. A practice that schedules patients, verifies coverage, delivers care, codes it and bills it is running the same model as everyone else with different furniture. The test is whether a vendor’s data model can represent your reality, not whether their screens match your habits.
2. Where genuine distinctiveness does show up is in the specialty layer, and the specialty work in this cluster is a decent illustration of what real difference looks like: cardiology with component splits across a stacked encounter, gastroenterology with a modifier decided mid-procedure, oncology where the drug rather than the procedure carries the value, dermatology where coverage turns on documentation language, orthopedics with episode-level global periods. Those are real structural differences. Even so, most of them are addressable inside a platform’s rules layer.
3. Test two is the one that saves people money: Suppose the workflow genuinely is unusual. Ask whether that unusual thing is how the organization makes money, or whether it is an accident of history. Organizations frequently propose building software to preserve a process that nobody chose, that predates most of the current staff, and that no one can articulate a commercial reason for. Encoding that into custom software makes it permanent and expensive.

If the honest answer is “this is just how we have always done it,” the cheaper project is changing the process to match a bought platform.

Tests Three And Four: Extend Instead, And Maintain For Life

Test three is a question to put to the vendor, in writing, before you conclude anything. Not “can your platform handle X,” which invites a yes. Ask instead: which of these three is X for us, configuration, API extension, or not possible? A vendor who answers that precisely is telling you something useful either way. A vendor who will not answer it precisely has told you something too.

Test four is the one that gets skipped, and it is the one that hurts.

Building software is a project with an end date. Owning software is not. Payer rules change quarterly, code sets get restructured, regulations arrive with compliance dates, and integrations break when the systems on the other end upgrade. Every one of those is a maintenance event, and they keep coming for as long as the software runs.

The specialty work in this cluster produced a steady supply of examples: a code series retired and replaced with a differently structured one, a mandatory modifier introduced with automatic denials attached, a federal interoperability rule with a compliance date. None of those were foreseeable at build time and all of them are maintenance.

So test four is not “can you fund the build.” It is: can you fund a small permanent team, indefinitely, for a system that will never be finished. Organizations that answer honestly here often discover their build case was really a budget-timing case, where the capital was available and the operating cost was not, and that combination is the worst possible reason to build.

The Hybrid Most Organizations Actually Land On

When all four tests are applied honestly, the common outcome is neither pure option. It is: buy the platform, build the thin layer that is genuinely yours.

That layer is usually small and specific. A rules engine for the handful of payer behaviors your platform does not model. A reconciliation process that compares expected against allowed at line level, which most platforms do not do well. A specialty-specific validation that runs before submission. An integration that moves data between the platform and something else you run.

Each of those is weeks of work rather than quarters, sits alongside a supported product rather than replacing it, and can be abandoned without stranding the operation. That last property matters more than it sounds. A thin layer you can throw away is a fundamentally different risk position from a platform you cannot leave.

This is also where the honest version of our own commercial interest sits. Most of the useful work we do in revenue cycle is this shape, not whole-platform replacement, and it is the recommendation I would give regardless of who did the building. If you want the detail on the build option, custom medical billing software development covers what we actually do, and claims processing configuration covers where the rules live.

The Questions That Actually Separate Vendors

Test three depends on getting precise answers from vendors, and the default evaluation process is not built to produce them. A demo shows the happy path. A feature matrix collapses “supported,” “supported with configuration” and “on the roadmap” into the same tick. Neither tells you what you need.

Six questions that do. I have watched all six change a decision.

1. “For each of these requirements, is it configuration, API extension, or not possible?” The question from test three, asked as a written list rather than a conversation. The value is partly in the answers and partly in whether you get answers at all.
2. “Show me the exception path, not the happy path.” Ask to see a claim that denies, gets worked, gets appealed and gets resolved. Ask to see a patient with two coverages where the secondary is wrong. The demo is built around the clean case; your revenue problem lives in the other one.
3. “What happens to my data if we leave?” Format, completeness, timeline, cost. A vendor who has thought about this answers immediately. The answer also tells you your real switching cost, which is the number that determines whether a wrong buy is genuinely recoverable.
4. “How often do you change the data model, and what happened to customers the last time you did?” Platforms evolve. If your custom extensions sit on top of it, their upgrade is your maintenance event.
5. “Which of my integrations are pre-built, which are configured, and which are custom work?” Integration count is the dominant cost driver whichever path you take. Pre-built means someone else maintains it. Custom means you do, even inside a bought platform.
6. “Who is accountable when a claim is wrong because of your rules engine?” Not a legal question. An operational one. The answer reveals whether the vendor treats their content as a product they stand behind or as a configuration you own.

If you get precise answers to all six, you can run the four-part test properly. If you cannot get answers, that is itself a finding, and it belongs in the decision.

What Building Actually Involves

If you have cleared all four tests, here is what you are taking on, described without enthusiasm.

1. Integration is the project: Not a workstream in it. Eligibility, clearinghouse, remittance, the electronic health record, the practice management system, whatever holds your contracts. Each has its own interface, its own reliability characteristics and its own upgrade schedule. Anyone who scopes a revenue cycle build primarily by feature list has scoped the wrong thing.
2. The edge cases are the product: The happy path in claims processing is straightforward and is not where the money is. The value is in the exceptions, and exceptions are discovered rather than specified, which means the requirements will grow during the build in ways that are not scope creep but genuine discovery.
3. Compliance is continuous, not a phase: Protected health information, audit trails, access control, breach obligations. These are architectural decisions made early that are expensive to retrofit.
4. And the last mile is where schedules die: Connecting to a major electronic health record is well understood. Getting a result to land in the right field, in the right workflow, in front of the right person, in a way that survives the vendor’s next upgrade, is the part that takes the time. I say that as the person who has to estimate it. Anyone presenting that part as routine has not done it.

When Buying Clearly Wins, And It Usually Does

The explicit version, because an article like this owes one.

• Buy when your workflows are ordinary, which is most of the time, and when a platform’s data model can represent your operation without contortion.
• Buy when the requirement is configuration or extension, which is where most requirements actually live.
• Buy when you cannot commit to permanent maintenance, regardless of how well the other three tests went. This one overrides.
• Buy when speed matters more than fit. A platform running next quarter usually beats a better-fitting system running the year after, because the revenue leaks in the meantime are real and the perfect system frequently arrives late.
• Buy when you do not have engineering capacity you are willing to dedicate permanently. Borrowed capacity builds things nobody maintains.

For the shortlist itself, our list of revenue cycle management companies is a starting point, and healthcare claims management software covers the claims-specific product category.

What Your Integration Layer Has To Do Either Way

One thing does not change with the decision, which is why it deserves its own section.

Whether you buy, build or run the hybrid, you will operate more than one system, and the quality of the connections between them will set the ceiling on everything else. Standards and systems are the vocabulary here: X12 transaction sets for claims and remittance, HL7 v2 and FHIR for clinical data, and whichever electronic health record you run, whether that is Epic, Cerner or eClinicalWorks.

Four things the layer has to do:

1. Move data both directions: Reading is the easy half. Writing back into the system of record, correctly and idempotently, is where the difficulty concentrates.
2. Reconcile identity across systems that were never designed to agree on what a patient, an encounter or an episode is.
3. Fail visibly: A silent integration failure produces a revenue gap nobody notices for a month.

Survive upgrades on the other side, which you do not control and are not consulted about.

Buying a platform does not remove this work. It changes who does it and how much of it is your problem, which is a real difference but not the same as elimination. Our prior authorization services covers one instance of this in depth, and automation in the revenue cycle and robotic process automation cover the approaches frequently proposed as an alternative to proper integration, which they are not.

Buying The Operation Rather Than The Software

Build-versus-buy framings usually omit a third option that is frequently the right one: do not run the revenue cycle yourself at all.

Outsourcing moves the software decision to someone whose business it is, along with the staffing, the payer expertise and the maintenance burden. For organizations under a certain size, or without anyone who owns billing technology as a job, it outperforms both alternatives comfortably. Outsourcing revenue cycle management covers where that line usually falls, and medical billing versus revenue cycle management clarifies the scope difference if it is fuzzy.

Two cautions, both from the work elsewhere in this cluster. Outsourcing relocates a problem that originates upstream rather than solving it, so if your denials are created at eligibility, an outsourced biller inherits bad data and works it faster. And a partner reporting performance against their own metric definitions is not independently verifiable, which is why how to improve revenue cycle management argues for owning the definitions whoever does the work. Rural and critical access organizations carry a different profile again, covered in critical access hospital reimbursement, and specialty operations like behavioral health have their own considerations.