Private patients: card, EFTPOS and Stripe

A private patient is the only payer who settles on the spot, which sounds like the easy case and is not. The money still arrives through a processor, and the processor decides what the bank line looks like. A terminal settles the day gross and bills its fee later. An online card processor pays out net, with the fee already gone before the practice sees the money. The invoices in the practice system are the same in both cases, so the whole difference lands in the bank feed.

A standalone terminal is the mirror image. The bank line equals the day's approved card takings, so the deposit reconciles against the receipts with no fee in sight. The fee turns up weeks later as a single monthly debit with no invoice behind it, and the canonical template posts that debit to the merchant fee account rather than netting it against revenue.

Stripe publishes a report whose stated purpose is this exact match, and it is the file a bookkeeper should be working from rather than a bank statement narration.

helps you match the payouts you receive in your bank account with the batches of payments and other transactions that they relate to²

One limit is worth knowing before a practice leans on the report. It covers automatic payouts. For an instant payout Stripe says it cannot identify which transactions are inside the payout, which leaves the practice matching those against its own transaction history.

In the allied health canonical template a private consultation posts to account 400, Clinical services, private patients, as GST free income. The ATO sets three conditions for a health service that is not a medical service: it is a listed health service, it is performed by a recognised health professional in that listed service or by their assistant under the supervision conditions the ATO sets out, and it is generally accepted in that profession as being necessary for the appropriate treatment of the recipient of the supply. Who handed the money over is not one of the three, and the ATO says a supply that meets the definition keeps its treatment where a third party pays the practitioner on the patient's behalf. A report or a training session posts to its own account as taxable, whichever card was tapped. Supervision sits on the same account by the template's default, and that account's own note asks a practice to confirm it, because one reading treats supervising another practitioner as a service to that practitioner rather than a health service and an ATO interpretative decision is cited as pointing the other way. A take home product is taxable by default too, with the template carrying an item level override to GST free for Schedule 3 medical aids, because the ATO treats goods a patient takes home as GST free only where they are a necessary part of the health service supplied at the same time.

The fee is the other side of the same deposit. The template posts a processing fee to 604, Merchant and claiming fees, with GST on expenses, and Stripe's pricing page states that its fees include GST. That puts a small input tax credit inside an otherwise GST free revenue stream, which is worth expecting on the activity statement rather than being surprised by.

Ledger Map holds one standing map for the practice, approved before anything syncs. A private card line resolves to its account and its tax rate through that map. A payout is posted as one balanced document set: the receipts against the clearing account, the fee against the merchant fee expense, and the transfer that leaves one exact match against the bank line. Anything the map cannot resolve becomes a question with the options laid out, rather than a quiet posting nobody sees.

None of the treatments on this page are choices Ledger Map made. The accounts and the tax codes come from the canonical template the practice starts from, and the practice approves the map before an invoice moves. You can see the shape of it on how it works, and compare the other private rails on the funders hub and the Tyro EFTPOS and HealthPoint page.