- A deposit tells you how much arrived. The 835 tells you what the payer did to each claim, and one payment file can hold every possible outcome at once.
- Billed, allowed, paid, adjusted, and patient responsibility are five different numbers. Reading only “paid” hides the other four.
- “Paid” is not “paid correctly.” A claim can be adjudicated, paid, and still short of what your contract says.
- Posting the money is step one. The value is in the exceptions: denials, partial payments, variances, and patterns that repeat.
Thursday, 10:14 AM. An ERA arrives. The payer deposited $18,742.31.
Finance sees the deposit. Billing sees the remittance. Leadership sees cash. It looks like a good morning.
But inside that same remittance:
- several claims were paid in full
- two were partially paid
- one shifted an amount to patient responsibility
- three contain adjustments
- one was denied
- another was paid below the expected contracted amount
All of those outcomes can sit inside the same payment file. The deposit tells you how much money arrived. The remittance tells you why, and what is still open.
A bank deposit answers “how much?” The 835 helps answer “what happened?”
First: ERA and 835 are related, but they are not exactly the same thing
ERA stands for Electronic Remittance Advice: the payer's electronic explanation of how it processed a set of claims. 835 is the standard electronic transaction commonly used to carry it. The X12 835 is the HIPAA-adopted standard for health care payment and remittance advice, and Medicare, for example, sends its ERAs in the X12 835 format.
In everyday billing conversations, teams use “ERA” and “835” almost interchangeably, and for this article that's fine. The point that matters operationally is that the remittance carries structured information about how the payer processed each claim. Structured means a system can read it, line by line, rather than someone squinting at a PDF.
The payer does not just send a payment amount
Depending on the claim and the outcome, a remittance can carry:
- payer information
- payee information
- payment information
- claim status
- billed amount
- allowed amount, where supplied
- paid amount
- adjustments
- patient responsibility
- service-line details
- adjustment reason information
- other remittance information
The exact information and structure vary with the claim, the payer, the transaction, and the adjudication outcome. Not every remittance supplies every value, and payers don't all report the same situation the same way. But for a typical adjudicated claim, the story looks something like this:
Illustrative example — not a real payer or customer
Five numbers, and each one answers a different question. The $680 is what the deposit reflects. The other four are why it's $680 and not $1,200.
A payment can contain multiple stories
Here are five of the claims inside a $24,380 remittance:
Illustrative example
| Claim | Outcome | Amount |
|---|---|---|
| A | Paid as expected | $1,200 |
| B | Partially paid | $780 |
| C | Denied | $0 |
| D | Paid, with patient responsibility | $640 payer / $160 patient |
| E | Paid below the expected contracted amount | $920 |
The ERA is not one outcome. It is a batch of individual adjudication decisions that happen to share a payment. Claim A is finished. Claims B, C, and E each need a person. Claim D needs the patient's balance updated. Posting the $24,380 total tells you none of that, which is why the payment total alone can't describe revenue performance.
Billed, allowed, paid, adjusted, and patient responsibility are not the same number
Payer methodologies vary, so these are working definitions rather than rules. Not every remittance reports every value in the same way.
| Term | What it generally means |
|---|---|
| Billed | The amount submitted on the claim |
| Allowed | Where applicable, the amount recognized under the payer's adjudication or contract methodology |
| Paid | What the payer paid on the claim or service line |
| Patient responsibility | The portion the payer assigned to the patient, where applicable |
| Adjustment | An amount changed or categorized during adjudication |
Illustrative example
- Billed$1,000
- Payer adjudication
- Allowed$700. The $300 difference from billed is reported as adjustments
- Payer payment$560
- Patient responsibility$140
The important question isn't “was there a payment?” It's “how did the payer get from the billed amount to the final outcome?” Every step between $1,000 and $560 is a decision, and the remittance is where the payer records it.
Adjustment codes are the payer's explanation layer
Remittances use standardized codes to explain adjustments. Group codes say who the adjustment is assigned to; Claim Adjustment Reason Codes (CARCs) say why; and Remittance Advice Remark Codes (RARCs) can add detail. X12 maintains all three lists. The group codes are short enough to show in full:
| Group code | Name on the X12 list |
|---|---|
| CO | Contractual Obligation |
| OA | Other Adjustment |
| PI | Payor Initiated Reduction |
| PR | Patient Responsibility |
CMS describes group codes as assigning financial responsibility for the unpaid portion of a claim: CO assigns it to the provider, PR to the patient. The reason codes are far more numerous and change over time, so rather than a table of them, it's more useful to think in categories:
- contractual adjustment
- patient responsibility
- coverage-related issue
- authorization-related issue
- coding-related issue
- duplicate or administrative issue
- other payer adjudication reason
Don't train staff to memorize a few adjustment codes and assume they mean the same thing in every context. A code should be read alongside the claim, the payer, the service, the contract, and the rest of the remittance. The same reason code can call for a write-off on one claim and an appeal on another.
A denial can live inside an ERA that also contains payment
Illustrative example
Finance sees $41,820 received. Revenue cycle sees seven claims that need work. Both are right, and they're looking at the same file.
A large deposit can hide unresolved claims, especially in a week when cash looks healthy. That's why cash posting and denial work should be connected but not treated as the same workflow. The posting confirms the money; the three denials belong in a denials queue with a reason, an owner, and a deadline, starting the day the ERA posts.
Partial payment deserves its own status
Paid and unpaid are the two statuses most systems start with, and they hide too much. Claim B above is “paid.” So is Claim E. Neither is finished.
More useful operational states can include:
- paid as expected
- partially paid
- denied
- patient responsibility
- pending secondary
- underpayment review
- adjustment review
- other follow-up
These aren't industry-standard statuses, and the payer won't send them. They're categories an organization can use to make remittance work visible, so “paid” stops being the place where follow-up goes to disappear.
Posting the money is only step one
An operational framework
- ERA received
- Match payment
- Match claim
- Post payer payment
- Post adjustments
- Post patient responsibility
- Identify denials
- Identify partial payments
- Identify potential underpayments
- Create follow-up work
The first six steps are the ones an ERA makes fast. Automated posting can match most lines to claims and apply payments and adjustments without anyone keying numbers. The last four are where the revenue is decided, and they need a workflow for exceptions whether posting is automated or not.
Automatic posting is most valuable when exceptions become visible instead of disappearing.
The claim should reconcile to the remittance
Illustrative example — simplified; real contracts are rarely this simple
In the first case, the payer's payment and the patient's share add up to what the contract says. In the second, they come up $90 short. That may be an underpayment. It may be a contract term nobody loaded, a multiple-procedure rule, or a benefit limit. Either way, the variance should create a review, not an automatic appeal and not a quiet write-off.
“Paid” can still be wrong
Illustrative example
If the workflow stops at “paid,” nobody asks another question, and $130 leaves quietly. If the workflow compares each payment with the contract, the same claim reads as paid + variance = review.
A payer doesn't need to deny a claim for revenue to be lost. Sometimes the claim is adjudicated and paid, just not at the amount the organization expected under its contract. That only becomes visible if the expected amount is known before the remittance arrives, which is what contracts and rates stored per payer and service are for.
The ERA is also a source of payer intelligence
One remittance tells you about one batch. A few months of them tell you how each payer behaves. Questions the data can answer:
- Which payers generate the most adjustments?
- Which payers create the most denials?
- Which services are frequently partially paid?
- Which claims take the longest to reconcile?
- Where are patient responsibility amounts increasing?
- Which adjustment reasons keep repeating?
- Where are contract variances appearing?
Illustrative data only — not ProbityCare customer results, not an industry benchmark
| Payer | Paid as expected | Review required | Denied |
|---|---|---|---|
| Payer A | 82% | 11% | 7% |
| Payer B | 71% | 21% | 8% |
Denial rates for the two are close. The difference is the review column: Payer B sends back nearly twice as many claims that need a person, which is labor, cash-flow delay, and a conversation worth having at contract renewal.
Repeated adjustments are not individual claim problems forever
This month, 54 claims came back with the same adjustment pattern. Billing worked all 54 individually. Next month, 61 more.
Is that still a claim-level problem? Or is it now:
- a payer configuration issue
- a contract interpretation issue
- a coding workflow issue
- an authorization workflow issue
- a provider setup issue
- a recurring documentation issue
- a training issue
When the same remittance problem repeats, stop treating it as a surprise.
The fix for a repeating pattern usually lives upstream, often as a claim scrubbing check that stops the claim before it goes out. We walked through turning payer responses into pre-submission checks in Seven claim problems you can catch before the payer sees them.
ERA posting and denial management should share context
Here's a common arrangement. The ERA posts the payment. The denied claim goes onto a separate spreadsheet. Then someone on the billing team looks up, by hand:
- the patient
- the service
- the authorization
- the claim
- the documentation
- the payer
- the reason
- previous follow-up
Eight lookups per denial, across several systems, before any actual work starts. The remittance already knew which claim it was about. It should connect back to it:
The better order
- ERA
- Claim
- Patient
- Authorization
- Documentation
- Denial or adjustment
- Assigned work
When remittance posting lands on the same record as the claim, the denial arrives in the queue with its context already attached. If the reason is an authorization problem, the authorization record is one click away, not a spreadsheet away.
Patient responsibility should not become invisible either
Where the payer assigns part of a claim to the patient, the patient's balance may need to change. Depending on the adjudication, that amount can include:
- deductible
- copay
- coinsurance
- other patient responsibility
Patient responsibility on a remittance is not an instruction to collect. Organizations should follow the payer's adjudication, their contracts, their financial policies, and applicable laws and patient billing requirements. Medicare is a concrete example: CMS notes that beneficiaries may be billed only when group code PR is used with an adjustment. The code on the remittance matters, not just the dollar amount.
An operational framework
- ERA
- Patient responsibility identified
- Patient balance updated
- Statement or collection workflowWhere appropriate
The failure mode here is quiet: the payer assigns $160 to the patient, nobody updates the balance, and the first statement goes out months later, by which point the patient doesn't remember the visit. A patient balance calculated from the remittance, rather than estimated at intake, is the one that's right the first time.
Secondary insurance creates another handoff
When a patient has secondary coverage, the primary payer's remittance is where the secondary workflow begins, not where the claim ends.
An operational framework
- Primary claim
- Primary ERA
- Primary payment and adjustments
- Secondary workflowWhere applicable
Coordination of benefits rules vary by plan and situation, and whether a secondary claim goes out automatically depends on your setup and the payers involved. The operational point is simpler: a claim with secondary coverage isn't resolved when the primary pays. It needs a status that says so, and an owner if the handoff doesn't happen on its own. The coverage on file from eligibility checks is what tells you a secondary exists in the first place.
The bank account and the ERA need to reconcile too
An ERA usually corresponds to a payment: an EFT or a check. Medicare, for example, issues one check or EFT for the claims itemized in an ERA. Back to Thursday morning:
Illustrative example
- Bank / EFT$18,742.31
- ERA$18,742.31
- Claims43
- PostingMatched
- Exceptions4 follow-ups: two partial payments, one denial, one below contract
The payment, the remittance, the claims, the posted amounts, the adjustments, and the exceptions should all be connectable. The money being in the bank doesn't mean the underlying claims are resolved. On Thursday it meant 39 of them were and four weren't.
What should go into a remittance work queue?
Illustrative example — remittance work queue
- Denied
- Partial payment
- Potential underpayment
- Patient responsibility
- Adjustment review
- Secondary follow-up
- Unmatched payment
| Patient | Payer | Outcome | Amount | Owner |
|---|---|---|---|---|
| A. Carter | Payer A | Underpayment review | $125 | J. Smith |
| M. Silva | Payer B | Denied | $840 | RCM team |
| J. Miller | Payer A | Partial payment | $190 | A. Brown |
| R. Jones | Payer C | Patient balance | $75 | Billing |
The goal is to turn remittance exceptions into assigned work. “Unmatched payment” deserves a special mention: money that arrived and can't be tied to a claim is the one exception that looks like good news until month-end close.
Remittance metrics worth watching
No targets here. They depend on payer mix, services, and contracts. Trend these against your own history:
| Metric | What it tells you |
|---|---|
| Total payer payments | Cash, the number everyone already watches |
| Claims adjudicated | Volume the payer has decided on |
| Claims paid as expected | How much volume needs no one's time |
| Partial payments | “Paid” claims that aren't finished |
| Denials | Claims the payer declined, in full or in part |
| Adjustment volume | How much of billed never becomes collectible, and why |
| Patient responsibility | What moved to patients, and whether it's growing |
| Potential contract variances | Payments that differ from what the contract says |
| Unmatched payments | Money that arrived without a claim to land on |
| Days from receipt to posting | How quickly the ERA is read at all |
| Days from exception to resolution | How quickly the hard part gets done |
| Adjustment reasons by payer | Which patterns to fix upstream, and with whom |
A practical ERA review checklist
Payment
- Payment identified
- Remittance identified
- Payment total reconciled where applicable
Claim
- Claim matched
- Service lines reviewed where needed
- Paid amount reviewed
- Adjustment information reviewed
Patient
- Patient responsibility reviewed
- Patient balance workflow updated where appropriate
Exceptions
- Denials identified
- Partial payments identified
- Unusual adjustments identified
- Potential contract variances identified
- Secondary workflow identified where applicable
Follow-up
- Exception assigned
- Owner identified
- Due date set where appropriate
- Claim and payer context available
- Resolution documented
Analysis
- Repeating adjustment patterns reviewed
- Denial trends reviewed
- Payer trends reviewed
- Contract variance trends reviewed
This is an operational review framework and not payer-specific billing guidance.
How ProbityCare approaches remittance posting
ProbityCare connects remittance data to the claim, the patient, the payer, the contract, and the rest of the revenue-cycle workflow, so an ERA posts into the same record the claim came from.
Illustrative example
In practice, that means:
- Remittance posting: the 835 imports from the clearinghouse, and each line is matched to its original claim on claim number, patient, date of service, and amount.
- Payments and adjustments post at the claim level, and patient responsibility is calculated from the remittance.
- Denials and partial payments route into the denials queue with the reason attached.
- Contract comparison: each remittance line is compared against the contracted rate, so a variance shows up when it posts rather than at quarter end.
- Patient balances update from the remittance rather than an intake estimate.
The matching and posting are automatic; the judgment isn't. Exceptions still go to a person, which is the point.
The takeaway
The claim was submitted. The payer made a decision. Money arrived. That is not the end of the revenue cycle.
The remittance tells you what the payer actually did:
- what it paid
- what it changed
- what it moved to the patient
- what it denied
- and what may still deserve another look
If your workflow ends when the deposit hits the bank, you're leaving the most useful part of the payer response unread.
The payment tells you what arrived. The remittance tells you what still needs work.
ERA and 835 questions
What is an ERA in healthcare?
An Electronic Remittance Advice is the payer’s electronic explanation of how it processed a set of claims: what it allowed, paid, adjusted, assigned to the patient, or denied, usually alongside a payment by EFT or check. Because it is structured data, a billing system can read and post it line by line.
What is an 835 file?
The X12 835 is the electronic transaction used to communicate health care claim payment and remittance information. It is the HIPAA-adopted standard for payment and remittance advice, which is why “ERA” and “835” are often used interchangeably.
What is the difference between an ERA and an EOB?
At a high level, an ERA is the structured electronic remittance a payer sends to the provider for billing workflows, while an Explanation of Benefits typically communicates benefit and adjudication information to the member. Formats and terminology vary by payer, and some payers still send paper remittances to providers.
Does an 835 mean a claim was paid?
No. A remittance can contain paid claims, partial payments, adjustments, denials, and other adjudication results, often in the same file. The payment amount alone does not tell you which claims are finished.
What is ERA payment posting?
ERA payment posting is the process of applying payer remittance information to the corresponding claims and balances: matching each line to its claim, posting payments and adjustments, recording patient responsibility, and identifying exceptions such as denials, partial payments, and variances for follow-up.
Can an ERA show patient responsibility?
Yes, depending on the adjudication. A remittance can assign part of a claim to the patient, for example as deductible, copay, or coinsurance. Organizations should still follow payer adjudication, contracts, financial policies, and applicable laws before billing the patient.
Can a paid claim still be underpaid?
Potentially. A payment can differ from the amount an organization expected under its payer contract or reimbursement methodology, and that difference may warrant review. Not every difference is an underpayment: benefits, patient responsibility, and contract terms can all explain it.