How claims move through Ona

An insurance claim in Ona isn't created in one place — it's assembled from data entered across the product, then moved through the payer's system. Understanding the whole path makes each individual step, and each rejection, easier to reason about.

The one-line version

Set up once → document a visit → build a claim from it → send it through a clearinghouse → track the payer's response → get paid.

Everything that follows is that sentence, expanded.

Stage 0 — One-time setup

Before any claim can go out, four things must be configured. They're done once, though enrollments take the longest:

1. Insurance — your organization's billing NPI (Type 2), Tax ID, legal name, and each clinician's rendering NPI (Type 1). See Setting up insurance.
2. Clearinghouse — who transmits your claims: Stedi or Claim.MD. See Setting up your clearinghouse.
3. Enrollments — per-payer authorization to transact through the clearinghouse. Slowest step; payers take weeks. Gated on insurance setup.
4. Billing rules — the checks that scrub a claim before it goes out. See Billing rules and claim scrubbing.

Services and locations also carry claim data set up front: each service has its CPT code and place-of-service default (Setting up services), and each location has its facility NPI and taxonomy (Setting up your workspace). A claim pulls all of this together, which is why a gap in any one shows up later as a rejection.

Stage 1 — Check coverage

Before or at the visit, an eligibility check confirms the patient is covered. Ona sends a 270 request and stores the 271 response, shown as a badge on the patient and in the Visits list. See Reading eligibility results.

This is the cheapest place to catch a problem. An Ineligible result now saves a rejected claim later.

Stage 2 — Document the visit

The claim's clinical substance comes from the visit:

• Services on the visit become the billable line items (CPT codes).
• Diagnoses charted on the visit become the linked diagnosis codes. A claim without a diagnosis usually rejects.
• A signed note is required before the visit can be billed (the Note required per visit rule, on by default).

So the clinical work and the billing are the same act: charting the visit is building the claim's content. See Creating a consultation / starting a visit and Reviewing and signing an AI-drafted note.

Stage 3 — Freeze a superbill

Once the visit is Completed (which needs the signed note), you create a superbill — a frozen, CMS-1500-style snapshot of the billing: patient, provider with NPI, practice, place of service, diagnoses, and CPT line items with units and fees. It's immutable by design; to change it you void and recreate. Finalize locks it as the basis for a claim. See From signed note to superbill and claim.

Stage 4 — The claim, and its statuses

A claim is generated from the finalized superbill and enters the Claims queue. It carries two independent axes:

• Status — what the payer thinks: Draft → Submitted → Acknowledged → Accepted/Rejected/Denied → Paid.
• Bucket — what your team is doing: Untriaged, Review, Hold, Payments, Pending, Settled, Patient Billing, Closed.

Before submission, the claim is scrubbed against your billing rules. Submit sends it to the clearinghouse — this is real EDI and can't be undone from Ona, so it's the point to check codes and payer carefully. See The claims queue.

Stage 5 — The payer responds

After submission, the clearinghouse relays the payer's responses, visible on the claim's History tab as a timestamped audit trail. The critical distinction:

• Rejected — bounced before adjudication (a format or data problem). Fix and resubmit. Claims are versioned, so each correction is tracked.
• Denied — adjudicated and refused (a coverage or clinical decision). Appeal, or bill the patient.
• Paid — payment issued.

View response on a History entry shows the payer's exact reason code — the thing you need to fix a rejection.

Stage 6 — Get paid, or bill the patient

A Paid claim closes the loop. What insurance doesn't cover — a copay, an uncovered balance — goes to the patient as an invoice, collected through Stripe. This is the other billing rail: invoices bill the patient, claims bill the payer, and a single visit can produce both. See Invoices and patient payments.

The diagram at the top of this page shows the whole path at a glance: the one-time setup band, then the per-visit sequence from eligibility check through documentation, superbill, submission, the payer's response, and finally payment or a patient invoice for the remainder.

Why it's built this way

Each stage gates the next on purpose. You can't superbill an undocumented visit, can't bill without a signed note, can't submit without a clearinghouse and enrollment. It feels like a lot of gates, but each one prevents a specific, expensive failure downstream — a claim going out before the work behind it exists, or without the codes a payer needs. When something stalls, the gate that's blocking you is usually pointing at exactly what's missing. Troubleshooting lists the common ones by symptom.