NDIS Service Agreement Generator
Draft a participant service agreement from the plan and the current price limits in minutes — every rate, support item and cancellation term in place before a coordinator signs off.
Reads the participant's plan and the current NDIS price limits, drafts the full agreement, and surfaces every rate and term for a person to check and approve before it goes to the participant.
Where this works well
The slow, invisible cost a service agreement hides is the cross-checking. Every line has to be traced from a funded support category in the participant's plan, to a support item, to a price limit in a document that gets reissued during the year, and then written up with the right cancellation terms and participant-rights wording. Done properly by hand it is an hour or two per agreement, and the part most likely to be skipped under time pressure is the rate-by-rate check against the current price limits. This pattern earns its keep by doing that cross-check every time, in full, and showing its working.
It helps most a support coordinator or plan manager who drafts agreements regularly — at the point of plan start, plan review, or onboarding a new participant — and who is currently rekeying figures out of a plan summary and a price file. At ten or twenty agreements a month the recaptured time is real, and it goes back into the participant conversation rather than the paperwork.
Where it works badly
It is confidently wrong when the inputs are stale. Point it at last year's Pricing Arrangements, or a plan that has since been reviewed, and it will draft a clean, professional agreement full of rates that no longer hold. The output looks more trustworthy than the data behind it — that is the trap. It is also weak where a support does not map cleanly to a single support item: bespoke arrangements, quotable supports, or anything that needs a judgement about which item actually applies. There it should flag the ambiguity, not guess.
The honest test: if you cannot say, right now, which version of the price limits and which plan period this agreement is drafted against, this tool will make your wrong answer faster, not safer. And if most of your agreements are non-standard one-offs rather than recurring service schedules, the template gives you less than the manual judgement already does.
What it doesn't do — and shouldn't
It drafts; a person approves. It surfaces the rate it used, the support item it matched, the price limit it checked against, and a flag wherever it could not match cleanly — and then it stops. It does not send the agreement, does not certify it as NDIS-compliant, and does not decide whether the service mix is right for the participant. Those are the coordinator's calls.
That boundary is deliberate. A service agreement is the document a participant signs and the basis on which a provider claims — it carries obligations under the NDIS Practice Standards (incident management, complaints handling, participant rights) and under the participant's plan. Getting a rate or a term wrong has consequences for both the participant's budget and the provider's standing with the NDIS Quality and Safeguards Commission. The accountable person stays on the decision because the consequence lands on them, not the tool.
What your data has to look like for this to work
Concretely: the participant's plan summary needs to expose funded supports as structured fields — category (Core, Capacity Building, Capital), support area, and budget — not buried in a PDF a coordinator retypes. You need the current NDIS Pricing Arrangements and Price Limits as a current, machine-readable price file, and a way to know it is the version in force today. You need the support item catalogue to map against, the provider's registration and ABN details, and a clear plan period and review date.
Most providers have some of this in good shape and some of it not. The price limits are usually the weak point — held as last year's PDF, or as a spreadsheet someone updates by hand and forgets. Fixing that is usually the real first job: it is a question of how the plan and price information is captured and kept current, not of buying another tool. That groundwork is the work we help with, and it is typically larger and more valuable than the drafting layer that sits on top of it — because once the inputs are clean and current, every agreement after that is faster and right by default.
Could it draft an agreement that quietly overcharges a participant or breaches a price limit?
It can draft a rate that is wrong — that is exactly why nothing is sent on its say-so. It maps each funded support to a support item, applies the current price limits, and shows its working: the rate it used, the limit it checked against, and a flag where it could not match a support cleanly. A coordinator or plan manager checks those before approving. The tool surfaces the numbers; the person stands behind them. If a rate is stale or a support item is mismatched, that shows up at the review step, not after the participant has signed.
Our plan exports and price files are messy — half PDF, half spreadsheet, some hand-keyed. Will it still work?
It works from structured fields — funded support categories, budgets, the support item catalogue, the published price limits. If your plan data lives in a PDF a coordinator retypes each time, the draft is only as good as that retyping, and the tool cannot tell a typo from a real figure. Getting the plan summary and the current price file into a clean, current, structured form is usually the first piece of work, and it is the piece that pays off across every agreement you draft afterwards.
Does this replace our support coordinator or plan manager?
No. It removes the typing and the cross-checking against the price guide — the two hours of clerical work around an agreement — so the coordinator spends their time on the judgement calls: whether the service mix actually serves the participant's goals, whether the frequency is right, whether the participant understands what they are signing. The agreement is still theirs. The capacity it frees goes back into participant-facing work, not off the books.
How current does the price and plan data need to be?
Current to the active arrangements. NDIS price limits are reissued — the 2025-26 Pricing Arrangements and Price Limits, for example, have already been updated mid-year — and a plan can be reviewed or changed at any time. If the tool is pointed at last year's price file or a superseded plan, it will draft confidently wrong rates. The honest test: do you know, today, which version of the price limits and which plan period this agreement is being drafted against? If not, fix that before drafting.
Where does the participant's plan data go, and who can see it?
A participant's NDIS number, plan and funded supports are sensitive personal information under the Privacy Act and the NDIS Code of Conduct. Any deployment runs against your own systems and data handling, not a shared pool, and we scope where the data sits and who can see it as part of the build. The demo you see here runs entirely on fabricated data — Emma Nguyen is not a real participant.
Will it keep the agreement compliant with NDIS rules on its own?
It drafts to the rules it has been given and flags where a rate sits outside a price limit, but it does not certify compliance. Things like incident-management obligations, complaints pathways and the participant-rights wording come from the NDIS Practice Standards and your own registered-provider obligations — a person confirms those apply and are current for this participant. The tool gets the draft 90% of the way; the accountable person closes the last 10%.
Estimated build: 3–4 weeks. Most of it is template work we've already done.
Fixed scope, fixed price, fixed dates.
The cost band reflects the engagement shape, not a per-feature line item. We work on fixed scope, fixed price, fixed dates — see the services catalogue for what falls inside each band.
Considering this for your org?
The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where it hurts; we’ll play it back, scope it, and show you what’s possible.