Transaction History
Use the Transaction History page for additional visibility into how payments are posted across all charges for the claim, including a timeline view and details by procedure code.
Note: The current release is only for non-CHC (Community Health Center) customers, and only includes the following scenarios:
- Claims fully paid by the primary or secondary payer (Billed amount = Paid amount)
- Claims with primary or secondary payer adjustments, transfers, denials
- Claims with posting rules that transform the claim
-
Go to the Claim Edit page or the Visit & Claim Update page for a specific claim. (Refer to Claim Edit or User Guide — Visit & Claim Update in O-help for detailed steps to get to those pages.)
Note: The NEW Transaction History link only appears if the claim fits one of these scenarios:
- Claims fully paid by the primary or secondary payer (Billed amount = Paid amount)
- Claims with primary or secondary payer adjustments, transfers, denials
- Claims with posting rules that transform the claim
- On the Visit & Claim Update page, the link will be to the right of the existing Transaction History section header.
- On the Claim Edit page, the link will be in the existing Charges section.
-
Click the NEW Transaction History link.
- The Transaction History page opens in a separate window.
- The new page will not affect the existing Transaction History or any other information on the Claim Edit and Visit & Claim Update page. You will still have uninterrupted access to both the Claim Edit and Visit & Claim Update pages.
You can access this page if you have access to the Claim Edit page and Visit & Claim Update page.
Use the new Transaction History page for better visibility and insight into how payments are posted across charges.
- View posting at a summary level or detail level
- See the timeline of claim events from initial billing to the most recent remittance (ERA/EOB) received from payers, in chronological order
- See all transactions grouped by payer ERAs/EOBs, for a clearer picture of transactions and remittances
-
View denials tags in the Transaction Overview; view denial codes and descriptions in the Transaction Details by Charge
-
View Electronic Remittance Advice (ERA) source data in ANSI X12 835 format
Tip: Click the image to see an expanded view
Important:
-
The current functionality includes primary and secondary payer transactions (payment, adjustment and transfer, denials, posting rules)
-
This enhancement currently does not support claim editing activities such as voiding claims, moving or updating charges, and viewing voided charges.
-
We plan to add more posting scenarios in upcoming releases.
| athenaOne release date | Type of transaction | Additional details |
|---|---|---|
| March2025 |
|
|
| March 2026 |
|
Watch a demo video: |
| July 2026 |
|
| Section | Description/ Image |
|---|---|
|
Welcome information (first time access) |
The first time you access the Transaction History page, a Welcome to the New Transaction Historypop-up window will automatically appear.
|
|
Page banner |
Information at the top of the page:
|
|
Transactions Overview |
Consolidated view of how transactions were posted across all charges for the claim.
Tip: Click the image to see an expanded view
|
|
Transaction Detail by Charge |
Posting details for the individual charges (procedure codes):
Tip: If the number of charges exceeds 7, the menu will change from radio buttons to a drop-down menu.
Tip: Click the image to see an expanded view
|
In the Transaction Overview:
-
Sequestration adjustment amounts are listed as a separate Transaction Type for better visibility.
In the Transaction Details by Charge:
- You can view payer remark codes and their descriptions in this section without navigating through the payer remittance.
About posting rules
Posting rules are written by athenahealth to allow more accurate transaction and denial posting. athenahealth normally posts according to the remittance information; however, in some situations, a literal interpretation of the remittance data will lead to inaccurate posting. A posting rule overrides the literal interpretation so that the correct transaction or denial is reflected on the claim.
In the Transaction History page > Transaction Details by Charge:
- The TRANSFORMED tag indicates a posting rule was applied to a charge.
- View posting rule explanation/details directly from the Transaction view, for insight into how the rule impacted the charge.
Note: All posting rule details are still captured in claim notes.
- If a posting rule (global, practice-specific, or code-based) directly transforms or impacts the transaction data on the claim, it will also appear in Transaction Details for visibility, in addition to the claim notes.
Tip: Click the image to see an expanded view
Note: The Posting Rule Summary is generated by AI and provides a high-level overview of the rule's logic. While it provides a quick understanding of the rule's purpose and conditions, it may not encompass all detailed or complex aspects of the rule logic.
Electronic Remittance Advice (ERA) source data is the raw payment and claim details sent by the insurance payer in ANSI X12 835 format, including amounts paid, adjustments, and reason codes.
It is the original, unprocessed data used to understand how a claim was paid or denied.
On the Transaction History page, you can find ERA source data in the timeline events in both sections of the page:
- Transaction Overview
- Transaction Details by Charge
Example: Transaction Details by Charge > ERA source data
Tip: Click the image to see an expanded view.
You can view the ERA source data in two formats:
- Formatted — User readable format
- Raw — ANSI X12 format
Example: Transaction Details by Charge > ERA source data (Formatted | Raw)
Tip: Click the image to see an expanded view.
| Transaction Overview | |
|---|---|
|
Overview — Timeline Displays the sequence of claim events in chronological order, from the time it was billed to the remittance received from the payer(s) |
|
| Billed events |
Each billed event in the timeline includes:
|
| ERA events |
Each ERA event in the timeline includes:
Note: The ERA event also serves as an anchor grouping the transactions received in the ERA or by payment batches from the same payer. This ensures clear visual hierarchy and understandable view of the billing process. |
| Overview — Table of transactions | |
| Transaction Type |
|
|
Claim |
The total transaction amount, which is the sum of all individual charge amounts and payment amounts |
| CPT <code, modifier> | The transaction amount for each specific CPT code/modifier |
| Transaction Details by Charge | |
| Procedure code |
The first charge in the claim is selected by default. Select any other individual charge (Procedure code) to view details for that charge:
|
|
Transaction Details by Charge — Timeline Displays the sequence of claim events in chronological order, from the time it was billed to the remittance received from the payer(s) |
|
| Transaction Details by Charge — Table of transactions | |
| Transaction Type |
|
|
Primary Insurance, Secondary Insurance, Patient |
View the transaction amounts received from each insurance and the patient. |
| Claim Billing Events | |
|
Billing batches / Remit Received (from legacy page) |
|
| Bills mailed |
View the billing batch through which claim sets were submitted to the insurance company. |
| Remits Received |
Provides details on the number of remittances received from the insurance company (whether primary, secondary, or patient) along with their dates and full remittance information for easy access. |
| Posting Rules | |
| Rule ID | A unique identifier assigned to each rule, helping to easily track, reference, and manage individual rules within the system. |
| Rule Name | A descriptive title of the rule, summarizing its purpose. |
| Rule Overview | |
| What kind of rule is this? | A description of posting rules. |
| Who does it apply to? | A list of which Payers the rule applies to. |
| Why is this done? | A brief description of the purpose of the rule. |
| What does the rule do? |
A summary of the rule, describing what the rule does, the business process it supports, and the conditions under which it activates. |







