- A signature finishes the note. Claim readiness asks whether the whole service reconciles: schedule, attendance, authorization, documentation, provider, and payer data.
- Documentation completion, service readiness, claim validation, and payer adjudication are four different questions, answered at four different times.
- Every readiness problem should route to the person who can fix it. Billing shouldn't be the organization's universal cleanup department.
- Fix the source, not only the claim, and the next hundred claims inherit the fix.
Thursday, 4:41 PM. Billing opens tomorrow's claim batch.
127 services. 124 notes signed. At first glance: almost ready. Then the review begins.
- Three signed notes belong to services whose authorization has expired.
- Two claims point to a rendering provider whose payer enrollment needs review.
- One patient is marked present in the note but absent on the group roster.
- Four encounters have signed documentation, but other required workflow elements are still incomplete.
Add the three unsigned notes, and 13 of the 127 services aren't ready: 114, not 124. The notes are finished. The claims are not.
A signed note answers “did someone finish the note?” Claim readiness asks “does the entire service reconcile?”
Documentation completion and claim readiness are different states
Illustrative example
A documentation system tracks states like draft, incomplete, signed, co-signed, and final. A billing workflow needs to know other things: is the patient eligible, were they present, was the service authorized where that applies, does the service match the program, is the documentation complete, is the provider configured correctly, and does the claim data reconcile?
These are related workflows, not the same one. It helps to keep four questions apart:
| Question | Who answers it | When |
|---|---|---|
| Is the documentation complete? | The clinician, against configured documentation requirements | After the service |
| Is the service ready to become a claim? | Operations, by reconciling schedule, attendance, authorization, provider, and documentation | Before the claim is created |
| Is the claim valid? | Claim scrubbing, against configured claim rules | Before submission |
| Will it be paid? | The payer, through adjudication | After submission |
A “yes” to any one of them doesn't answer the next. This article is about the second row, the one most organizations don't name at all.
Clinical completion is an input to claim readiness, not the definition of it.
The service should reconcile across systems
When a service is ready, every record about it agrees:
Illustrative example
- ScheduleA. Carter · IOP · Sep 10
- AttendancePresent
- AuthorizationActive
- DocumentationSigned
- ProviderReady
- ClaimReady
And when it isn't:
Illustrative example
The goal isn't to make every field identical. Records describe different things, and some differences are expected. The goal is to notice when data that should agree doesn't, before the claim leaves.
Start with the schedule
The schedule usually establishes the intended service: the patient, date, time, program, service, clinician, location, whether it's telehealth, the group, and other operational details. It's the first record, and often the one everything downstream is built from.
That's exactly why it has to change when the care does:
Illustrative example
Nothing here is anyone's fault. The patient's day changed, the clinician documented what happened, and the schedule was never updated. How the service should be billed is a coding question for your payer rules. The readiness question is simpler: the record should reflect the care that actually occurred before anyone bills it.
Attendance is part of the billing story
Illustrative example
Eleven notes, ten patients fully present. The answer may be perfectly valid: the patient who left early received part of the service and was documented. But the discrepancy is exactly the kind of thing that should be reviewed before a claim goes out, not discovered afterward.
Whether partial attendance, a late arrival, or an early departure is billable depends on the program, payer, service, and contract. There is no universal rule, and this article won't invent one. The operational point is that attendance on the group roster and the group notes should agree, or disagree for a reason someone has recorded.
Authorization can invalidate an otherwise perfect note
Illustrative example
The note may document the care accurately. The authorization problem exists independently of it, and no amount of documentation quality fixes it. That's why authorization status needs to be visible before claims are created, not discovered during submission. Better still, before the service is scheduled, which is the argument of The authorization expired yesterday. Who was supposed to know?
A note can be signed and still fail documentation readiness
“Signed” doesn't necessarily mean every required documentation element is satisfied. Depending on the organization's configured requirements, documentation readiness can involve:
- required sections
- treatment-plan connection, where appropriate
- service information
- clinician signature
- co-signature, where applicable
- date and time information
- a required attestation
- other configured fields
Not every program requires all of these. Requirements vary by payer, service, program, jurisdiction, and organization, which is why they should be configured rather than assumed.
Conceptual example
Treatment-plan context can matter before the claim leaves
A treatment plan isn't a claim-editing rule. But if the organization's workflow expects services to connect to active treatment goals, a note with no visible relationship to the plan is a documentation signal worth a clinical look.
Illustrative example
That doesn't mean the claim should be denied or held automatically. It means a clinician, not a billing rule, should decide whether the note says what the care was for. We covered keeping the treatment plan connected to the chart in The treatment plan is current. Is the care actually connected to it?
Provider readiness belongs in the same picture
Illustrative example
Whether a provider can bill a given service can depend on credentialing, enrollment, licensure, taxonomy, contract participation, supervision, the service, the location, and other payer requirements. None of those is universal, and several can change without anyone touching the note. Tracking credentials and payer enrollment with expiration dates is what keeps a lapse from showing up first on a claim.
The service and the note should describe the same level of care
Illustrative example
Level-of-care mismatches tend to appear at predictable moments:
- transitions between programs
- schedule changes
- manual claim creation
- template selection
- program transfers
- configuration changes
Step-downs from residential to PHP and IOP, and from there to outpatient, are clinically routine, and they're the most common source. One record updates; another doesn't.
Claim readiness should distinguish errors from warnings
| State | Example |
|---|---|
| Blocking error | No patient identifier, or an invalid required configuration |
| Review warning | The authorization is nearing its limit |
| Information | The patient has secondary coverage |
Not every issue should stop a claim. Not every issue should be ignored either. The same distinction applies to claim scrubbing, and we went through it in more detail in Seven claim problems you can catch before the payer sees them.
If every warning is red, staff stop seeing red.
Billing should not have to read every note to know what is missing
Here's the usual version:
- Billing opens the claim and sees an error.
- Opens the chart and searches for the note.
- Checks the treatment plan.
- Checks the authorization spreadsheet.
- Emails the clinician.
- Checks the credential file.
- Comes back two days later.
The better version tells billing what's wrong without the search:
Illustrative example
The system identifies the category of the problem and routes it to the right person. Billing still sees the hold. It just doesn't have to diagnose it.
The person who can fix the problem should own the problem
| Issue | Owner |
|---|---|
| Unsigned note | Clinician |
| Expired authorization | Utilization review |
| Payer enrollment | Credentialing |
| Patient demographic mismatch | Admissions or billing |
| Claim edit | Billing |
Only one of those five belongs to billing. A readiness queue becomes useful the moment problems stop being dumped onto the billing team and start going to whoever can resolve them. Billing can't sign a note or extend an authorization; it can only chase the people who can.
Billing should not become the organization's universal cleanup department.
A claim should move forward when the service is ready, not just when the calendar says so
“Every Friday at 5 PM, submit everything.” A fixed batch is simple to manage, and it tends to produce claims sent with unresolved issues, claims held by hand with no clear owner, rushed corrections, incomplete documentation, and payer responses that were avoidable.
The alternative is to let each service's state decide what happens to it:
| State | What happens |
|---|---|
| Ready | Submit |
| Review | Resolve, then submit |
| Not ready | Hold, with a reason and an owner |
A hold is not a license to wait indefinitely. Payers set their own filing limits, and a held claim still has to go out within them. That's one more reason every hold needs an owner and a reason, rather than sitting in a pile until someone remembers it.
Documentation clocks and billing clocks are connected
Illustrative example
- MondayService delivered
- Configured deadlineNote due under your documentation policy
- WednesdayNote signed
- ThursdayClaim batch runs
- Still pendingCo-signature outstanding, so the claim isn’t ready
Clinical documentation deadlines set the pace at which claims can move. The problem isn't that documentation takes time; it's when billing discovers the outstanding co-signature on Thursday afternoon, while the batch is running. A documentation clock that shows the pending co-signature on Tuesday gives someone two days to act on it.
Late documentation creates downstream work
When documentation stays incomplete, organizations can see:
- claim delays
- manual follow-up
- missing information
- authorization reconciliation problems
- delayed patient balances
- less visibility into expected cash
Illustrative numbers
Late documentation doesn't automatically cause a denial. What it reliably causes is work: fourteen claims that someone has to track, six clinicians someone has to reach, and a cash forecast that's off by fourteen services until they're done.
Claim readiness should happen before claim scrubbing
The sequence
- Service delivered
- Operational reconciliationSchedule, attendance, authorization, provider
- Documentation ready
- Claim created
- Claim scrubbingThe claim validated against configured rules
- Submission
Claim scrubbing validates the claim. Claim readiness validates whether the underlying service is ready to become a claim. The checks overlap (both can look at authorization, provider, and documentation state), but the questions differ. A claim can pass scrubbing perfectly while describing a service that didn't happen the way the claim says, because nothing upstream compared the claim with the roster.
Fix the source, not only the claim
A claim comes back flagged for a provider taxonomy mismatch. Someone corrects the claim by hand. Next week, the same issue appears on 17 more claims.
The better question is where the wrong information came from:
- the provider profile
- payer configuration
- service setup
- a schedule template
- the patient record
- program configuration
The strongest workflow fixes the source record, so every future claim built from it inherits the correction. That sometimes means the fix belongs to someone other than the person who found it, which is one more reason readiness issues need owners.
A corrected claim fixes one claim. A corrected source fixes the next hundred.
Repeated claim-readiness failures are operational metrics
Illustrative numbers — not a benchmark
Grouped by reason, holds turn into questions a leader can actually act on:
- Why are documentation holds increasing?
- Which program generates the most authorization holds?
- Is one provider configuration causing repeated failures?
- Are admission errors flowing downstream into claims?
One patient-day should tell one consistent story
This matters most in PHP and IOP, where one day of care can involve several services:
Illustrative example
Two attended groups and three notes. Maybe the third note documents something real; maybe it was generated from the schedule. Whether two groups meet the program's requirement for the day isn't something this article can decide. The discrepancy needs review against the applicable program and payer rules. We walked through that day-level question in What has to be true before an IOP day is actually billable, and the documentation side of it in Twelve patients were in the same group. Why do their notes all look identical?
A practical pre-bill readiness checklist
Patient
- Demographics complete
- Payer information current
- Member information reviewed where applicable
Service
- Service date correct
- Program / level of care correct
- Service information reflects actual care
- Location / modality correct where applicable
Attendance
- Attendance captured
- Group roster reconciled where applicable
- Attendance discrepancies reviewed
Authorization
- Authorization status reviewed where applicable
- Remaining utilization / expiration reviewed
- Service aligns with applicable authorization information
Documentation
- Required note exists
- Documentation status complete
- Required signatures reviewed
- Required co-signature reviewed where applicable
- Configured documentation elements complete
Provider
- Rendering provider correct
- Credentialing / enrollment status reviewed where applicable
- Required provider configuration present
Claim
- Claim generated from reconciled service data
- Blocking issues resolved
- Warnings reviewed
- Claim ready for scrubbing
This checklist is an operational framework and not payer-specific billing guidance.
What leadership should be able to see
Illustrative numbers
The 28 services under review or not ready, broken out by reason, with the oldest one named. A revenue-cycle leader should be able to see where claims are waiting before they turn into denials, rejections, or delayed cash, and whose desk each one is sitting on.
How ProbityCare approaches claim readiness
ProbityCare connects clinical documentation, authorization, attendance, provider information, and claim validation in one record, so the billing team can see whether a service is ready before it's submitted.
Illustrative example
- Attendance drives the claim: the group roster records present, late, and excused per participant, so the notes and the claim start from the same attendance record.
- Documentation state is checked: unsigned encounters don't leave as claims, and the documentation clock escalates a late note and holds its claim when it goes overdue.
- Authorization is matched: the date of service has to fall inside the authorized window, with units inside the authorized amount.
- Provider and service are validated: credential and taxonomy validity for the payer, and level-of-care consistency between the claim and the patient's program, through claim scrubbing.
- For PHP and IOP, whether the day qualifies under what you've configured is answered before the claim goes out.
It surfaces configured issues and inconsistencies. It doesn't guarantee payer acceptance or payment, and no pre-submission check can.
The takeaway
A signed note is important. But it's only one piece of a billable service.
Before a claim leaves the organization, the patient, service, attendance, authorization, documentation, provider, and payer data should tell a consistent story. The goal isn't to make billing inspect the whole chart before every submission. It's to give billing a clear answer: ready, review, or not ready, and why.
The claim should be the output of a complete workflow, not the place the workflow gets repaired.
Behavioral health documentation and claim readiness questions
Does a signed note mean a behavioral health claim can be submitted?
Not necessarily. A signature completes the documentation step, but claim readiness can also depend on attendance, authorization, provider configuration, payer and patient data, and whether the service recorded in the note matches the scheduled program and the claim.
What documentation is required before billing a behavioral health claim?
There is no universal list. Requirements vary by payer, service, setting, jurisdiction, and program, and can include required sections, signatures, co-signatures, attestations, and other elements. They should be configured to the rules that apply to your organization rather than assumed.
What is claim readiness?
Claim readiness is an operational determination of whether the underlying service and its associated records, including schedule, attendance, authorization, documentation, provider, and payer data, are sufficiently reconciled for the billing workflow to proceed.
Is claim readiness the same as claim scrubbing?
No. Claim readiness asks whether the underlying service is complete and consistent enough to become a claim. Claim scrubbing validates the claim itself against configured rules before submission. Some checks, such as authorization and documentation state, overlap.
Can an unsigned note delay billing?
Potentially, depending on the organization’s requirements and applicable payer and program rules. Many organizations hold claims until the related documentation is complete, which is why documentation deadlines and claim timing are connected.
Should billing fix documentation problems?
Ideally, no. Readiness issues should route to the team that owns the source of the problem: clinicians for notes, utilization review for authorizations, credentialing for enrollment, and admissions or billing for demographic data. Billing can see the hold without having to repair every upstream workflow.
Can software determine if a claim will be paid?
No. Software can identify configured issues and inconsistencies before submission, but it cannot guarantee payer adjudication or reimbursement. Payment depends on the payer’s decision, coverage, contract terms, and other factors.