Skip to main content
ERA charge-level adjustment records with HDB practice, provider, and appointment cross-references applied. Each row represents one charge-level adjustment within an ERA. This table’s columns and relationships are shown in the Hosted Database schema.
Read this before totaling any money column. One row is one adjustment line, but the money columns are recorded at three different levels of granularity, so adding them up without reducing to the right level double-counts.Duplication at both levels is common rather than exceptional: a large share of charges carry more than one adjustment line, and a meaningful minority are adjudicated in more than one ERA. Summing charge_paid or charge_amount straight off the table can therefore overstate them by close to 2x. The example queries below all reduce to the correct level first.
For reporting on but not limited to:
  • Adjustment totals by payer, practice, or service date
  • Denial rates and denial reasons by CPT code
  • How long payers take to remit, by payer or practice
  • Per-appointment revenue when joined to the appointment table
  • Per-provider revenue, by provider_npi
  • Drill-down on a specific claim or charge
Two payment-date columns sit on this table and they answer different questions.
  • era_payment_date is the date the payer remitted this ERA. Use this one to measure payer payment timing. It is null when Elation Billing holds no posted payment for the ERA.
  • claim_latest_payment_date is the date of the most recent payment of any kind on the claim, patient payments taken at the time of service included. It is claim-level rather than charge-level, so the same value repeats across every row of the same claim.
Because claim_latest_payment_date spans every payment source, it can fall later than era_payment_date. On a small share of rows it falls earlier, where Elation Billing records no transaction tying this ERA’s payment to the claim.
Each row carries a match_confidence column that grades the appointment-id inference. Filter to match_confidence = 'provider_match' for high-trust per-provider analytics. The provider_mismatch class is common in practices that bill incident-to (charges file under a supervising physician while visits are scheduled under the rendering NP or PA), and the appointment_id on those rows points at the supervisor’s appointment rather than the rendering visit. patient_practice_date_only and no_match rows have a null appointment_id.

Charges and adjustments for a date range

Pulls every charge-level adjustment row for a given service-date window with the per-row financials and payer detail.

Practice-level totals over a period

Rolls up charges, adjustments, and totals per practice and payer for a given service-date window. Useful for AR snapshots and payer-mix analysis. The era_charge step reduces each charge to one row per ERA, which is the level the payer figures are recorded at. Because the query splits by payer, a charge adjudicated by both a primary and a secondary payer contributes to each of them, so total_charged_to_payer reads as the amount presented to that payer rather than a count of distinct money billed. Use the per-provider query below when you want each charge counted once.

Payer remittance timing

Measures how long each payer takes to remit, from date of service to the date the payer paid. This uses era_payment_date, the payer’s own remittance date. Using claim_latest_payment_date here would understate the lag wherever a patient co-pay was collected at the visit, because that column takes the latest payment of any kind on the claim. The era_charge step applies here too, even though this query totals no money. Both dates in the lag are fixed for a given charge and ERA, so averaging over raw rows would weight each charge by its number of adjustment lines. Reducing first makes avg_days_to_remit the mean lag per charge adjudicated, matching the charges count beside it.

Per-appointment revenue

Joins ERA rows to the appointment that produced them. Filters to provider_match so each appointment’s totals reflect a confident link to the rendering provider’s visit. Two reduction steps run before the totals are taken: era_charge collapses the adjustment lines of each charge, then charge collapses the ERAs so each charge is counted once. charge_paid is summed across ERAs, because a primary and a secondary payer each contribute money; charge_amount is taken once, because it describes the charge.

Per-provider revenue

Attributes charges to the billing provider. ERA rows identify the provider by NPI, so the join to canonical_physician goes through npi rather than an id. Uses the same two reduction steps as the per-appointment query, so each charge is counted once no matter how many adjustment lines or ERAs it carries. The join is a LEFT join on purpose. Not every NPI on an ERA belongs to a physician in your own records, since claims can be billed under organizational or external NPIs. provider_name and specialty are null on those rows, while provider_npi is still populated.

Single-claim drill-down

Returns every ERA line for one claim, ordered by service date and charge.

CPT denial breakdown

Identifies the procedure codes most often denied, with the dominant adjustment reason for each.
If you have any questions about this topic please reach out to Elation Support Portal with the subject line HDB - <your_question>