The claim submission process, and how to clear rejections

The claim submission process is the path a charge takes from your practice management system into the payer’s adjudication system: built as an electronic 837 claim, checked by your scrubber and your clearinghouse, acknowledged by the payer first as a file and then claim by claim, and finally either accepted with a payer claim number or rejected. Nothing gets paid, denied or appealed until the claim is accepted.

Most practices measure the end of this path, the payment and the denial. This guide stays at the front, where a claim can disappear without a trace. It pairs with the denials guide, which picks up once the payer has decided, and with the other billing guides.

What happens between “submit” and “accepted”?

Between pressing submit and having an accepted claim, a claim passes four checkpoints: your own scrubber, the clearinghouse’s edits, the payer’s file-level syntax check reported on the 999, and the payer’s claim-level edits reported on the 277CA, and a claim can fail at any of them. Only the last one gives you a payer claim number.

Medicare uses exactly these two acknowledgments for incoming claims: the X12 999 implementation acknowledgment and the X12 277CA claim acknowledgment¹. Its manual describes the split. Errors serious enough to reject a whole transaction set come back on the 999; errors the translator can pass along are marked “accepted, but errors noted” and travel on to the claim-level edits, which report each claim’s result on the 277CA¹.

For Medicare, each claim that passes every edit gets a claim control number, and that number comes back on the 277CA¹. The manual’s stated purpose is to let you ask about a single claim instead of a whole submission¹. Record it against the claim. It is the only proof the payer has the claim.

How do you get set up to submit electronically?

You get set up by obtaining an EDI enrollment with each payer for each billing provider, connecting through a clearinghouse with a signed agreement, and confirming that the provider’s identifiers match what the payer holds, because a claim from a submitter the payer does not recognize is rejected before anyone reads it. Setup errors reject every claim, not just one.

Medicare’s rules show the pieces. A provider needs an NPI, and the MAC checks that the NPI is active in PECOS before it approves the EDI enrollment agreement; if it cannot verify the NPI, the agreement is denied¹. The EDI number and password act as the provider’s electronic signature, and the provider is liable if someone it improperly shared them with misuses them¹.

If you send through a billing agent or clearinghouse, Medicare requires an agreement signed by that third party in which it accepts the same security and privacy obligations; the provider keeps it rather than sending it to Medicare¹. Providers may not share their own EDI access credentials with a billing agent or clearinghouse¹.

The transactions themselves are HIPAA standards. Claims and encounter information, claim status, eligibility, and payment and remittance advice are among the standard transactions, and covered entities must use the adopted X12 standard for them⁶. For professional claims that is the 837 in version 005010X222A1¹.

Do you have to send claims electronically?

For traditional Medicare, yes, unless you qualify for an exception: the Administrative Simplification Compliance Act and 42 CFR 424.32 require initial claims to be submitted electronically, and Medicare is prohibited from paying claims sent on paper that do not meet the limited exceptions¹. Commercial payers set their own rules in their provider manuals.

The main exception is size. For practices billing a Part B MAC, Medicare treats physicians, practitioners, facilities and suppliers with fewer than 10 full-time equivalent employees as small providers, and providers billing a Part A MAC with fewer than 25¹. The manual counts part-time hours toward the FTE total and excludes contracted staff such as a billing agency’s employees¹.

Two details catch practices out. “Initial claims” under the rule include resubmissions of claims that were rejected before, claims with paper attachments and claims where Medicare is secondary¹. And the requirement does not apply to claims sent to Medicare managed care plans or to other health plans¹, whose own rules govern.

What makes a claim clean before it leaves?

A clean claim is one the payer can adjudicate without going back to anyone for more information, which means it passes every edit, carries every required and conditional data element, and arrives inside the filing limit. Medicare’s manual defines it as a claim that does not need investigation or development outside the contractor’s own operation before payment, and says clean claims must be filed in the timely filing period².

The opposite is an unprocessable claim. Medicare defines it as a claim with required information that is incomplete or missing, or that is complete but invalid². Incomplete means a required or conditional field is empty; invalid means the field is filled but illogical, incorrect or no longer in effect, such as an expired number².

That definition gives the scrubber its job. Every rule should test one required or conditional field against a source of truth:

Write a rule each time a new rejection reason appears, then retire the rule only when the reason has not returned for a year. The charge entry service and the scrubber work as one step: a wrong field at entry is a rejection two days later.

Why is a rejection more dangerous than a denial?

A rejection is more dangerous than a denial because a rejected claim was never received: it has no receipt date, no remittance, no appeal rights and often no record in the payer’s system, while the filing limit keeps counting from the date of service. A denial at least sits in the payer’s system with a reason code and an appeal path.

Medicare’s manual is direct about this. Claims that fail basic legibility, format or completion requirements are not considered received and may be rejected; they are not considered received until resubmitted as corrected, complete claims². A claim returned as unprocessable is not denied and has no appeal rights².

How the return reaches you varies. When the error is caught at the front end, the claim is returned without its data being kept in the system and no remittance is issued; when it is caught inside the processing system, the claim can be rejected through the remittance with codes explaining the error². On an 835, remark MA130 tells you the claim was unprocessable and carries no appeal rights⁵.

Meanwhile the clock runs. Medicare claims must generally be filed within 12 months, or one calendar year, of the date of service, and on a professional claim with span dates the line item “From” date is the one that counts². A claim for February 29 must be filed by February 28 of the following year². Commercial and Medicaid limits are set by contract and state rules; the timely filing table lists them by payer, and the proof of timely filing post covers the evidence that counts when a resent claim lands close to the limit.

How do you read the 999 and the 277CA?

Read the 999 first, to confirm the payer accepted the file or transaction set, then read the 277CA claim by claim, where the category code tells you whether each claim entered adjudication or was rejected and why. A batch with an accepted 999 can still hold rejected claims.

Medicare’s manual says the 999 reports the transaction-level errors the translator finds and acknowledges receipt of claims that had no syntax errors, unless the submitter chose not to receive acknowledgments for clean files¹. Download it promptly: MACs may purge an undownloaded 999 from the submitter’s mailbox after five business days, though they are encouraged to keep it up to 30 days¹.

If you missed the 999, the manual’s fallback is a claim status inquiry; if the response shows no record of the claim, that suggests a front-end rejection, and you can resubmit and receive a new 999¹.

On the 277CA, the category codes beginning with A are the acknowledgment set. In our words: A1 means the payer received the claim but has not accepted it for adjudication, A2 means it was accepted into the adjudication system, A3 means it was returned as unprocessable, A6 means information was missing, A7 means information was invalid, and A8 means two related fields conflict³. Only A2 is a finished submission. The status codes that travel with the category name the field; the 277CA post covers the common ones.

How do you resubmit a rejected claim?

Resubmit a rejected claim by fixing the field the rejection names and sending it as a new original claim, because a claim the payer rejected at the front end does not exist in its system and there is nothing to replace. Replacement and void codes are only for claims the payer accepted.

The paper form shows the rule plainly. Item 22 on the 1500 takes a resubmission code and the payer’s original reference number, with frequency code 7 for a replacement of a prior claim and 8 for a void or cancel, and the NUCC instructions say the item is not meant for original claim submissions⁴.

Medicare’s manual matches the logic: for a front-end return, or when a remittance was used to return the claim, you may send a corrected claim or an entirely new claim, because the original data was not retained². Where the claim was suspended for development instead, corrections can go in writing, online or by phone, and Medicare processes the claim if they arrive within 45 days².

Sending a replacement code on a claim the payer never accepted turns one rejection into two: the payer has no original to replace, and the replacement fails as well.

What should a daily submission routine include?

A daily submission routine includes four counts and one list: claims sent, files accepted on the 999, claims accepted on the 277CA, claims rejected, and a rejection worklist sorted by days left to each payer’s filing limit. If the counts do not reconcile, a claim is missing somewhere between your system and the payer.

Report the gap between claims sent and claims accepted weekly, by payer. It is the earliest warning a practice gets: a rejection that nobody works becomes a timely filing write-off months later, and by then nobody remembers the original error.

Worked example · hypothetical

A worked example: a clearinghouse change

This is a hypothetical example. A four-provider podiatry practice moves to a new clearinghouse on the first of the month. The ERA and EDI enrollments are updated in advance with each payer, and the first batches go out on day one.

By day three the biller’s reconciliation shows a gap. Every batch has an accepted 999, but 41 claims for one regional commercial plan have no 277CA at all, and 14 Medicare claims are back as A7, rejected for invalid information. The two problems have different causes.

The 41 missing acknowledgments trace to a payer ID mapping: the new clearinghouse routes the plan’s claims to the plan’s old processing address, which no longer returns acknowledgments. The clearinghouse corrects the mapping. Because the payer has no record of the claims, the biller sends all 41 as new original claims and confirms A2 acknowledgments the next day. One of them had already been resent by a temp as a replacement with frequency code 7; the plan rejected it, since there was no original to replace, and it goes out again as a new claim.

The 14 Medicare rejections share one feature: all are for a podiatrist who joined two months ago, and the rendering provider field carries the group NPI instead of hers. The provider file is fixed, and the 14 claims go back out as new claims the same day.

By the end of the week, claims sent and claims accepted agree for every payer, and the scrubber has a new rule: a rendering NPI that matches a group NPI stops the claim before it leaves.

When should a billing team handle claim submission?

Hand claim submission to a billing team when charges sit unbilled for days, when nobody reconciles the 999s and 277CAs, or when rejections are found only after a payer’s filing limit has passed. A dedicated remote biller can scrub and release claims, reconcile every acknowledgment daily, work rejections against the filing clock and fix the provider or template cause behind each group.

Remitwright’s claim submission service works this way, with a dedicated biller per client (or a dedicated team for larger groups) working remotely in the client’s own practice management system and clearinghouse. The practice keeps its EDI enrollments, its clearinghouse account and its data; the biller works inside them.

The test of the work is simple. Every claim sent should have an acceptance and a payer claim number, or a reason on the worklist and a name beside it.

Checklist

Claim submission checklist

1. Every billing NPI has an active EDI enrollment with each payer, and the clearinghouse agreement is on file
2. Payer IDs in the clearinghouse are checked against the plan on the eligibility response, not the card
3. Charges are entered and scrubbed within a set number of days of the visit, with the lag reported
4. Scrubber rules exist for every rejection reason seen in the last year
5. Every batch sent has an accepted 999, checked the same day it arrives
6. Every claim has a 277CA showing acceptance into adjudication and a payer claim number
7. Rejected claims are worked the same day, sorted by days left to the payer's filing limit
8. A claim rejected at the front end is resent as a new claim, not as a replacement
9. Replacement and void frequency codes are used only on claims the payer accepted
10. The cause behind each rejection group is fixed in the provider file, template or master data
11. Claims with no acknowledgment get a claim status inquiry before they age past a week
12. Submitted versus accepted counts are reported weekly by payer

Print this checklist

Or get a link to this guide in your work email, so you can come back to it.

Leave these three fields empty.

Company websiteCommentsSubject

Work email

Email me a copy

By sending this you agree that we may contact you about your inquiry and keep your details as described in our privacy policy.