Home/Technology/835 Reconciliation
Line-level 835 match · 98% auto-post · variance surfaced

Line-level 835 match, 98% auto-post.

Header-level posting hides the money. Partial payments, takebacks on unrelated lines, and bundling adjustments all look fine when you reconcile at the claim header. They show up at the CPT plus modifier plus rev code level, which is where this engine reconciles. 98 percent auto-post; the 2 percent we cannot auto-post route to the exception queue with the full context attached.

CPT + modifier + rev code level match Contractual variance vs fee schedule Cross-period takeback tracking
The line-level match

Submitted lines, vs paid lines.

An anonymized sample. A four-line claim for a behavioral health practice. The 837 went out with four service lines. The 835 came back with payment data per line. The engine matches each submitted line to its paid counterpart at CPT plus modifier plus rev code level, reconciles the charge, allowed, paid, and adjustment amounts, and checks contractual variance against the fee schedule.

Line 1 matches cleanly. Line 2 carries a contractual variance outside tolerance. Line 3 was paid but not at the expected rate (partial payment). Line 4 was submitted but missing from the 835 entirely. The engine surfaces all of it. The recovery queue ranks by dollar value.

Header-level reconciliation would have logged this claim as paid $128.40 against $530 charged and moved on. Line-level reconciliation logs $83.60 in recoverable gaps that a specialist can act on: a variance dispute for line 2, a short-pay inquiry for line 3, and a resubmission for line 4. None of those three actions happen if the posting engine stops at the claim header. Multiply across a year of ERAs and the difference between header-level and line-level posting becomes a measurable share of total revenue.

837 line vs 835 line · CPT + mod + rev match
837 LINE 1 · 97153 HM
$120.00 charge
Expected allowed $48.00
835 LINE 1 · MATCHED
$48.00 paid
CO-45 contractual $72.00
837 LINE 2 · 97155 HO
$180.00 charge
Expected allowed $72.00
835 LINE 2 · VARIANCE
$58.00 paid
Variance $14.00 over tolerance
837 LINE 3 · H0046
$95.00 charge
Expected allowed $38.00
835 LINE 3 · PARTIAL
$22.40 paid
No reason code for short pay
837 LINE 4 · 90837
$135.00 charge
Expected allowed $54.00
835 LINE 4 · MISSING
Not adjudicated
Routed to recovery queue
Header would show $128.40 paid · line-level shows $83.60 in recoverable gaps
The capabilities

Six capabilities. Line-level honest.

Every 835 ERA runs through the same engine. Line-level matching, contractual variance, partial payment, takeback tracking, bundling detection, payer-specific posting rules, exception queue. No header-level shortcuts that hide the recoverable dollars.

01 · Line-level 835/837 match

CPT + mod + rev level.

Every paid line on the 835 matches to its submitted line on the 837 at CPT plus modifier plus rev code level. Header-level matching hides partial payments, takebacks on unrelated lines, and bundling adjustments. Line-level matching surfaces all of it.

02 · Partial payment detection

Short pays, no reason code.

When a line gets paid at less than the expected allowed amount with no adjustment reason code that explains the gap, the engine identifies the short pay and routes the dollar gap to the recovery queue. Distinct from a contractual write-off; this is recoverable revenue.

03 · Contractual variance

Allowed vs fee schedule.

For every paid line, compare the payer allowed amount against the expected contractual amount in the fee schedule library. Variance outside tolerance (typically 2 percent) surfaces with expected vs actual delta and payer-specific contract reference. Underpayments accumulate in a dollar-ranked recovery queue.

04 · Takeback tracking

Cross-period recoupment trail.

Track takebacks across the full payer-provider ledger. A March recoupment against an October claim ties back to the original payment trail. The engine flags high-frequency takeback patterns on specific payer-provider combinations and routes them with the original payment context attached.

05 · Bundling detection

NCCI edits, payer rules.

Bundling and unbundling detection by comparing submitted CPT code combinations against paid code combinations. Cross-references NCCI edit pairs and payer-specific bundling rules. Mismatches route to a senior coder for review before posting; compliance and reimbursement issues both caught.

06 · Payer posting rules

Non-standard codes encoded.

Some payers use non-standard adjustment reason codes. Some require manual contractual write-off entries. Some have specific patient responsibility allocation rules. The payer-specific posting rules library encodes these exceptions and applies them before the auto-post decision. Refreshed when payer policies change.

How an ERA runs

Four steps. Inbound to posted.

From the moment the 835 ERA arrives from the clearinghouse or direct payer EDI feed, here is the work the engine executes before the dollar amounts land in the patient ledger.

Step 01

Parse the 835.

X12 835 parser extracts the claim payment information at header and line level. Handles all four standard 835 versions plus the payer-specific extensions. Schema validation flags malformed segments before posting.

Step 02

Match to the 837.

Line-level match against the originating 837. CPT plus modifier plus rev code. Charge, allowed, paid, adjustment amounts reconciled. Variance check against fee schedule. Bundling check against NCCI and payer rules.

Step 03

Apply posting rules.

Payer-specific posting rules library applies non-standard adjustment codes, manual write-off entries, and patient responsibility allocation. Auto-post decision: clean cases go to the patient ledger, ambiguous cases route to the exception queue.

Step 04

Route the exceptions.

Exception queue carries the full context: line-level match output, variance calculation, expected vs actual, recoupment history. Specialist reviews and posts. Recovery queue ranks underpayments by dollar value for follow-up.

What the engine delivers

Measured outcomes from line-level posting.

Across the active book. Anonymized; individual results depend on payer mix and contract complexity.

98%
Auto-post rate, no human touch
98 percent of ERAs post to the patient ledger automatically. The 2 percent that route to the exception queue carry the full reconciliation context so a specialist resolves the case in minutes, not hours. Industry norm sits around 84 percent auto-post.
1.4%
Recoverable underpayments surfaced
Of total billed dollars, 1.4 percent on average sits in contractual variance and partial payment gaps that line-level reconciliation surfaces. Header-level posting misses this entirely. The recovery queue ranks by dollar value for actionable follow-up.
100%
Takebacks tied to source payment
Every recoupment, no matter how far back the source payment, ties to the original 835 line. Cross-period takeback patterns are visible per payer-provider. Suspicious recoupment frequency flags for review before the dollars move out of the ledger.
Common questions

Frequently asked questions: 835 reconciliation.

What does line-level 835 to 837 matching actually do?
It matches every service line on the inbound 835 ERA to the corresponding line on the original 837 claim, not just the claim header. Header-level matching is the common shortcut and it hides partial payments, takebacks against unrelated lines, and bundling adjustments. Line-level matching surfaces all of it. The engine reconciles charge, allowed, paid, adjusted, patient responsibility, and contractual variance at the CPT plus modifier plus rev code level.
What is the 98% auto-post rate?
98 percent of ERAs we ingest post to the patient ledger automatically with no human intervention. The remaining 2 percent route to the exception queue for a specialist to review. Exceptions split across recognizable categories: cross-period takebacks, payer reissue against a different claim ID, manual posting required per the payer rule library, and ambiguous adjustment reason codes. The 2 percent is honest measurement; we do not auto-post the cases the engine is not confident about.
How does contractual variance surfacing work?
For every paid line we compare the payer allowed amount against the expected contractual amount stored in the fee schedule library. Any variance outside a configurable tolerance (typically 2 percent) surfaces with the expected vs actual delta, the affected service code, and the payer-specific contract reference. Underpayments accumulate into a recovery work queue ranked by dollar value. Overpayments flag for review against the contract before posting to avoid downstream takeback surprises.
What is partial payment detection?
A partial payment is when the payer pays some but not all of a multi-line claim, or when a single line is paid at less than the expected allowed amount with no adjustment reason code that explains the gap. The engine identifies these in two ways. First, the line-level match reveals lines that were submitted but not adjudicated. Second, the contractual variance check catches dollar gaps that fall outside tolerance. Both route to the recovery queue with the missing-pay calculation visible.
How are takebacks tracked?
A takeback is when the payer recoups previously-paid dollars in a later ERA, typically against a different claim. We track takebacks across the full payer-provider ledger so a recoupment in March against an October claim is tied back to the original payment trail. The engine flags suspicious takeback patterns (high-frequency takebacks on a specific payer-provider combination) and surfaces the recoupment notes to the work queue with the original payment context attached.
What about bundling and unbundling detection?
Bundling happens when the payer pays a single code instead of the multiple codes submitted on the claim. Unbundling is the reverse. Both are common compliance and reimbursement issues. The engine detects them by comparing the submitted CPT code combination against the paid code combination, flagging mismatches against NCCI edit pairs and payer-specific bundling rules. The exception routes to a senior coder for review before posting.
How do payer-specific posting rules work?
Some payers use non-standard adjustment reason codes. Some require manual contractual write-off entries. Some have specific patient responsibility allocation rules that the standard 835 parser does not handle. The payer-specific posting rules library encodes these per-payer exceptions and applies them before the auto-post decision. The library is refreshed when payer policies change and is the same one our certified posting specialists work from.
How does this connect to CredPro, the AR workflow, and root cause analytics?
All three. CredPro tracks the contracted fee schedule per payer per provider, which feeds the contractual variance check. The AR workflow tool consumes the exception queue and the recovery queue directly so a specialist sees underpayments and missing payments in the same view as denial work. The root cause analytics module aggregates contractual variance patterns by payer and CPT to identify systemic underpayment trends. See the credentialing page for how the fee schedule library is maintained.

Send 30 days of ERAs. We send back the recovery map.

A free 30-day ERA reconciliation audit. Drop your last 30 days of 835 files and the matching 837 export. We return a four-page audit covering line-level match coverage, contractual variance dollars, partial payment recoverables, takeback patterns, and a 90-day fix plan. A senior partner on the call.