One deposit, many claims
A payer rarely settles one claim at a time. A single remittance advice commonly covers a few dozen claims across several patients and several dates of service, and the deposit that follows is one number — the sum of everything the payer decided to pay in that batch, after every adjustment and denial has already been applied.
That single number is not useful on its own. A practice needs to know which of the dozens of claims it actually explains, which were paid in full, which were adjusted, and which were denied — the exact breakdown the remittance itself contains, read line by line rather than trusted as one lump sum that happens to look about right.
Why this is harder than it sounds
Checking that a remittance total matches the deposit is the easy version of this problem, and it only answers one question: do the numbers agree. It says nothing about which claims are behind that number, which is exactly what a practice needs the moment a specific patient calls asking about their balance, or a specific claim needs to be tracked down for an appeal.
The harder, more useful version reads every line — not just the remittance's own summary total — and keeps each claim's outcome individually. That is more work to do by hand, on a document that can run to several pages for a busy payer, which is exactly why it gets skipped in practice and replaced with a quick glance at whether the bottom-line numbers roughly agree.
What gets read per claim line
| Field | Why it matters |
|---|---|
| Claim / patient reference | Links this line back to the specific claim that was billed |
| Billed amount | What was originally claimed, before any adjustment |
| Allowed amount | What the payer's contract permits for this claim |
| Adjustment | The contractual write-off between billed and allowed |
| Patient responsibility | What, if anything, is left for the patient to pay |
| Paid amount | What the payer actually sent for this specific claim |
| Denial / reason code | Why a claim received less than expected, or nothing at all |
Seven fields, read from every line on the remittance rather than only the ones that look important — a denial buried on line thirty of a forty-line remittance is exactly as visible as a full payment on line one.
How a deposit actually gets matched
Once every claim line is read, matching is arithmetic: the sum of the paid amounts across a remittance's claim lines should equal the deposit that remittance explains. Where it does, the deposit is confirmed and every claim inside it is accounted for. Where it does not, the difference is a specific, calculable figure rather than a vague sense that something does not add up.
That arithmetic is what turns a stack of documents into a confirmed match rather than a plausible-looking pair — the same principle behind every reconciliation check on this site, applied here at the level of an individual claim line instead of a whole account.
When a deposit covers only part of a remittance
Occasionally a payer issues a remittance for a batch of claims but settles it in more than one payment — a partial deposit now, the remainder later, for reasons that rarely make it into any documentation the practice sees.
The remittance is still read in full the first time it is seen, regardless of how much of it has actually been paid so far. The unmatched portion — claims the remittance lists but no deposit yet covers — is flagged as outstanding, not dropped or assumed resolved, so it stays visible until a later deposit actually closes the gap.
When one deposit spans several remittances
High-volume payers often do the opposite: several separate remittance batches, sometimes issued days apart, all settle in a single combined payout. The deposit that lands in the bank is the sum of remittances that, on paper, look unrelated to each other.
Grouping remittances that share a payer and a settlement date, then matching their combined total against the one deposit that covers all of them, is exactly the kind of arithmetic that is tedious by hand and mechanical once every remittance has already been read into the same table.
A remittance, matched
A single remittance from one payer, six claims, matched against the deposit it explains.
| Claim | Billed | Paid | Outcome |
|---|---|---|---|
| #4471 | 220.00 | 220.00 | Paid in full |
| #4472 | 340.00 | 255.00 | Contractual adjustment |
| #4473 | 180.00 | 0.00 | Denied — code CO-16 |
| #4474 | 410.00 | 410.00 | Paid in full |
| #4475 | 260.00 | 195.00 | Adjustment + patient balance |
| #4476 | 150.00 | 150.00 | Paid in full |
Paid amounts sum to 1,230.00 — the exact figure the deposit shows, confirming every claim on this remittance is accounted for. One denial, code CO-16, is now a specific claim ready for appeal rather than a number quietly missing from a monthly total.
Building the match
Upload the remittance and the bank statement
Together, for the period the deposit falls in.
Every claim line read
Reference, billed, allowed, adjustment, patient responsibility, paid, and any denial code.
Deposits identified on the statement
The specific line that corresponds to this payer's payout.
Sum checked against the deposit
Confirming the remittance explains the deposit in full, or flagging what is still outstanding.
Exported claim by claim
One row per claim, with its outcome and the deposit it belongs to.
Before and after
Before
A remittance total roughly matches a deposit, so it gets filed without a second look. A denial buried on line thirty stays unnoticed until a patient calls asking why they were billed, weeks after the appeal window closed.
After
Every claim line is read the same week the remittance arrives. The one denial on line thirty is visible immediately, with the appeal window still open.
What it changes
Every claim traceable to its deposit
Not just a matching total, but a specific line linking each claim to the payment that settled it.
Multi-remittance deposits handled
Several remittances settling in one payout are grouped and matched together automatically.
Denials visible the week they happen
Not buried on line thirty of a document nobody reads past the summary.
One export, claim by claim
A clean table ready for a biller, an appeal, or a patient billing question.
Who reaches for this
A practice manager
Wants to know which claims a deposit actually covers, not just whether the totals roughly agree.
A medical biller
Needs denials and adjustments surfaced at the claim level to file appeals before the window closes.
A billing service handling several practices
Matches remittances across multiple clients without a separate template for each payer.
A practice switching billing systems
Reconstructs a claim-level payment history from remittances and statements alone, independent of the old system's records.
ERA files versus PDF remittances
Larger payers increasingly offer electronic remittance advice — a structured data file rather than a printed or PDF document, designed to be read by a machine in the first place. Where a practice or its clearinghouse has access to ERA files, they carry the same claim-level fields a PDF remittance does, just in a format built for parsing rather than for a human to read on a page.
Many practices, especially smaller ones or those working with a payer that has not adopted ERA for a given contract, still receive remittances as PDF or even printed documents. Both are read for exactly the same fields — claim reference, billed, allowed, adjustment, patient responsibility, paid, denial code — so a practice working with a mix of ERA-enabled and PDF-only payers gets one consistent output regardless of which format each specific remittance happened to arrive in.
That consistency matters more than it might seem. A practice transitioning payers onto ERA over time does not need to run two separate reconciliation processes during the changeover — the claim-level table looks the same whether last month's remittance came in as a structured file or a scanned page.
It also removes a decision that otherwise has to be made every time a payer changes how it delivers remittances: whether to invest in parsing the new format specifically, or fall back to a manual read until someone gets around to it. Reading based on what a document means rather than how it is packaged sidesteps that decision — a new delivery format from a payer is simply another document to read, not a new integration to build.
One remittance versus a month of them
Matching a single remittance against its deposit is a five-minute exercise, manageable by hand without much trouble. A practice processing forty or fifty remittances a month across a dozen payers is a different problem entirely, and not simply because there is more of the same work — the nature of what needs attention changes.
At low volume, every remittance gets a look regardless of whether anything is wrong with it. At higher volume, that is no longer realistic, and the useful question shifts from “does this remittance match” to “which of these forty remittances need a look”. The arithmetic check that confirms a remittance's claim lines sum to its deposit answers exactly that question — the remittances that balance need no further attention, and the ones that do not are precisely the ones worth opening.
That shift from checking everything to checking only what fails is what makes claim-level matching practical at real volume rather than a theoretical ideal that only works for a handful of remittances a month.
The same shift changes what a monthly review actually looks like. Instead of a manager or biller re-opening every remittance from the month to confirm nothing was missed, the review becomes a short walk through the remittances that were flagged during the month — usually a handful out of dozens — plus a glance at the payer-level totals to confirm nothing drifted. What used to be a full day of re-checking becomes an hour of confirming what the weekly process already caught.
Volume also changes who benefits most from claim-level detail rather than a summary total. At low volume, a manager can hold the whole picture in their head. Past a few dozen remittances a month, that stops being realistic, and the claim-level table becomes the only reliable memory of what actually happened — not a nice-to-have, but the record everything else gets checked against.
That record is also what makes a staffing change survivable. A new billing coordinator inheriting a claim-level table can pick up exactly where the previous one left off; a new coordinator inheriting only a folder of PDFs and a vague sense of what usually matches has to rebuild that understanding from scratch, often losing weeks of institutional knowledge in the process.
That handover cost is easy to underestimate until it actually happens — and by then, the gap in coverage has already cost the practice whatever claims quietly slipped through during the transition, sometimes without anyone noticing until months later, by which point the appeal window on most of them has already closed for good, turning a temporary staffing gap into a permanent revenue loss that no amount of catching up afterward can actually recover, no matter how thoroughly the backlog eventually gets reviewed.
What this is not
Not a claims-submission tool
It reads remittances after a claim has already been processed by the payer, not before.
Not an appeal or denial-management workflow
It surfaces a denial at the claim level. Filing the appeal remains a human task.
Not a rate or contract validator
It reads the allowed amount the remittance states, not whether that amount matches the payer contract.
Not a replacement for the practice management system
This is the matching layer between remittances and deposits, not the claims pipeline itself.
The first one
Take one remittance and the bank statement covering the period it was paid in, and match them.
Check two things: whether every claim line's paid amount sums to the deposit, and whether any claim shows a denial or adjustment worth a second look. The second is usually the more useful finding on a first attempt.
For the wider routine this fits into, see practice income reconciliation and how to reconcile insurer payments.