Preparing and Transmitting Claims for Payer Processing
A completed encounter doesn't become a payable claim the moment someone clicks Submit. Charges must be supported, required data assembled, edits checked, and the electronic transaction routed to the right destination. Even then, a sent claim can be rejected before the payer considers payment.
What Actually Counts as a Submitted Claim?
A health care claim is a request to a payer for payment or adjudication of health care services or items. It combines information about the patient, subscriber, billing and rendering providers, services performed, dates, charges, diagnoses, and other elements required for the claim type. A claim may contain several service lines. It isn't necessarily the same as an invoice or a patient statement.
Claim creation assembles billable activity into a claim record. Claim validation checks that required information and applicable coding and billing rules are met. Claim submission transmits the claim to the correct destination. Claim acknowledgment reports whether a transaction or claim passed a particular receiving stage. Adjudication is the payer's subsequent determination of how the claim processes under coverage, contract, benefit, and payment policies.
| Activity | What happens | Important distinction |
|---|---|---|
| Charge entry and coding | Supported services, codes, units, and charges enter the account | A correctly entered charge is not yet a submitted claim. |
| Claim generation | Billing software assembles claim-level and service-line data | A generated claim can still be on hold or incomplete. |
| Pre-submission review | Rules and edits identify missing, inconsistent, or unsupported information | Passing a system edit does not establish medical necessity or guarantee payment. |
| Submission | An electronic file or permitted paper form is sent to the intended recipient | Sending does not prove payer acceptance. |
| Acknowledgment | A receiving system reports transaction or claim acceptance/rejection at a specific stage | Acknowledgment does not mean the claim has been paid. |
| Adjudication | The payer evaluates the claim and reports its processing result | A denial after adjudication differs from a pre-adjudication rejection. |
Many claims travel electronically from the provider's practice-management or patient-accounting system through a clearinghouse or billing service and then to the payer. Some organizations submit directly. The system diagram and the payer's trading-partner rules determine exactly who sends and receives each status response.
Where Claim Preparation Begins and Who Is Responsible
Claim preparation ordinarily happens after services are documented and applicable charges and codes are available. The claim might be created after an outpatient visit, at the end of a hospital stay, on a scheduled billing cycle, or after another event defined by the organization. Not all encounters are ready for billing immediately after service.
Registration supplies patient identity, account, subscriber and insurance details. Clinical and service departments supply documentation. Coding and charge staff establish supported codes, quantities, dates, and charges. Billing personnel validate account readiness, payer destination, claim type, required identifiers, attachments and submission status. A designated team may resolve authorization, enrollment, medical-record or technical exceptions.
| Role or system | Contribution to a claim | When an issue needs attention |
|---|---|---|
| Patient access and insurance verification | Patient, subscriber, plan, service-date coverage, payer sequence | Identity or policy information is inconsistent. |
| Clinical service department | Record of care, orders, dates, procedures, documentation | Documentation does not support reported activity. |
| Coding and charge capture | Diagnosis and service coding, modifiers, units, charges | Code, unit, bundling, or documentation questions arise. |
| Billing or claims team | Claim assembly, edits, release, routing, submission, monitoring | Claim holds, rejection responses, or unresolved submission issues appear. |
| Clearinghouse / EDI support | File translation, routing, transaction validation, response delivery | A file does not transmit or a technical edit fails. |
| Payer and AR follow-up | Claim acceptance, adjudication, status research, financial resolution | No response, denial, underpayment, or processing delay occurs. |
Ownership varies. A biller who sees an unsupported diagnosis should not independently select a more payable code. The correct response may be to route the matter to coding or the provider under the approved process. Similarly, configuring claim logic or changing payer routes typically requires authorized technical or payer enrollment staff.
What Information Goes Into a Claim?
A claim is a structured record, not a single form field. Required data elements depend on professional versus institutional billing, services, payer rules, and the applicable electronic implementation guide. The following information groups are common, though no list substitutes for the requirements of a specific claim type.
| Information group | Examples | What to verify |
|---|---|---|
| Patient and subscriber | Names, birth date, relationship, member ID, addresses | Correct person, correct fields, and policy applicable to the date of service. |
| Payer and coverage | Payer ID, plan, billing order, other coverage | Correct destination and coordination-of-benefits sequence. |
| Provider and facility | Billing, rendering, referring, or attending provider; NPI; tax ID; service location | Appropriate provider roles, enrollment, identifiers, and payer requirements. |
| Service and claim dates | Date of service, admission/discharge dates when applicable | Dates agree with documentation and claim type. |
| Diagnoses | ICD-10-CM codes and appropriate sequencing/pointers | Current valid codes supported by documentation. |
| Services and units | CPT/HCPCS or institutional line information, modifiers, revenue codes, quantities | Codes, modifiers and quantities agree with documented services and claim rules. |
| Charges and financial data | Line charges, claim total, prior-payer amounts when applicable | Totals reconcile and coordination-of-benefits information is accurate. |
| Supporting details | Authorization number, claim frequency, condition/value/occurrence data when applicable | Required fields and documentation paths are complete. |
Diagnoses, procedures, and service lines
A diagnosis explains the patient's condition or reason for care as documented and coded under applicable guidelines. A procedure or service code identifies what was reported. A diagnosis pointer or comparable relationship may connect a service line to supporting diagnoses, depending on claim type. A diagnosis that appears on the account isn't automatically appropriate for every service line.
For example, a professional claim may contain an office visit and a separate laboratory service. Each line must have its own correctly reported service, units and applicable modifiers. If the laboratory procedure did not occur, it shouldn't be included merely because it was ordered. Likewise, a claim cannot become compliant by substituting a diagnosis code solely to bypass an edit.
Provider identity and place of service
Provider-related fields are not interchangeable. An NPI identifies a provider, but payer enrollment and the role in which the provider appears on the claim also matter. Professional claims may need an appropriate place-of-service code; institutional claims use different facility and bill-type reporting structures. A service location or provider change can create a submission problem even when the patient and CPT code are correct.
Payer order and secondary claims
When a patient has multiple payers, staff must determine the applicable primary and secondary sequence rather than simply submitting to the first plan shown in the system. Subsequent claims may need prior-payer payment and adjustment information. A claim reported as secondary without required prior-payer adjudication details may be delayed or rejected. The detailed payment and coordination mechanics belong in our Primary and Secondary Posting guide, but accurate claim creation cannot ignore them.
Professional, Institutional, and Electronic Claim Formats
HIPAA-adopted electronic health care claim standards include ASC X12N 837 Version 5010. The familiar paper forms and electronic formats correspond to different billing purposes; they should not be treated as identical or interchangeable. CMS describes professional Medicare claims on the CMS-1500 / 837P pathway and institutional Medicare claims on the CMS-1450 (UB-04) / 837I pathway. Dental claims use a separate 837D format in applicable electronic workflows. CMS transaction standards.
| Claim pathway | Used for | Foundational note |
|---|---|---|
| 837P / CMS-1500 | Professional claims, as applicable to provider and payer arrangements | Uses professional claim data structures, including relevant service lines and provider roles. |
| 837I / CMS-1450 (UB-04) | Institutional billing, as applicable | Includes institutional data such as bill type, revenue codes, and other facility-specific elements. |
| 837D / applicable dental claim format | Dental claim workflows | Separate transaction specifications and payer requirements apply. |
| Permitted paper submission | Defined cases where paper is accepted or an exception applies | Do not assume paper can replace electronic filing at will. |
Medicare generally requires initial claims electronically unless an applicable waiver or exception applies. Other payers and provider arrangements can have additional submission conditions. CMS institutional electronic filing guidance.
The 837 is more than a digital picture of a paper form. It is structured information organized into segments, loops, and hierarchical relationships specified by the relevant transaction implementation guide. A field shown on a practice-management screen may map to several underlying requirements. The companion CMS-1500 and UB-04 Claim Forms guide explains form fields in detail; this guide concentrates on preparing a valid claim and moving it successfully to the payer.
Step-by-Step Claim Creation and Submission
The following sequence illustrates a typical electronic billing workflow. Organizations may combine steps or use different queues, interfaces, and approval controls.
Step 1: Confirm the account is ready for billing
Locate the correct account and encounter. Check that the services are documented, charge entry and coding are complete to the degree required, and any necessary billing holds are resolved. Identify unresolved authorization, registration, or record issues before releasing the claim. A workqueue may show a green status while an external document or another department still has an open task; status indicators must be understood in context.
Step 2: Validate coverage and payer routing
Confirm the plan relevant to the date of service, correct payer ID, claim routing, subscriber data and any additional coverage. For Original Medicare, covered fee-for-service claims generally route to the appropriate Medicare Administrative Contractor; Medicare Advantage claims route to the applicable Medicare Advantage plan. CMS submitting claims.
Step 3: Assemble the correct claim type
The billing application uses the configured professional or institutional claim pathway. It collects required provider identifiers, diagnoses, service detail, dates, quantities, charges and claim-level attributes. Verify the correct combination of billing entity, rendering/attending information, location, bill type or place of service, and frequency when applicable.
Step 4: Reconcile the charges and line details
Review whether the claim contains supported completed services, correctly reported units and modifiers, and balanced monetary totals. Compare to the charge account and relevant source records. Watch for duplicate lines, missing late charges, incorrect service dates or stale code mappings. A total charge equal to the account balance doesn't guarantee every line is correct.
Step 5: Run prebill edits and review exceptions
Claim systems and clearinghouses may flag required fields, formatting, payer enrollment, diagnosis relationships, units, code validity, or payer-specific requirements. Examine the actual error message rather than treating every edit as the same problem. Some edits require a data correction, others require documentation review or escalation to coding, enrollment, or technical support.
An edit that can be bypassed isn't automatically appropriate to override. Resolve the underlying cause using authoritative documentation and role-specific approval.
Step 6: Release and transmit under authorized procedure
Move the validated claim from the hold or ready-to-bill status into an authorized submission batch, direct connection, or clearinghouse workflow. Verify the correct date, control totals, claim count, recipient and file status. Maintain the submission identifier and a traceable record of the outbound transaction.
Step 7: Review acknowledgments, not just the 'sent' flag
Confirm receipt and status at the actual stages returned by the trading partners. A successfully uploaded file can still contain rejected transactions or individual rejected claims. Review technical acknowledgments, payer claim acknowledgments and any clearinghouse-specific reports. Each stage may have its own submission or batch identifier.
Step 8: Work rejected claims and verify corrected acceptance
If a transaction or claim is rejected before adjudication, identify where it stopped, correct verified information, follow the correct resubmission method, and confirm a new acceptance acknowledgment. Preserve the original rejection, correction history, and resubmission trail. The best correction is not always another copy of the entire batch.
Step 9: Monitor payer status and protect filing deadlines
For accepted claims, monitor payer processing through authorized status tools and normal AR schedules. Match the payer claim identifier when available, keep filing deadlines in view, and follow up when the expected response is absent. Acceptance is not final adjudication. A claim can be accepted and later denied, reduced, or pended for additional information.
Reading the Submission Trail: 999, 277CA, 276/277, and 835
Several transactions appear in claims work, but they answer different questions. Medicare EDI documentation distinguishes technical and claim acknowledgments from later claim status and payment transactions. The exact responses and visibility depend on the recipient and clearinghouse. CMS Claims Processing Manual, Chapter 24.
| Message / transaction | Primary purpose | What it does not prove |
|---|---|---|
| TA1 (where used) | Interchange-level acknowledgment and certain envelope problems | Does not demonstrate claim adjudication. |
| 999 | Implementation acknowledgment about transaction compliance at the relevant receiver | Does not confirm that every claim is accepted for adjudication. |
| 277CA | Claim acknowledgment identifying accepted or rejected claims at the relevant stage | Does not confirm payment or final adjudication. |
| 276 / 277 | Claim status inquiry and response | Is not the same as the 277CA acknowledgment; status details depend on the payer. |
| 835 | Electronic remittance advice reporting adjudication and associated financial activity | Is not itself proof that the corresponding EFT funds settled in the bank. |
Example of a misleading 'submitted' status: A practice transmits a file containing 120 claims. The transfer completes, but a validation response rejects the file because of a structural problem. The practice cannot conclude that 120 claims are waiting for payer adjudication merely because its own system shows that the file was transmitted. It must investigate the rejection, correct the relevant issue, resend as permitted, and verify acknowledgment of the replacement transmission.
A different example is a file that passes the transaction level while individual claims return claim-level rejections. A billing representative should identify the affected claims and avoid resubmitting the already accepted claims without a documented reason. Repeated transmission of accepted claims can contribute to duplicate-claim processing problems.
Worked Claim Example: From Encounter to Acknowledgment
Illustrative training scenario; the details below are fictional and not payer fee schedules or a recommended code selection.
A medical practice completes an outpatient encounter. The account contains the documented services and two charge lines. The first attempt to submit the claim fails because the subscriber ID doesn't match the payer's required information.
| Example claim element | Illustrative value | Review question |
|---|---|---|
| Service date | October 8, 2026 | Is this the actual service date on the encounter? |
| Primary payer | Plan B, effective October 1 | Was the old plan removed from this encounter's billing pathway? |
| Subscriber ID | Initially entered incorrectly | Does the number match verified policy information? |
| Service line A | 1 unit, $180 charge | Is the documented service supported and coded correctly? |
| Service line B | 2 units, $65 per unit | Are both units supported and appropriately reported? |
| Total billed charges | $310 | Does $180 + (2 × $65) equal the claim total? |
The initial file is transmitted. A payer-facing acknowledgment indicates that the claim was rejected before adjudication because the subscriber identifier could not be matched. The representative checks the registration record and approved payer sources, confirms the correct ID and asks the authorized registration/billing employee to correct the record. The corrected claim is released under the approved resubmission workflow.
A subsequent acknowledgment shows claim acceptance. At that point the practice can appropriately track the claim as accepted for further processing, but it should not post a payment or assign a patient balance based on that acknowledgment alone. The payer's later adjudication and associated remittance will supply the financial outcome.
The two charge lines and $310 total were correct from the start. The failure occurred in the coverage identification data. This is why a claim should be reviewed as a complete record rather than assuming that a balanced claim is a clean claim.
Common Claim Creation Problems and How to Resolve Them
One account may have several problems at once. The most efficient review starts with the returned status, confirms where the failure occurred, and then traces the affected data to its authoritative source.
| Problem | What to investigate | Appropriate response |
|---|---|---|
| Claim held before billing | Workqueue reason, missing data, unresolved documentation or authorization | Resolve the specific hold or route to its owner; verify release readiness. |
| Payer could not identify member | Patient/subscriber fields, service-date coverage, policy identifiers | Verify against reliable information and correct authorized data before resubmission. |
| Invalid provider or location | NPI role, enrollment, payer registration, location mapping | Validate setup and refer enrollment or configuration concerns to the authorized team. |
| Unsupported code or units | Current code set, service record, coding guidance, charge mapping | Obtain coding or documentation review; do not select a payable code by guesswork. |
| Duplicate-claim response | Previous submissions, payer identifiers, exact service lines, claim frequency | Confirm whether the original was accepted or adjudicated before sending another claim. |
| Claims missing from acknowledgment | Transmission log, batch counts, acknowledgment delivery, translation queues | Trace the file and involve EDI support rather than assuming the payer received it. |
| Wrong primary payer | Coverage dates, coordination-of-benefits information, prior-payer activity | Correct billing order after verifying applicable payer sequence. |
| Approaching timely filing limit | Applicable contract or program deadline, prior submission evidence, outstanding issue | Escalate promptly and document evidence; never assume an attempted upload meets a deadline. |
Rejection, denial, and payment variance are different investigations
A pre-adjudication rejection may mean the receiving party could not accept a claim for processing. The appropriate next step usually involves correcting submission or claim data and obtaining confirmed receipt. A payer denial generally follows adjudication and requires examination of the remittance, benefit and medical policy context, and any reconsideration or appeal options. An underpayment requires comparing adjudicated payment against applicable contract and other financial requirements. These subjects connect, but the correction pathways aren't interchangeable.
A denial should not routinely be 'fixed' by sending the same original claim as though it were rejected. Likewise, a claim with no confirmed acknowledgment should not automatically be marked denied. Staff should use the actual returned evidence and payer instructions.
When a claim is corrected after payer acceptance
Some payers distinguish an initial claim, a corrected or replacement claim, and a void/cancel transaction, often using specific claim frequency or control references. Requirements vary by payer and claim type. Investigate what has already been accepted or adjudicated, determine the proper adjustment pathway, and ensure the correct original claim reference is included where required. Sending a replacement as a new original claim can create duplicates or misdirected payments.
Controls, Reconciliation, and Recurring Submission Failures
A claim-submission process needs controls at three levels: what was prepared, what was transmitted, and what was accepted. Those populations are not always the same.
Consider a billing batch prepared with 80 claims totaling $47,500 in gross charges. A transmission report shows that 80 claims were sent, but a claim acknowledgment identifies 77 accepted and three rejected. The batch totals reconcile on the provider side, yet three claims still require correction. The proper control isn't just to balance the claim totals. It's to compare outbound counts and identifiers against returned claim-level statuses, identify the rejected records, and confirm their ultimate disposition.
| Control point | Evidence to retain | What the reviewer checks |
|---|---|---|
| Claim generation | Ready-to-bill list, claim IDs, creation timestamp, gross charge totals | Accounts expected to enter billing were actually generated. |
| Outbound transmission | Batch ID, receiver, timestamp, count, file status | The intended file reached the next trading partner. |
| Technical acknowledgment | TA1 / 999 or applicable receiver report | Structural or transaction-level problems were identified and worked. |
| Claim acknowledgment | 277CA or payer/clearinghouse equivalent | Every expected claim has a defensible accepted/rejected status. |
| Follow-up | Payer claim identifiers, status history, AR follow-up records | Accepted claims progress and unresolved claims receive action. |
An organization may find a recurring pattern in which claims from one rendering location reject every Monday. The useful investigation would involve sampling the rejected claims, comparing identifiers and routing details, tracing what changed, and involving enrollment or EDI configuration staff. A front-line analyst can document the pattern and demonstrate the impact without independently changing production mappings.
We will treat broader revenue leakage, automation failures, payer contract configuration and enterprise-level remediation in the Revenue Integrity and Reporting series. For this foundation, the essential operational principle is that a correction is not finished until the corrected claim is verified at the receiving stage.
Documentation, Compliance, and Timely Filing
Claims should be supported by the underlying record and prepared in accordance with applicable coding, coverage, and payer instructions. A submitted field cannot substitute for documentation that does not exist. Employees should follow organizational privacy and role-based access requirements when viewing accounts, transmitting files or supplying documentation.
Payer companion guides can clarify payer-specific transaction requirements, but they supplement rather than replace the governing X12 implementation guides. Medicare's companion-guide resource describes that relationship directly. CMS Medicare FFS Companion Guides.
Timely filing limits may be set by Medicare rules, Medicaid program requirements, payer contracts or other applicable terms. They should be checked for the payer and claim involved. Staff should preserve submission dates, rejection notices, corrected-claim history and other evidence needed to support a filing investigation. A claim created on time is not necessarily a claim received on time; a claim sent to the wrong destination may not satisfy the relevant rules.
Records and transmission identifiers also matter when handling confidential claim data. A technical employee may need transaction IDs, timestamps and error codes without needing to circulate unnecessary patient information. Documentation provided to a payer must use an approved, secure pathway and include only what is appropriate under the applicable rules.
Practical Claim-Submission Checklist
Use this checklist as an educational reference. Actual release criteria depend on the organization and payer.
Before release
- Confirm the correct patient, account and encounter.
- Verify payer, policy, subscriber and coordination-of-benefits information for the date of service.
- Confirm documented services, service dates, codes, modifiers, quantities and charges.
- Check appropriate claim type, provider roles, identifiers and service location.
- Resolve holds and route coding, authorization or documentation concerns to their owners.
- Review pre-submission edits and verify any authorized correction.
After transmission
- Record the file or batch identifiers, date, claim count and expected recipient.
- Review technical acknowledgments and claim-level accept/reject statuses.
- Compare the expected claims with returned acknowledgments; investigate gaps.
- Correct rejected items through the proper workflow and confirm subsequent acceptance.
- Avoid resubmitting accepted claims without establishing why a new transaction is needed.
- Track accepted claims to payer status and adjudication within follow-up schedules.
- Preserve filing evidence and escalate unresolved deadline risks promptly.
The next step in the claims series
Claim creation and submission pull together information from patient access, coding, charge capture, and payer requirements. The related foundational guides explore CMS-1500 and UB-04 claim forms, clearinghouses and claim edits, claim rejections and corrections, and payer requirements and timely filing in much greater detail. Those specialized guides build on this submission workflow rather than replacing the basic checks established here.
References and Further Learning
These resources support the guide and provide opportunities for additional learning. Check applicability, publication dates, and current requirements before using a resource operationally.
References
| Source | What It Supports |
|---|---|
| CMS: Adopted Standards and Operating Rules | HIPAA-adopted 837 health care claim transaction, other administrative standards and code sets. |
| CMS: Submitting Claims, CMS-1500 & 837P | Original Medicare claim routing and professional claim submission context. |
| CMS: Professional Paper Claim Form (CMS-1500) | Professional electronic claims, Medicare edit processing and claim acknowledgments. |
| CMS: Mandatory Electronic Medicare Claims Submission | Medicare electronic institutional claim submission and paper exceptions. |
| CMS: Medicare Claims Processing Manual, Chapter 24 | Medicare electronic data interchange, acknowledgment transactions and EDI responsibilities. |
| CMS: Medicare Fee-for-Service Companion Guides | Payer-specific trading partner instructions that supplement, not replace, X12 implementation guides. |
| CMS: Claim Status Request and Response | 276/277 claim status inquiries, distinct from initial claim acknowledgments. |
| CMS: Institutional Claim Form (CMS-1450) | Institutional paper-form context and relationship to 837I electronic claims. |
Additional Learning
| Resource | What You'll Learn |
|---|---|
| CMS: Medicare Billing, CMS-1500 & 837P | Explore common electronic professional billing transactions and how they relate to claims. |
| CMS: Institutional Billing, CMS-1450 & 837I | Learn Medicare institutional billing requirements and electronic-submission principles. |
| CMS: Health Care Transactions Overview | Understand how claims, claim status, eligibility and remittance transactions fit together. |
| CMS: Medicare FFS Companion Guides | See examples of operational EDI companion instructions and trading-partner-specific requirements. |
Educational Disclaimer
Revenue Cycle Uncovered is an independent educational resource. Content is provided for general informational purposes and does not represent the policies, practices, or positions of any employer or organization. Workflows, payer requirements, regulations, and operational practices may vary. Information should be independently verified when applied to specific situations.
Continue Exploring Revenue Cycle Uncovered
Explore related guides or return to the complete revenue cycle educational library.