Authorization-to-Claim Reconciliation Checklist
The pre-submission check that catches authorization and claim mismatches — code, units, dates, place of service, rendering provider — before they become CO-197 or CO-198 denials.
On this page: Direct answer
Direct answer
Authorization to claim reconciliation: what operators need to know
The pre-submission check that catches authorization and claim mismatches — code, units, dates, place of service, rendering provider — before they become CO-197 or CO-198 denials. Treat the authorization as a set of structured fields, not a number. A number alone cannot be reconciled against anything.
A denial that says the service was not authorized, when you are holding an approval for it, is almost never a coverage dispute. It is a matching failure: the authorization approved one thing and the claim described another, and the adjudication system compared the two and found them different. Code, units, dates, place of service, rendering provider, facility — any one of these can diverge, and each divergence produces a denial that takes far longer to appeal than it would have taken to prevent.
This is the cheapest denial class to fix because the fix is a comparison, not a judgement. The authorization and the claim are both in your possession before submission. The checklist below is the comparison, written as a pre-submission control rather than a post-denial investigation.
Key takeaways
The short version
- Treat the authorization as a set of structured fields, not a number. A number alone cannot be reconciled against anything.
- Compare seven things before submission: code, modifiers, units or days, date span, place of service, rendering provider, and facility or program.
- Units and date spans drift during an episode, which is why the check belongs at submission rather than at authorization.
- A rendering clinician who changed mid-episode is the most-missed mismatch, and it produces credentialing-flavoured denials rather than authorization ones.
- Record the reason a claim was held. The pattern tells you which upstream step is actually broken.
- Measure prevented denials, not caught errors. The number that matters is the drop in the matching-failure denial class.
Take the template with you
Free to copy · no email required
Pre-submission reconciliation checklist
The seven comparisons as a row-per-claim worksheet, with a fixed hold-reason vocabulary so the monthly pattern is countable.
claim_ref,episode_ref,payer,authorization_number,auth_codes_approved,claim_codes_billed,code_match,auth_modifiers,claim_modifiers,modifier_match,auth_units_approved,units_billed_prior,units_this_claim,units_within_approval,auth_start,auth_end,earliest_service_date,latest_service_date,dates_within_span,boundary_within_2_days,auth_place_of_service,claim_place_of_service,pos_match,authorized_rendering_provider,claim_rendering_provider,provider_match,provider_enrolled_on_dos,auth_facility_npi,claim_billing_npi,facility_match,auth_number_present_and_correct,result,hold_reason,owner,released_date CLM-0001,EP-0001,[payer],[number],H0015,H0015,yes,none,GT,no,36,24,12,yes,2026-09-01,2026-10-15,2026-10-14,2026-10-16,no,yes,facility,telehealth,no,[clinician],[covering clinician],no,yes,[npi],[npi],yes,yes,hold,modifier_mismatch; dates_outside_span; pos_mismatch; provider_mismatch,[name],
Saves as authorization-to-claim-reconciliation.csv
Fixed hold-reason list
Use these exact strings so holds stay countable. Free-text hold reasons cannot be aggregated, and an uncountable control cannot be improved.
code_mismatch modifier_mismatch units_exceed_approval units_cumulative_exceed_approval dates_outside_span boundary_date_review pos_mismatch provider_mismatch provider_not_enrolled_on_dos facility_mismatch auth_number_missing auth_number_invalid no_authorization_on_file retro_authorization_pending level_of_care_change_needs_second_auth
1. Why authorizations and claims drift apart
At the moment of authorization, a request is a plan: this level of care, roughly these dates, roughly this many units, this clinician. By the time a claim goes out, treatment has actually happened. The patient arrived two days later than planned, attended nine of twelve sessions, saw a covering clinician for two of them, and stepped down a level mid-episode. Every one of those ordinary events is a divergence between the approval and the claim.
The authorization did not change. The reality did. Systems that store an authorization as a single number in a text field cannot see the gap, because there is nothing to compare — which is why the first fix is structural rather than procedural.
| Field | Common drift | Typical denial flavour |
|---|---|---|
| Procedure code | Level of care changed; a different code was billed than authorized | Service not authorized; authorization does not cover the service billed |
| Modifiers | Telehealth, supervision, or program modifier added or dropped at billing | Service not authorized as billed; modifier inconsistent |
| Units or days | Patient attended fewer or more sessions than approved; billed beyond the approved count | Benefit maximum or authorization exceeded |
| Date span | Admission or discharge shifted outside the approved window | Service date outside the authorization period |
| Place of service | Program moved between facility and office settings, or to telehealth | Place of service inconsistent with authorization |
| Rendering provider | Covering clinician delivered part of the episode | Rendering provider not eligible or not the authorized provider |
| Facility or program | Multi-site group billed under a different location NPI | Provider or facility does not match authorization |
| Authorization number | Transcription error, wrong episode's number, or number omitted | Missing or invalid authorization number |
2. The seven-point pre-submission check
- 01
Code and modifiers
Does every billed line's code appear on the authorization, with the same modifiers? If the level of care changed mid-episode, is there an authorization covering each code for its own dates?
- 02
Units or days against the approval, net of prior claims
Compare billed units to approved units minus what has already been billed for the same authorization. This is the check that prevents the second and third claim in an episode from exceeding an approval the first one left intact.
- 03
Date span inside the approved window
Every service date must fall within the approved start and end. Flag any line within two days of either boundary, because boundary dates are where renewals and discharges collide.
- 04
Place of service
Does the billed place of service match the setting the authorization approved? Telehealth delivery of a service authorized in a facility setting is a frequent and quiet mismatch.
- 05
Rendering provider against the authorization and the roster
Is the rendering clinician the one authorized, or within the authorized group where the payer allows that? Separately, is that clinician enrolled and effective with this payer on this date of service?
- 06
Facility, program, and billing NPI
For multi-site groups, confirm the location and billing NPI match what the authorization names. A correct clinician at the wrong registered site denies the same way.
- 07
Authorization number present and correct
Check the number is populated, belongs to this episode, and is transcribed exactly. Then check it against the episode record rather than against the last claim, so a copied error does not propagate.
3. Reading the denial when one gets through
When a matching failure does reach adjudication, the remittance tells you which comparison failed — but only if you read the remark codes alongside the reason code. A claim adjustment reason code gives the category; the remittance advice remark codes narrow it to the field. Generic reason codes in particular are meaningless on their own and carry their real content in the paired remark.
Route by field rather than by code. A denial about units goes back to the authorization and utilisation record; a denial about the rendering provider goes to credentialing; a denial about place of service goes to scheduling and charge capture. Sending every matching failure to the appeals desk guarantees the upstream cause is never fixed.
| What the remittance indicates | Field to compare | Who owns the fix |
|---|---|---|
| Service not authorized / precertification absent | Code and modifiers; whether an authorization exists at all | Authorization coordinator |
| Authorization exceeded | Units or days, net of prior claims on the same approval | Utilisation review and billing jointly |
| Service date outside authorization period | Date span against admission and discharge | Authorization coordinator and scheduling |
| Rendering provider not eligible on the date of service | Clinician enrolment and effective dates | Credentialing |
| Place of service or setting inconsistent | Place of service and delivery setting | Scheduling and charge capture |
| Missing or invalid authorization number | Number presence and transcription | Billing |
| Generic denial with a paired remark code | Read the remark code before routing anything | Whoever the remark identifies |
4. Where the control belongs in the workflow
The temptation is to put this in the clearinghouse scrub, because that is where other claim edits live. That is the wrong home for most of it. A clearinghouse can check that a field is populated and well-formed; it generally cannot check that the units billed are within what this payer approved for this episode minus what you already billed, because it does not hold your authorization record.
The check belongs where the authorization data lives, immediately before the claim is released, with a hold state that a person clears. Keep the clearinghouse edits as a second net rather than the first.
- Run the comparison at claim release, not at authorization, so it sees what actually happened.
- Make the hold a real state with an owner and a dated next action, not a report someone reads.
- Re-run it on every claim against the same authorization, because the units check depends on cumulative billing.
- Give concurrent-review episodes a boundary check: any line within two days of the approved end date gets human review.
- Keep the authorization record and the claim in one place, or the comparison becomes a manual lookup and gets skipped under load.
- Log the hold reason in a fixed vocabulary, so the monthly pattern is countable rather than anecdotal.
5. Measuring whether it worked
Counting caught errors flatters the control and tells you nothing. The question is whether the matching-failure denial class shrank, and whether the days it used to cost came back.
| Measure | Definition | Why this one |
|---|---|---|
| Matching-failure denial rate | Denials in the matching-failure class ÷ claims submitted | The outcome the control exists to change |
| Hold rate | Claims held by the check ÷ claims released | Rising holds with falling denials is the control working |
| Hold reason mix | Share of holds by failed check | Points at the upstream step that is actually broken |
| Time in hold | Release date minus hold date | A control that delays cash is a cost, so watch this one |
| Rework avoided | Holds cleared × average appeal handling time for that denial class | Translates the control into staff hours |
| Boundary-date holds | Holds triggered within two days of an approval's end | Isolates the renewal-collision problem from everything else |
Common questions
Answers before you build.
Is this not what our clearinghouse already does?+
Partly. A clearinghouse can check that fields are present and well-formed and apply payer-specific edits it knows about. It generally cannot verify that billed units sit within what this payer approved for this episode net of prior claims, because it does not hold your authorization record. Keep the clearinghouse as the second net.
What if the level of care changed mid-episode?+
Then you need an authorization covering each code for its own date range, and the check has to compare line by line rather than claim by claim. A single authorization spanning a step-down is a common cause of partially denied claims that look inexplicable.
Our authorizations are stored as a number in a notes field. Where do we start?+
There. Until the approved code, units, date span, place of service, and rendering provider exist as fields, there is nothing to reconcile against and every check is a manual lookup that gets skipped when volume rises. Structuring the approval is the prerequisite, not the first improvement.
Should the check block submission or just warn?+
Block, with a human release. A warning that does not stop the claim becomes noise within a week. The point is a small number of holds that someone actually resolves, with the reason recorded.
How do we handle retroactive authorizations?+
As a distinct path with its own owner, because the date-span check will fail by design until the retroactive approval is in hand. Flag the episode, hold the claim, and track the retro request separately rather than letting the hold queue absorb it.
Practical closeout
Use this operator checklist.
- Treat the authorization as a set of structured fields, not a number. A number alone cannot be reconciled against anything.
- Compare seven things before submission: code, modifiers, units or days, date span, place of service, rendering provider, and facility or program.
- Units and date spans drift during an episode, which is why the check belongs at submission rather than at authorization.
- A rendering clinician who changed mid-episode is the most-missed mismatch, and it produces credentialing-flavoured denials rather than authorization ones.
- Record the reason a claim was held. The pattern tells you which upstream step is actually broken.
- Measure prevented denials, not caught errors. The number that matters is the drop in the matching-failure denial class.
Continue through the cluster
Verified customer case studies are added only with customer permission and supporting evidence; none is implied by these operational examples.
Codes on this topic
Look up the code on the remittance
- CO-197The payer found no authorization on file for this service, or none it could match to the claim.Denial code · Authorization
- CO-198An authorization exists, but the service went beyond it: more days, units, or visits, or dates past the approved span.Denial code · Authorization
- CO-15CARC 15 was deactivated on May 1, 2018. Payers on the current X12 list report the same problem with other codes.Denial code · Authorization
- CO-199On a facility claim, the revenue code and the procedure code on the same line don't match under the payer's rules.Denial code · Coding & billing
- CO-B15The payer won't pay this service until a qualifying primary service has been received and paid.Denial code · Coding & billing
- CO-185The payer says the clinician listed as rendering provider isn't eligible to perform the service billed.Denial code · Provider & credentialing
- CO-B7The provider wasn't certified or eligible to be paid for this service on the date it was provided.Denial code · Provider & credentialing
Sources & methodology
Trace the operational claims.
Marsa Health Editorial reviewed the primary and research sources below on October 18, 2026. We translate them into workflow controls, distinguish proposals from final rules, and flag where plan, program, state, contract, or clinical requirements vary.
- 01Health care payment and remittance advice Centers for Medicare & Medicaid ServicesHow the 835 carries claim adjustment reason codes and remittance advice remark codes, which is what a reconciliation step actually reads.Accessed or rechecked October 18, 2026
- 0242 CFR 422.568: Standard organization determination timeframes Electronic Code of Federal RegulationsSets the 7-calendar-day standard decision deadline for Medicare Advantage items and services subject to prior authorization, beginning January 1, 2026.Accessed or rechecked October 18, 2026
- 0342 CFR 438.210: Coverage and authorization of services Electronic Code of Federal RegulationsParagraph (d) sets 7-calendar-day standard and 72-hour expedited decision limits for rating periods beginning on or after January 1, 2026; (c) governs notice of adverse benefit determination.Accessed or rechecked October 18, 2026
- 04CMS Interoperability and Prior Authorization Final Rule CMS-0057-F Centers for Medicare & Medicaid ServicesThe fact sheet listing which payers are impacted, the four required APIs, the denial-reason duty, and the compliance dates.Accessed or rechecked October 18, 2026
- 05Appealing health plan decisions Centers for Medicare & Medicaid ServicesCMS guidance on internal claims and appeals rights, notice contents, and the relationship between internal appeals and external review.Accessed or rechecked October 18, 2026
- 06Electronic Prior Authorization Centers for Medicare & Medicaid ServicesCurrent CMS provider-readiness guidance for 2027 electronic prior authorization, EHR questions, FHIR testing, and workflow preparation.Accessed or rechecked October 18, 2026
- 07Minimum Necessary Requirement U.S. Department of Health and Human ServicesHIPAA guidance on limiting uses, disclosures, and requests for protected health information when the standard applies.Accessed or rechecked October 18, 2026
Organizational author. Editorial review covers source accuracy, search intent, workflow boundaries, and human-oversight requirements. This material is educational and does not provide clinical, legal, coding, or coverage advice.
No named clinical or legal expert reviewer is attributed to this version. Marsa Health does not invent reviewer credentials.
Read our editorial methodRevision history
What changed and when
October 18, 2026
Initial publication, source review, and operational editing.