Get and correlate acknowledgments 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:
- Discover responses by polling for processed transactions or listening for event-driven webhooks.
- 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.
Response types
You can receive two types of responses after you submit a professional, institutional, or dental claim.
277CA claim acknowledgment
The 277CA indicates whether the claim was accepted or rejected and (if relevant) the reasons for rejection. Though it can contain claim status information, the 277CA is different from the synchronous 277 claim status response you receive after submitting a real-time claim status request.
You may receive multiple separate 277CAs for each claim you submit.
- You’ll receive the first 277CA from Stedi within about 30 minutes of submitting the claim. This 277CA may contain rejection message(s) and warnings, if applicable.
- You may receive additional 277CAs from intermediary clearinghouses.
- You’ll receive one or more 277CAs from the payer. Typically, there is one 277CA that indicates receipt of the claim and a second 277CA that contains summary counts of transactions received, information about accepted transactions, and details for rejected transactions.
Each 277CA typically correlates to one 837 claim. However, some payers may send a single 277CA that references multiple claims.
Determine sender
You can determine whether a 277CA is from a clearinghouse or the payer from the transactions.payers array in the report. The organizationName property contains the name of the sender (for example, CIGNA) and the identityIdentifierCodeValue contains either Clearinghouse or Payer.
This information is also available at the top of the 277CA’s transaction details page in the Stedi portal.
835 Electronic Remittance Advice (ERA)
The ERA contains details about payments for specific services and explanations for any adjustments or denials. The payer only sends ERAs for accepted claims. If a claim is rejected in a 277CA, there’s no adjudication or payment information to report.
Processing ERAs always requires transaction enrollment with the payer.
277CA claim status details
The 277CA response contains two main objects for claim status information:
-
informationClaimStatuses: This is the primary section to examine for detailed acceptance/rejection status of a claim. It contains information that would be useful to the submitter of the claim regarding acceptance/rejection, including:- Payer-specific rejection reasons
- Claim charge amount details
- The
patientControlNumberfrom the claim (returned aspatientAccountNumber) - All granular claim processing details
-
providerClaimStatuses: This section contains more generic information that would be useful to the provider regarding rejection/acceptance. It typically only includes basic status information like “accepted for processing” or “denied” without the granular information ininformationClaimStatuses.
Discover processed responses
You can discover processed responses by either listening for webhooks or polling for transactions.
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.
Example transaction processed event
Example transaction processed event
As these events are emitted, you can:
- Determine the transaction type from the
x12.transactionSetIdentifierproperty:277(277CA) or835(ERA). - Use either the
transactionIdto retrieve the transaction in JSON format or thefileExecutionIdto 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
Authorizationheader. - Either the
startDateTimeorpageTokenquery parameters. To retrieve a list of transactions after a specific date, usestartDateTime. To retrieve the next page of transactions, usepageToken(you can find this value in thenextPageTokenfield in the response).
The following example shows an API call to retrieve transactions after a specific date:
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:277or835
The following example shows a response containing a processed 277CA transaction:
Sample Poll Transactions response
Sample Poll Transactions response
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.
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:
- 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.
- Retrieve the transaction ID from the configured webhook or the Poll Transactions response. This value is available in the
transactionIdproperty. - 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
Authorizationheader and thetransactionIdquery 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:
- 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.
- Retrieve the file execution ID from the configured webhook or the Poll Transactions response. This value is available in the
fileExecutionIdproperty. - Call the Get 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
Authorizationheader and theexecutionIdquery parameter containing the file execution ID for the response you want to retrieve.
Correlate 277CA
Use the following properties to correlate the 277CA with the original claim.
Entire Claim
Use the claim’s claimInformation.patientControlNumber.
It’s returned in two locations in the 277CA’s transactions.payers.claimStatusTransactions.claimStatusDetails.patientClaimStatusDetails.claims.claimStatus object:
patientAccountNumberreferencedTransactionTraceNumber
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.
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.
The following example shows a serviceLines object for a rejected claim containing the lineItemControlNumber property.
Example serviceLines object from 277CA for rejected claim
Example serviceLines object from 277CA for rejected claim
Correlate 835 ERA
Use the following properties to correlate the 835 ERA with the original claim.
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.
Example serviceLines object from 835 ERA
Example serviceLines object from 835 ERA
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.crossoverClaim 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.
ERA code lists
You may need to refer to the following code lists while evaluating the 835 ERA. Note that this page doesn’t list all possible code lists, only those that are too long to properly represent within the API documentation.
Claim Adjustment Group Code
This code is returned in the transactions.detailInfo.paymentInfo.claimAdjustments.claimAdjustmentGroupCode property. It categorizes the adjustment reason codes returned in the claimAdjustments object.
Claim Adjustment Group Code list
Claim Adjustment Group Code list
CO- Contractual Obligations | The payer uses this code when a joint payer/payee contractual agreement or a regulatory requirement resulted in an adjustment. An example of a contractual obligation might be a Participating Provider Agreement.OA- Other adjustments | The payer uses this code when the adjustment doesn’t fall within the other categories.PI- Payor Initiated Reductions | The payer uses this code when, in their opinion, the adjustment is not the responsibility of the patient, but there is no supporting contract between the provider and the payer (i.e., medical review or professional review organization adjustments).PR- Patient Responsibility | The payer uses this code when the adjustment amount is the responsibility of the patient.
Claim Filing Indicator Code
This code is returned in the transactions.detailInfo.paymentInfo.claimPaymentInfo.claimFilingIndicatorCode property. It identifies the type of claim submitted.
Claim Filing Indicator Code list
Claim Filing Indicator Code list
12- Preferred Provider Organization (PPO) | This code is also used for Blue Cross/Blue Shield participating provider arrangements.13- Point of Service (POS)14- Exclusive Provider Organization (EPO)15- Indemnity Insurance | This code is also used for Blue Cross/Blue Shield non-participating provider arrangements.16- Health Maintenance Organization (HMO) Medicare Risk17- Dental Maintenance OrganizationAM- Automobile MedicalCH- ChampusDS- DisabilityHM- Health Maintenance OrganizationLM- Liability MedicalMA- Medicare Part AMB- Medicare Part BMC- MedicaidOF- Other Federal Program | This code is used for the Black Lung Program.TV- Title VVA- Veterans Affairs PlanWC- Workers’ Compensation Health ClaimZZ- Mutually Defined
Claim Status Code
This code is returned in the transactions.detailInfo.paymentInfo.claimPaymentInfo.claimStatusCode property. It identifies the status of an entire claim as assigned by the payer, claim review organization, or repricing organization.
Codes 19, 20, and 21 indicate that the claim is a crossover claim that has been forwarded to an additional payer for processing. This practice is common in coordination of benefits (COB) scenarios. You may need to enroll the provider with the additional payer before they can process the claim.
Claim Status Code list
Claim Status Code list
1- Processed as Primary | The payer uses this code when the claim was adjudicated by the current payer as primary regardless of whether any part of the claim was paid.2- Processed as Secondary | The payer uses this code when the claim was adjudicated by the current payer as secondary regardless of whether any part of the claim was paid.3- Processed as Tertiary | The payer uses this code when the claim was adjudicated by the current payer as tertiary (or subsequent) regardless of whether any part of the claim was paid.4- Denied | The payer uses this code when the Patient/Subscriber is not recognized, and the claim was not forwarded to another payer.19- Processed as Primary, Forwarded to Additional Payer(s)20- Processed as Secondary, Forwarded to Additional Payer(s)21- Processed as Tertiary, Forwarded to Additional Payer(s)22- Reversal of Previous Payment23- Not Our Claim, Forwarded to Additional Payer(s) | The payer sends this code when the patient/subscriber is not recognized or the claim was not adjudicated by the payer, but other payers are known and the claim has been forwarded to another payer.25- Predetermination Pricing Only - No Payment
Credit or Debit Flag Code
This code is returned in the transactions.financialInformation.creditOrDebitFlagCode property. It indicates whether the payment is a credit or a debit.
C- Credit | The payer uses this code to indicate a credit to the provider’s account and a debit to the payer’s account, initiated by the payer. In the case of an EFT, no additional action is required of the provider. The payer also uses this code when a check is issued for the payment.D- Debit | The payer uses this code to indicate a debit to the payer’s account and a credit to the provider’s account, initiated by the provider at the instruction of the payer.
Payment Method Code
This code is returned in the transactions.financialInformation.paymentMethodCode property. It identifies the payment format. Note that the remaining properties in the financialInformation object contain additional requirements and information about the payment.
Payment Method Code list
Payment Method Code list
ACH- Automated Clearing House (ACH) | The payer uses this code to move money electronically through the ACH, or to notify the provider that an ACH transfer was requested.BOP- Financial Institution Option | The payer uses this code to indicate that the third-party processor will choose the method of payment based upon endpoint requests or capabilities.CHK- Check | The payer uses this code to indicate that a check has been issued for payment.FWT- Federal Reserve Funds/Wire Transfer - Nonrepetitive | The payer uses this code to indicate that the funds were sent through the wire system.NON- Non-Payment Data | The payer uses this code when thetransactions.financialInformation.transactionHandlingCodeisH, indicating that this is information only and no dollars are to be moved.
Transaction Handling Code
This code is returned in the transactions.financialInformation.transactionHandlingCode property. It indicates the actions taken by both the sender and the receiver.
Transaction Handling Code list
Transaction Handling Code list
C- Payment Accompanies Remittance Advice | The payer uses this code to instruct the third-party processor to move funds and remittance details together through the banking system.D- Make Payment Only | The payer uses this code to instruct the third-party processor to move only funds through the banking system and to ignore any remittance information.H- Notification Only | The payer uses this code when the actual provider payment (listed in thetransactions.financialInformation.totalActualProviderPaymentAmountproperty) is zero, and the transaction is not being used for Prenotification of Future Transfers. This indicates remittance information without any associated payment.I- Remittance Information Only | The payer uses this code to indicate to the payee that the remittance detail is moving separately from the payment.P- Prenotification of Future Transfers | This code is used only by the payer and the banking system to initially validate account numbers before beginning an EFT relationship.U- Split Payment and Remittance | The payer uses this code to instruct the third-party processor to split the payment and remittance details and send each on a separate path.X- Handling Party’s Option to Split Payment and Remittance | The payer uses this code to instruct the third-party processor to move the payment and remittance detail, together or separately, based upon endpoint requests or capabilities.