# Submit dental claims
Source: https://www.stedi.com/docs/healthcare/submit-dental-claims

***

title: Submit dental claims
sidebarTitle: "Dental claims"
-----------------------------

You can send 837D dental claims to payers through the Stedi API or SFTP connection.

Once you send a claim, Stedi automatically receives and processes 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA) responses.

## Before sending claims

You may need to complete the following steps before sending claims.

### Transaction enrollment

[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer. Some payers require enrollment before allowing providers to submit 837 claims through a new clearinghouse.

Enrolling through Stedi may cancel existing claims enrollments you have through other clearinghouses. We can help you determine whether this applies to your specific payers. However, enrolling through Stedi for 837 claims doesn't affect your existing enrollments for other transaction types. For example, enrolling with Stedi won't unenroll the provider from receiving transactions like Electronic Remittance Advices (ERAs) through other clearinghouses.

You can check whether a specific payer requires transaction enrollment for 837 claims in the [Payer Network](https://www.stedi.com/healthcare/network) or through the [Payers API](/healthcare/api-reference/get-payer).

To enroll, complete the following steps:

1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for the claim type. [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)

### Coordination of benefits check

We recommend running a coordination of benefits (COB) check to ensure you submit claims to the correct payer. COB checks can help you determine:

* If a patient is covered by more than one health plan
* Whether coverage overlap requires coordination of benefits
* Each payer’s responsibility for payment (primacy) in coordination of benefits scenarios

Visit [Coordination of benefits (COB) checks](/healthcare/coordination-of-benefits) for more information.

## UI submission

You can submit dental claims in X12 EDI format through the Stedi portal. Manual claim submission can be useful for testing, QA, and debugging your pipeline.

Your X12 EDI claim data must adhere to the [837 Claim: Dental (X224A2)](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-dental-x224a2/01JCJZ46AEK835RYV1BXQNBPK8) specification.

To manually submit an X12 EDI claim:

1. Go to the [Transactions page](https://portal.stedi.com/app/healthcare/transactions).
2. Click **Submit claim** and choose **Upload EDI file** from the menu.
3. Do one of the following:
   * Click **Upload X12 EDI** and select an existing `.edi` file to add.
   * Select the transaction type and then paste the X12 EDI content into the text area.
4. Configure the settings to send a test or a production claim. Production claims are sent to payers. Test claims aren't sent to payers - Stedi's test clearinghouse processes them and returns test 277CA acknowledgments so you can evaluate your claim processing pipeline.
   1. Select either **Test** or **Production** in the menu at the top of the text area.
   2. Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data) or `P` (Production Data), accordingly.
5. Fix any validation errors that appear after adding the claim X12 EDI content. Stedi highlights errors in red and displays the specification for the claim type you selected on the right side of the screen to make it easier to identify and fix issues.
6. Click **Submit claim** to submit the claim to Stedi.

Stedi processes the claim and takes you to the claim's details page. Stedi also displays the claim on the [Transactions page](https://portal.stedi.com/app/healthcare/transactions).

## SFTP submission

You can use Stedi’s fully-managed SFTP server to submit claims to to payers and retrieve claim responses without calling Stedi’s APIs.

You must submit claims in X12 EDI format, and Stedi returns claim responses through the SFTP connection in X12 EDI format. This makes Stedi SFTP a good option if you have an existing system that generates X12 EDI files and you want to send them through the Stedi clearinghouse without completing an API integration. Visit [SFTP connection](/healthcare/submit-claims-sftp-connection) for more information.

## API submission

Call one of the following endpoints to submit 837D dental claims:

* [Dental Claims](/healthcare/api-reference/post-healthcare-dental-claims) to send requests in JSON
* [Dental Claims Raw X12](/healthcare/api-reference/post-healthcare-dental-claims-raw-x12) to send requests in X12 EDI

Both endpoints return a synchronous response from Stedi in JSON format. Later, the payer will respond with a 277CA claim acknowledgment.

### Headers

When constructing the request, you must include the following information in HTTP headers:

* **`Authorization`:** [Generate an API key](https://portal.stedi.com/app/settings/api-keys) to use for authentication.
* **`Content-Type`:** Set to `application/json`.

### Body - JSON

The information you submit for a claim depends on your use case. Refer to the [Dental Claims](/healthcare/api-reference/post-healthcare-dental-claims) endpoint for a complete list of properties. However, all claims require the following high-level information:

{/* prettier-ignore-start */}

\| Information | Description |
\| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
\| `tradingPartnerServiceId` | This is the payer ID. You can send requests using the primary payer ID, the Stedi payer ID, or any alias listed in the payer record. If you don't already have payer IDs you use today, we recommend using the primary Payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list. |
\| `tradingPartnerName` | This is the payer's business name, like Cigna or Aetna. |
\| `submitter` object | Information about the entity submitting the claim. This can be either an individual or an organization, such as a doctor, hospital, or insurance company. |
\| `receiver` object | Information about the payer, such as an insurance company or government agency. |
\| `subscriber` and/or `dependent` objects | Information about the patient who received the medical services. Note that if a dependent has their own, unique member ID for their health plan, you should submit their information in the `subscriber` object and omit the `dependent` object from the request. You can check whether the dependent has a unique member ID by submitting an [Eligibility Check](/healthcare/api-reference/post-healthcare-eligibility) to the payer for the dependent. The payer will return the member ID in the `dependents.memberId` field, if present. |
\| `claimInformation` object | Information about the claim, such as the [patient control number](#patient-control-number), claim charge amount, and place of service code. It also includes information about each individual service line included in the claim. |
\| `billing` object | Information about the billing provider, such as the [NPI](/healthcare/national-provider-identifier), taxonomy code, and organization name. |

{/* prettier-ignore-end */}

#### Patient Control Number

You must submit a Patient Control Number (PCN) with each claim in [`claimInformation.patientControlNumber`](/healthcare/api-reference/post-healthcare-dental-claims#body.claimInformation.patientControlNumber). The payer returns this value in related transactions, such as the 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA), so you can correlate responses and real-time claim status checks with the original claim.

When assigning a PCN, follow these best practices:

* Use a unique PCN for each claim. The identifier should be more complex than a simple sequential number and should be hard to guess.
* Use random strings. Formats with patient initials or the date of service in them can create duplicates. We recommend using [nanoid](https://www.npmjs.com/package/nanoid) or a similar library to create a strong, unique 17-character PCN for each claim.
* Keep it 17 characters or less. Some payers cut off values longer than 17 characters in ERAs and claim acknowledgments, which makes it hard to match them with the original claim.
* Use alphanumeric characters only. Avoid special characters, as many payers don't handle them properly.

#### Service line identification

A claim can contain multiple service lines. Since the payer may accept, reject, or pay a subset of those lines, you can receive an 835 ERA that references a `patientControlNumber`, but only pertains to some of the service lines.

However, the `claimInformation.serviceLines.providerControlNumber` serves as a unique identifier for each service line in your claim submission. This value appears in the 277CA claim acknowledgment and 835 ERA as the `lineItemControlNumber`, allowing you to correlate these responses to specific service lines from the original claim. If you don't set the `providerControlNumber` for a service line, Stedi uses a random UUID.

Stedi returns service line identifiers in the `claimReference.serviceLines` object of the synchronous API response.

#### Conditional requirements

Note that objects marked as **required** are required for all requests, while others are conditionally required depending on the circumstances. When you include a conditionally required object, you must include all of its required properties.

For example, you must always include the `subscriber` object in your request, but you only need to include the `supervising` object when the rendering provider is supervised by a physician.

### Body - X12 EDI

You must send a payload in [837 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-dental-x224a3/01GRYB6G91ZX6R1XAFGBMRTBBW).

Note the following requirements and behavior when sending dental claims through the raw X12 endpoint.

#### Envelope and header

Stedi generates its own `ISA` and `GS` headers and `IEA` and `GE` trailers before sending your claim to the payer. You can submit your claim to Stedi with any values in these segments, as long as they conform to the X12 EDI specification.

However, you must set `ST03` (Implementation Guide Version Name) to `005010X224A2`.

#### Payer ID

You must submit a payer identifier in `Loop 2010BB` (Payer Name) `NM109` so Stedi can route your claim to the correct payer. This identifier **must** be a payer ID or payer ID alias listed in the [Payer Network](https://www.stedi.com/healthcare/network). If you don't already have payer IDs you use today, we recommend using the primary Payer ID.

#### `CLM01` (Patient Control Number)

We **strongly recommend** submitting a unique value for `Loop 2300` (Claim Information) `CLM01` (Patient Control Number). The payer returns this value in related transactions, such as the 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA), so you can correlate responses and real-time claim status checks with the original claim.

When assigning a PCN, follow these best practices:

* Use a unique PCN for each claim. The identifier should be more complex than a simple sequential number and should be hard to guess.
* Use random strings. Formats with patient initials or the date of service in them can create duplicates. We recommend using [nanoid](https://www.npmjs.com/package/nanoid) or a similar library to create a strong, unique 17-character PCN for each claim.
* Keep it 17 characters or less. Some payers cut off values longer than 17 characters in ERAs and claim acknowledgments, which makes it hard to match them with the original claim.
* Use alphanumeric characters only. Avoid special characters, as many payers don't handle them properly.

#### Service line identification

A claim can contain multiple service lines. Since the payer may accept, reject, or pay a subset of those lines, you can receive an 835 response that references a patient control number, but only pertains to some of the service lines.

However, the line item control number serves as a unique identifier for each service line in your claim submission.

* You can set the line item control number in `Loop 2400 REF02`, when `REF01` = `6R`. The line item control number appears in the 277CA and 835 ERA responses as the `lineItemControlNumber`, allowing you to correlate these responses to specific service lines from the original claim.
* If you don’t set the line item control number for a service line, Stedi uses a ULID.

### Character restrictions

Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause validation and HTTP `400` errors.

<Accordion title="Basic character set">
  The X12 Basic character set includes uppercase letters, digits, space, and some special characters. Lowercase letters and special language characters like `ñ` are not included.

  The following special characters are included:

  ![Basic special characters](/images/basic-special-characters.png)
</Accordion>

<Accordion title="Extended character set">
  The Extended character set includes the characters listed in Basic, plus lowercase letters and additional special characters, such as `@`.

  The following additional special characters are included:
  ![Extended special characters](/images/extended-special-characters-healthcare.png)
</Accordion>

In addition, the following characters are reserved for delimiters in the final X12 EDI transaction to the payer: `~`, `*`, `:`, and `^`. X12 doesn’t support using escape sequences to represent delimiters or special characters. Stedi returns a `400` error if you use these restricted characters improperly.

* **JSON endpoint:** Don’t include delimiter characters anywhere in your request data.
* **Raw X12 endpoint:** You can use these characters as delimiters, but not in the body of the request data.

### Sample request and response

The following examples send a dental claim. The response shape is the same for both the JSON and X12 EDI endpoints. It contains summary information from Stedi about the claim submission and whether it was successful.

<Tabs items={["Request - JSON", "Request - X12 EDI", "Response"]}>
  <Tab value="Request - JSON">
    {/* schema:DentalClaimsSubmissionRequestContent */}

    ```bash
    curl --request POST \
      --url https://healthcare.us.stedi.com/2024-04-01/dental-claims/submission \
      --header 'Authorization: <api-key>' \
      --header 'Content-Type: application/json' \
      --data '{
      "usageIndicator": "T",
      "tradingPartnerServiceId": "52133",
      "tradingPartnerName": "United HealthCare Dental",
      "subscriber": {
        "paymentResponsibilityLevelCode": "P",
        "memberId": "123412345",
        "firstName": "John",
        "lastName": "Doe",
        "groupNumber": "1234567890",
        "gender": "F",
        "address": {
          "address1": "1234 Some St",
          "city": "Buckeye",
          "state": "AZ",
          "postalCode": "85326"
        },
        "dateOfBirth": "20180615"
      },
      "submitter": {
        "organizationName": "ABA Inc",
        "submitterIdentification": "<YOUR-SUBMITTER-ID>",
        "contactInformation": {
          "phoneNumber": "3131234567",
          "name": "BILLING DEPARTMENT"
        }
      },
      "rendering": {
        "npi": "1999999992",
        "taxonomyCode": "106S00000X",
        "providerType": "RenderingProvider",
        "lastName": "Doe",
        "firstName": "Jane"
      },
      "receiver": {
        "organizationName": "United HealthCare Dental"
      },
      "payerAddress": {
        "address1": "PO Box 7000",
        "city": "Camden",
        "state": "SC",
        "postalCode": "29000"
      },
      "claimInformation": {
        "signatureIndicator": "Y",
        "toothStatus": [
          {
            "toothNumber": "3",
            "toothStatusCode": "E"
          }
        ],
        "serviceLines": [
          {
            "serviceDate": "20230428",
            "renderingProvider": {
              "npi": "1999999992",
              "taxonomyCode": "122300000X",
              "lastName": "Doe",
              "firstName": "Jane"
            },
            "providerControlNumber": "a0UDo000000dd2dMAA",
            "dentalService": {
              "procedureCode": "D7140",
              "lineItemChargeAmount": "832.00",
              "placeOfServiceCode": "12",
              "oralCavityDesignation": [
                "1",
                "2"
              ],
              "prosthesisCrownOrInlayCode": "I",
              "procedureCount": 2,
              "compositeDiagnosisCodePointers": {
                "diagnosisCodePointers": [
                  "1"
                ]
              }
            },
            "teethInformation": [
              {
                "toothCode": "3",
                "toothSurfaceCodes": [
                  "M",
                  "O"
                ]
              }
            ]
          }
        ],
        "serviceFacilityLocation": {
          "phoneNumber": "3131234567",
          "organizationName": "ABA Inc",
          "npi": "1999999992",
          "address": {
            "address1": "ABA Inc 123 Some St",
            "city": "Denver",
            "state": "CO",
            "postalCode": "802383100"
          }
        },
        "releaseInformationCode": "Y",
        "planParticipationCode": "A",
        "placeOfServiceCode": "12",
        "patientControlNumber": "<YOUR-CLAIM-ID>",
        "healthCareCodeInformation": [
          {
            "diagnosisTypeCode": "ABK",
            "diagnosisCode": "K081"
          }
        ],
        "claimSupplementalInformation": {
          "priorAuthorizationNumber": "20231010012345678"
        },
        "claimFrequencyCode": "1",
        "claimFilingCode": "FI",
        "claimChargeAmount": "832.00",
        "benefitsAssignmentCertificationIndicator": "Y"
      },
      "billing": {
        "taxonomyCode": "106S00000X",
        "providerType": "BillingProvider",
        "organizationName": "ABA Inc",
        "npi": "1999999992",
        "employerId": "123456789",
        "contactInformation": {
          "phoneNumber": "3134893157",
          "name": "ABA Inc"
        },
        "address": {
          "address1": "ABA Inc 123 Some St",
          "city": "Denver",
          "state": "CO",
          "postalCode": "802383000"
        }
      }
    }'
    ```
  </Tab>

  <Tab value="Request - X12 EDI">
    ```bash
    curl --request POST \
      --url https://healthcare.us.stedi.com/2024-04-01/dental-claims/raw-x12-submission \
      --header 'Authorization: <api-key>' \
      --header 'Content-Type: application/json' \
      --data '{
      "x12": "ISA*00*          *00*          *ZZ*001690149382   *ZZ*STEDITEST      *240630*0847*^*00501*000000001*0*T*>~GS*HC*001690149382*STEDITEST*20240630*084744*000000001*X*005010X224A2~ST*837*3456*005010X224A2~BHT*0019*00*0123*20061123*1023*CH~NM1*41*2*PREMIER BILLING SERVICE*****46*TGJ23~PER*IC*JERRY*TE*7176149999~NM1*40*2*INSURANCE COMPANY XYZ*****46*66783JJT~HL*1**20*1~NM1*85*2*DENTAL ASSOCIATES*****XX*1999999992~N3*234 SEAWAY ST~N4*MIAMI*FL*33111~REF*EI*587654321~HL*2*1*22*1~SBR*P********CI~NM1*IL*1*SMITH*JANE****MI*111223333~NM1*PR*2*INSURANCE COMPANY XYZ*****PI*66783JJT~HL*3*2*23*0~PAT*19~NM1*QC*1*SMITH*TED~N3*236 N MAIN ST~N4*MIAMI*FL*33413~DMG*D8*19920501*M~CLM*26403774*150***11>B>1*Y*A*Y*I~DTP*472*D8*20061029~REF*D9*17312345600006351~NM1*82*1*DOE*JOHN****XX*1999999992~PRV*PE*PXC*1223G0001X~LX*1~SV3*AD>D2150*100****1~TOO*JP*12*M>O~LX*2~SV3*AD>D1110*50****1~SE*31*3456~GE*1*000000001~IEA*1*000000001~"
    }'
    ```
  </Tab>

  <Tab value="Response">
    {/* schema:DentalClaimsSubmissionResponseContent */}

    ```json
    {
      "status": "SUCCESS",
      "controlNumber": "1",
      "tradingPartnerServiceId": "52133",
      "claimReference": {
        "correlationId": "01JDQMX92Q1T561BH8NKX750TQ",
        "patientControlNumber": "0U1LBRS4",
        "timeOfResponse": "2024-11-27T20:27:27.077Z",
        "payerId": "52133",
        "formatVersion": "5010",
        "rhclaimNumber": "01JDQMX92Q1T561BH8NKX750TQ",
        "serviceLines": [
          {
            "lineItemControlNumber": "a0UDo000000dd2dMAA"
          }
        ]
      },
      "httpStatusCode": "200 OK",
      "meta": {
        "traceId": "9b491769-052e-4738-93d6-e0b5f6d83f53"
      },
      "payer": {
        "payerName": "United HealthCare Dental",
        "payerId": "52133"
      }
    }
    ```
  </Tab>
</Tabs>

### Test claims

All claims you submit through the API are sent to the payer as production claims unless you explicitly designate them as test data.

To send test claims:

* **JSON endpoint:** Set the `usageIndicator` property in the test claim body to `T`.
* **X12 EDI endpoint:** Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data) instead of `P` (Production Data).

When you send a test claim, Stedi doesn't send it to the payer. Instead, it processes the claim as if it were sent to the payer and returns a 277CA claim acknowledgment indicating whether the claim was successfully processed.
Designating a claim as test data also allows you to filter for test claims on the [Transactions](https://portal.stedi.com/app/core/transactions) page in the Stedi portal.

You'll receive a 277CA claim acknowledgment in response to test claims, but you won't receive a test 835 Electronic Remittance Advice (ERA) response unless you send the claim to the [Stedi Test Payer](https://www.stedi.com/healthcare/network?search=StediTest\&entry=FRCPB). Visit [Test claims workflow](/healthcare/test-claims-workflow) to learn how generate test ERAs.

### Concurrency limit

Dental claim submission endpoints share a concurrency pool with other claim endpoints. For more information, visit [Concurrency limits](/healthcare/api-reference#concurrency-limits).

### Recommended API clients

You may want to use an API client to make testing and debugging easier.

We **don't recommend** using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds.

Visit [API clients](/healthcare/api-reference#api-clients) for a list of recommended clients you can use instead.

## View submitted claims

You can view the files that Stedi sends and receives in the [Files](https://portal.stedi.com/app/core/file-executions) page of the Stedi portal.

On the [Transactions](https://portal.stedi.com/app/core/transactions) page, you can review and filter claims by **Usage** - production or test. Click any claim submission to review its details, including the full request and response payload and processing events.

## 275 claim attachments

If the claim requires attachments, you must include additional details about the attachments in the [`claimInformation.claimSupplementalInformation.reportInformation`](/healthcare/api-reference/post-healthcare-dental-claims#body.claimInformation.claimSupplementalInformation.reportInformation) object or the [`claimInformation.claimSupplementalInformation.reportInformations`](/healthcare/api-reference/post-healthcare-dental-claims#body.claimInformation.claimSupplementalInformation.reportInformations) array (multiple attachments).

Visit [Claim attachments](/healthcare/submit-claim-attachments) for complete instructions.

## Submit claims to a secondary or tertiary payer

In [coordination of benefits (COB)](/healthcare/coordination-of-benefits) scenarios, you'll need to submit a claim to multiple payers.

You must set the `subscriber.paymentResponsibilityLevelCode` to either `S` (when submitting to the secondary payer) or `T` (when submitting to the tertiary payer).

You must also include the following information about how prior payers have adjudicated the claim. For example, if a patient's private insurance plan (primary payer) adjusted the requested reimbursement amount and paid for its portion of the services, you must include that information in the claim you submit to Medicare (secondary payer). You can find these details in 835 ERA responses from prior payers.

### Claim information

You must submit one `claimInformation.otherSubscriberInformation` object for each prior payer. Supply all the required properties in the object plus the following additional information:

* `claimLevelAdjustments`: Provide if the prior payer made adjustments at the claim level. Codes and their associated amounts must come from ERAs sent by the prior payers. You can find these codes in the ERA's [`transactions.detailInfo.paymentInfo.claimAdjustments`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.claimAdjustments) object.
* `medicareInpatientAdjudication` (institutional claims only): You must include this if Medicare was one of the prior payers and reported inpatient adjudication information on the ERA.
* `medicareOutpatientAdjudication`: You must include this if Medicare was one of the prior payers and reported outpatient adjudication information on the ERA.
* `otherPayerName.otherPayerAdjudicationOrPaymentDate`: The date the payer adjudicated or paid the claim. You must provide this if you aren't providing a value in the `claimInformation.serviceLines.lineAdjudicationInformation.adjudicationOrPaymentDate` property.
* `payerPaidAmount`: This is the total amount in dollars the payer paid on this claim.

### Service line information

You must submit `serviceLines.lineAdjudicationInformation` objects when the prior payers provided line-level adjudication information. Submit one object for each prior payer. For each object, you should include the following properties.

* `adjudicationOrPaymentDate`: The date the payer adjudicated or paid the claim. Don't include this if you're providing a date in the `otherPayerName.otherPayerAdjudicationOrPaymentDate` property.
* `claimAdjustmentInformation`: You can find this information in the ERA's [`transactions.detailInfo.paymentInfo.serviceLines.serviceAdjustments`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.serviceLines.serviceAdjustments) object.
* `otherPayerPrimaryIdentifier`: The identifier for the other payer. This value should match the identifier you supplied for the payer in the `claimInformation.otherSubscriberInformation.otherPayerName.otherPayerIdentifier` property.
* `procedureCode`: The adjudicated procedure code for the service line.
* `serviceIdQualifier`: A code identify the type of procedure code. Visit [Claims code lists](/healthcare/claims-code-lists#composite-medical-procedure---product-or-service-id-qualifier-codes) for a complete list.
* `serviceLinePaidAmount`: The total amount in dollars the prior payer paid on this service line.
* `paidServiceUnitCount`: The number of paid units for the service line. When paid units are not present on the remittance advice, use the original billed units.
* `remainingPatientLiability`: The amount of the service line the patient is responsible for paying.

## Claim Filing Indicator Code

The Claim Filing Indicator Code indicates how a claim was filed with a payer, such as `MC` (Medicaid) or `CI` (Commercial Insurance Co.).

Choosing the correct claim filing indicator code is important for successful claim submission. Visit the [Claims code lists](/healthcare/claims-code-lists#choosing-the-right-code) documentation for best practices for selecting the appropriate code.