Stedi’s October 2026 updates give dental billing teams several specific items to review: provider taxonomy, claim frequency codes, authorization references, attachment details, and secondary-claim remark codes. The month also brought changes to rejection filtering and eligibility workflows.
For a practice submitting electronic dental claims through Stedi, the priority is to check how these changes affect its actual software configuration. A clearinghouse update does not establish that every practice management system exposes the same features. This DentalXpand guide explains the published changes and turns them into practical checks for billing teams.
Published by DentalXpand. Sources checked November 5, 2026; announcements covered October 9–28, 2026.
Dental claim validation changes to review first
An 837D is the electronic transaction used for dental claims. Several October updates add checks that can stop an invalid claim before Stedi forwards it to the payer. Passing those checks does not guarantee coverage or payment.
Billing provider taxonomy when no other treating provider is reported
On October 9, 2026, Stedi announced an edit rejecting 837D claims without a billing provider taxonomy code when neither a rendering provider nor an assistant surgeon appears anywhere on the claim. That includes both the claim level and individual service lines. In this situation, the billing provider is treated as the provider who performed the service. Read Stedi’s dental taxonomy update.
Review provider setup and a sample of outgoing claims together. If the condition applies, confirm that the correct billing provider taxonomy reaches the submission. Do not add an unrelated rendering provider simply to bypass the edit. For technical teams, Stedi identifies the dental JSON field as billing.taxonomyCode.
Valid claim frequency codes for original, replacement, and void claims
Another October 9 edit checks whether the frequency code is valid for the transaction type. For 837D dental claims, Stedi lists three accepted values:
- 1: Original claim.
- 7: Replacement of a prior claim.
- 8: Void or cancellation of a prior claim.
Review how your software translates staff actions such as “resubmit” or “correct” into a frequency code. A valid code must still match the intended action. Before choosing a replacement or void, check the claim’s history and the payer’s submission instructions rather than assuming every correction needs code 7. Read Stedi’s frequency-code update.
Prior authorization and referral numbers need separate handling
Stedi’s October 9 update rejects claims that use the same value for a prior authorization number and a referral number. The comparison ignores letter case and checks both claim-level and service-line information, including certain comparisons between the two levels. A prior authorization and a referral serve different purposes, so copying one identifier into both fields can cause a rejection. Read the authorization and referral matching rule.
An October 21 update adds another check: an 837D service line can report only one prior authorization number and one referral number for the payer receiving the claim. Another payer’s authorization can be identified separately using that payer’s identifier. Stedi’s JSON API does not support payer identifiers for referral numbers, so it permits only one referral number per service line. Read the service-line reference update.
Audit templates that automatically copy these values. Use the actual authorization or referral documentation to resolve duplicates, and ask your software vendor how it associates references with the correct payer.
Attachments marked available on request must omit the control number
The October 16 attachment edit applies when the transmission code is AA, meaning the attachment is available on request at the provider’s site. Stedi rejects a claim that combines this code with an attachment control number. For 837D claims, the published fields are at the claim level. Read Stedi’s attachment update.
Check whether your system automatically inserts a control number when staff select “available on request.” The transmission method should accurately describe what happened to the attachment. Do not remove control numbers from every claim, or mark a required submission as available on request merely to pass validation. Review the payer’s documentation requirements and the actual attachment workflow.
Secondary claims need remark codes valid on the adjudication date
On October 19, Stedi added validation for prior-payer remark codes in coordination of benefits (COB) claims. Each reported Remittance Advice Remark Code (RARC) must be valid and must have been active on the date the previous payer adjudicated the claim. Checking only whether a code is active today can miss that date-specific requirement. Read Stedi’s COB remark-code update.
When preparing a secondary dental claim, compare the entered remark codes and adjudication date with the primary payer’s explanation of benefits or electronic remittance advice. Investigate transcription errors and software mapping issues. If the source document itself appears inconsistent, clarify it rather than substituting a code that changes the payer’s meaning.
Separate Stedi rejections from payer rejections
On October 23, Stedi added “By Stedi” and “By payer” options under the portal’s Rejected filter. A Stedi rejection occurs before the claim is sent to the payer. A payer rejection occurs before adjudication and may happen after the payer acknowledges receipt. Read Stedi’s rejection-filter update.
Use those categories to organize follow-up. Review recurring Stedi errors for data-entry or mapping problems, and group payer rejections by payer to investigate repeated patterns. Record the error, correction, owner, and next action for each claim.
Keep rejection follow-up separate from denial management. Receipt alone does not establish adjudication or payment, and the correct next step depends on the claim’s actual status.
For more background on the outputs your team may review, see our guide to benefits, claim status, and remittance workflows.
Eligibility and claim status workflow improvements
Missing provider names can be filled from NPPES
Stedi’s October 28 update makes provider names optional in specified eligibility and claim status endpoints. When the required name is missing, Stedi looks up the NPI and uses the primary name from an active National Plan and Provider Enumeration System (NPPES) record when available. It does not replace a name already supplied, including a placeholder. This announcement concerns eligibility and claim status checks, not claim submission. Read Stedi’s provider-name update.
Ask your integration owner whether requests send unnecessary placeholders. Stedi recommends omitting the name unless there is reason to use a different payer-specific name. Check the applicable endpoint before changing your workflow, and investigate unexpected benefit responses rather than assuming every name mismatch has been resolved.
Eligibility PDFs become available sooner after a completed check
On October 20, Stedi reported that eligibility PDFs are typically ready within milliseconds after a check completes, with a small number taking slightly longer than one second. The retrieval endpoint returns HTTP 404 until the PDF is ready. The endpoint and PDF format are unchanged. Read Stedi’s eligibility PDF update.
This change reduces the wait for the document after the response; it is not a claim that the eligibility check itself completes in milliseconds. If your workflow retrieves PDFs automatically, have the integration owner review any fixed delay while retaining appropriate handling for a PDF that is not ready yet.
A practical review plan for your dental billing team
Start with a small sample of recent submissions and rejected claims. A focused review is easier to act on than changing every template at once.
- Confirm your submission route. Identify which claims and checks use Stedi, and whether staff work through its portal, an API integration, or another application.
- Trace fields from entry to submission. Compare what staff see with what the software actually sends, especially when a default or copied value is involved.
- Assign each recurring error. Separate staff training issues from provider-record corrections and software mapping changes.
- Test before broad rollout. Have the appropriate team verify revised mappings or templates in a suitable test workflow before applying them widely.
- Measure the result. Track rejection reasons and correction time consistently. Use your own results to judge improvement rather than assuming a clearinghouse update guarantees faster payment.
For dental practice leaders, the most useful next step is a short review with the billing lead and software vendor. Confirm which changes apply, choose the highest-volume recurring problem, and document how the team should correct it.
For billing companies serving multiple client practices, explore DentalXpand’s dental billing company software to review client-specific workflows, PMS action scope and exception ownership.
To review the work around eligibility checks and team handoffs, explore DentalXpand’s dental insurance verification workflows or request a workflow demo. Discuss your actual payer connections and software configuration; this article does not announce a DentalXpand integration or feature release. Please keep patient information out of demo requests.
Frequently asked questions
Does every dental claim need a billing provider taxonomy code under this new edit?
The October 9 Stedi edit is conditional. It rejects a missing billing provider taxonomy when no rendering provider or assistant surgeon is reported at either claim or service-line level. Review other applicable payer requirements separately.
Should every corrected dental claim use frequency code 7?
No. Code 7 identifies a replacement claim. Determine whether you are replacing an existing claim or correcting a rejected submission, and follow the receiving payer’s instructions.
Does the provider-name update fix names on submitted claims?
No. The announced change applies to specified eligibility and claim status checks. It fills missing names and does not overwrite names already sent.
Do faster eligibility PDFs mean faster insurance verification?
The announced speed improvement concerns PDF availability after an eligibility check finishes. It does not establish a faster payer response or guarantee that the returned benefits answer every coverage question.
This article summarizes Stedi announcements published October 9–28, 2026. Availability within a practice’s software depends on its integration. Verify current payer instructions and product documentation before changing a billing workflow.
