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

Claim Adjustment Reason Code (CARC)

Claim status category code

Claim status code

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:

Real-time claim status checks

Real-time status checks are synchronous. With Stedi, you can run real-time claim status checks in three ways:

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:

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

Claim Adjustment Reason Code (CARC)

Claim status category code

Claim status code

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:

Real-time claim status checks

Real-time status checks are synchronous. With Stedi, you can run real-time claim status checks in three ways:

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:

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

Claim Adjustment Reason Code (CARC)

Claim status category code

Claim status code

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:

Real-time claim status checks

Real-time status checks are synchronous. With Stedi, you can run real-time claim status checks in three ways:

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:

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

Twitter
LinkedIn

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

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.

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.

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.