Differences between ERAs and real-time claim status checks
Jan 20, 2026
Guide
Both Electronic Remittance Advice (ERAs) and real-time claim status checks can tell you the current state of a claim, but they’re not interchangeable. Each provides different information, serves a different purpose, and is used at a different point in the claims lifecycle.
This guide covers how each transaction type differs at a high level and when to use each.
Differences at a glance
The following table outlines the major differences between ERAs and real-time claim status checks.
835 Electronic Remittance Advice (ERA) | 276/277 Real-time claim status check | |
Use case | Payment reconciliation – matching payments to claims | Claim tracking and visibility |
Claim-level information | ||
Line-item-level information | CARCs and optional Remittance Advice Remark Codes (RARCs) | Typically none (claim-level only) |
Payment information | Payment amounts Check/EFT numbers Patient responsibility | No payment information |
Transaction enrollment requirements | Always required. One clearinghouse per billing provider per payer. | Rarely required. Multiple clearinghouses allowed. |
Availability | Only after adjudication. | After acceptance and throughout the claim lifecycle |
Synchronous or asynchronous? | Asynchronous | Synchronous |
Typical response time | 7-20 business days after claim submission | 1-5 seconds |
Use cases
ERAs
An ERA acts as the receipt for one or more claims. It tells you what a payer paid to a provider – and why. It’s the electronic equivalent of an Explanation of Benefits (EOB) or Explanation of Payment (EOP).
ERAs have some important characteristics:
An ERA is tied to a payment, not a particular claim.
A single ERA can include information for multiple claims.
A single claim can appear across multiple ERAs – for example, if the claim is paid in installments.
Not every ERA maps to a claim. Payers also use them for things like bonus payments or value-based care adjustments.
Providers primarily use ERAs for payment reconciliation – the process that ensures payments, adjustments, and patient responsibility amounts are accurately reflected in their accounting systems.
Real-time claim status checks
A real-time claim status check is a synchronous request that returns the current status of one or more claims.
Conceptually, it’s the electronic equivalent of making a telephone call to a payer and asking:
“Where is this claim in the claim lifecycle?”
The difference is speed and automation. Instead of minutes on the phone, results come back in seconds. And you can run real-time claim status checks programmatically.
To run a real-time status check, you provide information for a related claim, such as patient details, provider identifiers, and service dates. Claim status responses indicate whether a claim has been received, rejected, pending, denied, or paid. The response may return statuses for multiple matching claims depending on the search criteria provided.
Transaction enrollment
Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions, like claims or ERAs, with a payer.
You can check a payer’s enrollment requirements for each transaction type and expected approval timelines in the Stedi Payer Network or using Stedi’s Payers API.
ERAs
Transaction enrollment is always required for ERAs.
A payer only sends ERAs to the healthcare clearinghouse – like Stedi – that the provider has enrolled with. A provider can only enroll to receive ERAs from the payer through one clearinghouse at a time. For example, if a provider receives ERAs from Cigna through Stedi, they can’t get those ERAs through another clearinghouse. For more information, see How payers route ERAs.
Real-time claim status checks
For transaction types other than ERAs, enrollment requirements vary by payer. Payers rarely require enrollment for claim status checks.
Unlike ERAs, you can run claim status checks using multiple clearinghouses at the same time.
Transaction processing
ERAs
Payers deliver ERAs asynchronously to the clearinghouse that the provider has enrolled to receive ERAs at.
If you receive ERAs at Stedi, you need a way to know when an ERA arrives and how to retrieve it. Stedi supports several options:
Webhooks and APIs
If you want to work with JSON, you can set up a Stedi webhook to listen for incoming ERAs, then retrieve the ERA using the ERA Report API endpoint.SFTP
If you already work with X12, you can download X12 versions of the ERAs from thefrom-stedidirectory using your Stedi SFTP connection.Stedi portal
You can download ERAs from the Stedi portal. You can also view related claims and acknowledgments handled through Stedi in the portal.
Real-time claim status checks
Real-time status checks are synchronous. With Stedi, you can run real-time claim status checks in three ways:
JSON API
If you want to work in JSON, you can use our JSON Real-Time Claim Status API endpoint.X12 API
If you already work with X12, you can use our X12 Real-Time Claim Status API endpoint.Stedi portal
You can manually submit a real-time claim status request through the Create claim status check form in the Stedi portal.
Response times and availability
ERAs
Payers issue ERAs after claim adjudication – where the payer determines what they’ll pay for a claim.
A related ERA typically arrives 7-20 business days after you submit a claim. They’re preceded by a claim acknowledgment from the payer, which typically arrives within 2-7 days after claim submission.
There’s no way to programmatically request an ERA from a payer. Payers send them automatically. If you’ve enrolled to receive ERAs from a payer and haven’t received an ERA for a submitted claim after 21 days, you can use a real-time claim status check to confirm the claim has been received and adjudicated.
Real-time claim status checks
You can run a real-time claim status check any time after claim submission. Stedi typically returns check responses within 1-5 seconds.
In most cases, providers run real-time claim status checks when they haven’t received a claim acknowledgment or ERA from the provider within the above expected timeline.
Returned data
ERAs
In a claim, a service line is a row that describes billing for one specific service, procedure, or supply – for example, an office visit or a dental filling.
During adjudication, the payer may adjust or deny specific service lines. This lets them pay for some services while denying others, or pay a different amount than what was requested in the claim.
ERAs include Claim Adjustment Reason Codes (CARCs) that describe why a service line – or the entire claim – was paid the way it was. Remittance Advice Remark Codes (RARCs) provide additional details.
For example, a JSON 835 ERA Report response:
{ "transactions": [ { ... "detailInfo": [ { ... "paymentInfo": [ { ... "claimAdjustments": [ { ... "adjustmentReasonCode1": "161", // Claim-level Claim Adjustment Reason Code (CARC) for provider performance bonus "adjustmentReason1": "Provider performance bonus", ... "serviceLines": [ { ... "serviceAdjustments": [ { ... "adjustmentReasonCode1": "B12", // Line-item-level CARC for missing documentation "adjustmentReason1": "Services not documented in patient's medical records.", ... } ], ... "healthCareCheckRemarkCodes": [ { "codeListQualifierCode": "HE", // Indicates use of a Remittance Advice Remark Code (RARC) "codeListQualifierCodeValue": "Claim Payment Remark Codes", "remarkCode": "M30", // RARC for missing pathology report "remark": "Missing pathology report." } ], ... } ] } ] } ] ... } ] } ... ], ... }
In addition to information about specific service lines, the ERA contains financial information that’s important for payment reconciliation. For example, the ERA contains the check or Electronic Funds Transfer (EFT) number used for payment:
{ "transactions": [ { "financialInformation": { "checkIssueOrEFTEffectiveDate": "20190316", // Payment issue date "paymentMethodCode": "ACH", // EFT payment via ACH "totalActualProviderPaymentAmount": "1100", // Provider payment amount "creditOrDebitFlagCode": "C", // Credit ... }, "paymentAndRemitReassociationDetails": { "checkOrEFTTraceNumber": "71700666555", // EFT reference number ... }, ... } ], ... }
ERAs also contain patient responsibility information at both the claim and service line levels, including copays, deductibles, and coinsurance amounts. This information can help providers determine what they should collect from patients or refund. For example:
{ "transactions": [ { "detailInfo": [ { "paymentInfo": [ { "claimPaymentInfo": { "patientResponsibilityAmount": "300", // Claim-level patient responsibility amount ... }, ... }, ... ] } ], ... }, ... ], ... }
Real-time claim status checks
Real-time claim status check responses include two types of codes that describe the claim’s current status: a claim status category code and a claim status code.
The category code indicates the broad state of the claim, such as accepted, rejected, pending, or finalized. The claim status code is a more specific status for the claim. For a rejected or denied claim, claim status codes often indicate a reason for the rejection or denial.
Some claim status codes also require an entity identifier code that tells you who or what the claim status relates to.
Together, these codes show exactly where your claim stands with the payer. For example, in a JSON Real-Time Claim Status API response:
{ "claims": [ { "claimStatus": { "statusCategoryCode": "F1", // Finalized/Payment - The claim/line has been paid. "statusCode": "65", // Claim/line has been paid. ... }, ... } ], ... }
In most cases, claims status checks only provide claim-level status information, like the above claim status codes. Although supported, most payers don’t return line-item-level details in claim status checks.
Claim status checks never include detailed adjustment reason codes or denial explanations – even for fully adjudicated claims. For that level of detail, you need the ERA.
Correlate ERAs and claim status checks to claims
You can use the patient control number (PCN) to match an ERA or claim status check back to the original claim(s). For more information on PCNs and examples, see our How to track claims blog.
X12 transaction sets
HIPAA is a U.S. federal law that, among other things, requires that certain electronic healthcare transactions – including ERAs and claim status checks – use X12 EDI.
While Stedi supports X12 directly for both transaction types, most Stedi customers use our JSON APIs or the Stedi portal. In that case, we translate the transactions into the corresponding X12 for you.
ERAs
ERAs use the 835 Healthcare Claim Payment/Advice X12 transaction set.
Real-time claim status checks
Claim status checks use two underlying X12 transaction sets:
276 Claim Status Request for requests
277 Status Request Response for responses
Note: Claim acknowledgments use a different implementation of the 277 X12 transaction set, called the 277CA Claim Acknowledgment. While both indicate the claim’s status, there are major differences in the implementations. Claim acknowledgements and claim status checks serve different use cases. In most of these use cases, they’re not interchangeable.
Everyday usage
People often refer to a transaction type by its X12 transaction set. For example, you may hear people refer to an ERA as an “835.” Similarly, someone may refer to a claim status request as a “276” and a claim status response as a “277.”
Process ERAs and claim status checks with Stedi
Stedi’s Basic plan is free and includes 100 ERAs and real-time claim status checks each month.
Signup takes less than two minutes. No credit card is required.
Both Electronic Remittance Advice (ERAs) and real-time claim status checks can tell you the current state of a claim, but they’re not interchangeable. Each provides different information, serves a different purpose, and is used at a different point in the claims lifecycle.
This guide covers how each transaction type differs at a high level and when to use each.
Differences at a glance
The following table outlines the major differences between ERAs and real-time claim status checks.
835 Electronic Remittance Advice (ERA) | 276/277 Real-time claim status check | |
Use case | Payment reconciliation – matching payments to claims | Claim tracking and visibility |
Claim-level information | ||
Line-item-level information | CARCs and optional Remittance Advice Remark Codes (RARCs) | Typically none (claim-level only) |
Payment information | Payment amounts Check/EFT numbers Patient responsibility | No payment information |
Transaction enrollment requirements | Always required. One clearinghouse per billing provider per payer. | Rarely required. Multiple clearinghouses allowed. |
Availability | Only after adjudication. | After acceptance and throughout the claim lifecycle |
Synchronous or asynchronous? | Asynchronous | Synchronous |
Typical response time | 7-20 business days after claim submission | 1-5 seconds |
Use cases
ERAs
An ERA acts as the receipt for one or more claims. It tells you what a payer paid to a provider – and why. It’s the electronic equivalent of an Explanation of Benefits (EOB) or Explanation of Payment (EOP).
ERAs have some important characteristics:
An ERA is tied to a payment, not a particular claim.
A single ERA can include information for multiple claims.
A single claim can appear across multiple ERAs – for example, if the claim is paid in installments.
Not every ERA maps to a claim. Payers also use them for things like bonus payments or value-based care adjustments.
Providers primarily use ERAs for payment reconciliation – the process that ensures payments, adjustments, and patient responsibility amounts are accurately reflected in their accounting systems.
Real-time claim status checks
A real-time claim status check is a synchronous request that returns the current status of one or more claims.
Conceptually, it’s the electronic equivalent of making a telephone call to a payer and asking:
“Where is this claim in the claim lifecycle?”
The difference is speed and automation. Instead of minutes on the phone, results come back in seconds. And you can run real-time claim status checks programmatically.
To run a real-time status check, you provide information for a related claim, such as patient details, provider identifiers, and service dates. Claim status responses indicate whether a claim has been received, rejected, pending, denied, or paid. The response may return statuses for multiple matching claims depending on the search criteria provided.
Transaction enrollment
Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions, like claims or ERAs, with a payer.
You can check a payer’s enrollment requirements for each transaction type and expected approval timelines in the Stedi Payer Network or using Stedi’s Payers API.
ERAs
Transaction enrollment is always required for ERAs.
A payer only sends ERAs to the healthcare clearinghouse – like Stedi – that the provider has enrolled with. A provider can only enroll to receive ERAs from the payer through one clearinghouse at a time. For example, if a provider receives ERAs from Cigna through Stedi, they can’t get those ERAs through another clearinghouse. For more information, see How payers route ERAs.
Real-time claim status checks
For transaction types other than ERAs, enrollment requirements vary by payer. Payers rarely require enrollment for claim status checks.
Unlike ERAs, you can run claim status checks using multiple clearinghouses at the same time.
Transaction processing
ERAs
Payers deliver ERAs asynchronously to the clearinghouse that the provider has enrolled to receive ERAs at.
If you receive ERAs at Stedi, you need a way to know when an ERA arrives and how to retrieve it. Stedi supports several options:
Webhooks and APIs
If you want to work with JSON, you can set up a Stedi webhook to listen for incoming ERAs, then retrieve the ERA using the ERA Report API endpoint.SFTP
If you already work with X12, you can download X12 versions of the ERAs from thefrom-stedidirectory using your Stedi SFTP connection.Stedi portal
You can download ERAs from the Stedi portal. You can also view related claims and acknowledgments handled through Stedi in the portal.
Real-time claim status checks
Real-time status checks are synchronous. With Stedi, you can run real-time claim status checks in three ways:
JSON API
If you want to work in JSON, you can use our JSON Real-Time Claim Status API endpoint.X12 API
If you already work with X12, you can use our X12 Real-Time Claim Status API endpoint.Stedi portal
You can manually submit a real-time claim status request through the Create claim status check form in the Stedi portal.
Response times and availability
ERAs
Payers issue ERAs after claim adjudication – where the payer determines what they’ll pay for a claim.
A related ERA typically arrives 7-20 business days after you submit a claim. They’re preceded by a claim acknowledgment from the payer, which typically arrives within 2-7 days after claim submission.
There’s no way to programmatically request an ERA from a payer. Payers send them automatically. If you’ve enrolled to receive ERAs from a payer and haven’t received an ERA for a submitted claim after 21 days, you can use a real-time claim status check to confirm the claim has been received and adjudicated.
Real-time claim status checks
You can run a real-time claim status check any time after claim submission. Stedi typically returns check responses within 1-5 seconds.
In most cases, providers run real-time claim status checks when they haven’t received a claim acknowledgment or ERA from the provider within the above expected timeline.
Returned data
ERAs
In a claim, a service line is a row that describes billing for one specific service, procedure, or supply – for example, an office visit or a dental filling.
During adjudication, the payer may adjust or deny specific service lines. This lets them pay for some services while denying others, or pay a different amount than what was requested in the claim.
ERAs include Claim Adjustment Reason Codes (CARCs) that describe why a service line – or the entire claim – was paid the way it was. Remittance Advice Remark Codes (RARCs) provide additional details.
For example, a JSON 835 ERA Report response:
{ "transactions": [ { ... "detailInfo": [ { ... "paymentInfo": [ { ... "claimAdjustments": [ { ... "adjustmentReasonCode1": "161", // Claim-level Claim Adjustment Reason Code (CARC) for provider performance bonus "adjustmentReason1": "Provider performance bonus", ... "serviceLines": [ { ... "serviceAdjustments": [ { ... "adjustmentReasonCode1": "B12", // Line-item-level CARC for missing documentation "adjustmentReason1": "Services not documented in patient's medical records.", ... } ], ... "healthCareCheckRemarkCodes": [ { "codeListQualifierCode": "HE", // Indicates use of a Remittance Advice Remark Code (RARC) "codeListQualifierCodeValue": "Claim Payment Remark Codes", "remarkCode": "M30", // RARC for missing pathology report "remark": "Missing pathology report." } ], ... } ] } ] } ] ... } ] } ... ], ... }
In addition to information about specific service lines, the ERA contains financial information that’s important for payment reconciliation. For example, the ERA contains the check or Electronic Funds Transfer (EFT) number used for payment:
{ "transactions": [ { "financialInformation": { "checkIssueOrEFTEffectiveDate": "20190316", // Payment issue date "paymentMethodCode": "ACH", // EFT payment via ACH "totalActualProviderPaymentAmount": "1100", // Provider payment amount "creditOrDebitFlagCode": "C", // Credit ... }, "paymentAndRemitReassociationDetails": { "checkOrEFTTraceNumber": "71700666555", // EFT reference number ... }, ... } ], ... }
ERAs also contain patient responsibility information at both the claim and service line levels, including copays, deductibles, and coinsurance amounts. This information can help providers determine what they should collect from patients or refund. For example:
{ "transactions": [ { "detailInfo": [ { "paymentInfo": [ { "claimPaymentInfo": { "patientResponsibilityAmount": "300", // Claim-level patient responsibility amount ... }, ... }, ... ] } ], ... }, ... ], ... }
Real-time claim status checks
Real-time claim status check responses include two types of codes that describe the claim’s current status: a claim status category code and a claim status code.
The category code indicates the broad state of the claim, such as accepted, rejected, pending, or finalized. The claim status code is a more specific status for the claim. For a rejected or denied claim, claim status codes often indicate a reason for the rejection or denial.
Some claim status codes also require an entity identifier code that tells you who or what the claim status relates to.
Together, these codes show exactly where your claim stands with the payer. For example, in a JSON Real-Time Claim Status API response:
{ "claims": [ { "claimStatus": { "statusCategoryCode": "F1", // Finalized/Payment - The claim/line has been paid. "statusCode": "65", // Claim/line has been paid. ... }, ... } ], ... }
In most cases, claims status checks only provide claim-level status information, like the above claim status codes. Although supported, most payers don’t return line-item-level details in claim status checks.
Claim status checks never include detailed adjustment reason codes or denial explanations – even for fully adjudicated claims. For that level of detail, you need the ERA.
Correlate ERAs and claim status checks to claims
You can use the patient control number (PCN) to match an ERA or claim status check back to the original claim(s). For more information on PCNs and examples, see our How to track claims blog.
X12 transaction sets
HIPAA is a U.S. federal law that, among other things, requires that certain electronic healthcare transactions – including ERAs and claim status checks – use X12 EDI.
While Stedi supports X12 directly for both transaction types, most Stedi customers use our JSON APIs or the Stedi portal. In that case, we translate the transactions into the corresponding X12 for you.
ERAs
ERAs use the 835 Healthcare Claim Payment/Advice X12 transaction set.
Real-time claim status checks
Claim status checks use two underlying X12 transaction sets:
276 Claim Status Request for requests
277 Status Request Response for responses
Note: Claim acknowledgments use a different implementation of the 277 X12 transaction set, called the 277CA Claim Acknowledgment. While both indicate the claim’s status, there are major differences in the implementations. Claim acknowledgements and claim status checks serve different use cases. In most of these use cases, they’re not interchangeable.
Everyday usage
People often refer to a transaction type by its X12 transaction set. For example, you may hear people refer to an ERA as an “835.” Similarly, someone may refer to a claim status request as a “276” and a claim status response as a “277.”
Process ERAs and claim status checks with Stedi
Stedi’s Basic plan is free and includes 100 ERAs and real-time claim status checks each month.
Signup takes less than two minutes. No credit card is required.
Both Electronic Remittance Advice (ERAs) and real-time claim status checks can tell you the current state of a claim, but they’re not interchangeable. Each provides different information, serves a different purpose, and is used at a different point in the claims lifecycle.
This guide covers how each transaction type differs at a high level and when to use each.
Differences at a glance
The following table outlines the major differences between ERAs and real-time claim status checks.
835 Electronic Remittance Advice (ERA) | 276/277 Real-time claim status check | |
Use case | Payment reconciliation – matching payments to claims | Claim tracking and visibility |
Claim-level information | ||
Line-item-level information | CARCs and optional Remittance Advice Remark Codes (RARCs) | Typically none (claim-level only) |
Payment information | Payment amounts Check/EFT numbers Patient responsibility | No payment information |
Transaction enrollment requirements | Always required. One clearinghouse per billing provider per payer. | Rarely required. Multiple clearinghouses allowed. |
Availability | Only after adjudication. | After acceptance and throughout the claim lifecycle |
Synchronous or asynchronous? | Asynchronous | Synchronous |
Typical response time | 7-20 business days after claim submission | 1-5 seconds |
Use cases
ERAs
An ERA acts as the receipt for one or more claims. It tells you what a payer paid to a provider – and why. It’s the electronic equivalent of an Explanation of Benefits (EOB) or Explanation of Payment (EOP).
ERAs have some important characteristics:
An ERA is tied to a payment, not a particular claim.
A single ERA can include information for multiple claims.
A single claim can appear across multiple ERAs – for example, if the claim is paid in installments.
Not every ERA maps to a claim. Payers also use them for things like bonus payments or value-based care adjustments.
Providers primarily use ERAs for payment reconciliation – the process that ensures payments, adjustments, and patient responsibility amounts are accurately reflected in their accounting systems.
Real-time claim status checks
A real-time claim status check is a synchronous request that returns the current status of one or more claims.
Conceptually, it’s the electronic equivalent of making a telephone call to a payer and asking:
“Where is this claim in the claim lifecycle?”
The difference is speed and automation. Instead of minutes on the phone, results come back in seconds. And you can run real-time claim status checks programmatically.
To run a real-time status check, you provide information for a related claim, such as patient details, provider identifiers, and service dates. Claim status responses indicate whether a claim has been received, rejected, pending, denied, or paid. The response may return statuses for multiple matching claims depending on the search criteria provided.
Transaction enrollment
Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions, like claims or ERAs, with a payer.
You can check a payer’s enrollment requirements for each transaction type and expected approval timelines in the Stedi Payer Network or using Stedi’s Payers API.
ERAs
Transaction enrollment is always required for ERAs.
A payer only sends ERAs to the healthcare clearinghouse – like Stedi – that the provider has enrolled with. A provider can only enroll to receive ERAs from the payer through one clearinghouse at a time. For example, if a provider receives ERAs from Cigna through Stedi, they can’t get those ERAs through another clearinghouse. For more information, see How payers route ERAs.
Real-time claim status checks
For transaction types other than ERAs, enrollment requirements vary by payer. Payers rarely require enrollment for claim status checks.
Unlike ERAs, you can run claim status checks using multiple clearinghouses at the same time.
Transaction processing
ERAs
Payers deliver ERAs asynchronously to the clearinghouse that the provider has enrolled to receive ERAs at.
If you receive ERAs at Stedi, you need a way to know when an ERA arrives and how to retrieve it. Stedi supports several options:
Webhooks and APIs
If you want to work with JSON, you can set up a Stedi webhook to listen for incoming ERAs, then retrieve the ERA using the ERA Report API endpoint.SFTP
If you already work with X12, you can download X12 versions of the ERAs from thefrom-stedidirectory using your Stedi SFTP connection.Stedi portal
You can download ERAs from the Stedi portal. You can also view related claims and acknowledgments handled through Stedi in the portal.
Real-time claim status checks
Real-time status checks are synchronous. With Stedi, you can run real-time claim status checks in three ways:
JSON API
If you want to work in JSON, you can use our JSON Real-Time Claim Status API endpoint.X12 API
If you already work with X12, you can use our X12 Real-Time Claim Status API endpoint.Stedi portal
You can manually submit a real-time claim status request through the Create claim status check form in the Stedi portal.
Response times and availability
ERAs
Payers issue ERAs after claim adjudication – where the payer determines what they’ll pay for a claim.
A related ERA typically arrives 7-20 business days after you submit a claim. They’re preceded by a claim acknowledgment from the payer, which typically arrives within 2-7 days after claim submission.
There’s no way to programmatically request an ERA from a payer. Payers send them automatically. If you’ve enrolled to receive ERAs from a payer and haven’t received an ERA for a submitted claim after 21 days, you can use a real-time claim status check to confirm the claim has been received and adjudicated.
Real-time claim status checks
You can run a real-time claim status check any time after claim submission. Stedi typically returns check responses within 1-5 seconds.
In most cases, providers run real-time claim status checks when they haven’t received a claim acknowledgment or ERA from the provider within the above expected timeline.
Returned data
ERAs
In a claim, a service line is a row that describes billing for one specific service, procedure, or supply – for example, an office visit or a dental filling.
During adjudication, the payer may adjust or deny specific service lines. This lets them pay for some services while denying others, or pay a different amount than what was requested in the claim.
ERAs include Claim Adjustment Reason Codes (CARCs) that describe why a service line – or the entire claim – was paid the way it was. Remittance Advice Remark Codes (RARCs) provide additional details.
For example, a JSON 835 ERA Report response:
{ "transactions": [ { ... "detailInfo": [ { ... "paymentInfo": [ { ... "claimAdjustments": [ { ... "adjustmentReasonCode1": "161", // Claim-level Claim Adjustment Reason Code (CARC) for provider performance bonus "adjustmentReason1": "Provider performance bonus", ... "serviceLines": [ { ... "serviceAdjustments": [ { ... "adjustmentReasonCode1": "B12", // Line-item-level CARC for missing documentation "adjustmentReason1": "Services not documented in patient's medical records.", ... } ], ... "healthCareCheckRemarkCodes": [ { "codeListQualifierCode": "HE", // Indicates use of a Remittance Advice Remark Code (RARC) "codeListQualifierCodeValue": "Claim Payment Remark Codes", "remarkCode": "M30", // RARC for missing pathology report "remark": "Missing pathology report." } ], ... } ] } ] } ] ... } ] } ... ], ... }
In addition to information about specific service lines, the ERA contains financial information that’s important for payment reconciliation. For example, the ERA contains the check or Electronic Funds Transfer (EFT) number used for payment:
{ "transactions": [ { "financialInformation": { "checkIssueOrEFTEffectiveDate": "20190316", // Payment issue date "paymentMethodCode": "ACH", // EFT payment via ACH "totalActualProviderPaymentAmount": "1100", // Provider payment amount "creditOrDebitFlagCode": "C", // Credit ... }, "paymentAndRemitReassociationDetails": { "checkOrEFTTraceNumber": "71700666555", // EFT reference number ... }, ... } ], ... }
ERAs also contain patient responsibility information at both the claim and service line levels, including copays, deductibles, and coinsurance amounts. This information can help providers determine what they should collect from patients or refund. For example:
{ "transactions": [ { "detailInfo": [ { "paymentInfo": [ { "claimPaymentInfo": { "patientResponsibilityAmount": "300", // Claim-level patient responsibility amount ... }, ... }, ... ] } ], ... }, ... ], ... }
Real-time claim status checks
Real-time claim status check responses include two types of codes that describe the claim’s current status: a claim status category code and a claim status code.
The category code indicates the broad state of the claim, such as accepted, rejected, pending, or finalized. The claim status code is a more specific status for the claim. For a rejected or denied claim, claim status codes often indicate a reason for the rejection or denial.
Some claim status codes also require an entity identifier code that tells you who or what the claim status relates to.
Together, these codes show exactly where your claim stands with the payer. For example, in a JSON Real-Time Claim Status API response:
{ "claims": [ { "claimStatus": { "statusCategoryCode": "F1", // Finalized/Payment - The claim/line has been paid. "statusCode": "65", // Claim/line has been paid. ... }, ... } ], ... }
In most cases, claims status checks only provide claim-level status information, like the above claim status codes. Although supported, most payers don’t return line-item-level details in claim status checks.
Claim status checks never include detailed adjustment reason codes or denial explanations – even for fully adjudicated claims. For that level of detail, you need the ERA.
Correlate ERAs and claim status checks to claims
You can use the patient control number (PCN) to match an ERA or claim status check back to the original claim(s). For more information on PCNs and examples, see our How to track claims blog.
X12 transaction sets
HIPAA is a U.S. federal law that, among other things, requires that certain electronic healthcare transactions – including ERAs and claim status checks – use X12 EDI.
While Stedi supports X12 directly for both transaction types, most Stedi customers use our JSON APIs or the Stedi portal. In that case, we translate the transactions into the corresponding X12 for you.
ERAs
ERAs use the 835 Healthcare Claim Payment/Advice X12 transaction set.
Real-time claim status checks
Claim status checks use two underlying X12 transaction sets:
276 Claim Status Request for requests
277 Status Request Response for responses
Note: Claim acknowledgments use a different implementation of the 277 X12 transaction set, called the 277CA Claim Acknowledgment. While both indicate the claim’s status, there are major differences in the implementations. Claim acknowledgements and claim status checks serve different use cases. In most of these use cases, they’re not interchangeable.
Everyday usage
People often refer to a transaction type by its X12 transaction set. For example, you may hear people refer to an ERA as an “835.” Similarly, someone may refer to a claim status request as a “276” and a claim status response as a “277.”
Process ERAs and claim status checks with Stedi
Stedi’s Basic plan is free and includes 100 ERAs and real-time claim status checks each month.
Signup takes less than two minutes. No credit card is required.
Share
Get started with Stedi
Get started with Stedi
Automate healthcare transactions with developer-friendly APIs that support thousands of payers. Contact us to learn more and speak to the team.
Get updates on what’s new at Stedi
Get updates on what’s new at Stedi
Get updates on what’s new at Stedi
Developers
Resources
Backed by
Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.
Developers
Resources
Backed by
Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.
Developers
Resources
Get updates on what’s new at Stedi
Backed by
Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.
