> ## Documentation Index
> Fetch the complete documentation index at: https://docs.officeridge.com/llms.txt
> Use this file to discover all available pages before exploring further.

# EVV to paid claim

> Follow a visit from an attendant clocking in through to payment posted against the claim.

This guide follows one visit from an attendant clocking in through to payment posted against the
claim.

This is the chain that determines whether your agency gets paid for care it has already delivered.

## The chain

```mermaid theme={null}
graph LR
    A[Authorization<br/>units + dates] --> B[Recurring<br/>schedule]
    B --> C[Planned<br/>visit]
    C --> D[Attendant<br/>clocks in]
    D --> E{Clean?}
    E -->|Yes| F[COMPLETED]
    E -->|No| G[EXCEPTION]
    G -->|reason code| F
    F --> H[EVV match<br/>bill code rule]
    H --> I[Claim line]
    I --> J[Claim]
    J --> K[837P export]
    K --> L[Remittance<br/>835 posting]
```

Every arrow is a place the chain can break. Most unbilled revenue sits at the exception step.

## Step 1 — The authorization permits the visit

Before anything else, the member needs an active authorization with units remaining and a service
code matching what you will deliver.

<Warning>
  Once units are exhausted, delivered visits stop being payable. The care still happened; you cannot
  bill it. Watch **Used** against **Units** and request a new authorization before you reach the cap.
</Warning>

See [Authorizations](/members/authorizations).

## Step 2 — The schedule generates a planned visit

Scheduling checks each visit against the authorization and flags conflicts — visits outside the date
range, exceeding remaining units, or using an uncovered service code.

<Steps>
  <Step title="Review conflicts before the visit date">
    A flagged visit can still be delivered, but will not produce a payable claim.
  </Step>

  <Step title="Fix the authorization, not the flag">
    Extend the authorization or correct the service code.
  </Step>
</Steps>

See [Scheduling](/scheduling).

## Step 3 — The attendant clocks in and out

The clock times determine actual units, which is what gets billed — not the planned times.

| Result                                          | Status      |
| ----------------------------------------------- | ----------- |
| Clean clock-in and out at the member's location | `COMPLETED` |
| Something failed                                | `EXCEPTION` |
| No clock-in at all                              | `MISSED`    |

## Step 4 — Clear exceptions

This is the step that costs agencies the most money, because an unresolved exception is revenue that
never bills.

<Steps>
  <Step title="Work the exception queue daily">
    Aggregator submission windows are time-bound.
  </Step>

  <Step title="Identify the actual cause">
    Failed geofence, missing clock-out, or units exceeding the schedule.
  </Step>

  <Step title="Apply the reason code that matches reality">
    It is submitted to the state aggregator.
  </Step>

  <Step title="Fix systematic causes">
    Repeated geofence failures for one member usually mean a wrong address, not attendant error.
  </Step>
</Steps>

<Warning>
  Reason codes are a regulatory record. Applying a code that does not match what happened
  misrepresents visit data to the state. If you cannot determine what happened, escalate rather than
  guess.
</Warning>

See [Time & Attendance](/attendance).

## Step 5 — EVV matching produces a claim line

A bill code rule must exist for the payer, program, and service combination, and the service date
must fall inside the rule's effective window.

<Steps>
  <Step title="Confirm a bill code rule matches">
    No rule means no claim line. See [EVV matching](/billing/evv-matching).
  </Step>

  <Step title="Check the match result">
    **Result** and **Variance** show what matching concluded.
  </Step>

  <Step title="Investigate any variance">
    A non-zero variance explains why billed units differ from visit units.
  </Step>
</Steps>

<Warning>
  **Denial Begin** on a bill code rule is a temporal rule. Claims for service dates on or after that
  date are denied without a matching EVV transaction, even though earlier dates paid fine. A
  configuration that worked last year can start failing once this date passes.
</Warning>

## Step 6 — Claim lines become a claim

<Steps>
  <Step title="Review the claim before submitting">
    Check **Units** and **Charge** against the authorization.
  </Step>

  <Step title="Export the 837P">
    **Submitted** records the date.
  </Step>
</Steps>

<Warning>
  Review before submitting, not after. A claim submitted with the wrong service code has to be
  corrected and resubmitted, which restarts the payment clock and risks the timely filing deadline.
</Warning>

See [Billing](/billing).

## Step 7 — Post the remittance

<Steps>
  <Step title="Match the payment reference">
    **Check/EFT** against your bank deposit.
  </Step>

  <Step title="Post against the claims">
    Each claim's **Paid** amount and status update.
  </Step>

  <Step title="Review adjustments by reason">
    Contractual reductions are expected. Authorization and EVV adjustments are not.
  </Step>

  <Step title="Work the denials">
    Correct and resubmit before the timely filing deadline.
  </Step>
</Steps>

See [Remittances](/billing/remittances).

## Diagnosing a break in the chain

Work backwards from where the visit stopped:

| Symptom                              | Check                                        | Module                                |
| ------------------------------------ | -------------------------------------------- | ------------------------------------- |
| No planned visit generated           | Schedule active? **Effective From** reached? | [Scheduling](/scheduling)             |
| Visit shows `MISSED`                 | Attendant did not clock in                   | [Time & Attendance](/attendance)      |
| Visit stuck in `EXCEPTION`           | Needs a reason code                          | [Time & Attendance](/attendance)      |
| Aggregator not advancing             | Visit must be `COMPLETED` with no exception  | [Time & Attendance](/attendance)      |
| No claim line for a verified visit   | No bill code rule matched                    | [EVV matching](/billing/evv-matching) |
| Billed units differ from visit units | Check **Variance** and **Unit Type**         | [EVV matching](/billing/evv-matching) |
| Claim sits in `NOT_BILLED`           | Not yet picked up for submission             | [Billing](/billing)                   |
| Claim `DENIED`                       | Read the adjustment reason                   | [Remittances](/billing/remittances)   |
| Paid less than charged               | Adjustment codes on the remittance           | [Remittances](/billing/remittances)   |

## Recurring denial causes

Group your denials by reason. A reason that repeats is a process problem, not bad luck:

| Denial reason                         | Fix it here                                   |
| ------------------------------------- | --------------------------------------------- |
| Authorization expired or out of units | [Authorizations](/members/authorizations)     |
| Service code mismatch                 | [Authorizations](/members/authorizations)     |
| Member identity mismatch              | [Members](/members)                           |
| No matching EVV transaction           | [Time & Attendance](/attendance)              |
| Bill code rule missing or lapsed      | [EVV matching](/billing/evv-matching)         |
| Payer contract expired                | [Payer contracts](/licensing/payer-contracts) |

<Note>
  A valid authorization behind an expired payer contract still produces denials. When denials appear
  across many members at once, check the payer contract before investigating individual claims.
</Note>

## Next

<CardGroup cols={2}>
  <Card title="Month-end billing close" icon="calendar-check" href="/guides/month-end-billing-close">
    A repeatable monthly routine.
  </Card>

  <Card title="New member admission" icon="user-plus" href="/guides/new-member-admission">
    Getting the authorization right from the start.
  </Card>
</CardGroup>