The Claim Lifecycle: The Four Gates a Claim Passes
Between a service being performed and a payer deciding what it owes, a claim passes four gates. Each is owned by someone different, fails in a different way, and reports to a different place — and a claim can die at any one of them. Most confusion about claims comes from treating that journey as a single step called “billing.”
Updated 7 min read
On this page
Key takeaways
- Four gates: the scrubber, the clearinghouse, the payer's front door, and adjudication. Only the last one produces a denial.
- Sent is not received. The first three gates return claims, and none of them moves money — so nothing announces a failure the way a denial does.
- The gate a claim fails at determines who fixes it and how. The same underlying mistake produces a scrubber hold, a rejection, or a denial depending only on how far it traveled first.
- Failing early is good. A claim held by the scrubber is fixed before anything is at stake; the same claim denied has to be reworked against a filing deadline that has been running the whole time.
The four gates
A claim does not go from your system to a decision. It is checked by your own edits, routed and checked again by a clearinghouse, checked once more at the payer's front door, and only then adjudicated. Four checks, and the differences between them are what the rest of this article is about.
| Gate | What it checks | What a failure is called |
|---|---|---|
| 1. The scrubber | Your own edits, before the claim leaves: format, code validity, payer rules. See claim scrubbing. | A hold. Nothing has been sent, nothing is late, and the fix costs minutes. |
| 2. The clearinghouse | Structural validity and its own edit set, before routing the claim onward to the payer. | A rejection. Returned in an acknowledgment report; the payer never saw it. |
| 3. The payer's front door | Whether the payer can accept the claim into its system at all — identifiers that match, required data present. | Also a rejection — reported separately, and easy to miss if only the clearinghouse's report is read. |
| 4. Adjudication | What the payer owes: coverage, policy, contract, medical necessity. See adjudication. | A denial — the only one of the four. It arrives on the remittance, with reason codes. |
Gates 2 and 3 are both rejections and are worth counting together: they are two filters on one process, and a rejection rate that counts only the clearinghouse measures one of them. See claim rejection rate.
Why the gate matters more than the mistake
Here is the part that is genuinely counterintuitive: the same underlying mistake can surface at three different gates, with three different names, three different costs, and three different owners — and which one you get depends only on how far the claim traveled before something noticed.
Caught at gate 1
A scrubber edit holds the claim. Nothing was sent. The biller fixes it and it goes out the same day. No clock has started, nothing is at risk, and no report anywhere records that anything happened.Caught at gates 2 or 3
It becomes a rejection. The claim comes back in an acknowledgment report, is corrected, and is resubmitted — arriving at the payer as a first submission. Days have passed, and someone had to read a report that nothing forced them to read.Not caught until gate 4
It becomes a denial. Now the payer has decided, the claim is in the denial rate, the claim has been through a full adjudication cycle, and the response is a correction or an appeal against a deadline that has been running since the date of service. The same mistake, several steps further from the money.
Failing early is the goal, not the embarrassment
The silent stretch
There is one structural asymmetry in the lifecycle that explains a surprising amount of lost revenue: only gate 4 moves money.
Gate 4 announces itself: a denial is attached to a payment, on a document somebody already has a reason to open. Gates 2 and 3 announce nothing. Their failures come back in acknowledgment reports, which move no money and change no balance — so a claim can sit rejected for weeks while every dashboard in the practice looks normal. Submitting Claims covers why that happens and what the reports actually contain.
The worst outcome is a rejection nobody read
This is why reading acknowledgments is a numbered step in The Claim Submission Process rather than an assumed part of “submit.” A process that cannot tell you which of its gates a claim stopped at is not a process; it is a hope with a send button.
Where the lifecycle ends, and what begins
The claim lifecycle ends at adjudication, because at that point the claim is no longer moving through a process — a decision exists, and everything after is a response to it. The payer pays it, pays part of it, or refuses it, and the reasons come back on the remittance advice.
What follows is a different process with a different owner. A paid claim goes to posting. A refused one enters denial work, where the response is a corrected claim, an appeal, or a write-off. A claim that has been accepted but has simply gone quiet is neither — it needs follow-up, which is its own discipline and the last article in this section.
Two clocks run the whole way
Common questions
What is the difference between a claim being sent and a payer having it?
Two gates. After a claim is transmitted it still has to be accepted by the clearinghouse and then accepted at the payer's front door, and either can return it. A returned claim never reached adjudication, so the payer genuinely does not have it — even though your system says it was sent. This is why the submission process ends at an acknowledgment rather than at transmission: only the acknowledgment tells you which of those two statements is true.
Why is a rejection worse than a denial in practice?
Not because it is harder to fix — a rejection is usually easier, since it never reached adjudication and can simply be corrected and resubmitted. It is worse because of where it stops. A rejected claim is out of the process entirely: the payer does not have it, no decision exists, and no reason code will ever be issued for it. It is the only state in the lifecycle that is invisible from both ends, which is why it can age into a filing-deadline denial on a claim that was never wrong about the care.
Should a high scrubber hold rate worry me?
Generally not by itself. A scrubber holding claims is a gate working at the cheapest point in the lifecycle — nothing has been sent, no clock is running, and the fix costs minutes. The claims worth attention are the opposite ones: those that pass your edits cleanly and are then rejected or denied downstream, because those are mistakes your own edit set does not yet know about.
Where does the claim lifecycle end?
At adjudication — the moment the payer decides. Before that, the claim is moving through a process; after it, a decision exists and everything else is a response to it. A paid claim goes to posting, a refused one goes to denial work, and an accepted one that has gone quiet needs follow-up. The submission workflow deliberately stops at acceptance for the same reason, and the denial appeal process begins after adjudication, so the two meet without overlapping.
Key terms in this article
Defined once, on their own pages.
Continue learning
Where to go next on claims.
The Claim Submission Process
The ordered operational steps behind the gates described here.
Submitting Claims
Gates 2 and 3 in depth — clearinghouses, direct submission, and the acknowledgments.
Claim rejection rate
The metric that measures how often a claim fails before adjudication.
Charge lag calculator
Calculate how much of the filing window you spend before submitting.
Authoritative sources
- X12 — EDI standards (opens in a new tab)
Maintains the claim and acknowledgment transactions that carry a claim through the gates described here.
- Centers for Medicare & Medicaid Services (CMS) (opens in a new tab)
Publishes Medicare claims-processing and acknowledgment guidance for providers.
- Healthcare Financial Management Association (HFMA) (opens in a new tab)
Publishes standard definitions for the revenue-cycle metrics that measure this process.