Changelog

Claim edit: Missing attachment control number

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that indicate an attachment was or will be sent by mail, electronically, email, fax, or file transfer – but don’t include an attachment control number.

Some payers require supporting documents, such as X-rays or treatment plans, before approving claims for certain services. Depending on the payer, you can send attachments in several ways, including by mail or electronically using a 275 claim attachment transaction through Stedi.

When a claim indicates that an attachment was or will be sent by mail, electronically, email, fax, or file transfer, you must include an attachment control number. The payer uses this value to match the attachment to the claim.

Payers may reject claims missing this number, which can cause delays.

This edit – the industry’s term for an automated validation rule – catches the issue before it reaches the payer.

This edit only applies when the claim indicates that an attachment was or will be sent. If the claim does not reference an attachment, this edit does not run.

**Rejection errors
**If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Attachment control number is required when attachment is sent by mail, electronically, email, fax, or file transfer",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Claim edit: Missing initial treatment date for Medicare chiropractic claims

Stedi now rejects 837P professional claims that are billed to Medicare Part B for chiropractic services when the initial treatment date is missing.

Medicare requires chiropractic claims to include the initial treatment date. CMS defines this as the first date the chiropractor provided active treatment for the current episode. If that date is missing, the Medicare Administrative Contractor (MAC) payer will reject the claim, causing delays.

This edit – the industry’s term for an automated validation rule – catches the issue before the claim reaches the MAC.

**When this edit applies
**A claim will fail this edit when all of the following are true:

• The claim is billed to a MAC payer.

• The claim includes a service line with one of the following Chiropractic Manipulative Treatment (CMT) procedure codes: 98940, 98941, or 98942.

• The claim is missing the initial treatment date.

  • In raw X12, this is indicated by a date with qualifier 454 (Initial Treatment) in DTP01 (Date - Initial Treatment Date) of Loop 2300 (Claim Information).

  • In the JSON professional claims submission endpoint, you can provide this in the initialTreatmentDate field.

  • In the professional claim form, enter the date in Box 15 – Other date with a Qualifier of 454 (Initial Treatment). 

**Rejection errors
**If you submit a claim that fails the edit using Stedi’s professional claims submission API endpoints or professional claim form, you’ll get back an error message in real time. If you’re using the JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "An initial treatment date is required when the chiropractic service, 98940, is submitted to Medicare. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Claim edit: Missing patient date of birth or gender

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that are missing the patient’s date of birth or gender.

Payers use the patient’s date of birth and gender to match the claim to the correct patient record. If either field is missing, the payer will reject the claim, which can cause delays.

This new edit – the industry's term for an automated validation rule – catches the issue before the claim ever reaches the payer.

**Patient vs. subscriber vs. dependent
**In a health insurance claim, there are three distinct roles:

• The subscriber is the person who holds the insurance policy. They’re also called the insured, the primary policyholder, or the primary cardholder.

• A dependent is someone covered under the subscriber’s plan, such as a spouse or child.

• The patient can be either the subscriber or a dependent, depending on who received care.

For example, if a child receives dental care, the child is the patient even though the parent is the subscriber.

Claims must include the patient’s date of birth and gender – not just the subscriber’s – so the payer can identify the correct person.

**How the edit works
**A claim can include information for both the subscriber and the dependent, if applicable. You only include the dependent’s information if the dependent is the one who received care and the dependent doesn’t have their own member ID.

As part of the edit, Stedi checks the patient’s information to ensure the claim includes the patient's date of birth and gender:

• If the subscriber is the patient: The edit requires the subscriber’s date of birth and gender.

• If the dependent is the patient: The edit requires the dependent’s date of birth and gender and ignores the subscriber's date of birth and gender.

If the patient’s date of birth or gender is missing, Stedi rejects the claim so you can correct and resubmit it before it reaches the payer.

**Rejection errors
**If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes an error in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The patient's date of birth and gender are both missing. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Introducing automatic enrollment requests for failed CMS eligibility checks

Note: This feature was previously called "CMS automatic enrollment." For more information on the name change, see this changelog entry.

The Centers for Medicare and Medicaid Services (CMS) requires that providers complete transaction enrollment to run eligibility checks through Stedi or other clearinghouses.

When an eligibility check to CMS fails with AAA error 41 – meaning the provider isn’t enrolled with CMS for eligibility transactions – Stedi now automatically submits the required transaction enrollment request.

With this change, Stedi customers no longer need to track down and submit missing enrollments when a Medicare eligibility check fails. Stedi now handles that work for you. This reduces your operational overhead and helps ensure future Medicare checks will succeed.

For more information, see the related announcement blog.

Introducing SFTP support for multi-claim 837 transactions in X12

You can now submit multiple claims in a single 837 transaction set using X12 over SFTP. 837P professional, 837D dental, and 837I institutional claims are supported.

Some billing platforms create a single 837 transaction set (one ST/SE segment) that includes multiple claims from different billing providers or patients. The transaction set may include claims for different payers. To deliver the claims to the correct payer, the X12 must be split into separate 837 transactions.

Stedi automatically splits 837 transaction sets containing multiple claims at the Billing Provider (2000A), Subscriber (2000B), and Claim Information (2300) loops. Behind the scenes, Stedi creates separate 837 transactions for each claim and routes them to the payer independently. Multiple claims going to the same payer will also be split to maintain the same behavior across all 837 transactions.

For example, if your 837 transaction set has two billing providers (two 2000A loops), each with three subscribers (three 2000B loops), and two claims per subscriber (two 2300 loops), Stedi submits 12 separate claim transactions.

**Pricing
**Stedi charges for each split claim transaction. For example, if a transaction set would result in 12 claim transactions, you're billed for 12 claim submissions. For rates, see our pricing page or contact us.

Claim acknowledgments and ERAs
The Stedi portal’s Transactions page will only display one 837 transaction, representing the original X12 file, and you’ll receive a single 999 acknowledgment. However, 277CA claim acknowledgments – from Stedi and the payer – and 835 Electronic Remittance Advices (ERAs) will reference the split 837 claims. Stedi will also run claim edits on the split 837 claims to catch rejections early.

If you submit a batch X12 claim to the Stedi Test Payer (Payer ID: STEDITEST), each transaction receives its own mock 835 Electronic Remittance Advice (ERA).

Claim edit: COB claims must be balanced

Stedi now rejects secondary and tertiary 837P professional, 837D dental, and 837I institutional claims if the claim’s Coordination of Benefits (COB) amounts don’t balance.

When you submit a secondary or tertiary claim, you must include the payments and adjustments, like patient responsibility or disallowed amounts, from previous payers. These amounts must add up cleanly:

Total charges = All payments + All adjustments

This process is called Coordination of Benefits (COB) balancing.

If the numbers don’t match, the payer may reject the claim to avoid overpayment. This edit  – the industry term for an automated validation rule – catches the issue before it reaches the payer.

For more on COB balancing, see our How to balance COB claims guide.

**Rejection errors
**If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Coordination of Benefits (COB) balancing failed. The total charged amount of $140.00 does not equal the sum of the paid amount of $80.00 and all adjustment amounts of $35.00. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

**Resolution tip
**Double-check the payment and adjustment details from the previous payer’s Electric Remittance Advice (ERA), Explanation of Payment (EOP), or Explanation of Benefits (EOB). For help walking through the math, see How to balance COB claims.

Claim edit: Invalid billing provider ZIP Code

Stedi now rejects 837I institutional claims that include an invalid billing provider ZIP Code.

Institutional claims must include a full nine-digit ZIP Code – called a ZIP+4 – with no spaces or hyphens for the billing provider. For example: 100031502. If you don’t know the full ZIP+4, you can look it up using the USPS ZIP Code Lookup tool.

If you submit institutional claims through Stedi’s institutional claim submission JSON API endpoint, this ZIP Code is provided in the providers.address.postalCode field.

Payers reject claims that are missing a full ZIP+4 or that contain an invalid code, which can cause delays.

This edit – the industry’s term for an automated validation rule – prevents these claims from reaching the payer.

**Rejection errors
**If you submit a claim that fails the edit using Stedi’s institutional claim submission API, you’ll get back an error message in real time. If you’re using the JSON API endpoint, the response includes an error in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The Billing provider ZIP Code, 11113527, is invalid. ZIP Codes must be a nine-digit number with no spaces or hyphens. Correct and resubmit",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit an institutional claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Claim edit: Missing member ID

Stedi now rejects 837P professional and 837D dental claims that are missing the subscriber’s member ID when the subscriber is a person.

Payers use the subscriber’s member ID to identify the patient and verify eligibility. It’s typically printed on the subscriber’s insurance card. If it’s missing, the payer will reject the claim, which delays processing.

This new edit – an industry term for an automated validation rule – catches the issue before the claim ever reaches the payer.

**Rejection errors
**If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes an error in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The subscriber identification is missing. When the subscriber is a person, then the subscriber identifier (commonly member ID) is required. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

**Resolution tip
**Add the subscriber’s member ID and resubmit the claim. If you’re using Stedi’s JSON API endpoints, provide this value in the subscriber.memberID field.

Claim edit: Non-zero adjustment amounts

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims when an adjustment amount is zero.

In healthcare claims, an adjustment represents an amount that was written off, applied as patient responsibility, or previously paid by another payer. Adjustments can be applied at both the claim level and the service line level.

Payers expect adjustments in a claim to reflect a real dollar amount. A zero amount isn’t valid and will cause the claim to be rejected downstream, which can cause delays.

This new edit – an industry term for an automated validation rule – catches the issue before it reaches the payer. The edit ensures that no claim-level or line-level adjustment in a claim equals zero. If so, the claim fails the edit.

**Rejection errors
**If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Claim Adjustments at the Line-level (Segment CAS) contain one or more zero values. Segment CAS-03 represents the monetary amount for each adjustment, which must be greater than zero (0.00). Correct and resubmit",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

**Resolution tip
**Add the initial treatment date and resubmit the claim.

Claim edit: Total claim charges must equal line-level charges

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims when the total charge amount doesn’t equal the sum of the claim's service line charges.

Payers require these amounts to balance. If they don’t, the payer will reject the claim, which can cause delays. This edit – the industry’s term for an automated validation rule – catches the issue before it reaches the payer.

As part of the edit, we total up the line-level charges and compare them to the claim-level charge. A small rounding tolerance (±$0.01) is allowed. Anything outside that range fails the edit.

The edit applies to all claims, including Coordination of Benefits (COB) claims.

**Rejection errors
**If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Total claim charge amount ($110.20) does not equal the sum of all service line charge amounts ($109.20) for this claim. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

**Resolution tips
**Double-check that the claim-level charge and the sum of the line-level charges match. Most issues come from:

• Rounding or formatting errors. For example, using $100.005 instead of $100.00.

• Adding, removing, or editing service lines without updating the total.