Hey there, We’re Shivang & Tania. Each week, we write in plain English (and some sass) about how health insurance works, why claims get denied, and how patients and healthcare teams can get paid or reimbursed. If you’re new here, we recommend you start with RCM 101: How Healthcare Gets Paid, Eventually, Maybe

A claim is the structured request for payment that carries information about a healthcare service into the reimbursement system. But sending it is only the beginning.This week, we follow one claim from Dr. Singh’s office to Sage’s billing workflow, through electronic submission, into Otis’s side of claims processing, and back out as payment information for the provider and a benefit explanation for Biscuit. By the end, you’ll know what an 837 and 835 actually do, where a clearinghouse can fit, why rejected and denied mean different things, what happens during adjudication, and why a $1,000 charge may end with a very different payment. And if you work in RCM, there’s a second map underneath all of that: When a claim fails, where did the condition that produced the failure actually begin?

Before we follow Biscuit’s claim, we need to clear up something important.

There is no single kind of health coverage in the United States.

Biscuit could have a commercial insurance plan. He could be covered through an employer with a self-funded health plan, where the plan sponsor bears the financial risk for covered claims while a third-party administrator or insurer may handle claims administration.

He could have Original Medicare, Medicare Advantage, Medicaid, or coverage through a Medicaid managed care organization. Those arrangements are different.

The benefits can be different. The organizations involved can be different. The provider contracts, authorization requirements, reimbursement policies, claim edits, payment methodologies, and appeal processes can all be different.

But underneath those differences is a layer of national standards for certain electronic healthcare transactions.

HIPAA-covered health plans include insurance companies, employer-sponsored health plans, and government programs such as Medicare and Medicaid. HHS also recognizes healthcare clearinghouses as a separate type of covered entity. For self-funded plans, the Department of Labor explains that the plan sponsor generally bears the claims-paying risk, while outside administrators may handle claims and other administrative work. [HHS.gov]

Two claims can use the same electronic language and still end very differently.

And when I say “payer side” in Biscuit’s story, I’m using it as shorthand for the side receiving and processing the claim. Depending on the coverage arrangement, that side could involve an insurer, an administrator working for a self-funded plan, a Medicare contractor, a Medicare Advantage organization, a Medicaid program, or a Medicaid managed care plan.

For Biscuit’s patient-facing paperwork later in the story, we’ll use an EOB from a commercial-plan example. Other programs can use different notices. Original Medicare, for example, sends beneficiaries a Medicare Summary Notice rather than the commercial-style EOB we’ll give Biscuit.

Now we meet Sage. Sage works on the provider side, in the lab’s billing and revenue-cycle workflow. By the time Biscuit’s test reaches Sage, the clinical work has already happened.

Dr. Singh placed the order, and the lab had already performed the service, with the relevant documentation.

Now information about that service has to be turned into something the organization processing Biscuit’s health benefits can receive and process.

That is the claim.

CMS describes the standardized healthcare claim transaction as a request from a healthcare provider to a health plan to obtain payment, together with the information needed to process that request. And CMS is very explicit that the standard applies across HIPAA-covered entities, not only organizations working with Medicare or Medicaid. [CMS]

That is why CMS appears so often in our sources. It does not mean Biscuit has Medicare. CMS is one of the federal authorities explaining the national electronic transaction standards we are following.

Sage pulls up the claim: “This is going out as an 837.”

Biscuit would reasonably answer: “That explains absolutely nothing.”

The 837 is the standardized X12 transaction used to send electronic healthcare claim information. X12 is the standards organization behind the transaction format.

You do not need to know how an X12 file is written.

There are different types of 837 claim:

For our worked example, we are going to assume Biscuit’s outside lab is billing this particular service through the professional-claim workflow.

So Biscuit’s example uses an 837P.

(This is an illustration and not a claim that every laboratory service in every setting is always billed the same way)

The claim does not read like a letter:

“Dear insurance company, Biscuit got a blood test. Please pay us.”

It is structured data. Depending on the claim, that can include information about the patient or subscriber, the health plan, the billing and rendering provider, dates of service, where the service occurred, diagnosis information, the services or procedures reported, units, modifiers when applicable, charges, and other required information.

A few more acronyms live here, remember these from Medical billing 101:

You do not need to memorize those code sets to understand the claim. The important part is where the information came from.

Dr. Singh created clinical facts. The lab performed the test. Coding describes the relevant service in standardized terms. Sage’s side turns the information needed for billing into structured claim data. Sage builds and sends.

This is where claims become much more interesting. Sage can build an electronic claim that is perfectly formatted.

Every required field can be in exactly the right place. The receiving system can understand it perfectly. That does not mean the claim will ultimately be payable.

Because a lot was already true before Sage created it:

The claim inherits those upstream facts. That is why a technically clean 837 can still carry a reimbursement problem.

We have already taken Biscuit through prior authorization in an earlier pre·imbursed issue, so we are not going to rebuild that system here.

But it belongs on this map. If Biscuit’s test required prior authorization, that requirement existed before Sage submitted the claim.

And this still matters: Prior authorization does not guarantee payment.

Prior authorization addresses an authorization requirement.

Other conditions can still affect the final claim: eligibility, benefit coverage, coding, documentation, contractual requirements, and other applicable payment rules.

That is exactly why the claim is so useful as a teaching device.

It is where many things that happened separately finally meet.

When Sage clicks submit, the 837 still has to travel from the provider to the organization responsible for processing the claim. People often assume that every claim passes through a clearinghouse along the way, but that is not always true. Some providers use a clearinghouse, while others send claims through a more direct electronic connection.

A clearinghouse helps prepare, check, and route electronic healthcare transactions. HHS defines it as an organization that converts health information from a nonstandard format into a standard one, or the reverse. HHS also notes that providers can conduct electronic transactions directly or work through billing services and other third parties. [HHS.gov]

The transmission step may include a clearinghouse, but the clearinghouse does not decide whether Biscuit’s plan covers the test, whether it was medically necessary, or how much the provider should be paid. It simply helps the claim reach the claims-processing side, where it may go through additional front-end checks before entering adjudication.

Which brings us to two words that get mixed up constantly.

A rejected claim and a denied claim may both result in no payment, but they fail at different stages and often require different responses.

When a claim is rejected: Suppose Sage submits Biscuit’s claim, but required information is missing, an identifier is invalid, or the claim fails a front-end edit. The claim does not successfully move into adjudication, so Sage must identify the error, correct it, and resubmit the claim when appropriate.

When a claim is denied: Now imagine the claim passes those front-end checks and reaches adjudication. The claims-processing side evaluates it under the applicable benefits, coverage policies, authorization requirements, edits, and payment rules, then determines that some or all of it will not be paid. That is what we mean by a denial.

Biscuit: “So rejected means denied?”

Sage: “Different stage. Different problem.”

Do not rely on the label alone

Organizations do not always use the words rejected and denied consistently. Instead of relying only on the label, ask:

For RCM teams, a 277CA is one transaction that can communicate claim-level acknowledgment information, while a 999 is used to acknowledge whether an X12 transaction met applicable implementation requirements. CMS’s Version 5010 materials include both transactions. [CMS]

Understand the result before choosing the next step.

Even when a claim was denied, the answer is not always an immediate appeal. Depending on the reason and the plan’s process, the next step may be correcting the claim, providing additional information, resubmitting it, requesting reconsideration, filing an appeal, or taking another required action.

First understand what happened. Then decide how to respond.

This time, the claim makes it past the front end. Now we meet Otis. Otis represents the payer / claims-administration side of our story. That does not mean Otis represents one specific insurance company.

Depending on Biscuit’s coverage arrangement, the entity processing the claim could sit inside a very different structure.

Biscuit looks relieved: “So now they pay?”

Otis pulls up the claim: “Now it gets adjudicated.”

Biscuit stares: “I knew there was going to be another word.”

Adjudication is the process of evaluating the claim and determining the financial result under the applicable benefits, rules, contracts, and payment arrangements.There is no universal eight-step conveyor belt every health plan follows in exactly the same order.

Different plans and administrators have different systems, benefit designs, reimbursement policies, contracts, edits, and workflows.

So think of these as categories of questions that may matter, not a guaranteed sequence.

The 837 itself is not Biscuit’s complete medical record. Supporting clinical documentation can exist outside the claim and may be exchanged or requested separately.

Otis shows Biscuit the financial result. The lab submitted a $1,000 charge, but because it is in network, the amount recognized under its contract with the plan is $650. The $350 difference becomes a contractual adjustment, while the $650 allowed amount is divided between the plan and Biscuit.

In this example, the plan pays $550 and Biscuit is responsible for $100:

$1,000 billed − $350 contractual adjustment = $650 allowed

$650 allowed = $550 plan payment + $100 patient responsibility

Biscuit looks back at the original charge. “So they billed $1,000, but nobody is paying $1,000?”

“Not in this example.”

That is the point. The billed charge, allowed amount, contractual adjustment, plan payment, and patient responsibility are all different numbers. The original charge does not tell Biscuit what he owes, and the amount paid by the plan does not tell an RCM team whether the claim paid correctly. These figures are only illustrative; a real claim depends on the plan, provider contract, service, benefit design, and payment methodology.

For an RCM team, “the claim paid” is only the beginning. You still need to determine whether it paid at the expected allowed amount, whether the correct adjustment was applied, how much responsibility was assigned to the patient, and whether the final result matches the applicable contract or payment methodology.

That is where payment analysis starts.

Remember that the 837 carries claim information from the provider toward the payer or claims administrator. Once the claim has been adjudicated, the financial result can travel back to the provider through another standardized transaction: the 835.

The 835 is the X12 Health Care Claim Payment/Advice transaction. It carries the Electronic Remittance Advice, or ERA, which explains how the claim was processed. The ERA can show what the plan paid, which adjustments were applied, and how much was assigned to the patient based on factors such as the provider’s contract, benefit coverage, copays, and coinsurance. Version 5010 remains the adopted standard for the 835 transaction. [CMS]

Sage sends the first and receives the second.

The remittance does not simply say:

“We paid less than you billed. Figure it out.”

Standardized codes help describe adjustments.

You do not need to memorize individual codes for this issue. The useful idea is that the remittance contains structured clues about the financial outcome.

For an RCM team, those clues matter. But the reason code is not always the same thing as the root cause. It can tell Sage how the payer categorized the result.

Sage may still have to work backward to understand what created that condition.

For our worked example, Biscuit’s commercial health plan sends an EOB (Remember from Medical billing 101 ?)

EOB means Explanation of Benefits

It can show what the provider charged, what the plan allowed, what the plan paid, and what amount may be Biscuit’s responsibility.

Biscuit looks at the document.

“So this is my bill?”

No. CMS says this plainly:

An EOB is not a bill. [CMS]

If Biscuit owes the provider money, a provider bill can come separately.

Same underlying claim processing.

Different purposes. And remember, EOB is the patient-facing document in our worked example, not a universal name for every coverage arrangement.

Original Medicare beneficiaries receive a Medicare Summary Notice. Other plan or Medicaid arrangements may use their own patient-facing communications.

Suppose Biscuit’s claim was denied. The denial may appear at the end of the process, but the problem could have begun much earlier. Perhaps the test required prior authorization that was never obtained, his eligibility information was incorrect, or the order and supporting documentation were missing something the payer needed. The issue could also have been introduced during coding or claim creation, or the claim may have failed a submission check before it ever reached adjudication.

It is also possible that everything leading up to the claim was handled correctly, but the payer’s benefits, coverage policy, contract terms, or payment rules still produced a denial. A claim can even be paid and still reveal a problem if the amount is different from what the provider expected under its contract.

This is why it is misleading to assume every denial means billing made a mistake. Sometimes it does, but the underlying issue may have started before the care was delivered, in the clinical documentation, during coding, when the claim was created, or in the way it was adjudicated. The point is not that every denial begins upstream. The more useful question is:

Where did the condition that produced this outcome first enter the process?

When a claim fails or pays differently than expected, do not begin by assuming you already know the cause. Follow the result backward through the process.

1. Identify where the problem became visible

First, locate the stage where something went wrong. Did the claim fail during transmission or front-end intake? Did it reach adjudication and come back denied? Or did it pay, but at an amount different from what you expected?

Knowing where the issue appeared helps narrow the investigation, even if it does not yet tell you where the issue began.

2. Read the response that came back

Look at the actual response rather than relying only on how someone described the outcome. A submission error, claim acknowledgment, adjustment code, denial, and unexpected payment each point to a different part of the process and may require a different next step.

Before correcting, resubmitting, or appealing the claim, understand what the response is actually telling you.

3. Determine which requirement was being evaluated

Next, identify the rule or requirement connected to the outcome. Was the issue related to eligibility, coverage, prior authorization, coding, documentation, contract terms, or the payment methodology?

This turns a broad label such as “denied” or “underpaid” into a specific question the team can investigate.

4. Trace the issue back to its origin

Once you know the requirement, determine where the information or action behind it originated. The issue may have started during registration, scheduling, prior authorization, the clinical encounter, coding, claim creation, or contract configuration.

This matters because the team that sees the denial is not always the team that can prevent it from happening again.

5. Decide whether this is one claim or a pattern

Finally, look beyond the individual account. Is the same issue appearing across a particular payer, plan, service, code, location, or workflow?

Correcting one claim resolves one account. Identifying a repeated pattern can reveal a broken process, misunderstood payer rule, or configuration problem affecting many claims. That is the difference between working a denial and learning from one.

You do not need to memorize terms like 837, 835, CARC, or RARC. What matters is understanding enough of the process to ask better questions when a claim does not go as expected.

Biscuit looks at Otis one more time.

“So when does insurance pay?”

Now we can finally answer. After Biscuit receives the test, Dr. Singh’s clinical information and the lab’s records are used to build the claim. The claim is sent as an 837, either through a clearinghouse or a more direct electronic connection, to the organization responsible for processing it.

Before payment is considered, the claim must pass front-end checks and enter adjudication. That is where the applicable benefits, coverage policies, authorization requirements, claim edits, contract terms, and payment rules are evaluated. Only then is the financial result determined.

An 835, also called an Electronic Remittance Advice, can carry the payment information back to the provider. Biscuit receives a separate patient-facing explanation from his plan, an EOB in our commercial-plan example.

Biscuit studies the route.

“That was definitely more than ‘submit claim, get paid.’”

A claim sits surprisingly far downstream. By the time it reaches adjudication, decisions have already been shaped by coverage and authorization requirements, clinical documentation, coding, provider contracts, payment methodologies, and federal or state rules. Those requirements can also change depending on the payer, plan, line of business, jurisdiction, and contract involved.

That complexity is part of what we are working on at Converus. We are building a way for reimbursement teams to organize payer policies, contracts, billing requirements, and regulatory guidance into intelligence they can actually use before submitting a claim. Converus does not adjudicate claims, replace the health plan or administrator, or guarantee that a claim will be paid. The goal is to help teams understand the requirements that may shape the outcome before the outcome becomes the first time they discover them.

Because the claim may be where the problem becomes visible, but it is not necessarily where the problem began.

That's it for this issue. Hit reply. I read everything.

[Disclosure: The authors are the co-founders of Converus.ai, a company that organizes payer policy information for healthcare providers, and therefore has a commercial interest in the subject matter discussed. References to Converus.ai are made only where relevant and are not paid placements. To the fullest extent permitted by applicable law, the author and preimbursed disclaim all warranties and shall not be liable for any direct, indirect, incidental, consequential, or other damages arising out of or in connection with your use of, or reliance on, the Newsletter,