Changelog

Introducing paper claim submissions

You can now submit paper claims through Stedi.

Some payers don't accept electronic claims. Payers may also require paper claims for workers’ compensation, automobile, or liability-related claims.

Until now, you had to print and mail those paper claims yourself. That meant running a separate manual process outside your electronic claims workflow.

With paper claim submission, you submit through the same workflows as electronic claims: API, SFTP, or the Stedi portal. Stedi prints the claim and mails it to the payer for you.

Supported claim types

You can submit two claim types for printing and mailing:

How paper claims work

To submit a paper claim:

• Set the receiver ID – the ID for the entity receiving the transaction – to PAPER ("Print and Mail – All Payers"). If using the Stedi portal UI's CMS-1500 Claim Form, select By mail under Send instead.

• Set the payer ID, payer name, and payer address to the payer you’d like to mail the claim to.

• Fill out the rest of the claim as usual.

Transaction enrollment isn't required for paper claims.

For more detailed examples and instructions, see our documentation.

Pricing and availability

Paper claim submission is available on all Stedi production accounts.

Stedi charges for paper claims based on the number of printed and mailed pages. The number of pages varies based on the claim’s type and service line count:

A claim spills onto additional pages when its service lines exceed what one form holds. For example, a professional claim (CMS-1500 form) with 10 service lines requires 2 pages.

See stedi.com/pricing for per-page pricing.

Learn more

For more details, see our announcement blog and documentation.

Claim edit: Invalid CLIA number format

Stedi now rejects 837P professional claims that report a Clinical Laboratory Improvement Amendments (CLIA) number in an invalid format.

What is a CLIA number?

A Clinical Laboratory Improvement Amendments (CLIA) number identifies a lab authorized to test human specimens. CLIA is a federal laboratory regulatory program administered by the Centers for Medicare & Medicaid Services (CMS) and applies to the operation of the laboratory. Medicare and Medicaid claims that bill for lab services require this number. Most other payers have the same requirement.

You can specify CLIA numbers at the claim level or on individual service lines.

Claim-level CLIA number

Line-level CLIA number

How the edit works

Each CLIA number is 10 characters with a fixed NNDNNNNNNN format: a two-digit state code, the literal D, then a seven-digit facility and check identifier.

If one or more CLIA numbers in a professional claim don’t follow this format, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid CLIA Number. A valid CLIA number must be 10 characters with position 1-2 being the numeric state code, position 3 must be 'D', and positions 4-10 must also be numeric. The submitted value, 45X2167451, is not valid. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>544*[DATE]*U*[AMOUNT]********Invalid CLIA Number. A valid CLIA number must be 10 characters with position 1-2 being the numeric state code, position 3 must be 'D', and positions 4-10 must also be numeric. The submitted value, 45X2167451, is not valid. Correct and resubmit.~

Claim edit: Invalid email format

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include an invalid email address.

How the edit works

A claim can include email addresses for different contacts, such as the submitter, billing provider, subscriber, or patient.

To be valid, an email address must start with a local name, followed by the @ symbol, followed by a domain. For example: johndoe@example.com. A value such as johndoe example.com is invalid; it’s missing the @ symbol.

When a claim contains an email address with an invalid format, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Email Address. A valid email address must include a local name, an \"@\" symbol, and a domain (name@example.com). Submitted email address for Submitter is invalid, johndoe example.com. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, entity identifier code, and error message:

STC*A7>127>41*[DATE]*U*[AMOUNT]********Invalid Email Address. A valid email address must include a local name, an "@" symbol, and a domain (name@example.com). Submitted email address for Submitter is invalid, johndoe example.com. Correct and resubmit.~

Claim edit: Missing revenue code

Stedi now rejects 837I institutional claims that are missing a revenue code on a service line.

What are revenue codes?

Revenue codes are standardized 4-digit codes that hospitals and other care facilities use to group charges into billable categories, such as the type of room, service, or supply billed. Example revenue codes include:

• 0450 – Emergency Room

• 0360 – Operating Room Services

• 0300 – Laboratory

Revenue code

How the edit works

Every service line on an institutional claim must report a revenue code. Payers use the revenue code to classify the service line, price the claim, and validate the services billed. If a service line is missing a revenue code, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Revenue Code. A revenue code is required for each service line on institutional claims. Line 1 is missing a revenue code. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A6>455*[DATE]*U*[AMOUNT]********Missing Revenue Code. A revenue code is required for each service line on institutional claims. Line 1 is missing a revenue code. Correct and resubmit.~

Related claim edits

Stedi has another edit that validates the format of a revenue code. See Invalid revenue code.

Claim edit: Social Security Number with an unassigned area number

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain a Social Security Number (SSN) with an unassigned area number.

How the edit works

A claim can include a Social Security Number (SSN) for the billing provider, subscriber, patient, or other subscriber.

The first three digits of an SSN are the area number. The Social Security Administration (SSA) never issues an SSN whose area number is 000, 666, or in the 900-999 range, which is reserved for IRS Individual Taxpayer Identification Numbers (ITINs).

An SSN with one of these area numbers can't be valid, so it won't match any record at the payer. If a claim includes an SSN with an unassigned area number, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Social Security Number (SSN). The submitted SSN for Subscriber, 900123456, has an unassigned area number. The first 3 digits cannot be 000, 666, or in the 900-999 range. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, entity identifier code, and error message:

STC*A7>148>HK*[DATE]*U*[AMOUNT]********Invalid Social Security Number (SSN). The submitted SSN for Subscriber, 900123456, has an unassigned area number. The first 3 digits cannot be 000, 666, or in the 900-999 range. Correct and resubmit.~

Claim edit: Symptom onset date matches a service date

Stedi now rejects 837P professional claims where the symptom onset date matches a service date.

How the edit works

In a professional claim, the onset of current illness or symptom date, also called the symptom onset date, is when the patient first experienced symptoms of the illness or condition being treated. This date helps payers establish a clinical timeline to support coverage determinations and medical necessity reviews.

The symptom onset date is situational. Submitters only report it when it's relevant to a service line in the claim. It should differ from any service dates on the claim. If the symptom onset date matches a service date, omit it.

Symptom onset date

X12 standards state that the symptom onset date must differ from the date of service, also called the service date, for any service line in a claim.

Service date

If the symptom onset date matches a service date – or falls within a service date range – the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Onset of Current Illness date. The onset of illness/symptom date must be different from the service date, 20240301. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>397*[DATE]*U*[AMOUNT]******A7>187**Invalid Onset of Current Illness date. The onset of illness/symptom date must be different from the service date, 20240301. Correct and resubmit.~

Resolution tip

When the symptom onset date is the same as a service date in a claim, omit it and report only the service date.

Claim edit: Duplicate condition codes in institutional claims

Stedi now rejects 837I institutional claims that include the same condition code more than once within a single condition code group.

How the edit works

In institutional claims, condition codes report situations that can affect how a payer adjudicates – or determines how to pay – a claim.

For example, condition code 02 means the condition is employment-related. Code 17 means the patient is homeless. Condition codes are defined by the National Uniform Billing Committee (NUBC).

A claim can contain up to two groups of condition codes. Each group can contain up to 12 codes.

Condition code

The NUBC states that each condition code must be unique within a single group. If a claim includes the same condition code more than once within a single group, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Condition Code(s). If submitting multiple condition codes, each code must be unique. The submitted condition code(s) are submitted more than once, 17. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>460*[DATE]*U*[AMOUNT]******A7>732**Invalid Condition Code(s). If submitting multiple condition codes, each code must be unique. The submitted condition code(s) are submitted more than once, 17. Correct and resubmit.~

Claim edit: Duplicate occurrence codes in institutional claims

Stedi now rejects 837I institutional claims that include the same occurrence code more than once within a single occurrence code group.

How the edit works

In institutional claims, occurrence codes report significant events in a patient's care. These codes can affect how much a payer will approve or pay for a claim or service.

For example, occurrence code 11 reports the onset of symptoms or illness. Code 42 reports the date of discharge. Occurrence codes are defined by the National Uniform Billing Committee (NUBC).

A claim can contain up to two groups of occurrence codes. Each group can contain up to 12 codes.

Occurrence code

The NUBC states that each occurrence code must be unique within a single group. If a claim includes the same occurrence code more than once within a single group, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Occurrence Code(s). If submitting multiple occurrence codes, each code must be unique. The submitted occurrence code(s) are submitted more than once, 45. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>719*[DATE]*U*[AMOUNT]******A7>732**Invalid Occurrence Code(s). If submitting multiple occurrence codes, each code must be unique. The submitted occurrence code(s) are submitted more than once, 45. Correct and resubmit.~

Related claim edits

Stedi has another edit for duplicate occurrence span codes. Occurrence codes report a single event on a specific date. Occurrence span codes report a condition that applied over a range of dates. See Duplicate occurrence span codes in institutional claims.

Claim edit: Invalid admission type code

Stedi now rejects 837I institutional claims with an invalid admission type code.

How the edit works

In institutional inpatient claims, an admission type code indicates the general nature of a patient’s admission. It provides context about the urgency or purpose of the hospital admission.

Admission type code

Admission type codes are defined by the National Uniform Billing Committee (NUBC). Valid admission type codes are:

• 1 – Emergency

• 2 – Urgent

• 3 – Elective

• 4 – Newborn

• 5 – Trauma Center

• 9 – Information Not Available

If an institutional claim includes an invalid admission type code, such as 6 or 0, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Admission Type Code. The submitted admission type code, 0 is not a recognized value. The value must be valid per NUBC Priority (Type) of Admission or Visit Codes. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>231*[DATE]*U*[AMOUNT]********Invalid Admission Type Code. The submitted admission type code, 0 is not a recognized value. The value must be valid per NUBC Priority (Type) of Admission or Visit Codes. Correct and resubmit.~

Claim edit: Invalid date range

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims where the start of a date range is later than the end date.

Date formats

X12 standards require that every date on a claim, such as the service date or admission date, use one of two formats:

• Single date – Eight digits in CCYYMMDD format. Example: 20260515.

• Date range – Two dates in CCYYMMDD-CCYYMMDD format. Example: 20260515-20260516.

In raw X12, each date has a related qualifier indicating the format: D8 for single dates and RD8 for date ranges.

Date ranges in the JSON API

In Stedi's JSON Claim Submission API endpoints, most dates that support ranges use paired fields. For example, in the JSON Professional Claim Submission endpoint, you can provide a date of service either as:

• A single date using the serviceDate field

• A range using the serviceDate and serviceDateEnd fields.

Some dates accept a range in a single field. For example, in the JSON Dental Claim Submission endpoint, the claim-level serviceDate field accepts either a single date or a date range.

How the edit works

For date ranges in a claim, the start date should never fall after the end date. If it does, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Service date range. The start date (20250708) cannot be later than the end date (20250608). Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>187*[DATE]*U*[AMOUNT]********Invalid Service date range. The start date (20250708) cannot be later than the end date (20250608). Correct and resubmit.~