Daily Billing Command Center & Claim-Flow Reconciliation

Almost every unusable revenue cycle report fails on a counting question, not a technology question. Settle these eleven definitions in writing before you publish a single daily number.

Claim vs transmission attempt

A claim is identified by its unique claim ID together with the payer sequence (primary, secondary, tertiary). A transmission attempt is identified by the version or submission ID of that claim. One claim can have many transmission attempts. Count claims when you are describing work or inventory; count transmission attempts when you are describing traffic to a payer.

Units of measure are not interchangeable

Claims, claim lines, edit flags, encounters, patient accounts, and human touches are five different units. A claim with four blocking flags is one edited claim and four flags. An account can carry several claims; an encounter can generate professional and facility claims separately. Always state the unit on the report itself.

System throughput vs human output

Batch-generated claims belong to system throughput. Credit a person only for work with a documented audit trail — a resolved edit, a corrected rejection, a completed review. Counting autonomous batch generation as staff output overstates capacity and hides real bottlenecks.

The stage chain

Clearing an edit is not transmission. Transmission is not payer acceptance. Acceptance is not payment. Each arrow is a separate measurement with its own timestamp, and skipping one produces a metric no one can defend.

Resubmissions

A corrected resubmission is a further attempt on an existing claim. It does not become a new initial claim, and it must not re-enter the initial-submission denominator. Keep initial-claim cohorts and resubmission cohorts in separate reports.

Acknowledgment levels

A 999 or file-level acknowledgment tells you a file was structurally received. It is not claim-level payer acceptance. Claim-level acceptance comes from the payer 277CA or a documented equivalent claim status response. Where the payer channel does not produce one, say so on the report rather than inferring acceptance.

Pending is its own answer

A claim with no response yet is unknown, never assumed accepted. Report pending as a visible third bucket with the observation window used, and re-state the cohort once responses mature.

Rejection vs denial

A rejection happens before adjudication — the payer or clearinghouse refused the claim, and it typically never entered claim processing. A denial is an adjudicated determination on a claim the payer processed. They have different owners, different clocks, and different fixes. Mixing them makes both numbers meaningless.

Contractual adjustments are not denials

Routine contractual write-downs are the expected difference between charge and contracted rate. They are not denials and must never inflate denial dollars. This exclusion covers routine expected price reductions only — a CO group code can also accompany an actual denial, so classify by the specific adjustment reason rather than by the group code.

Segmentation is mandatory

Report professional and facility separately, primary and secondary separately, and segment by payer, service site, work queue, and complexity. An organization-wide single number hides the cohort that is actually failing.

Data mapping is local

Field names, report titles, and queue identifiers in your billing system, edit engine, and clearinghouse are local configuration. This toolkit names source categories, not vendor report names, because the correct mapping can only be confirmed in your own environment.

Most teams already say corrected claims, translated claims, DNFB, edit failure rate and clean claim rate. Those words are kept here on purpose. Each entry states what the term usually means and which measurement in this toolkit it maps to, so you can match a local report to a written definition instead of renaming everything.

Translated claims

Clearinghouse language for claims that passed structural translation into the payer format and were forwarded on. A translated claim is not an accepted claim and not a paid claim: claim-level acceptance still comes from the payer 277CA or a documented equivalent. Maps to first-submission payer acceptance.

Corrected claims

A claim that failed an edit, a front-end rejection or a denial and was fixed and resubmitted, usually with a resubmission or frequency code. It stays the same claim — it never re-enters the initial-submission denominator. Maps to rejection repair output, rejection turnaround and repeat rejection rate.

Clean claim rate / first-pass rate

The share of claims that leave the building with no blocking edit and are accepted by the payer on the first attempt. It is the inverse view of edit failure rate and initial rejection rate. State whether your version measures edits only, acceptance only, or both, because the three numbers differ.

Edit failure rate (scrubber hit rate)

The share of newly created claims that hit at least one blocking claim edit in the scrubber or edit engine. Say which severities are included: warning-only flags can inflate the incidence. Maps to initial edit incidence and edit flags per affected claim.

DNFB (discharged not final billed)

Accounts where the service or discharge has happened but the claim has not been finalized and billed. Commonly reported as DNFB days or DNFB dollars. Facility language, but the same idea applies to professional bill hold. Maps to billing lag.

DNSP / claims not submitted to payer

Finalized or near-finalized work that has still not reached the payer — the claim edit queue, the hold queue, unreleased batches. Reported separately from DNFB because the fix and the owner are different. Maps to edit backlog and aging.

Front-end rejection

A refusal by the clearinghouse or the payer before adjudication. It is not a denial, it has its own clock, and it is usually owned by billing rather than by appeals. Maps to first-submission payer acceptance and initial rejection rate.

Initial denial rate (first-pass denial rate)

The share of adjudicated claims — or adjudicated dollars — with a denial determination on first adjudication. Report by claim count and by dollars; the two rates answer different questions. Routine expected contractual price reductions are not denials.

Overturn rate / appeal win rate

The share of decided appeals resolved in the provider's favor, with the recovered dollars reported alongside. A low rate is a prompt to investigate evidence and filing quality, or correctly applied payer policy — not proof of either.

Timely filing and appeal deadlines

Payer-specific submission and appeal windows. Deadlines are payer and contract specific, so track the remaining days per claim from the payer's own current guidance rather than from a single organization-wide assumption.

Days in A/R (A/R days, DSO)

Net receivables divided by average daily net revenue. State the anchor date, whether credit balances are included, and the averaging window, because each choice moves the number. Maps to net days in A/R.

Aged A/R (over 90 / over 120)

The share of receivables past 90 or 120 days from the stated aging anchor. Segment by payer and financial class; a single organization-wide percentage hides the cohort actually failing. Maps to A/R over 90 and over 120 days.

Unapplied / suspense cash

Money received but not yet posted to accounts. It overstates A/R and understates cash at the same time. Maps to unposted cash.

Cost to collect (CTC)

Revenue cycle operating cost as a percent of net revenue collected. Only comparable when the cost scope — which departments, vendors and systems are inside it — is written down and stable. Maps to cost to collect.

COB / secondary billing

Coordination of benefits work: billing the next payer after the primary remittance posts. Measured from primary posting to secondary transmission, not from date of service. Maps to secondary billing lag.

999 vs 277CA

A 999 acknowledges that a file was structurally received. A 277CA is the claim-level acceptance or rejection response. Treating a 999 as acceptance is one of the most common measurement errors in daily reporting.

Touches / first-pass resolution

How many separate human actions a claim needed before it resolved. First-pass resolution is the inverse view: resolved on one touch. Count only substantive actions on the same resolved-claim cohort as the denominator.

Denial write-offs (avoidable write-offs)

Balances written off because a denial was never overturned, reported as a share of net patient service revenue. Routine contractual write-downs are excluded — but a contractual group code can accompany a real denial, so classify by the specific adjustment reason.

These are source categories, not report names. Your billing system, edit engine, and clearinghouse expose them under local configuration, and the correct mapping can only be confirmed in your own environment.

Billing creation and status history

Claim creation timestamps, status transitions, version history, ready-to-bill markers.

Edit queue and audit records

Blocking vs warning flags, assignment, resolution timestamps, user audit trail, escalation notes.

Clearinghouse submission and acknowledgment logs

File-level submission records, structural acknowledgments, front-end rejection detail.

Payer responses

Claim-level acceptance and rejection responses, claim status inquiries, payer portal determinations.

Adjudication remittance (835)

Adjudicated line detail, adjustment reason and remark codes, paid and denied amounts.

A/R aging

Debit and credit balances by age band, aging anchor date, payer and financial class.

Finance general ledger

Net patient service revenue, cash posted, write-off classifications, operating expense scope.

Authorized adjustments

Approved cancellations, denial write-offs, and other adjustments with approval evidence.

Time and quality records

Paid hours, locally defined non-task time, audited quality samples, rework records.

If the identity does not balance, the panel is wrong and the meeting is about data, not operations. Use the same queue boundary for every movement. Count each movement event once in its proper category; a claim entering and completing on the same day appears once in inflow and once in outflow. Reopened work is a new inflow event, not a new original claim.

• Every metric definition in this toolkit is original ClaimetryX work, written to be adoptable as a local operational definition.
• No external text is reproduced. External references are cited for framework and terminology context only.
• All numbers in examples are arithmetic illustrations and are labelled SYNTHETIC or illustrative. There are no live organizational figures, no national benchmarks, and no source claims beyond the cited references.
• The productivity task times are hypothetical assumptions used to demonstrate the capacity formula. They are not measured data from any organization or survey.
• General workflow guidance on remittance linking, secondary validation, and distinguishing printing from actual billing and payer acceptance is original and vendor-neutral. No proprietary vendor manual, screenshot, or report name is reproduced.
• This is a reference toolkit, not connected analytics. It reads no organizational system and holds no regulatory validation.

• HFMA MAP Keys

  Used only as a standardized KPI definition framework. Using any MAP figure as an exact benchmark requires the published inclusions and exclusions for that key. Where our definition differs, it is explicitly labelled as a ClaimetryX local operational definition.

• HFMA — Standardizing denial metrics

  Used for denial terminology and measurement alignment concepts only.

• CMS Medicare Claims Processing Manual — Transmittal 2346

  Cited narrowly as a 2011 historical reference for the acknowledgment framework, specifically that a 999 is a transaction-level acknowledgment and is not claim-level acceptance, which is conveyed by the 277CA. Current payer companion guides govern implementation.

• MGMA — Foundational benchmarks and KPIs for medical practice operations

  Used for practice KPI and peer-comparison context only. It does not support the hypothetical task times in this toolkit, which are arithmetic assumptions.