How to run transaction enrollment at scale

Transaction enrollment registers a provider to exchange specific transaction types with a payer. For Electronic Remittance Advice (ERAs), enrollment is always required. For other types of transactions, enrollment requirements depend on the payer.

Most traditional clearinghouses treat transaction enrollment as a cost center. Because ERA revenue is small, they try to minimize their involvement and put the work on you. You end up filling out PDFs, chasing signatures, and checking portal statuses just to onboard a provider.

Many Stedi customers manage transaction enrollment for hundreds or thousands of providers. At that scale, enrollment can be an operational burden. One team told us that before switching to Stedi, their staff spent 25–30% of their time just managing enrollment requests.

At Stedi, we treat transaction enrollment as a core part of our product experience. We offer fully managed, API-based transaction enrollment designed to reduce operational overhead, eliminate manual steps, and improve visibility. So you can scale provider onboarding without scaling manual work.

This guide explains how transaction enrollment works at Stedi, how we designed it, and how to manage enrollments at scale. It incorporates practices we’ve seen high-scaling teams use to streamline provider onboarding.

Types of enrollment

Transaction enrollment is just one part of the broader enrollment process. It’s the final step – and the only one that involves working with your clearinghouse. Providers typically complete three types of enrollment to work with a payer:

• Credentialing – Verifies licenses, training, and qualifications.
  
  

• Payer enrollment – Registers the provider with specific insurance plans. This is typically when providers set rates with a payer.
  
  

• Transaction enrollment – Enables the provider to exchange transactions through a clearinghouse.

This guide focuses only on transaction enrollment. For help with credentialing or payer enrollment, contact the payer or a credentialing service, like CAQH, Assured, or Medallion.

Transaction enrollment as a product

At Stedi, we take on as much of the transaction enrollment process as possible and work constantly to automate the rest. If a manual step is required, it’s built into the product with clear next steps and full visibility.

Our goal is to eliminate back-and-forth. You shouldn’t need to track spreadsheets or email threads to onboard a provider.

Key parts of this approach include:

• API-first design – Submit and track enrollment requests programmatically using the Enrollments API. Built for automation at scale, with full visibility into status and next steps. We also support UI and bulk CSV upload.
  
  

• One-click enrollment – For payers that support one-click enrollment, just submitting an enrollment request is enough. You don’t need to take any additional steps. One-click enrollment is available for 850+ payers. You can check support using the Payers API or the Payer Network.
  
  

• Delegated signature authority – For payers that still require signed forms, you can authorize Stedi to sign on your behalf. It’s a one-time setup that can eliminate 90% of your enrollment paperwork.
  
  

• Streamlined timelines – Enrollment timelines vary by payer, but most enrollments through Stedi complete in 24-48 hours.

When enrollment is required

Before exchanging transactions with a payer, check whether enrollment is required for the transaction type. Common requirement patterns:

• 835 ERAs. Always require enrollment. Payers can only send a provider’s ERAs to one clearinghouse at a time, so they need to know where to route them.

• 270/271 eligibility checks. A few payers, including Medicare, require enrollment. Most major payers don’t.

• 837P/837D/837I claim submissions. Most major payers don’t require enrollment, but certain payers do – TRICARE West Region and TRICARE East are two examples that do.

Use the Stedi Payer Network or Payers API to see which payers require enrollment by transaction type.

For example, the following JSON payer record from the Payers API indicates enrollment is required for 835 ERAs (claimPayment):

{
  "displayName": "Blue Cross Blue Shield of North Carolina",
  "primaryPayerId": "BCSNC",
  ...
  "transactionSupport": {
    "claimPayment": "ENROLLMENT_REQUIRED",
   ...
  }
}

How to submit an enrollment request

If a transaction type requires enrollment, Stedi’s Enrollments API lets you automate related requests at scale. Here’s how it works:

Step 1. Create a provider record.
Use the Create Provider endpoint to submit the provider’s basic information:

• Name
  
  

• NPI
  
  

• Tax ID – Either an Employer Identification Number (EIN) or Social Security Number (SSN), depending on whether the provider is a corporate entity or not.
  
  

• Contacts – Information for one or more provider contacts.
  
  Ensure this contact information – excluding email and phone number – matches what the payer has on record for the provider. Some payers reject enrollment requests if the name or address doesn’t match what’s already on file.
  
  The payer may use the provided email and phone to reach out with enrollment steps. If you’re a vendor representing a provider, you can use your own email and phone to have the payer contact you instead.
  
  When creating an enrollment request in Stedi, you must select one of these contacts as the primary contact.

curl --request POST \
  --url "https://enrollments.us.stedi.com/2024-09-01/providers" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "Bob Dental Inc",
    "npi": "1999999992",
    "taxIdType": "EIN",
    "taxId": "555123456",
    "contacts": [
      {
        "firstName": "Bob",
        "lastName": "Dentist",
        "email": "bob@example.com",
        "phone": "555-123-2135",
        "streetAddress1": "123 Some Street",
        "city": "Chevy Chase",
        "zipCode": "20814",
        "state": "MD"
      },
    ]
  }'

The request returns an id for the provider. You can use this ID to reference the provider record across multiple enrollment requests.

{
  ...
  "id": "10334e76-f073-4b5d-8984-81d8e5107857",
  "name": "Bob Dental Inc",
  "npi": "1999999992",
  ...
}

Step 2. Submit the enrollment request.
Use the Create Enrollment endpoint to submit the actual transaction enrollment request.

In the request, specify:

• The provider ID, returned by the Create Provider endpoint or fetched using the List Providers endpoint.
  
  

• The payer ID. You can get this using the Payers API.
  
  

• The transaction types (for example,  claimPayment, eligibilityCheck) you want to enroll the provider for.
  
  

• A primary contact – One of the contacts from the provider record.
  
  

• A userEmail address. Stedi will send notifications for enrollment status updates to this email address. If you’re a vendor representing a provider, you can use your own email address here.

curl --request POST \
  --url "https://enrollments.us.stedi.com/2024-09-01/enrollments" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "transactions": {
      "claimPayment": {
        "enroll": true
      }
    },
    "primaryContact": {
      "firstName": "John",
      "lastName": "Doe",
      "email": "test@example.com",
      "phone": "555-123-4567",
      "streetAddress1": "123 Some Str.",
      "city": "A City",
      "state": "MD",
      "zipCode": "20814"
    },
    "userEmail": "test@example.com",
    "payer": {
      "idOrAlias": "87726"
    },
    "provider": {
      "id": "db6665c5-7b97-4af9-8c68-a00a336c2998"
    },
    "source": "API"
  }'

Step 3. Track enrollment status
Each enrollment request moves through a defined set of statuses.

You can track the status of enrollment requests using the List Enrollments endpoint or the Stedi portal.

The endpoint lets you pull the status of every request and filter by status or transaction type. This lets you build custom views into your own systems or dashboards. For example:

curl --request GET \
  --url "https://enrollments.us.stedi.com/2024-09-01/enrollments?status=LIVE" \
  --header "Authorization: <api_key>"

You’ll also get email notifications whenever an enrollment status changes, like when it moves from PROVISIONING to LIVE, or if it's rejected. If an enrollment requires action on your part, we’ll reach out to you using Slack, Teams, or email with clear next steps.

Get started

Fully managed transaction enrollment is available on all paid Stedi plans.

If you’re not yet a customer, request a free trial. We get most teams up and running in under a day.