Reconciliation for healthcare billing and revenue cycle
Billing reconciles to the PM system, finance reconciles to the bank — and nobody reconciles remit-to-deposit-to-contract at line level. Astridex does.
Claims submitted (837), remittances received (835/ERA and paper EOBs), payer contracts and fee schedules, clearinghouse reports, practice-management or billing-system posting, patient payments, lockbox and bank deposits, and the GL rarely get reconciled against each other at line level. Remits arrive but never get posted; deposits show up with no matching remit and vice versa; allowed amounts come in below contract; takebacks and recoupments get netted inside a remit; denials go unworked. Billing teams reconcile to the PM system, finance reconciles to the bank, and the gap between "payment posting" and "cash reconciliation" is where RCM and finance stop talking to each other. Astridex runs claim-to-remit, remit-to-deposit, and allowed-vs-contract reconciliation at line level, continuously, and surfaces underpayments and unposted remits with payer, reason, and amount.
Where Astridex moves the needle
Bank Reconciliation
Astridex matches bank transactions to your ledger continuously — cash, card, and multi-entity accounts — with a reason attached to every item that does not match.
Explore →Payment & Settlement Reconciliation
Match payment-processor and gateway settlement files to posted payments, fees, refunds, and chargebacks — then tie the net deposit to the bank.
Explore →Revenue & Billing Reconciliation
Astridex reconciles what was billed against what was used or contracted, and what was billed against what hit the GL — surfacing unbilled usage and revenue drift continuously.
Explore →The reconciliation problem in healthcare billing & rcm
Claims submitted (837), remittances received (835/ERA and paper EOBs), payer contracts and fee schedules, clearinghouse reports, practice-management or billing-system posting, patient payments, lockbox and bank deposits, and the GL rarely get reconciled against each other at line level. Remits arrive but never get posted; deposits show up with no matching remit and vice versa; allowed amounts come in below contract; takebacks and recoupments get netted inside a remit; denials go unworked. Billing teams reconcile to the PM system, finance reconciles to the bank, and the gap between "payment posting" and "cash reconciliation" is where RCM and finance stop talking to each other. Astridex runs claim-to-remit, remit-to-deposit, and allowed-vs-contract reconciliation at line level, continuously, and surfaces underpayments and unposted remits with payer, reason, and amount.
The source-to-cash lifecycle
Claim submission
837 claims submitted to the payer, often via a clearinghouse.
Remittance
835/ERA or paper EOB comes back with the payer’s determination.
Posting
The remit is posted to the practice-management or billing system at line level.
Patient responsibility
Patient payments arrive via portal, POS, or statement.
Deposit
Payer and patient payments land in the lockbox and bank.
GL close
Posted revenue and cash are reconciled to the general ledger.
Sources that never agree
Each system reports accurately on its own records — the reconciliation lives in the gap between them.
Claims (837)
Submitted claims — the starting point for claim-to-remit matching. API or file ingestion.
835/ERA & paper EOBs
Payer remittances, at line level. API or file ingestion — 835 parsing is payer-specific and brittle without a dedicated reconciliation layer.
Payer contracts & fee schedules
The allowed-amount basis for underpayment detection. Custom implementation — formats vary by payer.
Clearinghouse reports
Change Healthcare, Availity, Waystar, and similar. API or file ingestion.
Practice-management / billing system
Where remits are posted at line level. API or file ingestion.
Patient payments & lockbox/bank
Portal, POS, and statement payments, and the deposits that follow. Native connector for major processors already in the Astridex integration catalog; lockbox/bank via API or file ingestion.
Reconciliation matrix
| Source · record key | Expected timing | Exception owner | Resolution / impact | |
|---|---|---|---|---|
| Claim-to-remit | 837 claim ID / payer claim number | Per payer remittance cycle | Billing / RCM — Remit received but never posted | Route to posting queue with the remit line attached |
| Remit-to-deposit | Remit / EFT trace number | Per deposit | Finance — cash application — Deposit with no matching remit, or remit with no matching deposit | Match on trace number; escalate unmatched pairs |
| Allowed-vs-contract | Payer / CPT or revenue code | Per remit line | RCM — payer contracting — Allowed amount below the contracted fee schedule | Flag as underpayment for appeal or follow-up |
| Recoupment / takeback | Remit line reference | Per remit | RCM — Takeback netted inside a remit, obscuring the original claim outcome | Unbundle and reconcile against the original claim |
Where the money leaks
- Remits received but never posted to the billing system.
- Deposits with no matching remit, and remits with no matching deposit.
- Allowed amounts below the contracted fee schedule — underpayments that go unappealed.
- Takebacks and recoupments netted inside a remit, obscuring the original claim.
- Denials that are never worked or appealed.
- Credit balances that sit unresolved instead of being refunded or reapplied.
Worked example: an underpayment hidden in a remit
A payer’s 835 remit allows $210 on a line with a contracted fee schedule of $260 — a $50 underpayment that’s easy to miss inside a batch of hundreds of remit lines posted the same day.
Astridex matches the remit line to the original claim and the payer’s contracted fee schedule at the time of service, flags the $50 gap with the payer, claim, and reason code attached, and hands the underpayment to a follow-up or appeal workflow instead of letting it post as accepted.
Outcomes finance teams see with Astridex
Across collections, payables, close, and procurement — measured on real customer workflows.
Sources we reconcile
Native connectors where they exist today; API or file ingestion, or a custom implementation, elsewhere — ask your Astridex contact for the current status on any system not listed.
Integrates with 500+ tools your team already uses — anything with an API.
Healthcare Billing & RCM: frequently asked questions
How is this different from what our PM system already does?
Most practice-management systems reconcile claims to remits within their own record. Astridex adds remit-to-deposit and allowed-vs-contract reconciliation at line level, and connects it to cash in the bank — the gap RCM and finance usually don’t close together.
Does Astridex parse 835/ERA files?
Yes — 835/ERA and paper EOBs are ingested and matched to claims and deposits at line level. 835 formats are payer-specific, which is exactly the brittleness Astridex is built to absorb.
What counts as an underpayment?
An allowed amount below what the payer’s contracted fee schedule specifies for that claim line, at the time of service — flagged for appeal or follow-up, not assumed to be correct just because it posted.
Is this HIPAA-compliant?
See our Trust Center and a BAA is available for healthcare customers — request our security package during procurement.
Does Astridex handle denials?
Astridex surfaces denials that haven’t been worked as part of claim-to-remit reconciliation and can hand them to a follow-up workflow; it does not itself adjudicate appeals.
How quickly can we see underpayments?
Since claim-to-remit and allowed-vs-contract reconciliation run continuously, most teams see their first surfaced underpayments within the first billing cycle after connecting remit and contract data.
See healthcare billing & rcm reconciliation on your data.
Connect your systems read-only and watch Astridex reconcile — with a reason on every exception.
Bring agentic finance to healthcare billing & rcm.
See Astridex on your actual systems and volumes — deployed in days.