Changelog

Claim edit: Invalid paid amount

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that report a negative or non-numeric other payer paid amount on a service line.

How the edit works

When a patient has more than one insurance plan, say a child covered by both parents’ health insurance, claims go to the primary payer first, then the secondary, and so on. This is called coordination of benefits (COB).

Claims sent to non-primary payers must report each previous payer’s payments for each service line.

Service line paid amount

Claim type	JSON API field	X12 element
837P professional	`claimInformation.serviceLines[].lineAdjudicationInformation[].serviceLinePaidAmount`	`SVD-02` (Service Line Paid Amount) of Loop `2430` (Line Adjudication Information)
837D dental	`claimInformation.serviceLines[].lineAdjudicationInformation[].serviceLinePaidAmount`	`SVD-02` (Service Line Paid Amount) of Loop `2430` (Line Adjudication Information)
837I institutional	`claimInformation.serviceLines[].lineAdjudicationInformation[].serviceLinePaidAmount`	`SVD-02` (Service Line Paid Amount) of Loop `2430` (Line Adjudication Information)

A service line's paid amounts must be non-negative numbers. If they aren't, 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 Other Payer Paid Amount. The service line other payer paid amount must be a valid number greater than or equal to zero. The submitted value on line 1 is invalid, -150.00. 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>643>PR*[DATE]*U*[AMOUNT]******A8>710**Invalid Other Payer Paid Amount. The service line other payer paid amount must be a valid number greater than or equal to zero. The submitted value on line 1 is invalid, -150.00. Correct and resubmit.~

Claim edit: Missing last name

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include a person entity with no last name.

How the edit works

In a claim, each entity, such as the billing provider or subscriber, is identified as either a person or a non-person using an entity type qualifier.

When an entity is a person, both a first name and last name are required. In X12, this is the entity’s NM1-03 element. If a person’s last name is missing, 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.

How entity type qualifiers are specified

If you use Stedi's JSON Claim Submission API endpoints, Stedi sometimes infers the entity type qualifier. For example, if you provide a firstName and lastName for the billing provider in a JSON 837P Professional Claims API request, the entity is treated as a person.

If you use X12, you set the entity type qualifier in NM1-02 (Entity Type Qualifier). 1 indicates a person and 2 indicates a non-person entity, such as a hospital or billing organization.

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 Last Name. Last name is required when Billing Provider is reported as a person by the entity type qualifier 1. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A6>504>85*[DATE]*U*[AMOUNT]********Missing Last Name. Last name is required when Billing Provider is reported as a person by the entity type qualifier 1. Correct and resubmit.~

Related claim edits

Stedi has a companion edit for missing first names. See Claim edit: Missing first name.

Claim edit: Payer responsibility level codes must be in order

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that skip a level in the payer responsibility sequence.

What are payer responsibility level codes?

In coordination of benefits (COB) scenarios, the patient is covered by insurance from more than one payer. The primary payer pays first, then the secondary payer, and so on.

COB claims must include information about all previous payers. Payer responsibility level codes, also called payment responsibility sequence number codes, indicate each payer’s payment order: P (primary), S (secondary), T (tertiary), then A through H for the fourth through eleventh payers.

Payer responsibility level code for the payer you’re sending the claim to

Claim type	JSON API field	X12 element
837P professional	`subscriber.paymentResponsibilityLevelCode`	`SBR-01` (Payer Responsibility Sequence Number Code) in `Loop 2000B` (Subscriber Hierarchical Level)
837D dental	`subscriber.paymentResponsibilityLevelCode`	`SBR-01` (Payer Responsibility Sequence Number Code) in `Loop 2000B` (Subscriber Hierarchical Level)
837I institutional	`subscriber.paymentResponsibilityLevelCode`	`SBR-01` (Payer Responsibility Sequence Number Code) in `Loop 2000B` (Subscriber Hierarchical Level)

Payer responsibility level codes for the patient’s other payers

Claim type	JSON API field	X12 element
837P professional	`claimInformation.otherSubscriberInformation[].paymentResponsibilityLevelCode`	`SBR-01` (Payer Responsibility Sequence Number Code) in `Loop 2320` (Other Subscriber Information)
837D dental	`claimInformation.otherSubscriberInformation[].paymentResponsibilityLevelCode`	`SBR-01` (Payer Responsibility Sequence Number Code) in `Loop 2320` (Other Subscriber Information)
837I institutional	`claimInformation.otherSubscriberInformation[].paymentResponsibilityLevelCode`	`SBR-01` (Payer Responsibility Sequence Number Code) in `Loop 2320` (Other Subscriber Information)

How the edit works

If a claim reports a secondary or later payer, it must also report every prior payer level before it in the order. Otherwise, the payer may reject the claim.

For example, the payer may reject a claim that reports a tertiary payer without a secondary payer.

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.

Note: A responsibility level code of U (Unknown) won’t trigger this edit. A code of U doesn’t indicate a specific payment order.

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 Payer Responsibility Sequence. Any payer responsibility level above primary must follow the prior levels in order. The submitted payer responsibility values are out of order, P, T. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>742*[DATE]*U*[AMOUNT]******A7>732**Invalid Payer Responsibility Sequence. Any payer responsibility level above primary must follow the prior levels in order. The submitted payer responsibility values are out of order, P, T. Correct and resubmit.~

Related claim edits

Stedi has another edit for duplicate payer responsibility level codes. See Duplicate payer responsibility level codes.

Stedi also rejects claims that don't report a primary payer. See Missing primary payer.

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:

Claim type	Submission methods
Professional claim (CMS-1500 paper form)	API: JSON API, Raw X12 API SFTP: 837P X12 EDI Stedi portal UI: CMS-1500 Claim Form or X12 upload
Institutional claim (UB-04 paper form)	API: JSON API, Raw X12 API SFTP: 837I X12 EDI Stedi portal UI: X12 upload

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:

Claim type	Service lines per page
Professional claim (CMS-1500 form)	Up to 6
Institutional claim (UB-04 form)	Up to 22

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

Claim type	JSON API field	X12 element
837P professional	`claimInformation.claimSupplementalInformation.cliaNumber`	`REF-02` (Reference Identification) of Loop `2300` (Claim Information)

Line-level CLIA number

Claim type	JSON API field	X12 element
837P professional	`claimInformation.serviceLines[].serviceLineReferenceInformation.clinicalLaboratoryImprovementAmendmentNumber`	`REF-02` (Reference Identification) of Loop `2400` (Service Line)

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"
    }
  ]
}

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"
    }
  ]
}

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

Claim type	JSON API field	X12 element
837I institutional	`serviceLines[].institutionalService.serviceLineRevenueCode`	`SV2-01` (Revenue Code) of Loop `2400` (Service Line)

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:

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"
    }
  ]
}

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

Claim type	JSON API field	X12 element
837P professional	`claimInformation.claimDateInformation.symptomDate`	`DTP-03` (Date Time Period) of Loop `2300` (Claim Information)

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

Claim type	JSON API field	X12 element
837P professional	`claimInformation.serviceLines[].serviceDate`	`DTP-03` (Date Time Period) of Loop `2400` (Service Line)

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"
    }
  ]
}

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

Claim type	JSON API field	X12 element
837I institutional	`claimInformation.conditionCodesList[][].conditionCode`	`HI-02` (Condition Code) of Loop `2300` (Claim Information), where `HI-01` is `BG` (Condition)

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"
    }
  ]
}

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.~