Should I write off a rejected Medicare claim?

A decline is not a bad debt and not a discount. The service was delivered and the claim can usually go back out once the reason code is dealt with, so the invoice belongs open rather than written off. The canonical template takes the same line: the rejected claims component posts nothing, and says the payment should be removed and the invoice reopened instead.

Why does Xero say the invoice cannot be edited?

Because a payment is allocated to it. Xero will not let the amounts on an invoice move while a payment or credit note is attached, which is why the payment has to come off before anything else. Cliniko reports the same wall from its side as payments only being made against Authorised documents, and Zanda states that Xero will not allow the invoice to be edited while a payment sits on it.

Do I have to undo the bank reconciliation as well?

Only if the deposit you matched actually included this claim. Check the payment report for the run. If the claim is not on it, the money never arrived in that deposit, the bank line was matched correctly and it stays as it is. The overstatement is in the clearing account, and removing the payment from the invoice clears it.

Where do I find why the claim was rejected?

On the bulk bill processing report in HPOS, which shows the claims processed with exceptions and carries a Medicare reason code against each one. It is available one business day after the claim is finalised, selected by payee provider number and lodgement date range. The payment report will not show the claim at all, because that report lists only claims that were paid.

When a claim is rejected by Medicare, can you resubmit?

Often yes, once the reason code is dealt with. A resubmission goes out as a fresh claim rather than as an edit to the old one, and it is paid in a later run, so the invoice belongs open until then. coreplus tells its users to resubmit and then check the Medicare report a few days later. Some reason codes mean the service was not claimable at all, in which case the amount is billed to the patient or carried elsewhere rather than reclaimed.

Does the same thing happen with DVA claims?

DVA claims are adjudicated and paid through the same Services Australia channel, and the canonical template gives DVA its own clearing account for one reason: DVA pays in separate runs, so the two do not belong in one balance. Whether the practice management systems other than Cliniko, Zanda and coreplus document what happens to their own payment when a claim is declined was not verified for this page.

Problems

Medicare claim rejected after the invoice was paid

The practice software closed the invoice when the claim was submitted, or when somebody recorded the expected benefit, and Services Australia later declined the whole claim. Remove the Xero payment, reopen the invoice, and queue the claim for resubmission with its reason code. If the deposit you reconciled did not include that claim, the bank side is already right and only the clearing account was overstated.

Key facts

What the claim status actually was: Declined by Services Australia, so no money was sent for that claim in any payment run²
Unit of rejection: The whole invoice. Tyro Health states that if one service item is rejected the whole invoice is marked as Declined²
Why a payment exists anyway: The practice system closed the invoice on submission or on an expected benefit, ahead of the payment report³
Where the rejection is written down: The bulk bill processing report, which shows all claims that have been processed with exceptions¹
When you can read it: One business day after the claim is finalised, through HPOS with a PRODA login¹
Why the claim failed: A Medicare reason code sits against each rejected claim on that report¹
What Xero will not let you do first: Edit the invoice. Xero returns that the document cannot be edited as it has a payment or credit note allocated to it⁵
Where the phantom money is sitting: 100 Medicare clearing, at the BAS Excluded tax rate⁸
What the template posts for a rejected claim: Nothing at all, with the reason carried on the component instead of an account code⁸

What you are looking at

The invoice is closed in the practice software. It is closed in Xero too, with a payment against it dated the day the claim went in. Services Australia sent nothing for it. The claim is sitting on a processing report with a reason code, and the money the ledger says arrived was never in any payment run.

This is not a sync failure. There is no error email and no failed sync notice, because every document that crossed between the two systems crossed correctly. What is wrong is a fact, not a record: a payment exists for money that did not come.

Why the invoice closed before Medicare paid

A bulk bill claim is asynchronous. It leaves the practice, Services Australia adjudicates it, and the answer comes back later. Cliniko's own instruction for the submission step is to leave the invoice alone.

there is no need for you to enter a payment at this point, because the invoice is now awaiting Medicare's approval on this claim³

Two habits close it anyway. The first is a receptionist who records the schedule benefit on the day of service, so the day sheet balances and the invoice list stays clean. The second is a practice that has set a Medicare payment allocation in its claiming partner settings, watched the payment appear by itself on approved claims, and stopped reading the payment report at all. The allocation is documented for approval. A decline is a different path, and the page that documents the allocation does not describe it.

Medicare declines the whole claim, not one line

If multiple service items are claimed and one item is rejected the whole invoice will be marked as Declined.²

That single sentence sets the arithmetic for the rest of the fix. A declined claim comes back as a whole invoice rather than as a part payment, so for that claim there is no residue to write off and no discount to record. The invoice has to go back out and be paid in a later run.

It also tells you what to look for. A claim you can find on the payment report was paid. A claim you cannot find there is either still in flight or on the processing report, and those two need opposite handling. A deposit that came in smaller than the claims you sent is the same event counted from the bank side.

Where the rejection is written down

Services Australia produces two reports per payee provider through HPOS, and they answer different questions. A decline is written on the second one only, so a practice that reads the payment report and stops there can carry the phantom payment for a quarter without seeing it.

The two bulk bill reports, and which one carries a rejection¹

Report	What it shows	When it is available
Bulk bill payment report	All claims that were successfully submitted and paid	One business day after the claim is finalised
Bulk bill processing report	All claims that have been processed with exceptions, each with a Medicare reason code	One business day after the claim is finalised

Both are selected by payee provider number, lodgement date range and claiming method, and both come out as a PDF or a spreadsheet. The reason code is the part worth keeping: it decides whether the claim goes back out unchanged, goes back out corrected, or was never claimable and has to be billed to the patient instead.

What the phantom payment does to the books

The payment moved the invoice out of receivables and into the clearing account, and it did that on a date when nothing had been approved. Everything downstream of those two facts is now slightly wrong, and none of it looks wrong on its own.

Plate 1One declined claim, as the ledger has it after an early payment and as it reads once the payment is removed.

The quiet one is the clearing balance. It grows by the value of every declined claim, and because it also grows legitimately between a payment run and the bank date, an ageing balance reads as ordinary timing until somebody lists what is in it. A balance that will not come back to nil is the standing symptom, and it has its own page.

The bank side may already be right

This is the half most guides skip, and it is the half that saves an hour. Ask one question before touching anything: did the deposit you reconciled include this claim?

If the claim was declined before the run went out, it was not in the run, so the bank line was correct when you matched it and it is still correct now. The bank reconciliation stays where it is. What was overstated was the clearing account, which was carrying an approval that never existed. Undoing a reconciliation you got right is work, and it puts a matched bank line back into the feed for no reason.

A bank deposit that agrees to the report total proves the payment run landed, not that every claim was coded correctly, assigned to the right provider, or ready to become revenue.⁷

The other case is rarer and worth naming. If somebody matched the deposit by picking payments until the total agreed, and this claim was one of the payments picked, then the match itself is wrong and the reconciliation does have to be undone. The difference between the two cases is whether the claim appears on the payment report, which is why the report comes before the keyboard.

Undoing the payment in Xero

Xero locks an invoice the moment a payment is allocated to it, so the order of these steps is not a preference. Both practice management vendors document the same constraint from their own side.

once a payment or credit note is allocated to an invoice in Xero, Xero won't allow that invoice to be edited⁵

Pull the processing report for the payee provider and the lodgement dates in question, and write the reason code against the claim before anything else.
Check the payment report for the same period. If the claim is not on it, the deposit did not carry it and the bank reconciliation stays as it is.
In Xero, remove the payment from the invoice. The invoice returns to Awaiting Payment and the clearing balance falls by the same amount.
In the practice software, remove or reverse its own payment so the two systems agree, and let the invoice sit open there too.
Put the claim in a resubmission queue with the reason code, the date it was declined and who owns it, rather than leaving it on the invoice list to be found again.
Check the clearing balance afterwards. It should now hold approved claims that have not yet reached the bank, and nothing else.

Telling a rejection from a timing difference

Four situations produce an invoice that looks paid and money that has not arrived, and only one of them is a rejection. Sorting them takes the two reports and about a minute per claim.

On the processing report with a reason code. Declined. Remove the payment, reopen the invoice, requeue the claim.
On neither report yet. Still in flight. Leave it and check again rather than reversing anything.
On the payment report but not yet in the bank. Approved and travelling. The clearing balance is doing exactly what it exists for, and the bank line will close it.
On the payment report, in the bank, and still open in the practice software. A matching problem rather than a claim problem, which is one deposit against many invoices.

The second one is the one people get wrong under pressure. Tyro Health puts adjudication at one to two business days from submission, so a claim that has not been answered yet is not a rejection, and reversing it early creates a second correction when the money turns up.

Where the reports are ambiguous, or nobody at the practice has HPOS access on the day, there is a slower path that settles the same question before anything is reversed. coreplus gives its users the number for it.

Contact the Medicare processing line on 132 150 to confirm if the invoice has actually been paid.⁶

What Ledger Map does with it

Ledger Map holds one standing map for the practice, approved before anything syncs. Paid Medicare claims resolve through that map into the Medicare clearing account on the date Services Australia paid them, the deposit is posted as one balanced document set, and one exact match is left in the bank feed. A declined claim resolves to no posting at all, because the canonical template says so in the rail itself rather than in a note somebody has to remember.

A whole claim is declined via Tyro's status flow or the processing report; the payment must never be posted, or must be removed and the invoice reopened rather than written off.⁸

Where a claim cannot be read as approved or declined from the reports the practice has, it becomes a question with the candidate postings shown rather than a silent guess. The account and the tax rate are the practice's own template, not a choice the product made. The learn hub carries the rest of the Medicare reconciliation questions, and how it works shows the map itself.

Questions

Should I write off a rejected Medicare claim?
A decline is not a bad debt and not a discount. The service was delivered and the claim can usually go back out once the reason code is dealt with, so the invoice belongs open rather than written off. The canonical template takes the same line: the rejected claims component posts nothing, and says the payment should be removed and the invoice reopened instead.
Why does Xero say the invoice cannot be edited?
Because a payment is allocated to it. Xero will not let the amounts on an invoice move while a payment or credit note is attached, which is why the payment has to come off before anything else. Cliniko reports the same wall from its side as payments only being made against Authorised documents, and Zanda states that Xero will not allow the invoice to be edited while a payment sits on it.
Do I have to undo the bank reconciliation as well?
Only if the deposit you matched actually included this claim. Check the payment report for the run. If the claim is not on it, the money never arrived in that deposit, the bank line was matched correctly and it stays as it is. The overstatement is in the clearing account, and removing the payment from the invoice clears it.
Where do I find why the claim was rejected?
On the bulk bill processing report in HPOS, which shows the claims processed with exceptions and carries a Medicare reason code against each one. It is available one business day after the claim is finalised, selected by payee provider number and lodgement date range. The payment report will not show the claim at all, because that report lists only claims that were paid.
When a claim is rejected by Medicare, can you resubmit?
Often yes, once the reason code is dealt with. A resubmission goes out as a fresh claim rather than as an edit to the old one, and it is paid in a later run, so the invoice belongs open until then. coreplus tells its users to resubmit and then check the Medicare report a few days later. Some reason codes mean the service was not claimable at all, in which case the amount is billed to the patient or carried elsewhere rather than reclaimed.
Does the same thing happen with DVA claims?
DVA claims are adjudicated and paid through the same Services Australia channel, and the canonical template gives DVA its own clearing account for one reason: DVA pays in separate runs, so the two do not belong in one balance. Whether the practice management systems other than Cliniko, Zanda and coreplus document what happens to their own payment when a claim is declined was not verified for this page.

Sources

Open questions

Cliniko documents the automatic payment allocation on an approved claim but not what its integration does with that payment when the claim is later declined, so this page states the manual removal path and claims nothing about the integration reversing itself.
Two Services Australia pages, on managing rejected claims and on looking up a Medicare reason code, returned no readable body to an automated fetch on 3 Sep 2026, so no fact here rests on them. The HPOS reports PDF from the same publisher was readable and carries the report facts instead.
Every central.xero.com article fetched for this page returned no readable body on 3 Sep 2026. The Xero steps rest on the two vendor articles and on the canonical template, and the Xero Central entry is listed unverified with no key fact resting on it.
The bank narration Services Australia uses for a payment run is not confirmed by any primary source in the corpus, so no descriptor string appears here and the matcher learns patterns from the practice's own feed instead.
coreplus documents resubmission and the Medicare processing line but not the removal of a payment that has already been recorded, and whether Halaxy, Nookal, splose or PracSuite do either was not verified on this pass.

How to access Medicare Bulk Bill reports in Health Professional Online Services (HPOS)
Services Australia. Retrieved 3 Sep 2026. Source updated Jul 2024.
primary
Medicare claims processing flows
Tyro Health developer portal. Retrieved 3 Sep 2026.
primary
Process bulk bill claims for Medicare
Cliniko. Retrieved 3 Sep 2026. Source updated 18 Jun 2026.
primary
An invoice failed to sync with Xero
Cliniko. Retrieved 3 Sep 2026.
primary
Troubleshooting Xero exports
Zanda. Retrieved 3 Sep 2026.
primary
Troubleshooting Medicare claims
coreplus. Retrieved 3 Sep 2026. Source updated 9 Aug 2025.
primary
Reconcile Medicare bulk bill and DVA payments in allied health
Invoice Data Extraction. Retrieved 3 Sep 2026. Source updated 14 May 2026.
secondary
Allied health by funding source, the canonical template
Ledger Map. Retrieved 3 Sep 2026.
primary
Remove and redo a bank reconciliation
Xero Central. Retrieved 3 Sep 2026.
unverified

Review

Last reviewed 4 Sep 2026 by Shane

General information for Australian allied health practices, not tax advice. Confirm a treatment with your BAS agent or accountant before you post it.

Guided onboarding

Run one real month before you go live.

Sign up, connect Zanda and Xero, and replay a month you already closed. The map is reviewed with whoever owns the books, and nothing posts until you approve it.

Start your map

Every practice starts from a template. Nothing posts until the map is approved.