What a claims VA
actually does in your system
Providers ask what the person will actually be doing all day. Here is the answer, screen by screen, for the four systems we place into most — plus the permissions to set and the two things that never leave your registered staff.
"Can they use Splose?" is the question every provider asks, and it is the wrong one. The systems are learnable in a fortnight. What takes months is knowing which line item applies, why a claim bounced, and what a service booking needs to look like before it will pay.
So this guide is about the work rather than the software. The tasks below are the same in Splose, ShiftCare, Lumary and Brevity — the buttons differ, the job does not.
Where the systems genuinely differ is permissions, and that matters more than feature lists. Each one gives you different levers to limit what a team member can see and change, and getting that right on day one is the difference between a safe arrangement and an uncomfortable one.
Who this is for
✓Worth your time if
- You already run Splose, ShiftCare, Lumary, Brevity or similar
- Claiming is late, or rejections are being written off rather than worked
- Coordinators are doing rostering and invoicing instead of participant work
- You want to know exactly what a VA would do before you commit
✕Probably not if
- You have not chosen a practice system yet — do that first
- You need someone participant-facing or clinically qualified
- Your service agreements and price guide mapping were never set up properly
- You want someone to hold your NDIS provider portal login
The daily and fortnightly work
The same in all four systems. Ordered roughly by how a fortnight actually runs.
Reviewing yesterday's delivered supports against the roster, flagging shifts with no note, no time or no service item attached — so problems are caught while people still remember.
Following up support workers whose notes are missing, and checking submitted notes are attached to the right shift and item. Chasing and formatting only; the content is the worker's.
Bookings created and extended before they expire — the single most common reason a claim fails.
Building the claim batch, checking every line against the booking and the price guide, and flagging anything that will not pass before it is submitted.
Submitting the batch and working the response the same day rather than next fortnight.
Diagnosing each rejected line — wrong item, expired booking, insufficient funds, duplicate — correcting and resubmitting. This is where the money is.
Invoices raised to plan managers in their required format, remittances tracked, unpaid invoices chased past terms.
Budget burn tracked per participant against plan end dates, with under-utilisation flagged early enough to act.
Next fortnight built against plans, availability and skill mix, with award-condition conflicts flagged for you.
Worker screening, first aid, insurances and training tracked with a rolling expiry list.
The two things that never leave your registered staff
Everything above is administrative. Two categories are not, and no system permission changes that.
- Anything participant-facingDirect support, assessment, clinical decisions and behaviour support require a qualified worker with NDIS Worker Screening. Not an offshore role, ever.
- The clinical content of notesA VA chases, formats and flags gaps. What is written about a participant is written by the person who delivered the support.
- Provider portal credentialsNever shared. Claiming happens through your practice system; the portal stays with your staff.
- Incident and restrictive practice decisionsReportable incident determinations and safeguarding judgements go through your own chain.
How the first month runs
Claiming first, and nothing submitted unreviewed until you have seen a full clean cycle.
Week one: access, permissions and shadowing
Named user created with scoped permissions, then they watch a full claim cycle and document what they see. Most providers discover their process was never written down.
Week two: claim preparation, not submission
They build the batch; you review every line before it goes. This is where the price guide learning actually happens, and where you find out what they do not yet know.
Week three: submission with review
They submit after your check, and own the rejection list. Recovery work starts here and is usually the first visible win.
Week four: the back log
Point them at the aged rejections nobody has worked. It is finite, measurable, self-funding, and it teaches your item mix faster than anything else.
Month two: rostering and invoicing
Add plan-managed invoicing and roster build once claiming is steady. Notes chasing and compliance registers come last, because they need standing with your team.
Full admin access because it was quicker
Every one of these systems has role-based permissions, and the temptation is to skip configuring them because the person needs to "see everything to do the job". They do not. A claims role needs participants, bookings, claims and invoices — not the ability to edit service agreements, change price guide mappings or alter historical notes. Spend twenty minutes on the permission set on day one. It is far harder to walk back later, and it is the first thing an auditor will ask about.