Problems
Two Medicare deposits landed on the same day
Two credits are two payment runs. Services Australia pays per payment run per payee provider number, and bank details are registered for each provider location, so one practice can be paid twice in a day. Group the paid claims by payee provider number and then by run number, match one credit to each group, and hold each run in its own clearing entry.
Key facts
- What one credit is
- The Medicare payment received to the bank account for one payment run, with the amount paid for each claim of that run listed underneath it5
- Why one practice can be paid twice
- Bank account details are registered with Services Australia for each provider location in order to receive a payment1
- The grouping key
- Payee provider number first, then the payment run number on the payment report2
- What joins a run to a credit
- The run number, which Zanda documents as corresponding to the payment identifier Medicare used for the bank payment2
- What a report pull needs
- Report type, payee provider number, a lodgement date range, a claiming method of either Easyclaim or Webclaim, and a format1
- When a report can be read
- One business day after the claim is finalised, through HPOS with a PRODA login1
- Who splits the money
- Services Australia, at provider level. Tyro Health states that it does not manage settlement for Medicare or DVA4
- Where each run is held
- 100 Medicare clearing for Medicare and 101 DVA clearing for DVA, kept apart because the two pay in their own runs7
A Medicare credit is a run, not a day
A second credit is not by itself a sign that something went wrong. The unit Services Australia pays in is the payment run, and a run is a set of claims that were finalised and approved together for one payee provider number. Two runs finishing on the same day produce two transfers, and the bank shows them as two ordinary credits with no relationship printed between them.
Deposit amount refers to the Medicare payment received to the bank account for the payment run. Amount Paid refers to the amount paid by Medicare for each claim of the payment run.5
The mistake that costs an hour is treating the two credits as one day's money. Added together they do reconcile against a day's claims, sometimes, and then the next day they do not, because a run is not bounded by a date. Each credit has its own list, and the rest of this page is about finding which list belongs to which credit.
Why two land together
Four situations produce a second credit on the same day. Three of them are documented and one is worth watching rather than asserting, so it sits in the open questions at the foot of this page.
| The situation | Where it is written down | What you will see |
|---|---|---|
| Two payee provider numbers, or one per site | The Services Australia report guide, which requires bank details per provider location | Two credits, each with its own payment report pulled under its own payee provider number |
| A Medicare run and a DVA run finishing together | The canonical template, which keeps a clearing account for each because DVA pays in its own runs | Two credits of unrelated size, the DVA one tied to its own run number |
| Two runs for the same payee provider number | The run number column on the payment report | Two credits whose claims carry different run numbers on the same report |
| Claims lodged by two claiming methods | The report form, which takes one claiming method per pull | One report per method, so the day looks incomplete until both are pulled |
The first is the common one in a group practice, and it is the one the canonical template writes into the Medicare rail itself rather than leaving in a note.
Medicare pays per payment run per payee provider number, so a practice with several provider numbers can see more than one Medicare deposit a day (docs/research/domain-mechanics.md, section 1.1).7
The provider is the payee, not the practice
This is the part that surprises people who think of the practice as the entity Medicare pays. It is not. The claim is assigned to a servicing provider and paid to a payee provider, and the bank account sits underneath that registration.
You must have your bank account details registered with Services Australia, for each provider location, in order to receive a payment.1
The claiming partners say the same thing from their side. Tyro Health, whose integration Cliniko practices use for Medicare claiming, states that it does not manage settlement for Medicare or DVA and that Medicare claims are settled at provider level. So a practice with three practitioners at two sites can hold several registrations, and each one of them can produce its own credit on its own schedule.
The grouping key that makes both credits reconcilable
Group the paid claims by payee provider number, then by run number, and each group is one credit. That is the whole method, and it holds whichever of the four situations above produced the second line. The run number is the join, because Zanda documents it as corresponding to the payment identifier Medicare used for the payment into the bank account.
Pulling the right reports
The report form is where the grouping key becomes real work, because it takes one payee provider number and one claiming method per pull. A practice with two registrations that claims by both methods pulls four payment reports to cover one day, and four processing reports again if a credit looks short.
- Log into HPOS with a PRODA account and open the Medicare bulk bill reports.
- Choose the report type. Payment reports list the claims that were successfully submitted and paid, which is the list that reconciles a credit.
- Enter one payee provider number. This is the field that separates the two credits, so run it once per registration rather than looking for a practice level total.
- Enter the lodgement date range, remembering that it is the lodgement date rather than the paid date, so the range that explains today's credit starts earlier.
- Choose the claiming method, Easyclaim for a terminal claim or Webclaim for a claim lodged in HPOS, and repeat the pull for the other method where the practice uses both.
- Choose the format, then add the paid amounts by run number. Each run total is one credit.
A report is available one business day after the claim is finalised, and Zanda notes that Medicare generates a payment status report 48 hours after a claim is processed. Those two are measured from different events, so on the day the second credit lands one of its claims may still have no report line.
When one of the two credits is DVA
DVA claims travel the same channel and are adjudicated by the same agency, which is why they are easy to mistake for Medicare money. They are paid in their own runs, so the second credit on a Tuesday may be the veterans' work rather than a second Medicare registration.
DVA claims are adjudicated and paid through the same Services Australia channel as Medicare but as separate payment runs (docs/research/domain-mechanics.md, section 1.2).7
The canonical template holds the two apart on the ledger for exactly that reason, with its own account for each. Keeping them apart is what lets an aged balance point at one funder instead of at a pooled figure that could be either.
The Xero pattern for two credits
The pattern that survives a second credit is the same clearing pattern that handles the first, applied once per run. Each approved claim is receipted into the funder's clearing account on the date Services Australia paid it, and the bank credit is matched as a transfer out of that account for the run total.
- Receipt each paid claim into the clearing account for its funder, on the paid date rather than the bank date.
- Match each credit against its own run total, so two credits leave two matched entries rather than one merged one.
- Keep Medicare and DVA in separate clearing accounts, because the two pay in separate runs and a pooled balance cannot be aged.
- Read the remaining balance as approved claims that have not yet been banked, and check it against the runs still outstanding for every payee provider number.
When the second credit has not arrived yet
The same mechanics explain the opposite symptom. If the day's claims are worth more than the credit that landed, a second run for another payee provider number may simply be behind rather than missing, and treating the difference as a shortfall on the day it appears usually creates a correction later in the week.
Whether a credit is short for a different reason is a separate question, and it has its own page. The test that separates the two is the run number: a credit that equals a run total is intact, whatever the day's lodgement adds up to.
What Ledger Map does with two credits
Ledger Map holds one standing map for the practice, approved before anything syncs. Paid claims resolve through that map into the funder's clearing account on the date they were paid, each run is posted as one balanced document set, and one exact match is left in the bank feed for each credit. Two runs produce two document sets and two matches, not one merged entry.
Where a credit cannot be tied to a run from the reports the practice holds, it becomes a question with the candidate groupings laid out rather than a silent posting. The accounts and the tax rates are the practice's own template, not a choice Ledger Map made. The funder hub for Medicare bulk bill sets out the money flow, DVA covers the other half of this pair, and how it works shows the map itself.
Questions
Why did two Medicare deposits land on the same day?
Because two payment runs finished on the same day. Services Australia pays one transfer per run per payee provider number, and bank details are registered for each provider location, so a practice with more than one registration can be paid twice. A Medicare run and a DVA run finishing together does the same thing.
How do I tell which claims are in which deposit?
Pull the bulk bill payment report for each payee provider number and the lodgement date range that covers the claims, then add the paid amounts by run number. Each run total is one credit. The run number is the field that ties a group of claims to the payment that landed.
What is a Medicare payment run number?
It is the identifier Services Australia gives a batch of claims paid together. Zanda documents it as a short code on the payment report that corresponds to the payment identifier Medicare used for the payment into the bank account, which makes it the join between a set of claims and one credit.
Do Medicare and DVA pay in the same deposit?
They are paid in separate payment runs, so expect separate bank lines. The canonical allied health template keeps a clearing account for each on that reasoning, which is what lets an aged balance name one funder rather than a pooled figure.
Should I match both credits in one Find and Match?
Matching each credit against its own run keeps the evidence. A single match across the whole day clears the bank screen but leaves a clearing balance that cannot say which registration is behind, so a run that did not arrive reads as a small unexplained difference for weeks.
Read next
- ProblemsMedicare deposit is less than the claims sent
- ProblemsClearing account will not clear in Xero
- ProblemsMedicare claim rejected after the invoice was paid
- FundersHow Medicare bulk bill payments land in Xero
- FundersHow DVA allied health payments land in Xero
- Practice systemsCliniko Xero integration: what syncs, what does not
- HubProblems
Sources
Open questions
- Whether Easyclaim and Webclaim claims for the same payee provider number are paid in separate runs is not stated by any source found this session. What is documented is that a report is pulled per claiming method, so this page states the report consequence rather than a payment rule.
- Services Australia publishes no cut off time for a payment run, so two runs landing on the same day for one payee provider number cannot be predicted from a published rule. The run number on the payment report is the evidence after the fact.
- The bank narration Services Australia uses is not confirmed by any primary source in the corpus. Zanda documents the run number as corresponding to the payment identifier, which is a join key rather than a narration string, so no descriptor string appears here.
- The Services Australia guide says reports are available one business day after a claim is finalised, while Zanda says a payment status report generates 48 hours after processing. Both are stated rather than merged, because they are measured from different events.
- That DVA is reported through a report type of its own is written into the canonical template but is not corroborated by an external source found this session. The Services Australia guide read here covers Medicare bulk bill reports, and the vendor screens show Medicare and DVA claims together, so the page states the separate runs rather than a separate report type.
- No search result snapshot was captured for this page's query, so the claim that it adds something the current answers lack rests on the neighbouring snapshot and on the source reading rather than on a captured result set.
- 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 Claim Payment (Bulk Bill / DVA) Report
MedicalDirector Bluechip knowledge base. Retrieved 3 Sep 2026.
secondary
- Cliniko Medicare frequently asked questions
Cliniko. Retrieved 3 Sep 2026. Source updated 15 Oct 2024.
secondary
Review
Last reviewed 3 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.
Every practice starts from a template. Nothing posts until the map is approved.