How to Pull DrChrono Billing Data Into a Daily Revenue Dashboard

The morning question at every clinic we've run is always the same: "How did we do yesterday?" On paper that sounds simple. In practice, if you're on DrChrono, answering it means opening the billing module, filtering by date, trying to remember whether a given payment hit the right appointment, and then manually reconciling cash versus insurance versus adjustments in a spreadsheet — before your first patient is even scheduled.

We burned enough mornings that way before we decided to build the fix ourselves.

What follows is a practical look at how we pull DrChrono billing data into a live dashboard that answers the owner's morning question in under thirty seconds, before the front desk unlocks the door.

Why the Default DrChrono Reports Fall Short

DrChrono's built-in reporting is built around claims and payment posting — exactly the right shape for a biller managing A/R. It's the wrong shape for an operator trying to run the business day-to-day.

The gaps we kept hitting:

No revenue-by-provider view that's fast to scan. Drilling down by provider requires multiple clicks and a lot of scrolled rows.
Cash and insurance are mixed by default. Separating them means filtering by payer type, which isn't exposed in every report.
No comparison to target or prior period without exporting and building it yourself.
Reports are static snapshots. If a payment posts at 3pm, you won't see it until you run the report again.

The dashboard we built solves all four. Here's how.

The Two API Endpoints That Do the Work

Everything lives in two DrChrono API resources: Appointments and Line Items.

Appointments

The /api/appointments endpoint returns scheduled appointments with their status (Complete, No Show, Cancelled, etc.), the rendering provider, the office, and the scheduled time. This is where we get the service-level view: who saw how many patients, at which location, on any given day.

We query it once in the morning for the prior calendar day and cache the result. The fields that matter most:

scheduled_time — filters to yesterday's date range
doctor — maps to a provider ID
status — we only count appointments with status Complete
office — essential for multi-location practices

Line Items

The /api/lineitems endpoint is where actual dollars live. Each line item is tied to an appointment, carries a CPT code, a billed amount, and — critically — allowed_amount and paid_amount. This is where we distinguish what was billed from what was actually collected.

We join line items back to appointments using the appointment foreign key. That join is the core of the whole build.

The /api/billing endpoint exists too, but it returns claim-level summaries. For a revenue dashboard, line items give you finer control — you can always roll up from the line-item level, but you can't go the other direction.

Structuring the Data for the Dashboard

Once we have appointments and line items joined, we build three aggregations on top:

Revenue by provider — sum of paid_amount for completed appointments, grouped by doctor. Providers see their own number; the owner sees all of them.
Cash vs. insurance split — line items where the insurance portion is zero are treated as cash-pay. For most practices this holds cleanly; if your payer mix is more complex, you can refine further using the payer ID.
Daily total vs. target — we store a simple target-per-weekday in a small database table we control (not in DrChrono) and compare the rolling sum against it each morning.

Handling Payments That Post Late

One thing to build for from the start: payments don't always post on the same day as the appointment. Insurance EOBs in particular can hit days or weeks later.

We handle this with a sliding window: the dashboard shows yesterday's appointments alongside a separate "payments posted yesterday" figure that spans any appointment date. The owner sees both — services rendered versus cash that actually hit — and we flag the gap if it's wider than a configurable threshold. Keeping these two numbers separate prevents confusion when insurance catches up in bulk.

What the Dashboard Actually Shows

The screen we use at the front desk shows four panels:

Yesterday's collections — total collected, split cash / insurance, with a delta versus the same weekday last week
Provider breakdown — revenue and completed visit count per provider, sortable by either column
Month-to-date vs. target — a simple progress bar against the monthly revenue goal
Payment lag — average days between appointment date and payment post date, rolling 30 days

None of this requires touching DrChrono settings or installing anything new in the EHR. It's a read-only layer that talks to the API and renders in any browser.

What You Need to Build It

If you're evaluating whether to build this yourself, the practical checklist:

DrChrono API credentials — OAuth 2.0. You'll need a client_id and client_secret from the DrChrono developer portal, plus a reliable refresh-token flow, since access tokens expire hourly.
A small HIPAA-eligible backend — any server that can make authenticated HTTP requests. We run a lightweight Node service on a hosting provider with a BAA in place.
A place to store your targets — a simple table: (weekday, provider_id, target_amount). No PHI involved, so hosting constraints are minimal.
A front-end — we use a plain HTML page with a charting library. The data shapes the value, not the UI framework.

The rate limits on the DrChrono API are generous for read-only queries; a morning pull for a typical single-location clinic is nowhere near the ceiling. The trickier parts are handling OAuth token refresh reliably and building the appointment-to-line-item join correctly across paginated responses. Both are solvable, but they're where a first-time DrChrono integration most often stalls.

The Wider Pattern

This dashboard is one piece of what we think of as the operator layer: a thin, HIPAA-compliant set of tools that sit on top of DrChrono, read from it in real time, and give practice owners and managers the visibility that a general-purpose EHR can't provide out of the box.

Revenue is the one people ask for first because it touches the bottom line directly. But the same API pattern — read from DrChrono, aggregate, write back when needed — underlies the patient flow board, the booking integration, and the care-plan tracker we've built. Once you have a working OAuth layer and a reliable paginator, each new view is much faster to add.

If you're currently building this report by hand every morning — or if you've started a build and stalled on the OAuth plumbing or the line-item join — we're glad to talk through a concrete build. We can usually scope a dashboard like this quickly because we've done it before and know where the edges are.