How Payment Posting Works
Payment posting is recording what a payer decided against the claims it decided about. It is the least glamorous step in the revenue cycle and one of the most consequential, because everything downstream reads what posting wrote — and none of it goes back to check.
Updated 6 min read
On this page
Key takeaways
- Money arriving is not posting. Funds land by EFT; until the remittance is posted, no claim is credited, no balance is right, and no denial is visible to anyone.
- Posting at the line level produces data. Posting a lump sum produces a number that reconciles and explains nothing.
- The group code decides who bears an amount. Recording it wrong bills a patient for money they do not owe.
- Posting is where exceptions become visible — denials, recoupments, credit balances. A posting process that records amounts without routing exceptions closes the balance and loses the work.
What posting quietly decides
It is worth being precise about how much rests on this step, because nothing about the task advertises it. Posting is transcription: read what the payer said, record it against the claim. And then every other part of the back end treats what was recorded as fact.
- What the patient is billed
- A statement bills whatever posting recorded as patient responsibility. Nothing between posting and the envelope re-checks that figure against the remittance.
- Which denials get worked
- A denial that posting does not surface does not exist as far as the practice is concerned. It is not in a queue, because posting is what would have put it there.
- What every metric says
- The net collection rate, days in A/R, the denial mix — all of it is computed from posted data. A posting error does not show up as an error; it shows up as a metric that is confidently wrong.
- Whether the secondary can be billed
- A secondary claim has to carry what the primary did. If that detail was not posted, it is not there to send.
A posting error never stays a posting error
The money arriving is not the payment being posted
These feel like the same event and are not. The funds arrive by EFT — a deposit in the bank account, carrying no information about which claims it covers. The explanation arrives separately as the remittance advice. Two things, two routes, two schedules.
Until the remittance is posted, the deposit has changed nothing except the bank balance. Every claim it paid still shows as outstanding. They will age, they may be followed up, and in the worst case they are refiled or written off — while the payment for them is already sitting in the account.
This is why posting has a backlog problem specifically
Line level, or nothing
There are two ways to post a payment, and the difference between them is the difference between having data and having a number.
| Dimension | Line-level posting | Lump-sum posting |
|---|---|---|
| What gets recorded | Per line: the allowed amount, the plan's payment, the adjustment and its group code, the patient's share. | One figure against the claim. The cash is right, and nothing else was captured. |
| Does the cash reconcile? | Yes. | Yes — which is exactly why this survives unnoticed. |
| Can you bill the secondary? | Yes. The primary's detail is there to send with the secondary claim. | Not without going back to the remittance and reconstructing it. |
| Can you see a denied line? | Yes. A claim can be paid on four lines and denied on the fifth, and that fifth line is visible. | No. A partial denial inside a largely-paid claim disappears into the total. |
| Can you find an underpayment? | Possibly — you have the allowed amount to compare against the contract. | No. There is no allowed amount recorded to compare with anything. |
| What the reporting shows | A denial mix, an adjustment breakdown, variance against contract. | That the claim is closed. |
The trap is the second row. Lump-sum posting is not sloppy in the way that gets caught — the money balances perfectly, and every check that looks at cash passes. What it destroys is the detail, and nothing checks for detail.
What automation does and does not solve
An ERA can be posted automatically, and where it can be, it should be. Software matching a structured remittance to structured claims is faster and more consistent than a person doing it by hand, and manual posting introduces exactly the transcription errors this article is about.
But automation changes where the work is, not whether it exists. Auto-posting handles what is unambiguous; what it cannot resolve goes to a person, and that exception queue is now where the difficulty lives — concentrated, rather than spread across every remittance. The queue is the job.
Automation can also post a mistake perfectly
The ordered steps of the whole process — matching, posting, applying the group code, routing exceptions, and proving the cash — are set out in The Payment Posting Process.
Common questions
The money is in the bank. Why does posting matter?
Because the bank balance is the only thing the deposit changed. Funds arrive by EFT carrying no information about which claims they cover; the explanation arrives separately as the remittance. Until that remittance is posted, every claim it paid still shows as outstanding — so it ages, may get followed up or refiled, and could be written off while the payment for it sits in the account. Posting is what connects the money to the claims.
Is posting the total against the claim good enough?
It is good enough for the cash and destroys everything else. The money reconciles — which is why lump-sum posting survives unnoticed — but the detail is gone: which line was reduced and why, what the allowed amount was, whether a line inside a largely-paid claim was denied. Without that you cannot bill a secondary, spot an underpayment, or produce a denial mix. You have a closed balance and no data.
Does auto-posting remove the need for posting staff?
It moves the work rather than removing it. Automation handles what is unambiguous; what it cannot resolve lands in an exception queue, and that queue is now where the judgment is concentrated rather than spread thinly across every remittance. It also changes the failure mode: manual posting produces scattered transcription errors, while a misconfigured rule produces the same error consistently, at volume. What needs checking becomes the rules rather than the typing.
Why does the group code matter when posting?
Because it decides who bears the amount, and the same figure under two group codes produces opposite outcomes — a write-off in one case, a patient statement in the other. Recording it wrong bills a patient for money they do not owe, which on a healthcare bill is a compliance problem rather than a service one. How to read the group codes and reason codes is covered in Reading a Denial.
Key terms in this article
Defined once, on their own pages.
Continue learning
Where to go next.
Authoritative sources
- X12 — EDI standards (opens in a new tab)
Maintains the 835 remittance transaction that posting reads, and the reassociation identifiers that link it to the payment.
- Centers for Medicare & Medicaid Services (CMS) (opens in a new tab)
Publishes Medicare remittance and electronic funds transfer guidance for providers.
- Healthcare Financial Management Association (HFMA) (opens in a new tab)
Publishes standard definitions for the revenue-cycle metrics computed from posted data.