Reconcile HICAPS Daily Settlement: Allied-Health Clinic Guide

To reconcile a HICAPS daily settlement report, you line up three sources for the same trading day: the settlement total HICAPS reports for the terminal, the deposit (or batched multi-day deposit) landing in the practice or provider bank account, and the per-claim rebate and gap records in the practice management system. Each fund rebate, each government-scheme payment, and each patient gap on the report should resolve to a matching PMS claim and a corresponding line in the bank feed.

The settlement report itself carries the day's claim batches with per-fund subtotals, the fund rebates that drove most of the activity, the patient-gap EFTPOS transactions run through the same terminal, any government-scheme settlements (Medicare Easyclaim, WorkCover, CTP, TAC, NDIS through HICAPS Digital Claims where the clinic uses them), and per-merchant splits when the terminal is configured for more than one provider. Whether you're a sole-practitioner physiotherapist, chiropractor, osteopath, podiatrist, exercise physiologist, dietitian, psychologist, or speech pathologist running your own terminal, or a practice manager at a multi-practitioner clinic, those are the same components on the same daily report.

The routine described in the rest of this guide is the same shape regardless of which practice management system the clinic runs. Cliniko, Halaxy, Splose, PowerDiary, Best Practice, and Genie each surface the daily-payments view differently, and the operator routine bridges across them rather than committing to one.

Extract the daily settlement report into structured rows

The settlement report is a PDF. Every step that follows depends on having it as structured rows you can sort, filter, sum, and look up against another spreadsheet. That's the bottleneck. Practices that try to reconcile straight from the PDF either skip the per-claim cross-check and settle for matching the day's grand total, or they re-key each row into a spreadsheet by hand and burn an hour a day on transcription. Both failure modes are the same root cause: the data is locked in the wrong format.

The row set the rest of this routine uses needs the following columns: settlement date, transaction time, fund or scheme, claim type (rebate, gap, or scheme payment), provider merchant identifier, patient identifier where the report carries one, item code, claim amount, rebate amount, and gap amount. Multi-merchant terminals add a load-bearing provider-merchant column the per-provider split in section 5 leans on. Once you have those rows in Excel, CSV, or whatever spreadsheet you reconcile in, every downstream step is a sort and a match: filter to today, group by fund, total the rebates, look up patient and date against the PMS, look up merchant subtotal against the bank deposit. The same row set feeds the bank-deposit match, the PMS cross-check, the multi-merchant split, the patient-gap arithmetic, and the posting step. Build it once, use it five times.

For practices that print the settlement report and re-type it, an automated step to extract the HICAPS daily settlement PDF into structured rows is what turns the daily reconciliation from manual transcription into a checking pass. The mechanics are unremarkable: upload the PDF, write a one-line prompt describing the columns above, download the spreadsheet. The settlement report is a non-invoice financial document like any other PDF the practice handles, and the same approach that works for supplier invoices works for the daily settlement export. What matters for the reconciliation routine isn't the tool, it's that you start the day with the rows in a spreadsheet rather than on a printout.

Match the day's totals to the bank deposit

When the deposit lands the same day or the next business day, this match is straightforward: the day's settlement total from the report equals the deposit on the bank line. The bridge between them is the deposit reference HICAPS writes on the bank descriptor. That reference is the operator's anchor for everything that follows, so identify it before you start matching amounts.

The harder case is multi-day batching. HICAPS regularly batches several settlement dates into a single bank deposit, especially across weekends and public holidays. A Monday deposit can cover Friday, Saturday, and Sunday claim activity in one line, and the deposit amount won't match any individual day's settlement total. The deposit reference is what tells you which report dates the deposit represents; once you've read the dates off the reference, sum the relevant settlement-report totals and compare the sum to the deposit amount. This is where the structured row set earns its place — a sort and a sum on the date column gives you the figure to compare in seconds rather than reading down a stack of PDFs.

The order of operations for daily totals reconciliation in an allied-health clinic is the same every day: identify the deposit reference, sum the matching settlement-report totals, and compare to the deposit amount. When the totals don't reconcile, the difference points to one of four things. The deposit may simply not have landed yet — a settlement still in transit will reconcile the next business day. A specific fund may settle direct to the practitioner's nominated account rather than through the HICAPS clearing flow, in which case the report total includes claims the HICAPS deposit doesn't cover. HICAPS may have applied a terminal fee or adjustment that nets the deposit below the gross settlement total. Or a claim may have been entered against the wrong day at the terminal, dragging it into the wrong settlement file.

This is the totals match only. It tells you that the headline numbers reconcile against the bank deposit, but it doesn't tell you that every individual rebate inside the day's total reconciles against a real PMS claim. Operators who stop here pass the daily check at the bank-feed level and discover rejections and per-claim breaks weeks later in the AR ageing. The per-claim cross-check is the next step.

Cross-check per-claim rebates against your practice management system

The per-claim match is what catches what the totals match misses. For each rebate row in the structured settlement set, the PMS should hold a matching claim with the same patient, the same date of service, the same provider, and a rebate amount within the expected range for that fund and item code. Run the match across the day's full row set rather than spot-checking — the structured rows are what makes daily per-claim verification tractable in the time a busy clinic actually has.

To reconcile HICAPS payments to practice management software, you bridge the settlement row set into whichever daily-payments view your PMS surfaces. Cliniko carries it under the daily payments report and surfaces patient, date, provider, and amount against the original invoice. Halaxy records HICAPS Digital Claims against the appointment and exposes a daily payments listing with the rebate split out from the gap. The same data appears in Splose under the patient ledger and the day's payments view, and in PowerDiary against the patient invoice with the rebate, gap, and any remainder visible per row. Best Practice routes the figures through the management module's daily transactions report, while Genie records claim payments under the daily banking summary tied to the provider. The labels and the click paths differ; the reconciliation routine doesn't. You're matching settlement-row rebate to PMS-claim rebate on patient + date + provider + amount, and the PMS is the lookup target.

Two break directions are common. A settlement-row rebate with no matching PMS claim usually means the claim was processed at the terminal but never recorded in the PMS — the front-desk shortcut around the integrated claiming flow, where the practitioner ran the rebate at the terminal and forgot to mark the appointment paid. The fix is a same-day update in the PMS so the patient ledger reflects what actually happened. A PMS claim with no matching settlement-row rebate is the more expensive break: the fund declined the rebate, the patient now owes the full fee, and the clinic needs to either re-submit (when the rejection reason is fixable, like an outdated card or a wrong item code) or invoice the patient for the gross fee. Rejections age fast — a clinic that batches the per-claim check to month-end accumulates a backlog of rejections that are harder to recover from than same-day re-submissions, especially where the patient has already left the consult and won't be back for weeks.

Split the deposit across providers on a multi-merchant terminal

A multi-merchant configuration sends each provider's claim settlements to their own merchant account, and the daily settlement report carries the per-merchant subtotals that map to those separate deposits. The reconciliation routine then runs once per merchant rather than once per terminal — the bank-deposit match runs against each provider's bank line, the per-claim cross-check runs against the PMS for that provider only, and the posting step lands in each provider's AR ledger or trust account separately. The HICAPS multi-merchant settlement split for a clinic with several practitioners is the structural reason the reconciliation has to be done this way.

The cap on the configuration is real and worth quoting: a HICAPS multi-merchant facility supports up to 25 separate bank accounts on a single terminal, so each provider's claims settle into their own account. Clinics with more than 25 providers run a second terminal; clinics under that threshold run a single terminal where every claim is tagged to the provider's merchant identifier on the way through. That tagging is what makes the per-merchant subtotals on the report meaningful.

The daily routine for a multi-merchant clinic is mechanical once the structured row set carries the provider-merchant column. Group the rows by merchant, sum each merchant's settlement total, match each merchant subtotal to that provider's bank deposit, and run the per-claim PMS cross-check inside each merchant's row set. The posting at the end of the routine credits each provider's AR or trust account against their own bank deposit, not against a single clinic-wide account. Clinics that reconcile against the terminal's grand total and post everything to one clinic AR account miss per-provider mismatches entirely — a missing rebate for one practitioner can hide inside another practitioner's surplus, and the discrepancy doesn't surface until a practitioner queries their own monthly statement and finds the numbers don't agree with the PMS.

The patient-gap EFTPOS transactions on the terminal are tagged to a merchant the same way fund rebates are, so the per-merchant discipline carries through to the gap reconciliation in the next section. Run the gap arithmetic per provider, not in aggregate, and the same break interpretation applies inside each merchant's row set.

Reconcile patient gap transactions with the (fee − rebate) check

The arithmetic is plain. For each patient on each date, the gap EFTPOS transaction on the terminal should equal the fee charged minus the rebate received. When it does, the patient has paid exactly what the PMS says they owe, and the per-patient ledger reconciles in the same step as the per-claim rebate match. When it doesn't, one of the three inputs — fee, rebate, or gap — is wrong, and HICAPS gap payment reconciliation becomes a directional exercise: the sign of the difference points you to the right correction.

Three break directions cover the field. Gap too low means the patient was under-charged at the terminal — perhaps a manual gap amount was keyed in instead of letting the terminal calculate it from the rebate, or a discount was applied informally at the front desk. The clinic owes the difference internally and may need to invoice the patient for the shortfall. Gap too high means the patient was over-charged and the clinic owes a refund. Gap is the right size but the rebate or fee doesn't match the PMS expectation usually means the PMS fee schedule is outdated, or the fund rebated at a different rate than the PMS expected (a fee schedule rotation that hasn't been mirrored in the PMS, or a fund-specific rate the PMS doesn't carry). The first two are corrections; the third is a configuration update the clinic owes its own setup.

Allocation discipline is what makes the per-patient match readable. The gap transaction at the terminal should be recorded against the same PMS invoice as the rebate, not as a separate unallocated EFTPOS receipt. When practices record gaps as standalone payments, the per-patient ledger shows the rebate allocated to the invoice and a floating EFTPOS credit on the patient account, and reconciliation breaks that are actually allocation problems present as if they were rebate or fee problems. Fix the allocation pattern and most of the noise on the daily gap check disappears.

Most allied-health clinical services delivered by a recognised health practitioner are GST-free, so the gap is normally GST-free too. Where the gap covers something that does carry GST — retail items dispensed alongside the consult, group programs, exercise classes, or consults that don't meet the GST-free criteria — the clinic-issued invoice still needs to meet the Australian tax invoice requirements for the clinic-issued invoice. Compliance for the GST-bearing component sits in the invoice the PMS issues, not in the HICAPS terminal record.

Route same-terminal scheme payments to their own reconciliation

Allied-health terminals rarely process only private-fund rebates. The same HICAPS terminal commonly handles Medicare Easyclaim payments for allied-health items billed under a chronic-disease management plan referred from a GP, WorkCover and CTP claims where the scheme accepts terminal-based claiming (icare NSW, TAC VIC, WorkSafe VIC, and WorkCover QLD vary in what they support, and what they support changes), DVA where the practitioner is registered to bill direct, and NDIS claims through HICAPS Digital Claims where the participant or their plan manager has authorised terminal-based payment. Each of these settles through the same daily settlement report, but each runs to a different downstream reconciliation routine.

On the settlement report, the fund or scheme identifier on each row tells you the payer, and the claim type tells you the rebate-versus-scheme split. Most government-scheme payments also surface as a separate settlement subtotal on the report, which makes the day's routing decision straightforward: anything tagged Medicare goes to the Medicare reconciliation, anything tagged to a workers' compensation or CTP scheme goes to that scheme's reconciliation, anything tagged DVA goes to the DVA routine, anything tagged NDIS goes to the NDIS reconciliation against the participant's plan. The fund-rebate match in the previous sections runs against what's left.

The operator routine is the same across schemes even though the downstream rules differ. Extract scheme payments out of the fund-rebate row set as a first step on the day's structured rows. Reconcile each scheme's settlement subtotal to its own bank deposit — some schemes deposit separately from the HICAPS clearing flow, and the deposit reference will identify which. Cross-check per-claim payments against the PMS where the PMS carries the claim record, and against the scheme's own portal where it doesn't (Medicare Easyclaim payments, for instance, often need verification against the practitioner's PRODA or HPOS view rather than the PMS, depending on how the claim was submitted). Flag rejections into each scheme's specific re-submission process — Medicare's, the workers' compensation scheme's, NDIS's — rather than treating them as fund rejections, because the rules, deadlines, and re-submission paths are scheme-specific.

The failure mode here is reconciling scheme payments through the same routine as fund rebates and missing scheme-specific rejection patterns. Each scheme has its own deadline clock, and a stale Medicare or WorkCover claim is harder to recover than a stale private-fund rebate. The routing decision is part of the daily HICAPS routine, not a separate workflow — the operator makes it once per day as they walk down the settlement rows, and the scheme-specific reconciliation runs from there.

Post the reconciled revenue into Xero, MYOB, or QuickBooks Online

The posting step uses a HICAPS clearing account in the accounting system. Each day's reconciled settlement total credits the clearing account and debits the per-fund rebate revenue accounts, or the per-provider AR accounts where the clinic runs a multi-merchant terminal. When the bank deposit lands, it debits the bank account and credits the clearing account, taking the clearing balance back to zero. The clearing account is what makes the reconciliation visible at month-end: a non-zero balance is either a deposit genuinely in transit or a missed reconciliation, and the size of the balance tells you which. A clinic that posts settlements straight to revenue and matches the deposit straight to revenue too will get the bank-feed match, but won't see the per-day breaks.

GST coding is the recurring trap. Most allied-health clinical services delivered by a recognised health practitioner are GST-free under Australian rules, so most rebate and gap revenue posts as GST-free. Retail items, group programs, and certain non-clinical services may carry GST and code differently. The per-line GST decision is made when the PMS fee item is set up, not at reconciliation, so the reconciliation just inherits whatever the PMS fee schedule has assigned. Worth flagging when the PMS fee schedule changes; not worth re-litigating every day.

The posting paths are platform-specific only at the click level. To post HICAPS settlement to Xero, MYOB, or QuickBooks Online, the discipline is the same — clearing account, GST-free coding for clinical services, deposit matched against the clearing account in the bank feed — and the platform variation is in how you stage the journal. In Xero, the daily settlement posts as a manual journal or a configured bank rule against the clearing account, and the deposit reconciles via Find & Match. In MYOB, the same journal pattern applies and you import the bank statement into MYOB for the deposit side of the match. In QuickBooks Online, the journal posts to the clearing account and the bank-feed transaction matches against it. In all three, the GST-free code on the revenue line is what carries the GST treatment through to the BAS.

Month-end then becomes a check rather than a reconciliation project. Every fund rebate is tied to a PMS claim. Every gap is tied to a same-day patient invoice. Every government-scheme payment has been routed to its own reconciliation. There are no orphan deposits in the bank feed. The HICAPS clearing account balance reflects only deposits genuinely in transit at the cut-off date. A clinic that holds this discipline daily walks into preparing the BAS in Xero (or the equivalent prep in MYOB or QuickBooks Online) with the AR side already clean. The bookkeeper handling the same monthly cycle will recognise the same discipline in reconciling payday super contributions for clinic staff on the staff-payment side of the practice.