A Broader View of Payment Reconciliation Goes Beyond Claim Status
Key Insights:
- Claim status is not the same as payment reconciliation—a claim can appear paid before its financial impact is fully accounted for
- Provider-level adjustments affect the overall remittance rather than a single claim, so they don’t always move through claim-level workflows
- Payers don’t consistently structure or populate the reference data needed to connect an adjustment back to its original transaction
- Operational discipline—automating the path to a decision, not the decision itself—strengthens payment integrity
Fueled by rapid technological advancement, the tools payers use to review claims are growing more sophisticated, and provider organizations are being asked to keep pace with finite staff and increasingly fragmented workflows. The operational pressure doesn’t always surface as higher denial rates. Often, it appears in the growing effort required to confirm what happened to a payment after the claim was processed.
A recent roundup of revenue cycle leaders by Becker’s confirms the pattern. Several health systems warn that payer complexity is outpacing administrative resources, and claim-level payment reductions that never appear in traditional denial reporting are among their concerns. A related challenge arises when payment activity happens at the provider level rather than the claim level, creating additional work to identify, reconcile, and account for it.
Claim Status vs. Payment Reconciliation
Claim status tells you what happened to the claim. Payment reconciliation tells you whether the financial transaction was received, posted, and accounted for against the underlying claims and payment history.
Many workflows address the first question cleanly—claims are submitted, adjudicated, posted, and moved out of active work. The second is typically murkier, particularly when payment activity arrives in a form that isn’t tied to a single claim.
The Council for Affordable Quality Healthcare (CAQH) has research on the claim status transaction that highlights part of the problem. Its findings note that what’s reported in a claim status response can differ from what later appears on the remittance advice, and that without payment identifiers such as a check number, providers can end up relying on “paid” responses without directly associating the payment information with the claim.
The space between the two is the blind spot after adjudication, where an account can look finished while the financial picture is still incomplete.
Where Provider-Level Adjustments Show Up
One place this surfaces is the 835 remittance file. When a payer applies an adjustment to the overall payment rather than to a specific claim or service, it’s reported through the PLB segment. Some of those adjustments add to the payment, such as interest or incentives. The adjustments that tend to create reconciliation work are those that reduce the payment: overpayment recoveries, forwarded balances, and other deductions tied to activity from an earlier remittance cycle.
Consider an overpayment recovery. A payer identifies an overpayment on a prior claim and recovers it by reducing a later, unrelated payment. The deduction appears on the current remittance, and when it relates to a prior claim, that claim may already have been posted and closed.
Reconnecting the two isn’t always straightforward. Some payers include a reference identifier, such as their own claim control number, that provides a path back to the original transaction. But those identifiers aren’t uniformly structured or consistently populated across payer implementations. One payer’s companion guide may supply the claim and patient control numbers; another may leave the field unused entirely. The data needed to reconnect an adjustment can be inconsistent, payer-specific, or absent.
It’s important to remember that a PLB adjustment isn’t automatically a mistake. Some are legitimate recoupments an organization genuinely owes. What’s missing isn’t correctness, it’s visibility: whether the adjustment is found, connected to its original transaction, and routed to someone who can decide what happens next.
Posted Isn’t the Same as Reconciled
Most health systems already receive 835s into their patient accounting system, and cash posting teams already process PLBs. The issue usually isn’t that the adjustment goes unseen. It’s that the adjustment may never become an actionable, traceable work item. It can be posted without a meaningful connection to the transaction it references, absorbed into a balance, or left without a defined workflow for review.
Visibility, in that sense, comes down to three things. Detection asks whether every relevant provider-level adjustment was identified. Attribution asks whether, where the data allows, it was connected to the prior transaction, account, or payment activity it relates to. Disposition asks whether it was reviewed and resolved, by accepting it, appealing it, or closing it out.
Once that visibility exists, the questions get more interesting. Which payers generate the most adjustments? Which reasons keep recurring? How much reimbursement is affected? Which items resolve on their own, and which end up written off because no one had time to chase them down?
Automate the Path, Not the Judgment
The value of automation here isn’t that people can’t read an 835. It’s that they shouldn’t have to repeatedly normalize payer-specific information and reconstruct relationships across remittance cycles by hand.
A mature workflow turns a remittance exception into a structured decision opportunity. That means identifying the adjustment, preserving whatever reference information the payer supplied, connecting available historical data where it exists, and routing the item according to rules the organization defines. Clear thresholds must be established to help distinguish what requires minimal intervention, what escalates immediately, and what’s worth flagging as a pattern, so the items that need a decision reach someone who can make it.
The goal isn’t creating a system that tries to assess whether every adjustment is correct. Whether a payer got it right depends on contract terms, payer-specific logic, and context that belongs with the revenue cycle team. The goal is streamlining the work involved in finding, organizing, and routing the exceptions that do require human judgement.
Staying Ahead
A clean claim is one milestone. A processed payment is another. Neither is the end of the story on its own. As payer complexity continues to outpace administrative resources, the advantage belongs to organizations that turn provider-level adjustments into traceable work items as they arrive, rather than untangling them months later, and resolve each one with a clear view of where it came from.
If keeping pace with payer complexity feels like a moving target, we can help. Contact RCMS and let’s talk through it.