Reconcile Medicare Bulk-Bill and DVA Rebates for Allied Health

To reconcile Medicare bulk-bill rebates in an allied-health clinic, start with the payment run, not the invoice total. Match the Medicare or DVA payment report total to the bank deposit, then reconcile each paid or rejected claim back to the PMS claim register by patient, service date, provider number, item code, rebate amount, and payment status.

That second step is where the real work sits. A bank deposit that agrees to the report total proves the payment run landed, but it does not prove every claim was coded correctly, assigned to the right provider, or posted to the right account. One payment run may include fully paid claims, rejected items, resubmissions, manual PMS allocations, and claims still sitting in a status that should not become revenue yet.

Keep the cash-flow streams separate from the start:

• Bulk-bill Medicare claims: Medicare pays the provider, so the clinic should see the rebate in its bank account.
• Patient claims: The patient may pay the full fee and receive the Medicare rebate personally, so the clinic should not chase a provider bank deposit for that rebate.
• DVA claims: The clinic needs DVA-specific claim evidence, card and eligibility context, and reason-code handling.
• Private health, NDIS plan-managed, WorkCover or CTP, and private-fee receipts: These belong in their own reconciliation streams before the month-end revenue total is tied back.

For a daily reconciliation, the three records that need to agree are the payment report, the bank deposit, and the PMS claim or invoice register. For month end, the clinic also needs a clean exception list showing which claims were rejected, short-paid, resubmitted, or still awaiting action.

Pull the Medicare, DVA, PMS, and bank records into one view

The reconciliation starts by collecting the report that explains the deposit. Depending on the clinic's claiming path, that may be an HPOS or Medicare Online payment report, a Medicare Easyclaim terminal report, a Halaxy Medicare report, a Cliniko Medicare transaction or claim-status view, a DVA claim report, or an exported PMS claim register.

Services Australia describes bulk bill processing and payment reports as including payment-deposit details, bank details, the claims or transactions covered by the payment, and accepted and paid bulk bill claims. Its bulk bill payment report also shows the payment amount for services, the total payment amount for the payment run, and the payment date. That makes the payment report the primary reconciliation source, not merely an attachment for the file.

Capture the fields that let the report line up with both the bank and the PMS:

• Payment date and total paid
• Bank account, bank reference, and payment-run reference
• Payee provider, provider number, and provider location
• Patient or claim identifier
• Service date
• MBS or DVA item
• Claim status
• Rebate or payment amount

For Halaxy, the Medicare report usually supports a payment-date, total-paid, and reference-number match against the bank deposit first, followed by claim-level checking. For Cliniko Medicare bulk bill reconciliation, add the PMS status layer: Medicare approval, invoice payment status, and any manual payment allocation need to agree with the report, not just with the dashboard total.

Medicare Easyclaim payment report reconciliation should be treated as its own source stream when claims are made through a terminal. The terminal-side reports, receipts, and declined transaction details may not line up neatly with PMS exports unless the clinic captures the same service date, item, provider, and patient reference in both places.

For MYOB clinics, the bank-feed side still needs discipline. If the bank feed is incomplete or a legacy file is being loaded, import bank statements into MYOB for deposit matching before clearing a Medicare or DVA payment run against the wrong receipt batch.

Reconcile each claim, not just the deposit total

Once the deposit and payment run agree, reconcile the claim rows. Match each report row to the PMS claim or invoice register using the patient, service date, provider number, clinic site, MBS or DVA item, rebate amount, and status. A payment run can be correct at total level while individual claims are allocated to the wrong practitioner, posted against the wrong visit, or left sitting as unpaid inside the PMS.

For CDM and EPC allied-health services, check the MBS item, referral, and annual service count before accepting a variance as an accounting issue. MBS notes for individual allied health services under chronic disease management cover items 10950 to 10970 and state that Medicare benefits are available for up to five allied-health services per patient per calendar year. If the PMS expected one item and the report paid or rejected another, the exception may come from the referral, five-service limit, practitioner type, provider location, or item selected at billing.

Mental Health Care Plan psychology rebate reconciliation has a similar shape but a different set of checks. MBS Better Access notes group psychological therapy items for clinical psychologists separately from focused psychological strategies items for psychologists, occupational therapists, and social workers, with rebates available for up to 10 individual allied mental health services in a calendar year. Review the plan and referral dates, the item family, the provider number, whether the service was face to face or telehealth, and whether the payment recipient matches the claim type. A patient claim paid to the patient is not an unreconciled provider deposit, even if the PMS visit looks like a Medicare-related service.

Multi-provider and multi-site clinics need one extra control: do not filter the PMS register only by payment date. A Medicare or DVA payment run may group claims across providers, locations, or earlier service dates. Use provider number and site as matching fields so a practitioner working across two locations does not create a false mismatch.

Manual payment allocations deserve the same scrutiny as imported claim statuses. If a staff member marked an invoice as paid inside the PMS before the Medicare or DVA report was available, the reconciliation should still prove the payment amount, claim status, and payment recipient from the report.

Keep DVA, HICAPS, NDIS, and private-fee streams separate

Mixed-payer allied-health clinics should reconcile each stream in its own worksheet, report pack, or clearing account before tying the totals back at month end. Similar dollar amounts are not enough to match payments across Medicare, DVA, HICAPS, NDIS, WorkCover, CTP, and private-fee receipts.

DVA bulk bill payment report reconciliation belongs beside Medicare, not inside it. DVA has its own card context, fee schedules, claim-status evidence, and reason-code handling. A gold card generally points to broad treatment coverage, a white card needs the service to relate to accepted conditions, and a Veteran Orange Card should usually be a red flag for allied-health treatment claims because DVA says it is for pharmaceutical concessions and cannot be used for medical or other healthcare treatment. For reconciliation, that means a DVA exception is not just a dollar variance; it may be an eligibility, service-type, or evidence issue.

HICAPS private-health settlements also need their own trail. A terminal may process private-health claims, Medicare Easyclaim transactions, and card payments in the same operating environment, but those reports do not become the same revenue stream. The clinic should be able to show which settlement line belongs to private health, which claim belongs to Medicare, and which receipt is an ordinary patient payment.

Plan-managed NDIS revenue is another sibling stream. When a clinic receives a plan-manager remittance, the matching job is remittance-to-invoice rather than Medicare item-to-rebate. Treat it separately and reconcile NDIS plan-manager remittance advice against the relevant invoices before it is included in the clinic's month-end revenue review.

The same principle applies to WorkCover, CTP, and insurer payments. Reconcile the scheme document to the invoice and bank receipt first, then bring the cleared total into the month-end view. A single clearing account may be convenient in the general ledger, but the supporting worksheet should still preserve payer type, source report, claim identifier, and exception status.

Treat rejected and short-paid claims as a queue, not a write-off

For Medicare rejected claims in allied health, the reconciliation should produce a live exception queue. Each rejected, zero-paid, short-paid, or resubmitted claim needs a reason, owner, next action, resubmission date, and final outcome. Until that outcome is known, it should not disappear into a write-off account simply because the bank deposit did not include it.

Common exception causes are operational, not accounting-only problems. A provider number may not match the service location. A referral may not have been lodged, may have expired, or may not cover the service date. The item code may not apply to the patient's plan or practitioner type. A CDM service count may have been exhausted. A telehealth item may have eligibility rules that differ from the face-to-face service the clinic expected.

Separate genuine rejections from timing differences. A claim lodged late in the day may sit outside the current payment run. A patient claim may have paid the patient instead of the clinic. A staff member may have manually allocated a PMS payment before the Medicare or DVA report confirmed the amount. Those items need different follow-up actions, even if they all appear as unmatched rows in the first pass.

Retain the evidence with the exception row. For Medicare, keep the status or rejection detail from the report or portal. For DVA, record the DVA reason code or other claim-response evidence. For both, link the exception back to the source report, PMS claim, invoice, and any resubmission record.

Recurring exceptions are useful management information. If the same provider location, referral type, item code, or intake process keeps producing rejected claims, the reconciliation is pointing to an upstream fix. The owner of the queue should report patterns back to reception, practitioners, or billing staff before the same problem rolls into the next payment run.

Post GST-free health revenue only after the claim evidence agrees

Most Medicare-rebated allied-health services are treated as GST-free health services, but GST coding is the last step, not the reconciliation itself. The clinic still needs evidence that the payment run, claim rows, bank deposit, and PMS status agree before revenue is posted or cleared.

A practical posting flow is:

• Reconcile Medicare, DVA, HICAPS, NDIS, scheme, and private-fee streams separately.
• Use a debtor or clearing account where the PMS has raised invoices before the payment arrives.
• Allocate the bank deposit against the claim or payment run once the report total agrees.
• Keep rejected and resubmitted claims in the exception queue until the outcome is known.
• Code the cleared Medicare or DVA revenue according to the clinic's GST-free health-service treatment and chart of accounts.

That sequence keeps the BAS review tied to source evidence. A bookkeeper can prepare BAS in Xero after reconciling GST-free health revenue, but the BAS check should not be the first time the clinic discovers that a Medicare payment run included rejected claims or a DVA payment was posted to the wrong provider.

The same logic applies in MYOB or QuickBooks Online. The software names differ, but the accounting test is the same: the deposit allocated in the bank feed should trace back to a source report, the report should trace back to claim rows, and open exceptions should remain visible until corrected, resubmitted, or formally written off.

Build a repeatable evidence pack for every payment run

The finished reconciliation should leave behind a payment-run evidence pack, not only a ticked bank transaction. A useful pack has one row per claim, receipt, or exception, with the source file, page or report reference, payment date, bank reference, provider number, patient or claim identifier, item code, status, rebate amount, exception reason, and accounting treatment.

For mixed-payer clinics, the evidence pack usually starts with inconsistent source documents: Medicare or DVA reports, HICAPS settlement PDFs, exported PMS claim lists, remittance advices, and bank-statement PDFs. Normalising those documents into the same row structure makes the matching work reviewable. It also gives the clinic an audit trail when a payment is questioned later.

Invoice Data Extraction fits that document-to-row step. It converts invoices and financial documents into structured Excel, CSV, or JSON output from uploaded PDFs or images, and every output row can include source-file and page references for checking against the original document. For this workflow, the relevant job is to extract Medicare and DVA payment reports to structured rows alongside HICAPS reports, PMS exports, remittance advices, and bank statements.

It does not submit Medicare claims, replace Halaxy or Cliniko, decide DVA eligibility, or post bank-feed transactions. Its role is narrower: give the bookkeeper or clinic operator a consistent row set that can be matched, filtered, checked, and retained as evidence.

Set the standard plainly: every posted deposit should trace back to report rows, and every exception should have an owner and status.