The insurance aging report in athenaOne tells you what is outstanding and how long it has been aging. What it does not tell you is the procedure code on each line, the denial reason code, or how much the payer allowed versus billed. For that level of detail, you need a different export: the claim-level or service-line billing data pulled from the ERA/Remittance or Claim Activity reports in athenaOne. This guide covers where that data lives, how to get it out, and how to use it for denial analysis and underpayment detection.
Claim-level vs. aging: the distinction that matters
The aging report operates at the balance level: dollars outstanding, bucketed by age. Claim-level data operates at the transaction level: what was billed, what was allowed, what was paid, and why the payer adjusted it. These are two separate layers in athenaOne, and most practices only ever pull the aging layer. The result is they know money is sitting in AR but cannot efficiently triage it without manually looking up each claim.
The ERA (835) file is where the claim-level detail actually lives. When a payer processes a claim and sends an 835 electronic remittance, every service line in that transaction carries the procedure code, the submitted charge, the allowed amount, the paid amount, and the Claim Adjustment Reason Code (CARC) plus Remittance Advice Remark Code (RARC) explaining any reduction or denial. athenaOne processes these ERA files automatically and stores the data; the job is getting it back out in a usable format.
Where to pull claim-level data in athenaOne
Two reports in athenaOne give you service-line billing detail:
- ERA/Remittance Advice report (sometimes labeled Electronic Remittance or Remittance Posting): This is the primary source for CARC and RARC codes. It surfaces the data athenaOne received from the 835 transaction for each claim. Navigate to Analytics or Reports, look under Billing or Revenue Cycle, and search for "remittance" or "ERA." Some athenaOne configurations call this "Remittance Transactions."
- Claim Activity report (sometimes "Claim Transactions"): This shows the full transaction history for a claim, including all submission, adjudication, and payment events over time. Useful when a claim has been through multiple submission cycles and you need to reconstruct what happened.
For denial management at scale, the ERA/Remittance report is the right tool. The Claim Activity report is better for investigating the history of a specific claim.
Export settings that matter
- Service-line detail, not claim summary. Most athenaOne ERA reports let you choose between a claim-level summary (one row per claim) and a service-line detail (one row per procedure line). Always choose service-line detail. A claim summary masks silent denials entirely: a claim that partially paid will show as paid at the claim level even if individual lines were denied.
- Date range. Use the ERA posting date rather than the service date when you want to see what remittances arrived in a specific window. Use the service date when you want to trace all adjudication activity for a specific encounter period.
- Payer filter. Apply one payer or payer group per export. The full-book ERA file for a busy practice will exceed row limits and produce files that are slow to analyze.
- Format. Export as CSV. The date and numeric formatting in the CSV is more predictable for downstream analysis than the Excel export from athenaOne.
What the export includes
A well-configured athenaOne ERA export at the service-line level gives you these key columns for each procedure line:
- Claim ID and Service Line Number: the join keys for linking to other reports.
- CPT/HCPCS code and modifier: what was billed for that line.
- Submitted charge, allowed amount, paid amount: the three-column arithmetic that tells you whether the payer paid correctly.
- CARC (Claim Adjustment Reason Code): the primary denial or adjustment code explaining why the line was adjusted. CO-45 (charge exceeds allowed), CO-97 (bundling), CO-4 (modifier issue), and CO-50 (medical necessity) are the most common.
- RARC (Remittance Advice Remark Code): the secondary code that often carries the specific explanation behind the CARC, such as the specific modifier required or the coverage limitation triggered.
- Patient name, payer, and plan: routing information for the appeal or dispute workflow.
Using the data to find denial patterns
The value of pulling service-line data at scale is pattern detection. Sort the export by CARC code, then by payer and CPT code. Three clusters are worth prioritizing immediately:
- CO-4 concentrated on one payer: a modifier configuration issue. Every claim in that stack has the same fix; submit corrected claims as a batch.
- CO-97 on a specific procedure pairing: a bundling edit the payer applies consistently. Worth checking whether a modifier override applies before appealing, rather than appealing each claim individually.
- CO-45 where allowed is below your contracted rate: an underpayment buried in a routine-looking adjustment. These claims posted as paid and closed; they will never appear in a denial queue. The only way to find them is the allowed-vs-contracted comparison in the claim-level data.
Combining claim-level data with aging
The complete denial management picture comes from joining the ERA export to the aging report on Claim ID. The aging report supplies the balance outstanding and the age bucket. The ERA export supplies the procedure code, CARC, and allowed amount. Together, they answer: how much is at risk, how long has it been sitting, and what is the specific reason code driving the balance.
In Excel or a database, do a VLOOKUP or JOIN on the Claim ID column. Sort the merged file by aging bucket (oldest first), then CARC code. This gives you a prioritized denial queue with the reason code already attached, so the biller does not need to look up each claim in the payer portal before starting work.
Handling large data sets in athenaOne
athenaOne's report engine queues large exports and notifies you when ready rather than blocking the browser. For practices billing several hundred or more claims per week, break exports by payer group and date range rather than running a single all-payer pull. This keeps individual files under the row limit and lets you analyze one payer's patterns without the noise of every other payer in the same sheet.
If your practice has access to athenaOne's raw data exports or the Marketplace API, those channels give you complete, unfiltered service-line data in a more reliable format than the UI-based report runner, which can time out on very large queries. Coordinate with your athenahealth account manager if UI exports are consistently failing for your volume.
The practical sequence
Pull the ERA/Remittance report at the service-line level, filtered by payer and date range. Join on Claim ID to your aging export. Sort by CARC and payer to surface patterns. Separate CO-45 underpayments from true denials before routing work. That sequence turns a raw data pull into an organized denial queue in one session, which is the starting point for any recovery effort that goes beyond the biggest, most obvious balances.