A question came up on the Splose community page a week or so back. A clinic had started seeing Medicare clients alongside private ones, the volume was climbing, and they wanted to know how everyone else stays on top of the rebates. Not because anything was broken. It was working fine at the volume they were at, and they could see it not working at the volume they were heading for.
That's the right time to ask, because the rebate isn't hard. It just isn't attached to anything that tells you it's due. Money arrives, someone reconciles it, the invoice goes green. Nothing in that says and this one was Medicare, so a family is now waiting on you.
So somebody has to go and look. You can see the payment matched in Xero, good, reconciled. Then, hold on, was that a Medicare one? Open the invoice. Check the item. No, sorry, wrong one, that was Sally's not John's. Back out, find the right one, now you can process it. Small, and it's the small ones that add up.
Instead of treating that as a memory problem, treat it as a notification problem. Everything you need to know is already true the moment the invoice is marked paid. Splose knows the item code. Xero knows the money landed. Nobody is looking at either.
So we made something look. It sits across the Splose and Xero APIs and watches two things: the service on the appointment, and the item code on the invoice. When an invoice carrying a Medicare item is marked paid, admin get an email. This one.
How the money arrived doesn't matter, and that's the part I like. A card payment through the link is close to instant, so the email is too. A bank deposit where the family used the invoice number as their reference gets matched by Xero on its own, the invoice flips to paid, and the email follows off the back of that. A manual match is the same thing, just at the moment somebody does the matching. Three different routes into the clinic, one trigger out.
Click the button and you're on the invoice, already paid, already synced to Xero, with the Medicare claim ready to start. Nobody assembles anything and nobody goes looking for which invoice it was. Start the claim, cross it off, next thing.
Two reasons we built it. The first is mental load, which I think about more than most, having been badly burnt out in the past. On its own this is a tiny thing. That's exactly why it's worth removing, because the small ones stack, and every one of them is something a person is quietly holding onto while they're trying to answer the phone or help a family. It's the same reason we don't leave a new enquiry waiting for someone to remember it.
The second is that we looked at our own turnaround and didn't love it. Between a family paying and the rebate reaching them was, in some cases, three to five days, depending on which day the payment landed and when our admin team were working. And plenty of clinics have no full-time admin at all. The owner is the admin, the reconciling happens late at night, and a few days of not getting to it is a family waiting on their money. Times are tough enough.
Worth saying what it doesn't do. It doesn't submit anything. The claim is still made by a person, on purpose. What it removes is the noticing, the checking and the finding.
If you want to know whether you need it, take the last ten Medicare invoices you were paid on and measure the gap between the payment landing and the claim going through. If it's always a few hours, you're fine. If it moves around depending on the day of the week, that isn't a discipline problem in your team. It's that nothing is telling them.
We've built the same shape more than once now. Registrations and insurance expiring is the same thing with a date instead of a payment. Once you see it, you start noticing it everywhere.
Common questions
Splose will show the invoice as paid, but it won't go and tell anyone. Ours is a Power Automate flow sitting across the Splose and Xero APIs, watching for an invoice with a Medicare item code changing to paid, then emailing admin. The data is all standard, it's the noticing that had to be built.
