Medicare Claim Reconciliation: From Sent to Paid

Model claim state explicitly

Give each claimable service a billing state, separate from the clinical record, and only allow it to change through defined transitions:

• Ready: the data is validated and the service is eligible, but it hasn't been submitted yet.
• Lodged / outstanding: submitted or exported, waiting for Medicare to assess it.
• Billed: Medicare paid the full benefit. This is a final state.
• Declined: Medicare rejected the claim. The reason is recorded and it's waiting for a decision.
• Private: moved to private or facility billing, with the reason recorded (no referral, annual cap reached, declined, or an operator's decision).

Matching results to claims

Whether results come from an intermediary's transaction report or from Medicare processing reports, matching follows the same rules:

• Match on your reference first. A deterministic invoice reference created at submission is the main key. Without one, reconciliation is guesswork.
• Then confirm the details. Medicare number and IRN, provider number and service date should all agree with the claim. A reference match with different details means the row was edited after export, so flag it for review instead of applying it.
• Mark as billed only when fully paid. For bulk billing, 'approved' has to mean the benefit equals the charge, nothing is outstanding, and nothing has been cancelled or refunded. Treat partial payments as exceptions.
• When a reference repeats, choose deliberately. A claim declined and then resubmitted produces two rows with the same reference. A fully paid attempt wins. Otherwise the newest attempt wins, ordered by date, then transaction ID, then position in the file.
• Make the import safe to repeat. Record every transaction ID you've applied, so importing an overlapping report a second time changes nothing. Add a database constraint that stops one transaction being linked to two claims.
• Apply each import in one transaction. Partial imports leave a batch half reconciled, which is worse than not importing it at all.

Turning rejections into worklists

Medicare's decline reasons come back as explanation codes with short text. Read them into groups that tell staff what to do next, rather than showing raw codes:

• Annual cap reached. The patient has used their allowance for the item group this year, often at another provider your system doesn't know about. In our data this was explanation code 160. Update the patient's entitlement and move the service to private billing.
• Referral problems. The referral is missing, expired, dated after the service, or the referring provider details don't match Medicare's records. Fix it against the referral document and resubmit.
• Patient details. The name, date of birth, card number or IRN doesn't match Medicare. Correct the patient record, which also fixes their future claims.
• Duplicate. The service has already been claimed. Find the earlier claim instead of resubmitting.
• Servicing provider problems. The provider number wasn't active at that location on the service date, or the practitioner isn't yet authorised to claim through the channel. These come in large groups (in one backlog batch they caused most of the declines), because they affect every claim from that practitioner. Fix the registration with Medicare once, then resubmit them together.

Resubmission and private billing

A declined service has three ways out: correct and resubmit, bill privately, or mark the patient's entitlement as used up. Resubmit under the same invoice reference, so the second attempt reconciles against the first, and clear the earlier outcome only when the corrected row passes validation again.

Private billing is where double charging happens. A service that's already on an invoice sent to a facility or patient must not then be claimed from Medicare, and a service paid by Medicare must not appear on the next invoice. Check both directions in the database, and use supplementary invoices for services moved to private billing after the original invoice has gone out, rather than reissuing it. Keep invoicing and claiming as separate processes that both check the same billing state.

Entitlement counters need a ledger

If your product tracks capped entitlements, such as allied health services per calendar year, don't keep the count as a single number that goes up and down. Keep a ledger with one entry per patient per service date, so a visit can't be counted twice, a reversal can't take off a visit from a different period, and historical data imported from before the system existed is marked for review instead of corrupting the count. A counter field gets out of step with reality. With a ledger you can see exactly why the count is what it is. The allied health claiming guide covers the caps themselves.