The steps in the medical billing process look simple on a slide: see the patient, send the claim, get paid. In the software and the files that move between systems, there are a dozen hand-offs, and each one has its own way of failing quietly.
This guide follows a single claim through its life. It starts with the work done before a claim exists, follows the X12 837 through the clearinghouse and payer, explains what the 277CA acknowledgment and the 835 remittance tell you, and ends with posting, denials and the deadlines that apply along the way.
What are the steps in the medical billing process?
Building or fixing a billing workflow?
Agnotic builds claim creation, clearinghouse connections, remittance posting and denial work queues for providers and billing companies.
The steps in the medical billing process are registration and eligibility, charge capture and coding, claim creation and scrubbing, submission as an X12 837 through a clearinghouse, acknowledgment with a 277CA, payer adjudication, the 835 remittance, payment posting, and denial follow-up or patient billing for whatever balance remains.
Each step produces data the next step depends on. A wrong subscriber ID at registration does not fail until the payer rejects the claim days later, which is why billing teams spend so much time tracing problems backward.
What happens before a claim exists?
Before a claim exists, the front end collects the data the claim will carry. Mistakes here are the cheapest to fix and the most expensive to find later.
- Registration: Patient name, date of birth, address and the subscriber's details exactly as the payer holds them.
- Eligibility: An X12 270 inquiry and 271 response confirm active coverage, plan type and patient cost sharing for the date of service.
- Authorization: Services that need prior authorization are approved before they are performed, with the authorization number stored on the visit.
- Referral and ordering provider: Captured when the payer or service type requires them.
A good billing system re-runs eligibility close to the visit, not only at booking, because coverage changes at month and year boundaries and when patients change jobs.
Coordination of benefits belongs here too. When a patient has two coverages, the order of primary and secondary payers must be set before the claim is built, or the first claim goes to the wrong payer and comes back weeks later with a denial that only says another payer is primary.
How does a visit become a claim?
A visit becomes a claim when its charges are captured, coded and assembled with the registration data into a claim record that passes the billing system's own checks.
- Charge capture: Services, procedures and supplies from the visit drop as charges, from the EHR or from a charge entry screen.
- Coding: CPT and HCPCS codes for services, ICD-10-CM codes for diagnoses, and modifiers where they apply.
- Claim assembly: Charges grouped by visit and payer, with billing, rendering and service facility providers and their NPIs.
- Scrubbing: Edits check required fields, code pairs, diagnosis pointers and payer-specific rules before the claim leaves.
Scrubber edits should be tuned from the organization's own rejection and denial history. A generic edit set catches format errors but misses the payer rules that cause most rework.
Many organizations hold claims for a short period after the visit so late charges, such as a lab result or a pathology read, can join the same claim. Make the hold period a setting per service type, and report claims that sit past it, because a hold with no end is a common way for claims to drift toward the filing limit.
How does a claim travel from 837 to 835?
A claim travels as an X12 837 file from the billing system to a clearinghouse, on to the payer, and comes back as acknowledgments and finally an X12 835 remittance. The HIPAA transaction standards fix the formats: 45 CFR 162.1102 names the ASC X12 837 version 005010 guides for professional claims (005010X222) and institutional claims (005010X223, with its errata).
- 1. Billing system: Builds the 837P for professional services or the 837I for facility services and sends the batch.
- 2. Clearinghouse: Validates the file's syntax, returns a 999 acknowledgment, applies its own edits, and routes each claim to the right payer.
- 3. Payer front end: Checks each claim for basic acceptability and returns a 277CA claim acknowledgment saying which claims were accepted into processing and which were rejected.
- 4. Payer adjudication: Accepted claims are matched to the member, edited, priced and decided, which can take days or weeks.
- 5. Remittance: The payer sends an 835 with the paid amount and adjustment codes for each line, and the payment by EFT or check.
- 6. Payment posting: The billing system matches the 835 to the claim, posts payments and adjustments, and moves any balance to the next payer or the patient.
The remittance format is set by 45 CFR 162.1602, which adopts the ASC X12 835 Health Care Claim Payment/Advice, version 005010X221. The same section ties the 835 to the EFT through the reassociation trace number, so a billing system can match the money in the bank to the remittance that explains it.
What do the 999 and 277CA tell you?
The 999 tells you whether a file was readable; the 277CA tells you whether each claim inside it entered the payer's system. A claim without an accepted 277CA has not been filed with the payer in any practical sense.
Track three states for every claim: sent, accepted by the clearinghouse, and accepted by the payer. Claims stuck between states are the most common source of timely filing losses, because staff assume a claim sent is a claim received. Rejections at this stage are not denials; the claim never entered adjudication, so the fix is to correct and resend, not appeal.
Clearinghouses add their own reports on top of the standard acknowledgments. Normalize them into one claim status history so staff see a single timeline per claim rather than reading three report formats.
How is a payment posted?
A payment is posted by reading the 835, matching each claim payment to the claim and each service line to the charge, then recording the paid amount, the contractual adjustment and any patient responsibility.
- Claim match: Use the claim identifier the billing system sent, echoed in the 835, not patient name and date.
- Line match: Match service lines by code, modifier and date, and handle lines the payer split or bundled.
- Adjustment codes: Record claim adjustment group and reason codes and remark codes on each line, because they drive the next action.
- Patient responsibility: Move deductible, copay and coinsurance to the patient balance or to a secondary payer.
- Cash match: Reconcile each 835 with its EFT deposit so unmatched money is visible.
Auto-posting should handle the clean majority, with exceptions in a queue: payments with no matching claim, takebacks of earlier payments and lines with unexpected adjustments. Manual posting of clean remittances is time a billing team can spend on denials instead.
What happens after a denial?
After a denial, the claim goes to a work queue by reason, and staff decide whether to correct and resubmit, appeal, or write off. The adjustment reason code on the 835 decides the queue.
- Correctable errors: Wrong modifier, missing information or invalid code, fixed and sent as a corrected claim with the right frequency code.
- Medical necessity: Records and a letter assembled for an appeal, within the payer's appeal window.
- Authorization: Checked against the authorization on file; if one exists, appeal with it, and if not, review the front-end process.
- Coverage: Eligibility re-run; bill the right payer or the patient.
- Contractual: Allowed amount compared with the contract; underpayments go to a separate queue.
Every denial worked should end with a recorded root cause as well as an outcome. Grouping those causes by payer and by upstream step shows which fixes belong at registration, coding or the scrubber, so the same denial stops arriving next month.
Which deadlines apply along the way?
Timely filing limits are the deadlines that cost the most when missed. For Medicare, 42 CFR 424.44 requires a claim for services furnished on or after January 1, 2010 to be filed no later than one calendar year after the date of service, with narrow exceptions such as errors by Medicare contractors or retroactive entitlement.
Commercial and Medicaid payers set their own filing limits and appeal windows, often shorter than Medicare's, through contracts and state rules. Store each payer's limits as data, calculate a due date for every claim and appeal, and sort work queues by days remaining rather than by age.
Where do claims get stuck?
- Unacknowledged files: A batch leaves the billing system and no 999 comes back, and nobody notices for a week.
- Rejected but unseen: 277CA rejections land in a clearinghouse portal that staff check irregularly.
- Unposted remittances: 835 files fail to load because of a payer ID mismatch and sit in a folder.
- Secondary claims: The primary pays, but the crossover to the secondary payer never happens.
- Lost corrections: A corrected claim is sent with the wrong frequency code and the payer treats it as a duplicate.
Each of these is visible in data the billing system already receives. A daily exception report covering files without acknowledgments, claims without payer acceptance and remittances without posting catches them while there is still time to act.
How Agnotic can help
Agnotic Technologies builds billing software for providers and billing companies: claim creation and scrubbing, clearinghouse connections for 837, 999, 277CA and 835 files, automated payment posting with exception queues, and denial work queues sorted by filing and appeal deadlines.
Agnotic also builds the claim status timeline that ties these steps together, so staff can see where every claim is and why, without logging in to three portals.
See every claim from 837 to posting
Explore medical billing software development, or read more revenue cycle articles.
Related reading on Agnotic
Read on with revenue cycle management, insurance eligibility checks, lab billing and outsourcing billing work.


