Payment Posting Errors
A payment posting error is a mistake the practice makes recording a remittance — not a mistake the payer made deciding the claim — and telling those two apart is the whole thing. A posting error makes the ledger disagree with the remittance advice: the remittance is right, the record of it is wrong, and re-reading the remittance proves it. Because the money is right and only its recording is off, the cash still reconciles and the account still closes to the expected total, so nothing announces the mistake. Finding one means comparing what was posted to what the remittance actually said; fixing one means reversing the entry — not deleting it — and following the error into everything it already touched.
Updated 10 min read
On this page
Key takeaways
- A posting error is the practice's own recording mistake — it makes the ledger disagree with the remittance. A payer error is the opposite: the posting is faithful, but the remittance itself disagrees with the contract.
- Nothing flags a posting error. The cash still reconciles and the account still closes; the money is right and only its recording is wrong, so the arithmetic balances around the mistake.
- The remittance is the source of truth. If the ledger and the remittance disagree, the error is the practice's to fix; if the ledger faithfully records a remittance that is short of contract, the variance is the payer's.
- Correcting one is a reversal, not a retype — and the ledger is the easy part. The real work is the wrong statement already sent, the secondary filed on wrong detail, and the denied line a dropped posting hid.
A posting error is yours, not the payer's
Posting is transcription: read what the payer decided about a claim, and record it against that claim. A payment posting error is a defect introduced in that recording — the remittance said one thing and the ledger now says another. It is categorically different from the payer getting the decision wrong, and keeping the two separate is what makes either one fixable, because they are owned by different people and corrected in different places.
The difference is a question of which document is the authority. A posting error makes the ledger disagree with the remittance: the remittance is correct, the record of it is not, and the proof is sitting in the remittance itself — re-read it and the mistake is plain. A payer error runs the other way. When a payer allows below the contracted rate, the posting can be perfectly faithful to the remittance and still be wrong, because the remittance advice itself is short of what the contract required. There the ledger and the remittance agree; it is the contractual adjustment against the contract that does not, and only the contract reveals it. That is an underpayment, not a posting error.
One question tells you whose it is
The ways a posting goes wrong
The mistakes are not exotic. They fall into a few recurring kinds, grouped by which part of the record each one corrupts — and every one of them leaves the cash whole, which is exactly why they survive.
| Error | What happens | What it corrupts |
|---|---|---|
| Wrong destination | The payment or adjustment is applied to the wrong claim, the wrong patient, or the wrong date of service — or an unmatched payment is forced onto a claim it does not fit rather than held. | Two accounts at once: the one it landed on and the one it should have. A forced, unmatched payment is how a deposit becomes unapplied cash posted to the wrong home. |
| Wrong amount | A figure is mis-keyed during manual posting, or a line's paid, allowed, and adjustment values are transposed among themselves. | The balance, and every metric computed from it — the mistake reads as a routine variance, not as a typo. |
| Wrong category | An adjustment is recorded under the wrong group code, so an amount the contract required be written off is instead billed to the patient — or a collectible balance is quietly written off. | Who bears the amount. This is the contractual adjustment vs. write-off line drawn wrong at posting. |
| Dropped line | A line inside a largely-paid claim — a partial denial, a reduced line — is not posted at all, because the claim overall looks paid. | The denial that never entered a work queue, and cannot be worked because nothing recorded it. |
| Duplicate | The same remittance is posted twice — by hand, or by an automated feed that received it twice. | The account, which now shows a credit balance built from money that was only received once. |
Read down the last column: not one of these is a discrepancy in the cash. Each leaves the total received intact and the account looking settled, which is why none of them trips an alarm. Posting a lump sum instead of line by line belongs on this list too — it is an error of omission, recording the cash and discarding the detail — and How Payment Posting Works covers why the line level is the difference between data and a number.
Why a posting error hides
A posting error does not produce an error. The money is right; only its recording is wrong — so the cash reconciles, and the account still closes to the total the remittance said it should. A compliant remittance has to balance: for every claim, the billed charge equals the payment plus all the adjustments, checked at the line, the claim, and the provider level. A mis-post does not break that balance. It just balances it around the wrong entry — the numbers still add up, they add up to the wrong story.
So detection is never a matter of watching for errors; it is a set of standing controls, each of which catches a different class and misses the others. Payment reconciliation proves the cash against the bank, which catches a whole remittance that was never posted — but it cannot see a mis-key inside a remittance that did post, because the cash still balances. Validating Contractual Adjustments and the zero-balance review compare amounts against the contract — but those catch payer errors too, so when one surfaces the first question comes back around: is this a payer shortfall, or my own mis-post? Re-reading the remittance settles it. Posting line by line and recording the right group code are not detectors at all; they are how the wrong-category and dropped-line errors are prevented from happening in the first place.
The detection of last resort is the patient
Correcting one is a reversal, not a retype
The instinct on finding a posting error is to open the account and fix the number. Do not delete the wrong entry. Reverse it — post an offsetting entry that backs it out — and then post the correct one, so the record shows a correction was made rather than pretending the mistake never happened. A deleted entry destroys the trail that explains why the account moved; a reversal keeps it, which is what makes the correction auditable and the account explainable later.
That reversal is the easy part, and it is not where the work is. A posting error never stays a posting error — the moment it was recorded, it began changing shape downstream, and each of those shapes has to be chased:
- A wrong patient responsibility figure already went out as a statement. Correcting the ledger does not recall the envelope: the statement has to be corrected and re-sent, and if the patient paid on it, the over-collection has to be refunded or reapplied. Billing a patient for money they do not owe is a compliance matter, not a service one.
- A secondary claim may have been filed carrying the wrong primary detail — or never filed, because the detail it needed was dropped. Either way the secondary has to be reworked from the corrected posting.
- A denied line that a dropped posting hid never entered a work queue, and the clock on it has been running the whole time. It may now sit closer to a filing or appeal limit — one that varies by payer and contract — than the calendar suggests.
- A duplicate post created a credit balance from money received once. It is cured by correcting the posting, not by cutting a refund — paying real cash against a paper credit turns a posting error into a genuine loss. Confirming a credit is real before refunding it is Credit Balance Refund's subject.
The ledger fix is a minute; the cleanup is the job
Keep the remittance, and compare to it
Because a posting error is provable against the remittance and invisible without it, the discipline is simple to state: keep the remittance, and treat it as the answer key. A balanced cash total is not evidence the posting was right — it is only evidence the money was right, and those are different claims. The check that finds a posting error is the ledger against the remittance, never the ledger against itself, because a ledger that balances internally will happily balance around a mistake.
Prevention is structural rather than a matter of care. Automate posting where the remittance is structured, so there are fewer keystrokes to fumble; post line by line, so a dropped or mis-categorized line has a place it can be caught; and route what does not match to a queue rather than forcing it onto a claim. Automation removes transcription error but reproduces a configuration error at volume — the same mistake, made perfectly, on every matching line — so what a rule set posts still has to be sampled, which is why Auto-Posting Rules treats the rules themselves as the thing to govern. Everything else in Payments & Posting assumes a payment was recorded correctly. The goal here is not zero errors; it is that every error has a control positioned to catch it before it leaves the practice as a bill, a secondary, or a number in a board report.
Common questions
How do I tell a posting error from an underpayment?
Re-read the remittance. A posting error makes your ledger disagree with the remittance — the remittance is right and your record of it is wrong. An underpayment is the opposite: your posting faithfully records the remittance, but the remittance itself paid less than the contract requires. If the ledger and the remittance match, it is not a posting error; it is a payer variance, and the contract — not the remittance — is where you prove it. That one comparison decides who owns the fix.
The cash reconciled. Doesn't that mean posting was right?
It means the money was right, which is a different thing. Reconciliation proves the total received matches the total deposited; a posting error can move an amount to the wrong claim, record it under the wrong category, or apply it to the wrong patient and leave that total untouched. The cash balancing is precisely why a posting error survives — every check that looks only at money passes it.
We posted the same remittance twice. What do we do?
The duplicate created a credit balance out of money that was received only once, so it is corrected by reversing the duplicate posting — not by refunding the credit. Cutting a real refund against a paper credit turns a posting error into an actual loss. Reverse the duplicate entry rather than deleting it, so the account shows what happened, and confirm any remaining credit is genuine before it is refunded, which Credit Balance Refund covers.
We billed a patient for something that should have been written off. Is fixing the ledger enough?
No. Correcting the group code on the account is the small part. The wrong statement already went out, so it has to be corrected and re-sent, and any amount the patient actually paid against it has to be refunded or reapplied. Billing a patient for money they do not owe is a compliance problem, not a customer-service one, so the downstream cleanup is not optional — it is the part that actually resolves the error.
Key terms in this article
Defined once, on their own pages.
Continue learning
Where to go next.
How Payment Posting Works
The mechanics a posting error corrupts — and why a mistake here never stays here.
Underpayments and Overpayments
The payer's error, not the practice's — the other side of the ledger-versus-remittance line.
Auto-Posting Rules
Automation removes the typo and scales the configuration error — so the rules become the thing to check.
Net collection rate calculator
The metric computed from posted data, measured against what was actually collectible.
Authoritative sources
- CMS — Medicare Claims Processing Manual, Pub. 100-04, Chapter 22 (opens in a new tab)
Specifies that the remittance must balance — the billed charge equals the payment plus all adjustments — and that a claim-adjustment group code names the category of an amount, not whether the amount is correct.
- Centers for Medicare & Medicaid Services (CMS) (opens in a new tab)
Publishes the electronic funds transfer and remittance-advice guidance for providers, including that a reassociated ERA enables a provider to auto-post payments to accounts receivable.
- X12 — EDI standards (opens in a new tab)
Maintains the ASC X12 835 remittance transaction — the HIPAA-adopted standard a posting reads and can be checked against.