> ## Documentation Index > Fetch the complete documentation index at: https://dso.getlemma.com/llms.txt > Use this file to discover all available pages before exploring further. # Step 10: Submit your first claim > Turn a real patient visit into an 837D claim: benefit verification, CDT coding with tooth and surface data, attachments, a predetermination for the crown, and the acknowledgments that come back. A **claim** is a structured request for payment sent by the billing provider to a payer. It identifies the patient, rendering provider, services, and dental anatomy. An electronic dental claim uses the **X12 837D** transaction. This step follows one visit from scheduling through claim acceptance. ## What Bluebird did Mrs. Alvarez, 46, booked as a new patient. The front desk verified eligibility two days before the visit and again at check-in: coverage active, \$\$1,500 annual maximum untouched, preventive covered at 100%, no waiting periods. Dr. Okafor did a comprehensive exam and radiographs, the hygienist a prophylaxis, and Dr. Okafor placed a one-surface composite on a lower molar and treatment-planned a crown on another. The biller entered charges that afternoon, the scrubber flagged a missing tooth surface on the composite line, the biller fixed it, and the claim went out that evening, with a **predetermination** for the crown right behind it. A 999 came back in minutes and a 277CA the next morning, both clean. ## The seven stages of one claim Before the visit, your system sends a **270** eligibility inquiry and the payer returns a **271** response: is coverage active on the date of service, what plan, what deductible remains. Dental verification has to go further than "active," because plan design determines what you collect: **remaining annual maximum**, coverage tiers (the "100/80/50" skeleton), **frequency history** (a prophylaxis already used this period will not pay again), missing tooth clause, waiting periods, and downgrade behavior. Do the 270/271 twice, at scheduling and at check-in, and **save the 271 response**; it is your evidence in an appeal. See [Verify eligibility and benefits](/guides/billing/verify-eligibility) and [Bill dental claims](/guides/billing/run-the-dental-billing-cycle). Collect the estimated patient share under the plan's coverage tiers, including amounts expected to exceed the remaining maximum. Explain that the final balance may change after adjudication. See [Deductibles, coinsurance, and patient balances](/concepts/payments/patient-responsibility). The dentist records findings, radiographs, periodontal charting, and the treatment plan in the PMS. The DSO may provide the system, but the clinical record belongs under the practice's professional control. The chart must support the submitted code, and radiographs or other clinical material may also serve as claim attachments. The practice should be able to connect each billed service to the contemporaneous record. See [Billing compliance: the lines you never cross](/concepts/compliance/billing-compliance-basics). Dental claims carry two kinds of data doing two different jobs: * **CDT codes:** five characters consisting of a “D” and four digits; they identify *what you did* * **Tooth number, surfaces, and quadrant/arch designations** say *where* ICD-10-CM diagnosis codes appear when the payer requires them, including in some Medicaid dental programs. Dental claims also depend on tooth, surface, and oral-cavity information. In this example, the service lines include an evaluation, radiographs, a prophylaxis, and **D2391**, a one-surface posterior resin-based composite, with the tooth number and surface reported. The treating dentist retains authority over code selection. Operations should make sure the chart supports each code, the CDT tables are current for the date of service, and the claim carries the required tooth, surface, and other fields. Assigning codes remains the PC's responsibility rather than the DSO's. See [CDT & the 837D](/reference/edi/cdt-and-837d). Two dental-specific moves happen before or alongside submission. **Attachments.** Dental payers may require radiographs, periodontal charts, and narratives for crowns, scaling and root planing, implants, buildups, and other procedures. One current workflow uses **NEA FastAttach** or another attachment service to issue a reference number that is reported on the claim.1 Follow the payer's documentation policy so the claim does not pend for a later information request. The X12 275 claims-attachment standard has a May 2028 compliance date.2 See [Dental attachments](/reference/edi/dental-attachments). **The predetermination.** For the crown Dr. Okafor treatment-planned, Bluebird submitted a **predetermination** using an 837D marked as a predetermination request and a radiograph attached through an NEA number. The payer returns an estimate that the patient can review before treatment. A predetermination is **not a guarantee** because final adjudication uses eligibility, the remaining maximum, and frequency limits on the date of service.3 **Preauthorization** is different: some payers, particularly Medicaid dental plans and DHMOs, require approval before specified procedures are payable. See [Get predeterminations](/guides/billing/get-predeterminations). The biller enters the charges. A **scrubber** in the PMS, clearinghouse, or both checks the claim against payer-specific edits before submission. Common checks include current CDT codes, consistent tooth and surface data, NPI and taxonomy alignment, and an attachment reference when required. Resolve scrubber edits before submission. They are generally faster to correct than a payer rejection or denial. See [Submit clean claims](/guides/billing/submit-clean-claims). The 837D identifies the **billing provider** (the PC, its Type 2 NPI, EIN, and address), the **rendering dentist** (Dr. Okafor and her Type 1 NPI), the **subscriber and patient**, and the **claim**. Each procedure has a service line with its CDT code, charge, units, and any applicable tooth, surface, or oral-cavity information. See [The 837: how claims are told to payers](/concepts/payments/understanding-837d) and [837 file anatomy](/reference/edi/837d-anatomy). Several come back, and they are not the same thing. | Acknowledgment | From | Means | | -------------- | --------------------- | --------------------------------------------------------------------------------------- | | **TA1** | Interchange level | The file envelope itself was or wasn't readable | | **999** | Clearinghouse / payer | The file was syntactically valid X12 (or wasn't) | | **277CA** | Payer | The payer **accepted the claim into adjudication** (or rejected it before adjudication) | A **277CA rejection is not a denial.** The claim never entered adjudication, no benefit determination was made, and the rejection usually does not stop the timely filing clock. Correct and resubmit it promptly. See [X12 transaction sets](/reference/edi/x12-transaction-sets). ## Rejection versus denial The distinction determines the next step. A rejected claim did not enter adjudication, while a denied claim did. | | Rejection | Denial | | ----------------- | ----------------------------------- | -------------------------------------------------- | | **Where** | Clearinghouse or payer front end | Payer adjudication | | **Signalled by** | 999 or 277CA | 835 with a \$\$0 or reduced payment and CARC codes | | **Meaning** | The claim was never accepted | The claim was processed and payment was refused | | **Fix** | Correct and resubmit as a new claim | Corrected claim, or a formal appeal | | **Appeal rights** | None, there's nothing to appeal | Yes, with deadlines | Step 11 explains why downgrades, frequency limits, and exhausted maximums can produce zero or reduced payments without being claim rejections or true denials. See [Claim denials, explained](/concepts/payments/denials-vs-downgrades). ## The eight things that reject first claims First claims often fail for enrollment or configuration reasons such as these: 1. **Billing provider NPI not recognized**, EDI enrollment isn't complete for that payer 2. **Legal name mismatch** between the W-9, the EIN letter, NPPES, and the claim 3. **Taxonomy mismatch** between what's on the claim and what you enrolled with 4. **Rendering dentist not credentialed** or not linked to the group contract 5. **Service date before the dentist's effective date** 6. **Subscriber ID wrong**, transposed digits, or the member ID without the alpha prefix 7. **Missing required preauthorization** on a Medicaid or DHMO service that needed one 8. **Tooth or surface data missing**, or inconsistent with the payer's history, which trips duplicate and frequency flags Most of these issues can be checked against the enrollment file and claim configuration before volume submission begins. ## Test before you go live Ask your clearinghouse whether the payer supports a test submission, and send one claim before sending a full batch. An accepted test claim provides evidence that the EDI enrollment, NPI, taxonomy, legal name, and effective date are configured correctly. ## Your artifact from this step * One claim accepted at 277CA * One predetermination submitted for the treatment-planned crown, attachment included * A documented rejection-resolution loop your biller can repeat * Confirmed EDI connectivity to payer #1 * A saved 271 eligibility response attached to the encounter ## Checklist * [ ] Eligibility verified twice and the 271 response saved * [ ] Plan design captured: remaining maximum, frequencies, downgrade behavior * [ ] Patient share collected at the point of care * [ ] Encounter documented before charges entered * [ ] CDT codes assigned by the dentist, with tooth and surface data on every line that needs it * [ ] Attachment uploaded and reference number on the claim where required * [ ] Predetermination submitted for the crown * [ ] Scrubber run and all edits cleared * [ ] 837D submitted * [ ] 999 received and clean * [ ] 277CA received and shows accepted * [ ] Any rejection corrected and resubmitted the same day ## Next The remittance arrives, including a downgrade, and the money lands. ## Sources 1. Vyne Dental, [FastAttach](https://vynedental.com/fastattach/); GEHA, [NEA FastAttach payer instructions](https://www.geha.com/en/resource-center/provider-resources/nea-fastattach); Open Dental, [claim attachments documentation](https://www.opendental.com/manual/claimtabattach.html). 2. Administrative Simplification: Adoption of Standards for Health Care Claims Attachments Transactions and Electronic Signatures, 91 Fed. Reg. 14350 (Mar. 24, 2026), compliance May 26, 2028. [Federal Register](https://www.federalregister.gov/documents/2026/03/24/2026-05676/administrative-simplification-adoption-of-standards-for-health-care-claims-attachments-transactions). 3. ADA, [Pre-authorizations and pre-treatment estimates](https://www.ada.org/resources/practice/dental-insurance/pre-authorizations).