What is predetermination of benefits for dental services?

Jan 27, 2026

Guide

A predetermination claim – also called a predetermination of benefits or a pre-treatment estimate – is a dental claim sent to a payer before care is delivered. They’re used by dental providers to find out two things:

  1. Whether the patient's plan covers a service or treatment.

  2. What the payer is likely to pay for the claim, including what the patient may owe.

Most claims are requests for payment – they’re essentially bills from a provider to a payer. A predetermination claim isn’t. It’s more like a dry run of a claim for cost estimation purposes.

This guide explains how predetermination claims work and how to interpret predeterminations in Electronic Remittance Advice (ERAs).

Important: This guide covers predeterminations for dental services. In most cases, medical services – like those covered by professional and institutional claims – use prior authorizations instead.

When are predetermination claims used?

In dental care, predetermination claims are commonly used for expensive treatments, like crowns, wisdom tooth removal, dentures, or periodontal surgery.

Some dental payers, such as Delta Dental, encourage patients and providers to use predetermination to help patients budget (and ensure providers are paid) for major dental procedures.

Predeterminations are estimates, not guarantees

However, the amounts returned by predetermination claims are estimates, not guarantees. They reflect eligibility and remaining benefits at the time the predetermination is processed. If coverage changes before the final claim is submitted, the final payment can change too.

Differences between predetermination claims and prior authorizations

Payers sometimes require approval – called prior authorization – before they’ll cover certain services.

That required-ness is the key difference. Prior authorization is required for coverage. Predetermination isn’t.

Predetermination may be encouraged by the payer to estimate provider payment and patient responsibility, but it’s optional.

Electronic X12 transactions

Another major difference between predetermination and prior authorization is the transaction you use to exchange them electronically.

HIPAA is a U.S. federal law that, among other things, requires that certain electronic transactions use the standardized X12 EDI format. Under HIPAA, prior authorizations and claims must use different X12 specifications, called transaction sets.

Prior authorizations use X12’s 278 Health Care Services Review Information transaction set. Claims, including predetermination claims, use X12’s 837 Health Care Claim transaction set. The 837 transaction set has different X12 implementation guides – called Type 3 Technical Reports (TR3s) – for professional (837P), dental (837D), and institutional (837I) claims.

You can submit 837P professional, 837D dental, and 837I institutional claims as X12 using Stedi’s SFTP or our X12 API. However, most Stedi customers use our JSON API or the Stedi portal. In these cases, we translate the JSON claim data into a HIPAA-compliant 837 X12 transaction for you.

Note: Stedi doesn’t currently support 278 prior authorization transactions.

Everyday usage

If you’re using Stedi’s JSON API or the Stedi portal, you don’t need to be familiar with X12 or the specs for specific transaction sets. However, people often refer to a transaction or claim type by its X12 transaction set or TR3. For example, you may hear people refer to an electronic dental claim as an “837D” or an “837D dental claim.”

Send a dental predetermination claim

With Stedi, you send a predetermination claim the same way you would a normal claim – just with special values.

To send a dental predetermination claim, submit an 837D claim with the following values:


JSON 837D Dental Claim Submission API

837D Dental Claim X12

Notes

Mark the claim as a predetermination

claimInformation.predeterminationOfBenefits is true

CLM19 (Predetermination of Benefits Code) is PB (Predetermination of Benefits Code) in Loop 2300 (Claim Information)


Omit the claim service date

claimInformation.claimDateInformation.serviceDate is omitted

DTP03 (Service Date) is omitted in Loop 2300 (Claim Information)

Predeterminations don’t include a service date because they’re submitted before care is given.

Omit service line dates

Each claimInformation.serviceLines[].serviceDate is omitted

DTP03 (Service Date) is omitted in each Loop 2400 (Service Line Number)

Predeterminations don’t include a service date because they’re submitted before care is given.

 For example, in a Dental Claims (837D) JSON API request body:

{
  "claimInformation": {
    ...
    "predeterminationOfBenefits": true,  // Mark the claim as a predetermination
    "claimDateInformation": {
      ...  // Omit the claim service date
    },
    "serviceLines": [
      {
        ...  // Omit service line dates
      },
      ...
    ]
  },
  ...
}

Predetermination in 835 ERAs

Once submitted, the predetermination claim will follow the same lifecycle as a standard claim.

First, one or more 277CA claim acknowledgments arrive within a few business days. Then, an 835 ERA follows. For standard claims, ERAs and any related payments typically arrive in 7-20 business days. ERAs for predetermination claims may arrive sooner, since no payment is issued. For more information on enrolling, listening for, and retrieving ERAs, see our ERA docs.

Claim payment status code

In an ERA, a claim payment status code tells you – at a high level – how the payer processed and paid a claim. A claim payment status code of 25 (Predetermination Pricing Only - No Payment) indicates the ERA is for a predetermination claim. You can find this code in the following locations:

For example, in a JSON 835 ERA API response:

{
  "transactions": [
    {
      "detailInfo": [
        {
          "paymentInfo": [
            {
              "claimPaymentInfo": {
                "claimStatusCode": "25",  // Indicates the ERA is a predetermination
                ...
              },
              ...
            },
          ],
          ...
        }
      ],
      ...
    }
  ],
  ...
}

Predetermination of benefits identification numbers

Payers may include one or more predetermination of benefits identification numbers in the ERA. You can use these numbers to link the estimate to a future claim.

The numbers can appear at the claim level, the service line level, or both:

Level

JSON 835 ERA API field value

835 ERA X12 element values

Claim level

otherClaimRelatedIdentification.predeterminationOfBenefitsIdentificationNumber

In Loop 2100 (Claim Payment Information):

  • REF01 (Reference Identification Qualifier) is G3 (Predetermination of Benefits Identification Number).

  • REF02 (Other Claim Related Identifier) is the predetermination of benefits identification number.

Service line item level

serviceLines[].serviceIdentification.preDeterminationOfBenefitsIdentificationNumber

In Loop 2110 (Service Payment Information):

  • REF01 is G3.

  • REF02 is the predetermination of benefits identification number.

For example, in a JSON 835 ERA API response:

{
  "transactions": [
    {
      "detailInfo": [
        {
          "paymentInfo": [
            {
              "otherClaimRelatedIdentification": {
                "predeterminationOfBenefitsIdentificationNumber": "1234567890", // Claim-level predetermination of benefits identification number
                ...
              },
              "serviceLines": [
                {
                  "serviceIdentification":{
                     "preDeterminationOfBenefitsIdentificationNumber": "0978654321", // Service-line-item-level predetermination of benefits identification number
                     ...
                  },
                  ...
                }
              ]
            },
            ...
          ]
        }
      ]
    }
  ],
  ...
}

Estimated provider payment amounts

Predeterminations often include estimated payment amounts for the provider. These estimates, included in the ERA as adjustments, are typically marked with a Claim Adjustment Reason Code (CARC) of 101 (Predetermination: anticipated payment upon completion of services or claim adjudication).

The CARC and its related adjustment may appear at the claim level, the service line level, or both:

Level

JSON 835 ERA API field value

835 ERA X12 element value

Claim level

claimAdjustments[].adjustmentReasonCode<N> is 101

In Loop 2100 (Claim Payment Information), CAS02 (Adjustment Reason Code) is 101.

Service line item level

serviceAdjustments[].adjustmentReasonCode<N> is 101

In Loop 2110 (Service Payment Information), CAS02 (Adjustment Reason Code) is 101.

{
  "transactions": [
    {
      "detailInfo": [
        {
          "paymentInfo": [
            {
              "claimAdjustments": [
                {
                  "adjustmentAmount1": "3000",    // Claim-level estimated payment
                  "adjustmentReasonCode1": "101", // Claim-level CARC for predetermination
                  ...
                }
              ],
              "serviceLines": [
                {
                  "serviceAdjustments": [
                    {
                      "adjustmentAmount1": "1000",    // Service-line-item-level estimated payment
                      "adjustmentReasonCode1": "101", // Service-line-item-level CARC for predetermination
                      ...
                    }
                  ],
                  ...
                }
              ]
            },
            ...
          ],
          ...
        }
      ],
      ...
    }
  ],
  ...
}

Linking the actual claim to the predetermination

After the provider provides treatment and is ready to bill the payer, you submit a dental claim to request actual payment. Submit the claim as normal:

  • Do NOT mark it for predetermination.

  • Include service dates at the claim and service line item levels.

If the payer returned predetermination of benefits identification numbers in the predetermination’s ERA, you can include them in the final claim to link the claim back to the estimate. Use the following fields:

Level

JSON 837D Dental Claim Submission API field

837D Dental Claim X12 elements

Claim level

claimSupplementalInformation.predeterminationOfBenefitsIdentifier

In Loop 2300 (Claim Information):

  • REF01 (Reference Identification Qualifier) should be G3 (Predetermination of Benefits Identification Number).

  • REF02 (Other Claim Related Identifier) should be predetermination of benefits identification number.

Service line item level

serviceLineReferenceInformation.predeterminationOfBenefits

In Loop 2400 (Service Line Number):

  • REF01 (Reference Identification Qualifier) should be G3 (Predetermination of Benefits Identification Number).

  • REF02 (Other Claim Related Identifier) should be the predetermination of benefits identification number.

 For example, in a Dental Claims (837D) JSON API request body:

{
  "claimInformation": {
    ...
    "predeterminationOfBenefits": false,  // You can also omit this field. It defaults to false.
    "claimSupplementalInformation": {
      "predeterminationOfBenefitsIdentifier": "1234567890", // Claim-level predetermination of benefits identification number
      ...
    },
    "claimDateInformation": {
      "serviceDate": "20260428",  // Include the claim service date
      ...
    },
    "serviceLines": [
      {
        "serviceDate": "20260428",  // Include the service-line-item service date
        "serviceLineReferenceInformation": {
          "predeterminationOfBenefits": "0978654321", // Service-line-item-level predetermination of benefits identification number
          ...
        }
      }
    ],
    ...
  },
  ...
}

Process claims and ERAs with Stedi

You can use Stedi to submit and track predetermination claims – and receive the related ERAs.

You can start for free. Our Basic plan includes 100 free claim submissions and ERAs for up to 100 paid claims each month.

Signup takes less than two minutes. No credit card required.

A predetermination claim – also called a predetermination of benefits or a pre-treatment estimate – is a dental claim sent to a payer before care is delivered. They’re used by dental providers to find out two things:

  1. Whether the patient's plan covers a service or treatment.

  2. What the payer is likely to pay for the claim, including what the patient may owe.

Most claims are requests for payment – they’re essentially bills from a provider to a payer. A predetermination claim isn’t. It’s more like a dry run of a claim for cost estimation purposes.

This guide explains how predetermination claims work and how to interpret predeterminations in Electronic Remittance Advice (ERAs).

Important: This guide covers predeterminations for dental services. In most cases, medical services – like those covered by professional and institutional claims – use prior authorizations instead.

When are predetermination claims used?

In dental care, predetermination claims are commonly used for expensive treatments, like crowns, wisdom tooth removal, dentures, or periodontal surgery.

Some dental payers, such as Delta Dental, encourage patients and providers to use predetermination to help patients budget (and ensure providers are paid) for major dental procedures.

Predeterminations are estimates, not guarantees

However, the amounts returned by predetermination claims are estimates, not guarantees. They reflect eligibility and remaining benefits at the time the predetermination is processed. If coverage changes before the final claim is submitted, the final payment can change too.

Differences between predetermination claims and prior authorizations

Payers sometimes require approval – called prior authorization – before they’ll cover certain services.

That required-ness is the key difference. Prior authorization is required for coverage. Predetermination isn’t.

Predetermination may be encouraged by the payer to estimate provider payment and patient responsibility, but it’s optional.

Electronic X12 transactions

Another major difference between predetermination and prior authorization is the transaction you use to exchange them electronically.

HIPAA is a U.S. federal law that, among other things, requires that certain electronic transactions use the standardized X12 EDI format. Under HIPAA, prior authorizations and claims must use different X12 specifications, called transaction sets.

Prior authorizations use X12’s 278 Health Care Services Review Information transaction set. Claims, including predetermination claims, use X12’s 837 Health Care Claim transaction set. The 837 transaction set has different X12 implementation guides – called Type 3 Technical Reports (TR3s) – for professional (837P), dental (837D), and institutional (837I) claims.

You can submit 837P professional, 837D dental, and 837I institutional claims as X12 using Stedi’s SFTP or our X12 API. However, most Stedi customers use our JSON API or the Stedi portal. In these cases, we translate the JSON claim data into a HIPAA-compliant 837 X12 transaction for you.

Note: Stedi doesn’t currently support 278 prior authorization transactions.

Everyday usage

If you’re using Stedi’s JSON API or the Stedi portal, you don’t need to be familiar with X12 or the specs for specific transaction sets. However, people often refer to a transaction or claim type by its X12 transaction set or TR3. For example, you may hear people refer to an electronic dental claim as an “837D” or an “837D dental claim.”

Send a dental predetermination claim

With Stedi, you send a predetermination claim the same way you would a normal claim – just with special values.

To send a dental predetermination claim, submit an 837D claim with the following values:


JSON 837D Dental Claim Submission API

837D Dental Claim X12

Notes

Mark the claim as a predetermination

claimInformation.predeterminationOfBenefits is true

CLM19 (Predetermination of Benefits Code) is PB (Predetermination of Benefits Code) in Loop 2300 (Claim Information)


Omit the claim service date

claimInformation.claimDateInformation.serviceDate is omitted

DTP03 (Service Date) is omitted in Loop 2300 (Claim Information)

Predeterminations don’t include a service date because they’re submitted before care is given.

Omit service line dates

Each claimInformation.serviceLines[].serviceDate is omitted

DTP03 (Service Date) is omitted in each Loop 2400 (Service Line Number)

Predeterminations don’t include a service date because they’re submitted before care is given.

 For example, in a Dental Claims (837D) JSON API request body:

{
  "claimInformation": {
    ...
    "predeterminationOfBenefits": true,  // Mark the claim as a predetermination
    "claimDateInformation": {
      ...  // Omit the claim service date
    },
    "serviceLines": [
      {
        ...  // Omit service line dates
      },
      ...
    ]
  },
  ...
}

Predetermination in 835 ERAs

Once submitted, the predetermination claim will follow the same lifecycle as a standard claim.

First, one or more 277CA claim acknowledgments arrive within a few business days. Then, an 835 ERA follows. For standard claims, ERAs and any related payments typically arrive in 7-20 business days. ERAs for predetermination claims may arrive sooner, since no payment is issued. For more information on enrolling, listening for, and retrieving ERAs, see our ERA docs.

Claim payment status code

In an ERA, a claim payment status code tells you – at a high level – how the payer processed and paid a claim. A claim payment status code of 25 (Predetermination Pricing Only - No Payment) indicates the ERA is for a predetermination claim. You can find this code in the following locations:

For example, in a JSON 835 ERA API response:

{
  "transactions": [
    {
      "detailInfo": [
        {
          "paymentInfo": [
            {
              "claimPaymentInfo": {
                "claimStatusCode": "25",  // Indicates the ERA is a predetermination
                ...
              },
              ...
            },
          ],
          ...
        }
      ],
      ...
    }
  ],
  ...
}

Predetermination of benefits identification numbers

Payers may include one or more predetermination of benefits identification numbers in the ERA. You can use these numbers to link the estimate to a future claim.

The numbers can appear at the claim level, the service line level, or both:

Level

JSON 835 ERA API field value

835 ERA X12 element values

Claim level

otherClaimRelatedIdentification.predeterminationOfBenefitsIdentificationNumber

In Loop 2100 (Claim Payment Information):

  • REF01 (Reference Identification Qualifier) is G3 (Predetermination of Benefits Identification Number).

  • REF02 (Other Claim Related Identifier) is the predetermination of benefits identification number.

Service line item level

serviceLines[].serviceIdentification.preDeterminationOfBenefitsIdentificationNumber

In Loop 2110 (Service Payment Information):

  • REF01 is G3.

  • REF02 is the predetermination of benefits identification number.

For example, in a JSON 835 ERA API response:

{
  "transactions": [
    {
      "detailInfo": [
        {
          "paymentInfo": [
            {
              "otherClaimRelatedIdentification": {
                "predeterminationOfBenefitsIdentificationNumber": "1234567890", // Claim-level predetermination of benefits identification number
                ...
              },
              "serviceLines": [
                {
                  "serviceIdentification":{
                     "preDeterminationOfBenefitsIdentificationNumber": "0978654321", // Service-line-item-level predetermination of benefits identification number
                     ...
                  },
                  ...
                }
              ]
            },
            ...
          ]
        }
      ]
    }
  ],
  ...
}

Estimated provider payment amounts

Predeterminations often include estimated payment amounts for the provider. These estimates, included in the ERA as adjustments, are typically marked with a Claim Adjustment Reason Code (CARC) of 101 (Predetermination: anticipated payment upon completion of services or claim adjudication).

The CARC and its related adjustment may appear at the claim level, the service line level, or both:

Level

JSON 835 ERA API field value

835 ERA X12 element value

Claim level

claimAdjustments[].adjustmentReasonCode<N> is 101

In Loop 2100 (Claim Payment Information), CAS02 (Adjustment Reason Code) is 101.

Service line item level

serviceAdjustments[].adjustmentReasonCode<N> is 101

In Loop 2110 (Service Payment Information), CAS02 (Adjustment Reason Code) is 101.

{
  "transactions": [
    {
      "detailInfo": [
        {
          "paymentInfo": [
            {
              "claimAdjustments": [
                {
                  "adjustmentAmount1": "3000",    // Claim-level estimated payment
                  "adjustmentReasonCode1": "101", // Claim-level CARC for predetermination
                  ...
                }
              ],
              "serviceLines": [
                {
                  "serviceAdjustments": [
                    {
                      "adjustmentAmount1": "1000",    // Service-line-item-level estimated payment
                      "adjustmentReasonCode1": "101", // Service-line-item-level CARC for predetermination
                      ...
                    }
                  ],
                  ...
                }
              ]
            },
            ...
          ],
          ...
        }
      ],
      ...
    }
  ],
  ...
}

Linking the actual claim to the predetermination

After the provider provides treatment and is ready to bill the payer, you submit a dental claim to request actual payment. Submit the claim as normal:

  • Do NOT mark it for predetermination.

  • Include service dates at the claim and service line item levels.

If the payer returned predetermination of benefits identification numbers in the predetermination’s ERA, you can include them in the final claim to link the claim back to the estimate. Use the following fields:

Level

JSON 837D Dental Claim Submission API field

837D Dental Claim X12 elements

Claim level

claimSupplementalInformation.predeterminationOfBenefitsIdentifier

In Loop 2300 (Claim Information):

  • REF01 (Reference Identification Qualifier) should be G3 (Predetermination of Benefits Identification Number).

  • REF02 (Other Claim Related Identifier) should be predetermination of benefits identification number.

Service line item level

serviceLineReferenceInformation.predeterminationOfBenefits

In Loop 2400 (Service Line Number):

  • REF01 (Reference Identification Qualifier) should be G3 (Predetermination of Benefits Identification Number).

  • REF02 (Other Claim Related Identifier) should be the predetermination of benefits identification number.

 For example, in a Dental Claims (837D) JSON API request body:

{
  "claimInformation": {
    ...
    "predeterminationOfBenefits": false,  // You can also omit this field. It defaults to false.
    "claimSupplementalInformation": {
      "predeterminationOfBenefitsIdentifier": "1234567890", // Claim-level predetermination of benefits identification number
      ...
    },
    "claimDateInformation": {
      "serviceDate": "20260428",  // Include the claim service date
      ...
    },
    "serviceLines": [
      {
        "serviceDate": "20260428",  // Include the service-line-item service date
        "serviceLineReferenceInformation": {
          "predeterminationOfBenefits": "0978654321", // Service-line-item-level predetermination of benefits identification number
          ...
        }
      }
    ],
    ...
  },
  ...
}

Process claims and ERAs with Stedi

You can use Stedi to submit and track predetermination claims – and receive the related ERAs.

You can start for free. Our Basic plan includes 100 free claim submissions and ERAs for up to 100 paid claims each month.

Signup takes less than two minutes. No credit card required.

A predetermination claim – also called a predetermination of benefits or a pre-treatment estimate – is a dental claim sent to a payer before care is delivered. They’re used by dental providers to find out two things:

  1. Whether the patient's plan covers a service or treatment.

  2. What the payer is likely to pay for the claim, including what the patient may owe.

Most claims are requests for payment – they’re essentially bills from a provider to a payer. A predetermination claim isn’t. It’s more like a dry run of a claim for cost estimation purposes.

This guide explains how predetermination claims work and how to interpret predeterminations in Electronic Remittance Advice (ERAs).

Important: This guide covers predeterminations for dental services. In most cases, medical services – like those covered by professional and institutional claims – use prior authorizations instead.

When are predetermination claims used?

In dental care, predetermination claims are commonly used for expensive treatments, like crowns, wisdom tooth removal, dentures, or periodontal surgery.

Some dental payers, such as Delta Dental, encourage patients and providers to use predetermination to help patients budget (and ensure providers are paid) for major dental procedures.

Predeterminations are estimates, not guarantees

However, the amounts returned by predetermination claims are estimates, not guarantees. They reflect eligibility and remaining benefits at the time the predetermination is processed. If coverage changes before the final claim is submitted, the final payment can change too.

Differences between predetermination claims and prior authorizations

Payers sometimes require approval – called prior authorization – before they’ll cover certain services.

That required-ness is the key difference. Prior authorization is required for coverage. Predetermination isn’t.

Predetermination may be encouraged by the payer to estimate provider payment and patient responsibility, but it’s optional.

Electronic X12 transactions

Another major difference between predetermination and prior authorization is the transaction you use to exchange them electronically.

HIPAA is a U.S. federal law that, among other things, requires that certain electronic transactions use the standardized X12 EDI format. Under HIPAA, prior authorizations and claims must use different X12 specifications, called transaction sets.

Prior authorizations use X12’s 278 Health Care Services Review Information transaction set. Claims, including predetermination claims, use X12’s 837 Health Care Claim transaction set. The 837 transaction set has different X12 implementation guides – called Type 3 Technical Reports (TR3s) – for professional (837P), dental (837D), and institutional (837I) claims.

You can submit 837P professional, 837D dental, and 837I institutional claims as X12 using Stedi’s SFTP or our X12 API. However, most Stedi customers use our JSON API or the Stedi portal. In these cases, we translate the JSON claim data into a HIPAA-compliant 837 X12 transaction for you.

Note: Stedi doesn’t currently support 278 prior authorization transactions.

Everyday usage

If you’re using Stedi’s JSON API or the Stedi portal, you don’t need to be familiar with X12 or the specs for specific transaction sets. However, people often refer to a transaction or claim type by its X12 transaction set or TR3. For example, you may hear people refer to an electronic dental claim as an “837D” or an “837D dental claim.”

Send a dental predetermination claim

With Stedi, you send a predetermination claim the same way you would a normal claim – just with special values.

To send a dental predetermination claim, submit an 837D claim with the following values:


JSON 837D Dental Claim Submission API

837D Dental Claim X12

Notes

Mark the claim as a predetermination

claimInformation.predeterminationOfBenefits is true

CLM19 (Predetermination of Benefits Code) is PB (Predetermination of Benefits Code) in Loop 2300 (Claim Information)


Omit the claim service date

claimInformation.claimDateInformation.serviceDate is omitted

DTP03 (Service Date) is omitted in Loop 2300 (Claim Information)

Predeterminations don’t include a service date because they’re submitted before care is given.

Omit service line dates

Each claimInformation.serviceLines[].serviceDate is omitted

DTP03 (Service Date) is omitted in each Loop 2400 (Service Line Number)

Predeterminations don’t include a service date because they’re submitted before care is given.

 For example, in a Dental Claims (837D) JSON API request body:

{
  "claimInformation": {
    ...
    "predeterminationOfBenefits": true,  // Mark the claim as a predetermination
    "claimDateInformation": {
      ...  // Omit the claim service date
    },
    "serviceLines": [
      {
        ...  // Omit service line dates
      },
      ...
    ]
  },
  ...
}

Predetermination in 835 ERAs

Once submitted, the predetermination claim will follow the same lifecycle as a standard claim.

First, one or more 277CA claim acknowledgments arrive within a few business days. Then, an 835 ERA follows. For standard claims, ERAs and any related payments typically arrive in 7-20 business days. ERAs for predetermination claims may arrive sooner, since no payment is issued. For more information on enrolling, listening for, and retrieving ERAs, see our ERA docs.

Claim payment status code

In an ERA, a claim payment status code tells you – at a high level – how the payer processed and paid a claim. A claim payment status code of 25 (Predetermination Pricing Only - No Payment) indicates the ERA is for a predetermination claim. You can find this code in the following locations:

For example, in a JSON 835 ERA API response:

{
  "transactions": [
    {
      "detailInfo": [
        {
          "paymentInfo": [
            {
              "claimPaymentInfo": {
                "claimStatusCode": "25",  // Indicates the ERA is a predetermination
                ...
              },
              ...
            },
          ],
          ...
        }
      ],
      ...
    }
  ],
  ...
}

Predetermination of benefits identification numbers

Payers may include one or more predetermination of benefits identification numbers in the ERA. You can use these numbers to link the estimate to a future claim.

The numbers can appear at the claim level, the service line level, or both:

Level

JSON 835 ERA API field value

835 ERA X12 element values

Claim level

otherClaimRelatedIdentification.predeterminationOfBenefitsIdentificationNumber

In Loop 2100 (Claim Payment Information):

  • REF01 (Reference Identification Qualifier) is G3 (Predetermination of Benefits Identification Number).

  • REF02 (Other Claim Related Identifier) is the predetermination of benefits identification number.

Service line item level

serviceLines[].serviceIdentification.preDeterminationOfBenefitsIdentificationNumber

In Loop 2110 (Service Payment Information):

  • REF01 is G3.

  • REF02 is the predetermination of benefits identification number.

For example, in a JSON 835 ERA API response:

{
  "transactions": [
    {
      "detailInfo": [
        {
          "paymentInfo": [
            {
              "otherClaimRelatedIdentification": {
                "predeterminationOfBenefitsIdentificationNumber": "1234567890", // Claim-level predetermination of benefits identification number
                ...
              },
              "serviceLines": [
                {
                  "serviceIdentification":{
                     "preDeterminationOfBenefitsIdentificationNumber": "0978654321", // Service-line-item-level predetermination of benefits identification number
                     ...
                  },
                  ...
                }
              ]
            },
            ...
          ]
        }
      ]
    }
  ],
  ...
}

Estimated provider payment amounts

Predeterminations often include estimated payment amounts for the provider. These estimates, included in the ERA as adjustments, are typically marked with a Claim Adjustment Reason Code (CARC) of 101 (Predetermination: anticipated payment upon completion of services or claim adjudication).

The CARC and its related adjustment may appear at the claim level, the service line level, or both:

Level

JSON 835 ERA API field value

835 ERA X12 element value

Claim level

claimAdjustments[].adjustmentReasonCode<N> is 101

In Loop 2100 (Claim Payment Information), CAS02 (Adjustment Reason Code) is 101.

Service line item level

serviceAdjustments[].adjustmentReasonCode<N> is 101

In Loop 2110 (Service Payment Information), CAS02 (Adjustment Reason Code) is 101.

{
  "transactions": [
    {
      "detailInfo": [
        {
          "paymentInfo": [
            {
              "claimAdjustments": [
                {
                  "adjustmentAmount1": "3000",    // Claim-level estimated payment
                  "adjustmentReasonCode1": "101", // Claim-level CARC for predetermination
                  ...
                }
              ],
              "serviceLines": [
                {
                  "serviceAdjustments": [
                    {
                      "adjustmentAmount1": "1000",    // Service-line-item-level estimated payment
                      "adjustmentReasonCode1": "101", // Service-line-item-level CARC for predetermination
                      ...
                    }
                  ],
                  ...
                }
              ]
            },
            ...
          ],
          ...
        }
      ],
      ...
    }
  ],
  ...
}

Linking the actual claim to the predetermination

After the provider provides treatment and is ready to bill the payer, you submit a dental claim to request actual payment. Submit the claim as normal:

  • Do NOT mark it for predetermination.

  • Include service dates at the claim and service line item levels.

If the payer returned predetermination of benefits identification numbers in the predetermination’s ERA, you can include them in the final claim to link the claim back to the estimate. Use the following fields:

Level

JSON 837D Dental Claim Submission API field

837D Dental Claim X12 elements

Claim level

claimSupplementalInformation.predeterminationOfBenefitsIdentifier

In Loop 2300 (Claim Information):

  • REF01 (Reference Identification Qualifier) should be G3 (Predetermination of Benefits Identification Number).

  • REF02 (Other Claim Related Identifier) should be predetermination of benefits identification number.

Service line item level

serviceLineReferenceInformation.predeterminationOfBenefits

In Loop 2400 (Service Line Number):

  • REF01 (Reference Identification Qualifier) should be G3 (Predetermination of Benefits Identification Number).

  • REF02 (Other Claim Related Identifier) should be the predetermination of benefits identification number.

 For example, in a Dental Claims (837D) JSON API request body:

{
  "claimInformation": {
    ...
    "predeterminationOfBenefits": false,  // You can also omit this field. It defaults to false.
    "claimSupplementalInformation": {
      "predeterminationOfBenefitsIdentifier": "1234567890", // Claim-level predetermination of benefits identification number
      ...
    },
    "claimDateInformation": {
      "serviceDate": "20260428",  // Include the claim service date
      ...
    },
    "serviceLines": [
      {
        "serviceDate": "20260428",  // Include the service-line-item service date
        "serviceLineReferenceInformation": {
          "predeterminationOfBenefits": "0978654321", // Service-line-item-level predetermination of benefits identification number
          ...
        }
      }
    ],
    ...
  },
  ...
}

Process claims and ERAs with Stedi

You can use Stedi to submit and track predetermination claims – and receive the related ERAs.

You can start for free. Our Basic plan includes 100 free claim submissions and ERAs for up to 100 paid claims each month.

Signup takes less than two minutes. No credit card required.

Share

Twitter
LinkedIn

Get started with Stedi

Get started with Stedi

Automate healthcare transactions with developer-friendly APIs that support thousands of payers. Contact us to learn more and speak to the team.

Get updates on what’s new at Stedi

Get updates on what’s new at Stedi

Get updates on what’s new at Stedi

Get updates on what’s new at Stedi

Backed by

Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.

Get updates on what’s new at Stedi

Backed by

Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.

Get updates on what’s new at Stedi

Backed by

Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.