> ## 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.

# Authorizations

> Approved service units from payers, and the service items you deliver against them.

An authorization is a payer's approval to deliver a set number of service units to a member over a
date range. Nothing bills without one.

## Authorizations

Service authorizations with discipline, service codes, date ranges, and unit allocations.

**Columns:** Member · Auth # · Discipline · Service Code · Begin · End · Units · Payer Type ·
Delivery Model · Cap Units · Used · Status

### The fields that decide whether a visit bills

| Field            | Why it matters                                                              |
| ---------------- | --------------------------------------------------------------------------- |
| **Auth #**       | The payer's authorization number. Appears on claims.                        |
| **Service Code** | The specific service approved. Must match what you actually deliver.        |
| **Begin / End**  | The window services may be delivered in. Visits outside it are not payable. |
| **Units**        | Total approved units.                                                       |
| **Cap Units**    | The ceiling the payer will pay to.                                          |
| **Used**         | Units consumed so far.                                                      |
| **Status**       | Only an active authorization supports new visits.                           |

<Warning>
  **Used** approaching **Units** is the single most useful early warning in OfficeRidge. Once units
  are exhausted, delivered visits stop being payable — the care still happened, but you cannot bill
  it. Request a new authorization before you reach the cap, not after.
</Warning>

### Watch the end date too

Members whose authorization is nearing expiry take the status
`AUTHORIZATION_HAS_EXPIRY_DATE`. Treat that as a prompt to start the renewal, not a notification
that renewal is complete.

## Service Items

Individual service delivery items for bathing, feeding, medication assistance, and more.

**Columns:** Member · Status · Bathing · Feeding · Meds · Checked

Service items record which specific tasks the member receives. They describe the content of care,
where the authorization describes the permission and quantity.

**Checked** indicates the item set has been reviewed and confirmed for that member.

## Recording an authorization

<Steps>
  <Step title="Confirm the payer">
    The payer must exist and be active. See [Care network](/members/care-network).
  </Step>

  <Step title="Enter the authorization number and service code">
    Copy them exactly from the payer's approval. A transposed service code produces denials that are
    tedious to unpick.
  </Step>

  <Step title="Set the date range and units">
    Record **Begin**, **End**, **Units**, and **Cap Units** as approved.
  </Step>

  <Step title="Set the status to active">
    Scheduling checks authorization status before allowing billable visits.
  </Step>

  <Step title="Confirm service items">
    Record what the member actually receives on the **Service Items** tab.
  </Step>
</Steps>

## How authorizations reach billing

```mermaid theme={null}
graph LR
    A[Authorization<br/>units + date range] --> B[Scheduling<br/>conflict checked]
    B --> C[EVV visit<br/>verified]
    C --> D[Claim line<br/>consumes units]
    D --> E[Claim]
```

Scheduling is authorization-aware: it flags visits that fall outside the authorized window or exceed
remaining units. See [Scheduling](/scheduling).

## Troubleshooting

| Problem                                 | What to check                                                                                                                         |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Scheduling refuses to plan a visit      | The authorization may be expired, inactive, or out of units. Check **End**, **Status**, and **Used** against **Units**.               |
| Used is higher than expected            | Every verified visit consumes units. Review the member's visits in [Time & Attendance](/attendance).                                  |
| Claims deny with an authorization error | Confirm **Auth #** and **Service Code** match the payer's record exactly, and that the service date sits inside **Begin** to **End**. |
| Units remain but visits still fail      | Check **Cap Units**. The payer will not pay above the cap even when units appear available.                                           |

## Related

<CardGroup cols={2}>
  <Card title="Scheduling" icon="calendar-clock" href="/scheduling">
    Authorization-aware conflict tracking.
  </Card>

  <Card title="EVV to paid claim" icon="route" href="/guides/evv-to-claim">
    The full chain from authorization to payment.
  </Card>
</CardGroup>