The Paper Participant

by | Jul 7, 2026

Paper Participant 1

NDIS payment integrity can look perfect on paper. Somewhere in the scheme’s ledgers lives a participant who receives immaculate services. Every shift delivered in full, every note complete, every claim justified. He doesn’t exist. He’s made of paper. And the integrity reforms were written specifically to find him.

Let’s start with the version everybody agrees on. The deliberate fraud — phantom shifts, cloned invoices, plans drained by providers the participant has never met — is indefensible, it steals from disabled people, and the sharpened enforcement toolkit that came with the integrity reforms (bigger penalties, better data-matching, a Commission and Agency finally comparing notes) is overdue. No honest provider mourns any of that.

Now the version that should worry honest providers: most payment integrity findings don’t start as dishonesty. They start as drift. And the reforms have collapsed the distance between drift and finding to almost nothing.

How honest providers end up with a paper participant

Drift has a hundred small doors, and they all look like operational pragmatism at the time.

The shift claimed as rostered rather than as delivered — the worker left forty minutes early, the roster says eight hours, the claim follows the roster, and nobody reconciles the two because they live in different systems. The participant in hospital for a week whose SIL claims kept running, because pausing them was somebody’s job and nobody was sure whose. The “flexible” relabelling — community access hours quietly claimed under a different line item when the participation budget tightened, because the support was “basically the same thing.” The travel claimed at the maximum because calculating the actual is tedious. The cancellation claimed without the evidence trail the rules require. The group support claimed at individual ratios because the roster template was never updated when the third participant moved in.

Any one of these, in isolation, reads as sloppiness. The reforms read them differently, for one structural reason: the Agency can now see patterns you can’t. Data-matching across claims, plans, rosters and payment histories means the question is no longer whether a single claim can be explained — it’s whether ten thousand of your claims, laid side by side against your service records, tell one consistent story. Drift is invisible claim by claim and glaring in aggregate. The provider is usually the last to see their own pattern.

And when the please-explain letter arrives, the test is brutal in its simplicity: for every dollar claimed, show the support delivered. Not the support rostered. Not the support agreed. Delivered — by whom, to whom, when, evidenced contemporaneously. If your answer is a roster export and a shrug, you don’t have a billing disagreement. You have a repayment demand, a compliance file, and — under the sharpened key personnel provisions — directors personally in the frame for a claims culture they didn’t know they had.

The one-system answer

Here’s the uncomfortable diagnostic question: *can your claims and your service delivery records disagree with each other?*

If claiming runs off the roster while reality lives in shift notes — if those are different systems, reconciled by hope — then disagreement isn’t a risk, it’s a certainty, and every disagreement is a future finding compounding at scale. The fix isn’t more auditing of the gap. It’s removing the gap.

That’s the design principle: claims should be generated from delivery, not from intention. The worker clocks the actual shift — actual start, actual end, actual participant — and that record *is* the claimable event. Shift shortened? The claim shortens with it, automatically, no reconciliation meeting required. Participant in hospital? The status change suspends claiming the day it’s entered, not the day finance finds out. Cancellation? The system captures the notice period and evidence at the moment it happens, and applies the rule, not the habit. Ratios, line items and price limits validated against the participant’s actual plan before the claim leaves the building — so the error is caught by your software on Tuesday instead of by the Agency’s algorithm in eighteen months, with interest and a headline.

Run claiming this way and something quietly profound happens: the paper participant becomes impossible to construct, even accidentally. Every claim has a delivery record as its parent. Every dollar traces to a timestamped human event. The please-explain letter, if it ever comes, gets answered with a query instead of a fortnight of forensic panic.

Integrity is a system property, not a personality trait

The sector likes to talk about payment integrity as a values question — good providers versus bad actors. Values matter, but the reforms embody a harder-headed view: at scale, integrity is architecture. A provider whose systems make wrong claims easy and right claims laborious will drift, whatever its values, because busy people follow the path of least resistance. A provider whose systems make the accurate claim the *only* claim the software can produce doesn’t need to rely on anyone’s virtue at 4:55pm on invoice day.

The deliberate fraudsters will be caught by data-matching, and good riddance. The honest-but-fragmented providers will be caught by the same algorithms, and the finding won’t care about the difference in intent — repayments, penalties and registration consequences read identically on the outcome page. The only durable position in the reformed scheme is the provider who can prove, continuously and automatically, that every claimed dollar bought a delivered support.

Paper participants are built one unreconciled shift at a time. So is the audit trail that proves you never built one. Same effort. Choose the second.

*HuGo is NDIS provider management software where claims are born from delivery records — shift-verified billing, plan and ratio validation before submission, automatic suspension on status changes, and a claims-to-delivery audit trail the Agency can’t argue with. If your roster and your invoices have ever disagreed, book a demo before someone else notices.*

Keep support delivery and records connected

Bring participant information, shift records and operational data together so your team has a clearer evidence trail of the support being delivered.