This guide is for developers building anything that sends Medicare claims: practice software, billing tools, or an internal operations platform that exports batches to a claiming intermediary. Most rejected claims come down to bad identifiers that could have been caught before submission. Medicare card numbers and provider numbers both carry check characters, so software can catch most typos for free. Most products don't.
It covers the two check algorithms, the reference number most systems get wrong, and the order of checks that keeps bad claims away from Medicare. It draws on recent work moving an allied health provider's Medicare claiming from manual entry to automated batches.
Anatomy of a Medicare card number
A Medicare card number is 10 digits. The first 8 identify the card, the 9th is a check digit, and the 10th is the card issue number, which goes up each time the card is reissued. Separately, each person on the card has an Individual Reference Number (IRN), the single digit printed next to their name. A claim needs both: the 10-digit number identifies the card and the IRN identifies the patient on it.
The first digit of a valid card number is 2 to 6. The check digit is a weighted sum of the first 8 digits:
- Multiply digits 1–8 by the weights
1, 3, 7, 9, 1, 3, 7, 9. - Sum the products and take the result mod 10.
- The result must equal digit 9.
- Digit 10, the issue number, must be 1–9. A zero there almost always means someone typed the IRN in the wrong place or dropped a digit.
The 11-digit problem
Staff and upstream systems often write the card number and IRN as one 11-digit string, because the card shows them close together. Claiming formats want them in separate fields. Detect 11 digits explicitly and split them, with the last digit going to the IRN and the rest validated as the card number. Don't just reject the value, and never silently cut it to 10 digits without moving the IRN. A clear message ('this looks like a card number with the IRN on the end') saves a support call every time.
Defaulting the IRN to 1 when it's missing is tempting, because most single-person cards use 1. For a resident on a couple's or family card, though, IRN 1 identifies someone else, and Medicare will reject the claim or match it to the wrong person. If you default it, flag the default so a person reviews it.
Anatomy of a Medicare provider number
A Medicare provider number is 8 characters: a 6-digit stem that identifies the practitioner, a location character (the practice location value, or PLV), and a check character. Because the number identifies a practitioner at a location, one clinician working across several sites has several numbers, and software has to treat them as location-scoped (more on this in the Medicare Web Services guide).
The check character is calculated like this:
- Multiply the 6 stem digits by the weights
3, 5, 8, 4, 2, 1and sum them. - Convert the location character to its value using the sequence
0123456789ABCDEFGHJKLMNPQRTUVWXY(0 is 0, A is 10, and so on, skipping I, O, S and Z). Multiply that value by 6 and add it to the sum. - Take the result mod 11 and use it as an index into
YXWTLKJHFBA. That letter must match the 8th character.
Dropped leading zeros
Spreadsheets drop leading zeros. A provider number that started as 0123456A arrives as 123456A, seven characters long and invalid. Pad it back to 8 characters, but only accept the padded value if it passes the check-character test. A check character makes recovery safe, so use it rather than guessing.
Referring provider numbers matter as much as servicing ones
Referred services, such as allied health under a GP chronic condition management plan, carry two provider numbers: the servicing practitioner's and the referring GP's. The referring number usually comes from a scanned referral form, which makes it the least reliable field on the claim. Validate it with the same check-character test, and keep a master list of known GPs with their numbers and the spellings of their names, so a valid number that belongs to someone else is caught too.
What else to validate before a claim leaves
Check digits catch typos, not wrong data. Before a claim is exported or submitted, also check:
- Date of birth is present, is a real date, and is before the service date. A wrong DOB is one of the most common patient-mismatch rejections.
- Patient name still has a first and last name after cleaning. Strip nicknames in brackets or quotes ('Margaret (Peggy) Smith') and characters the claiming channel won't accept. A name that empties out under cleaning is a data problem to send back to the source, not something to submit.
- Referral details match. The referring provider number, the provider's name, and the referral issue date all come from the same referral document. The issue date is on or before the service date and inside the referral's validity window.
- Item and service date are consistent with the patient's entitlement, including annual caps, which is where allied health claiming catches most teams out.
- Not already claimed. The same patient, item and service date is not already billed or in flight. A duplicate claim is the most avoidable rejection there is.
Run validation in two layers
Validate in the UI as data is entered, so staff fix problems while they still have the paperwork in front of them. Validate again in the database or API layer at export or submission time, because data changes between entry and claim: another user edits a profile, a referral expires, a visit is billed by another route. In a recent build, the export step called a database function that re-checked every selected row and refused the whole selection if any row had become ineligible since it was last validated. It caught real problems the UI checks had passed.
Allow an override, but record it. Real data occasionally fails a rule that Medicare will accept. A 'save anyway' flag on the row, with who set it and when, keeps staff moving without hiding the decision.
Building claim validation into practice or billing software, or cleaning up the identifiers behind a stream of rejections? CareForge has built these checks into production Medicare claiming. Book an intro call.
Last reviewed: October 2026