Patient Responsibility Estimation: Computing the Number Before the 835 Arrives
Every practice that collects at the front desk is running an estimator, whether or not anyone calls it that. \"Copay's twenty dollars.\" \"You've got a high deductible, so let's take a hundred.\" \"We'll bill you.\" Those are
Every practice that collects at the front desk is running an estimator, whether or not anyone calls it that. "Copay's twenty dollars." "You've got a high deductible, so let's take a hundred." "We'll bill you." Those are estimates with an undocumented model and no error measurement.
The reason this matters isn't customer service. It's that an estimate you collect against is a financial position you have to unwind if it's wrong. Over-collect and you owe a refund, a posting entry, and a credibility repair. Under-collect and you've converted a point-of-service payment into a receivable that ages.
The estimate itself is arithmetic. Three inputs, a defined order of operations, and a variance you can measure against the 835 that arrives two weeks later. This article walks one encounter through that arithmetic, checks it against the actual remittance, and shows where the gap comes from.
What you're actually computing
Patient responsibility before adjudication is a function of three inputs. Most bad estimates are missing one of them entirely.
1. The contracted allowed amount — not the billed charge. Your charge master is irrelevant to what the patient owes. The patient's share is computed off the payer's allowed amount for that CPT code, at that place of service, under your specific contract. This is the input people skip, because it's the one the payer doesn't hand you: the eligibility response won't contain your negotiated rate. You supply it from your own fee schedule, keyed by payer, plan, code, modifier, and place of service.
2. The benefit state at this moment. Pulled via an X12 270 eligibility inquiry, returned as a 271. The segments you care about are in the EB loop:
EB*C*IND*30**HEALTH PLAN*23*1500.00~
EB*C*IND*30**HEALTH PLAN*29*86.00~
EB*A*IND*98*****.2~
EB*B*IND*98****0.00~Read in order: EB*C is a deductible (EB01=C), individual (IND), $1,500 for the calendar year (EB06=23), with $86.00 remaining (EB06=29). EB*A is coinsurance at 20% (EB08=.2) for professional office visits (EB03=98). EB*B is a copay of $0.00 for that service type. Loop structure, service-type coverage, and which qualifiers a given payer actually populates vary considerably — validate against your clearinghouse's companion guide before you trust a field [verify].
3. The plan's order of operations. Copay first (if one applies), then deductible until satisfied, then coinsurance on what remains, all bounded by the out-of-pocket maximum. Plans deviate — some waive the deductible for office visits, some apply copay instead of coinsurance, some carry embedded family deductibles that behave differently from the individual number in the 271.
Worked example: estimate one encounter, then check it against the 835
An established patient, three lines. All values below are synthetic — no identifiers, no patient data.
| Code | Billed charge | Your contracted allowed |
|---|---|---|
| 99213 — office visit, level 3 | $185.00 | $96.40 |
| 93000 — ECG, 12-lead | $95.00 | $21.60 |
| 80053 — comprehensive metabolic panel | $68.00 | $14.30 |
| Total | $348.00 | $132.30 |
Apply the 271 benefit state ($86.00 deductible remaining, 20% coinsurance, $0 copay):
Allowed total 132.30
Deductible applied min(86.00, 132.30) = 86.00
Remaining allowed 132.30 − 86.00 = 46.30
Coinsurance 46.30 × 0.20 = 9.26
Plan liability 46.30 − 9.26 = 37.04
Estimated patient responsibility 86.00 + 9.26 = 95.26
Check: 86.00 + 9.26 + 37.04 = 132.30 ✓$95.26. Note what the two common shortcuts would have produced: billed charges give $348.00, and "20% of charges" gives $69.60. One is 3.7× the real number, the other is under it — and neither is defensible to the patient, because neither is derived from anything.
Two weeks later the 835 posts:
CLP*PCN-4417*1*348.00*64.24*68.06*12*ICN-2026-0803-1190*11~
SVC*HC:99213*185.00*35.52**1~
CAS*CO*45*88.60~
CAS*PR*1*52.00~
CAS*PR*2*8.88~
SVC*HC:93000*95.00*17.28**1~
CAS*CO*45*73.40~
CAS*PR*2*4.32~
SVC*HC:80053*68.00*11.44**1~
CAS*CO*45*53.70~
CAS*PR*2*2.86~Line balancing holds — SVC02 = SVC03 + sum of that line's CAS amounts:
- 99213 —
185.00 = 35.52 + 88.60 (CO-45) + 52.00 (PR-1) + 8.88 (PR-2)✓ - 93000 —
95.00 = 17.28 + 73.40 (CO-45) + 4.32 (PR-2)✓ - 80053 —
68.00 = 11.44 + 53.70 (CO-45) + 2.86 (PR-2)✓
And at the claim level: CLP03 − CLP04 = 348.00 − 64.24 = 283.76, which equals all CAS amounts summed (215.70 contractual + 68.06 patient). CLP05 = 68.06 — the PR-group total.
Actual patient responsibility: $68.06. Estimated: $95.26. Variance: $27.20 over.
The contracted rates were correct — every CO-45 matches the fee schedule exactly (185.00 − 96.40 = 88.60, and so on). The coinsurance percentage was correct. The error is entirely in PR-1: the payer applied $52.00 of deductible, not $86.00, because another provider's claim adjudicated in the gap between your eligibility check and this claim's adjudication, consuming $34.00 of the patient's remaining deductible first.
If you collected the full $95.26 at check-in, you now owe this patient $27.20.
Why estimates miss, and which misses cost you
The variance decomposes into a short list, and they don't carry equal risk:
- Stale benefit snapshot. The
271is a point-in-time read. Claims in flight at other providers aren't reflected, and deductible is allocated in adjudication order, not encounter order. This is the dominant, irreducible error source for deductible-phase patients — and it is directionally biased toward over-collection, which is the expensive direction. - Wrong fee schedule row. Modifier, place of service, site-of-service differential, multiple-procedure reduction. Silent and systematic: it produces the same error on every encounter until someone audits it.
- Coding drift. You estimate on the scheduled code and bill the documented one. A visit scheduled as 99213 and coded 99214 invalidates the estimate at the moment the note is signed.
- Bundling edits. An
NCCIedit produces aCO-97on a line you priced as separately payable. The patient's share drops; your estimate doesn't. - Benefit-category surprises. Preventive that converts to diagnostic mid-encounter is the classic case — same CPT, entirely different cost share.
- Undetected secondary coverage. COB changes the answer completely and often isn't visible in a single-payer
271.
How the common approaches compare on these:
| No estimate | % of billed charges | Payer portal, checked manually | 270/271 + your fee schedule | |
|---|---|---|---|---|
| Inputs used | None | Charge master only | Benefit state, transcribed by staff | Benefit state + contracted allowed + plan rules |
| Error direction | n/a | Overstates — charges exceed allowed | Depends what staff reads and copies | Bounded, mostly deductible staleness |
| Staff time per encounter | 0 | ~0 | Minutes, per payer, per patient | Seconds, automated |
| Refund exposure if collected | None | High | Moderate | Low, if collection is capped at the estimate |
| Covers the full schedule | n/a | Yes | No — doesn't scale past a handful daily | Yes |
| Auditable afterward | n/a | No | Only if the response is stored | Yes — retain the 271 and fee-schedule version |
| Reconciles to the 835 | Never | No | Not systematically | Yes — variance is a computed field |
The last row is the one that compounds. An estimator you can't reconcile never improves, because you never learn which of the six error sources is actually costing you.
Collecting against an estimate without creating a refund problem
The estimate's accuracy determines your collection policy, not just your talking points.
Cap the ask at the estimate, never above it. Rounding up "to be safe" is how a practice accumulates credit balances. Unclaimed patient credits are subject to state escheatment law, and retention rules vary by jurisdiction [verify for your state].
Scale the ask to the confidence. A patient with a satisfied deductible and a flat copay is a near-deterministic estimate — collect it in full. A patient in early-year deductible phase is your highest-variance case, and it's biased toward over-collection. Collecting the coinsurance portion at check-in and requesting the deductible portion after adjudication is a defensible split.
Put the arithmetic in writing. Allowed amount, deductible applied, coinsurance rate, resulting share — the same four lines from the worked example. Label it an estimate, state that the payer's adjudication governs, and note that you refund overages. Patients dispute numbers they can't derive; they rarely dispute arithmetic they can follow.
Close the loop on a fixed clock. When the 835 posts, compare your estimate to the PR-group sum per encounter. Over-collected → refund on a defined SLA, not when someone notices. Under-collected → request the delta immediately, while the encounter is still recent; a request-for-payment sent the day the 835 posts lands in the patient's banking app with the itemization attached, and carries no card credential or NSF exposure.
Self-pay is a separate regime. Uninsured and self-pay patients are covered by Good Faith Estimate requirements under the No Surprises Act, with their own content, timing, and dispute-process rules. Requirements applicable to insured patients — the Advanced EOB — have followed a different implementation path; confirm current federal and state obligations with counsel before setting policy [verify].
Then measure the estimator itself. Store the 271 response, the fee-schedule version, and the computed estimate alongside the encounter. When the 835 arrives, write the variance as a field. Sort by absolute variance monthly. A systematic error — one payer, one code, one place of service — is a fee-schedule bug you can fix once. Scattered small variances concentrated in PR-1 are deductible staleness, which you manage with policy, not code.
FAQ
Can I just use the payer's own estimate instead of building this?
Where a payer offers a real-time estimation API, use it — and reconcile it against the 835 exactly as you would your own. The practical limits are coverage and consistency: not every payer offers one, formats and available fields differ, and the estimate is still computed from a benefit snapshot with the same staleness problem. You also need your contracted rate in the loop regardless, since that's what every downstream variance check is measured against. Treat a payer estimate as one more input, not as the elimination of the reconciliation step.
What variance tolerance should I set before calling an estimate wrong?
Set it in dollars and percent together, and measure it before you set it. Run 60 recent encounters with an estimate and a matching 835, compute the variance distribution, then draw the threshold where the tail starts. What matters more than the threshold is decomposing by cause — a $30 miss from deductible staleness is expected behavior, while a $30 miss from a wrong fee-schedule row is a defect recurring on every encounter with that code. Any published benchmark accuracy figure won't reflect your payer mix or plan-design distribution [verify against your own data].
Does the eligibility check tell me what I've contracted for?
No, and this is the most common architectural mistake. The 271 returns the patient's benefit structure — deductible, coinsurance, copay, out-of-pocket status. It does not return your negotiated rate. If your estimator computes 20% of billed charges because that's all the 271 supports, it will overstate patient responsibility on essentially every commercial claim, since the allowed amount is materially below the charge. The contracted allowed amount comes from your own fee-schedule table, maintained per payer and per contract year.
Try it against your own data
The shteg.ai sandbox takes a de-identified 271, a fee-schedule row, and — optionally — the matching 835, and returns the full chain: computed estimate with the deductible/coinsurance arithmetic shown, actual patient responsibility parsed from the PR-group CAS amounts, and the variance decomposed by cause (benefit staleness vs. fee-schedule mismatch vs. coding drift vs. bundling edit). Same balancing checks as above, run automatically at both service-line and claim level.
Bring one encounter where the front desk collected a deposit and the 835 has since posted. The gap between those two numbers is usually the entire business case.
Open the shteg.ai sandbox → [verify link target before publish]
Educational content for physicians, practice administrators, and revenue-cycle staff. Not legal, billing, coding, or compliance advice. All segment values, claim identifiers, fee-schedule amounts, and dollar figures in this article are synthetic illustrations and contain no patient data. X12 transaction specifications, payer companion-guide requirements, and payment network capabilities change — verify current specifications with your clearinghouse and financial institution before making operational decisions. Patient financial estimation, collection, credit-balance handling, and Good Faith Estimate obligations are governed by your payer contracts and by applicable state and federal law; consult counsel for your jurisdiction.
Draft notes: ~1,680 words. H1 + 6 H2s (4 body + FAQ + CTA). Worked example carries both required forms — the estimation arithmetic and SVC02 = SVC03 + CAS balancing on all three lines, with claim-level tie-out (CLP03 − CLP04 = 283.76 = sum of all CAS; CLP05 = 68.06 = PR total). Estimate-vs-actual variance of $27.20 traces to a single cause (deductible consumed by a competing claim), so the "why estimates miss" section is grounded rather than abstract. Five [verify] flags: 271 EB loop/qualifier variation by payer, state escheatment rules, AEOB implementation status, benchmark accuracy figures, and the sandbox link. No statistics asserted. Angle diverges from patient-payments-1 (post-835 correct billable amount) by owning the pre-service side and treating the 835 as the scoring mechanism — the two link naturally without duplicate SVC/CAS explainer content.
Want me to save this to examples/seo-presence/workspace/drafts/patient-payments-3-<id>.md to match the pipeline convention? I'd need an ID in the workspace's format (the others use a short base-36 timestamp slug like msr720tp) — say the word and I'll write it.
<!-- generated_by: claude-draft-1 -->