Get, correlate, and interpret 277CAs and ERAs

After you submit a professional, dental, or institutional claim, you may receive asynchronous 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA) responses.

If you submitted the claims through the API or UI, there are two steps to retrieve claim responses from Stedi:

1. Discover responses by polling for processed transactions or listening for event-driven webhooks.
2. Call Stedi APIs to retrieve processed responses from Stedi.

Once you have the responses, you can correlate them with the original claim and specific service lines.

If you're using a Stedi SFTP connection, you don't need to poll or call Stedi APIs to retrieve responses. Instead, you can download them from the from-stedi directory.

Generate test responses

You can send test claims that generate test 277CA and 835 ERA responses. This approach helps you validate your integration and ensure your claims workflow is working smoothly from end to end. Visit Test claims workflow for instructions.

Discover processed responses

When submitting claims through Stedi's APIs or UI, you can discover processed responses programmatically by either listening for webhooks or polling for transactions. All claim responses are also available in the Stedi portal.

Listen for webhooks

Instead of polling for transactions, you can set up webhooks that automatically send events for processed 277CAs and 835 ERAs to your endpoint. You can either create a single webhook for all inbound transactions or create a separate webhook for each transaction type.

These webhooks are triggered by the processing events Stedi emits after it successfully receives and processes a response from the payer or intermediary clearinghouse.

As these events are emitted, you can:

• Determine the transaction type from the x12.transactionSetIdentifier property: 277 (277CA) or 835 (ERA).
• Use either the transactionId to retrieve the transaction in JSON format or the fileExecutionId to retrieve the transaction in X12 EDI format. Visit Retrieve responses from Stedi for more information.

If your webhook doesn't respond within 5 seconds, Stedi marks that as a failure and then automatically retries up to 5 times. This can result in duplicate deliveries, so we strongly recommend implementing ways to manage duplicates delivered through webhooks.

Poll for transactions

Call the Poll Transactions endpoint to return a list of transactions in your Stedi account.

You must include the following information in the request:

• Your Stedi API key as the Authorization header.
• Either the startDateTime or pageToken query parameters. To retrieve a list of transactions after a specific date, use startDateTime. To retrieve the next page of transactions, use pageToken (you can find this value in the nextPageToken field in the response).

The following example shows an API call to retrieve transactions after a specific date:

  curl --request GET -L \
    --url https://core.us.stedi.com/2023-08-01/polling/transactions?startDateTime=2023-08-28T00:00:00Z \
    --header "Authorization: ${STEDI_API_KEY}"

Filter for 277CA and 835 ERA transactions

The response includes all transactions that have been sent or received, including all 837 claims you have submitted and all 277CA and 835 ERA responses you have received from payers. You must filter for transactions that match the following criteria:

• direction: INBOUND - This indicates that the transaction came from the payer or intermediary clearinghouse.
• x12.transactionSetIdentifier: 277 or 835

The following example shows a response containing a processed 277CA transaction:

For each matching transaction, extract the x12.transactionSetIdentifier type and either the transactionId or the fileExecutionId to use when mapping the data. You'll use the transactionId to retrieve the transaction in JSON format or the fileExecutionId to retrieve the transaction in X12 EDI format. Visit Retrieve responses from Stedi for more information.

Stedi does not allow you to delete transactions, so make sure you track which transaction and/or file execution IDs you've already processed.

Stedi portal

You can view processed claim responses from the Transactions page in the Stedi portal. Click on any transaction to view its details.

You can also access responses through the Related transactions tab of the original claim submission. The following example shows the Related transactions tab of a test claim submission, with links to the associated test 277CA and test 835 ERA responses.

Retrieve responses from Stedi

You can retrieve the 277CA and 835 ERA responses from Stedi in either JSON format or X12 EDI format.

JSON format

Follow these steps to retrieve responses in JSON format:

1. Either set up webhooks to listen for transaction processed events or poll for transactions. This step allows you to discover when a new 277CA or 835 ERA is ready for retrieval.
2. Retrieve the transaction ID from the configured webhook or the Poll Transactions response. This value is available in the transactionId property.
3. Call the following endpoints to retrieve 277CA and 835 ERA responses from Stedi. In each request, you must include your Stedi API key in the Authorization header and the transactionId query parameter containing the ID of the transaction you want to retrieve.
   • Get 277CA Report: Retrieve 277CA responses
   • Get 835 ERA Report: Retrieve 835 ERA responses

X12 EDI format

Follow these steps to retrieve the responses in X12 EDI format:

1. Either set up webhooks to listen for transaction processed events or poll for transactions. This step allows you to discover when a new 277CA or 835 ERA is ready for retrieval.
2. Retrieve the file execution ID from the configured webhook or the Poll Transactions response. This value is available in the fileExecutionId property.
3. Call the Retrieve File Execution Input endpoint to retrieve the 277CA or 835 ERA in X12 EDI format. In the request, you must include your Stedi API key in the Authorization header and the executionId query parameter containing the file execution ID for the response you want to retrieve. You can find this value on the file's details page in the Stedi portal.

835 ERA PDF

Stedi autogenerates a PDF version of each processed 835 ERA. To download the PDF from the Stedi portal:

1. Go to the Transactions page.
2. Click the 835 ERA transaction you want to download.
3. On the Overview tab, click Download 835 ERA PDF.

You can also retrieve the PDF programmatically by calling the 835 ERA PDF endpoint.

The PDF contains a human-readable version of the ERA, including payment details, adjustments, and explanations for each service line. It resembles the Standard Paper Remittance (SPR) format that the Centers for Medicare and Medicaid Services (CMS) uses for ERA PDFs, regardless of which payer sent the ERA.

This is a PDF representation of the 835 ERA - it's not the same as an Explanation of Benefits (EOB) that you may receive from the payer.

• EOB: A statement from a payer explaining how a medical claim was processed, including what was covered, denied, and the remaining patient responsibility. The patient receives an EOB after a claim has been adjudicated.
• EOP: A version of the EOB for the provider. It contains more information related to how the payer has adjudicated the claim. The provider receives the EOP after claim adjudication and payment are sent.
• ERA: An electronic file that details payment and claim adjustment information. The provider receives the ERA after the payer has adjudicated the claim and issued payment, typically at the same time the funds are deposited electronically.

Determine 277CA sender

You can determine whether a 277CA is from a clearinghouse or the payer from the transactions[].payers[] array in the report (Loop 2100A).

The organizationName property contains the name of the sender (for example, CIGNA or STEDI). This is Loop 2100A NM103 (Information Source Name) in X12 EDI.

This information is also available at the top of the 277CA's transaction details page in the Stedi portal. The From and Entity type fields indicate whether the report is from Stedi or the payer.

Correlate 277CA

Use the following properties to correlate the 277CA with the original claim.

Entire Claim

Option 1: Patient Control Number

You can use the claim's claimInformation.patientControlNumber, if you provided one in the claim submission.

It's returned in two locations in the 277CA's transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails.claims[].claimStatus object:

• patientAccountNumber
• referencedTransactionTraceNumber

You can use either of these properties to correlate the 277CA with the original claim, but we recommend using the referencedTransactionTraceNumber.

Some payers batch acknowledgments for multiple claims into a single 277CA. In these cases, the 277CA will contain multiple patientClaimStatusDetails objects, each with its own referencedTransactionTraceNumber.

Option 2: Stedi's Correlation ID

If you didn't supply a patient control number, you can use the tracking number Stedi assigns to the claim when it's submitted. It's returned as the claimReference.correlationId property in the claim submission response.

In the 277CA, it's returned in the transactions[].payers[].claimStatusTransactions[].claimTransactionBatchNumber property.

Service line

Different claim types use different names for the same identifier:

• For professional and dental claims, use claimInformation.serviceLines.providerControlNumber.
• For institutional claims, use claimInformation.serviceLines.lineItemControlNumber.

This identifier is sometimes returned as the transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails.claims[].serviceLines[].lineItemControlNumber in the 277CA. It's not always present because a 277CA only contains a serviceLines object when the claim was rejected because of issues with the information provided for the service line. If the lineItemControlNumber isn't present, you can only correlate the 277CA at the claim level.

The following example shows a serviceLines object for a rejected claim containing the lineItemControlNumber property.

Interpret 277CA claim status

The 277CA response helps you understand whether a claim was accepted or rejected. These statuses don't indicate whether the claim was or will be approved or denied, only whether it was accepted or rejected for processing.

Status overview

For a high-level overview of the claim's acceptance/rejection status, examine the following array: transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].serviceProviderClaimStatuses.

This array typically only includes basic status information like "accepted for processing" or "denied". It's helpful for quickly determining the overall status of the claim. The following example shows a providerClaimStatuses object indicating that the claim was accepted for processing.

"providerClaimStatuses": [
  {
    "providerStatuses": [
      {
        "healthCareClaimStatusCategoryCode": "A1",
        "healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Receipt - The claim/encounter has been received. This does not mean that the claim has been accepted for adjudication.",
        "statusCode": "20",
        "statusCodeValue": "Accepted for processing."
      }
    ],
    "statusInformationEffectiveDate": "20240702"
  }
]

Status details

For more detailed acceptance and rejection information for the entire claim, examine the following array: transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails[].claims[].claimStatus.

This array contains more detailed information about acceptance or rejection, including:

• Payer-specific rejection reasons
• Claim charge amount details
• The patientControlNumber from the claim (returned as patientAccountNumber)

The following example shows a claimStatus object indicating that the claim was rejected as unprocessable due to missing or invalid information.

"claimStatus": {
  "claimServiceBeginDate": "20250101",
  "claimServiceEndDate": "20250109",
  "clearinghouseTraceNumber": "NA",
  "informationClaimStatuses": [
    {
      "informationStatuses": [
        {
          "healthCareClaimStatusCategoryCode": "A3",
          "healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Returned as unprocessable claim - The claim/encounter has been rejected and has not been entered into the adjudication system.",
          "statusCode": "21",
          "statusCodeValue": "Missing or invalid information."
        }
      ],
      "statusInformationEffectiveDate": "20250201",
      "totalClaimChargeAmount": "3459.3"
    }
  ],
  "patientAccountNumber": "AAA11111",
  "referencedTransactionTraceNumber": "AAA11111"
}

Not all payers send detailed accepted and rejection data for individual service lines. When available, this information will be in the following array: transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails[].claims[].serviceLines[].serviceClaimStatuses.

This can help you better identify the errors that caused the rejection. The following example shows a serviceClaimStatuses object from the same claim indicating that the service line was rejected as unprocessable and highlights the subscriber's member ID. Combined with the previous example, this indicates that the claim was rejected due to a missing or invalid member ID.

"serviceClaimStatuses": [
  {
    "serviceStatuses": [
      {
        "entityIdentifierCode": "IL",
        "entityIdentifierCodeValue": "Insured or Subscriber",
        "healthCareClaimStatusCategoryCode": "A3",
        "healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Returned as unprocessable claim - The claim/encounter has been rejected and has not been entered into the adjudication system.",
        "statusCode": "164",
        "statusCodeValue": "Entity's contract/member number."
      }
    ]
  }
]

Correlate 835 ERA

Use the following properties to correlate the 835 ERA with the original claim.

Sometimes, payers send duplicate ERAs for the same claim. You should have logic in place to identify and manage these duplicates.

Entire claim

Use the claim's claimInformation.patientControlNumber. It's returned as the transactions[].detailInfo[].paymentInfo[].claimPaymentInfo.patientControlNumber in the 835 ERA.

Service line

Different claim types use different names for the same identifier:

• For professional and dental claims, use claimInformation.serviceLines.providerControlNumber.
• For institutional claims, use claimInformation.serviceLines.lineItemControlNumber.

This identifier is always returned as the transactions[].detailInfo[].paymentInfo[].serviceLines[].lineItemControlNumber in the 835 ERA.

Duplicate ERAs

Payers typically only send one ERA per claim. However, they may occasionally retransmit another identical 835 ERA, so you should have logic in place to handle these duplicates.

You can assume an ERA is a duplicate if the Check or EFT Trace Number is the same. This is the transactions[].paymentAndRemitReassociationDetails.checkOrEFTTraceNumber property in a processed 835 ERA from Stedi. In X12 EDI, this is available in segment TRN (Reassociation Trace Number), element TRN02 (Check or EFT Trace Number).

Crossover claims

A claim is called a crossover claim when it is adjudicated by one payer and then forwarded to another payer for additional processing. This is common in coordination of benefits (COB) situations, where a patient has multiple insurance policies. For example, a patient may have coverage through both Medicare and private supplemental insurance. Once Medicare adjudicates the claim, it "crosses over" electronically to the secondary payer. This process helps reduce paperwork for providers and ensures the patient is billed correctly for any remaining balance.

You'll know a claim has been sent to a crossover payer when you receive an 835 ERA with the transactions.detailInfo.paymentInfo.claimPaymentInfo.claimStatusCode property set to either 19, 20, or 21. The ERA should also include information about the crossover payer in the transactions.detailInfo.paymentInfo.crossoverCarrier object.

Sometimes, the different payers are separate legal entities within the same parent corporation. If not, you'll need to enroll the provider separately with the crossover payer before they can process the claim. The payer may pause claim processing until the enrollment is complete or reject the claim. If the claim is rejected, you'll need to manually resubmit it once the enrollment is live. Stedi support can help you determine when you need to enroll with a crossover payer and determine the status of crossover claims while the enrollment is in progress.

You may receive an additional 835 ERA and/or 277CAs from the crossover payer. You may also be able to use the information from any 277CAs to submit real-time claim status requests for the crossover claim.