Using the NDIS Provider Portals

The agency gives providers three online portals, and each one does a different job. This lesson explains them. Key points: the my NDIS provider portal is used for participants whose plans are in the new computer system, known as PACE, and for all claim and payment enquiries; the myplace provider portal is where every payment request is made, and where service bookings are managed for plans in the old system; the integrity portal is only used when the agency writes asking for extra evidence. Screens change often, so use the agency's step by step guides for screen detail.

Many staff still talk about PRODA, but it no longer opens the agency's provider portals. This lesson explains what replaced it. Key points: from 10 November 2025 the agency required providers to use myID and Relationship Authorisation Manager, known as RAM, and discontinued PRODA access for its portals; myID is a personal Digital ID app; RAM records who may act for our business; the principal authority links our business first and then authorises staff; portal users need at least a Standard identity strength; and the NDIS Commission's portals need their own authorisation in RAM.

When someone joins our admin, finance or intake team, getting their portal access right from day one prevents both delays and shortcuts. This lesson walks through the process. Key points: confirm the role needs access and that a manager has approved it; the person sets up their own myID; their legal name must match their myID; the authorisation goes to a work email that only they can read; the request must be accepted within 7 days; new users may wait before their first login; and contact details in myplace should be updated to business details.

Portal access gives people a view of participants' personal information and the power to make claims in our name, so we give it carefully. This lesson explains the roles in RAM and how we decide who gets access. Key points: the principal authority links the business and can authorise others; authorisation administrators can create and manage authorisations; authorised users can act for the business but cannot manage authorisations; the machine credential role is not used for the NDIS portals; and every employee with my NDIS portal access can see the plan information shared with our organisation.

An authorisation left in place after someone leaves is one of the easiest security gaps to create and to prevent. This lesson sets out our leaver process and regular access review. Key points: RAM asks businesses to remove authorisations immediately when they are no longer valid; we remove a leaver's authorisation on or before their last day; role changes count too; a removed authorisation cannot be reinstated; record who removed access and when; and regularly export the RAM authorisation history, compare it with the staff list and keep the review as evidence.

The agency is running two computer systems side by side, and the rules differ between them. This lesson explains how to tell them apart and why it matters. Key points: old system plans are viewed in myplace and agency managed claims need a service booking; PACE plans are viewed in the my NDIS portal, have no service bookings and use my providers; PACE claims must go through bulk upload; before the first claim we check bank details, funding type, the booking or my provider record and our ABN; and as a my provider we see basic plan details, plus active goals with consent.

For participants whose plans are still in the old system, service bookings remain essential for agency managed supports. This lesson explains what they do and how we keep them tidy. Key points: a service booking sets aside funding in an agency managed budget for a registered provider; it must be in place before supports are delivered; most are created at the support category level; both we and the participant must approve it; the dates must sit within the current plan; changes cannot be made retrospectively; and bookings are ended by bringing the end date forward, not deleted.

For plans in PACE, being recorded as a my provider replaces the service booking. This lesson explains when it is needed and how it happens. Key points: my providers are needed for agency managed and plan managed funding in PACE plans, and for specialist disability accommodation, home and living and behaviour supports; we can be recorded through an automatic transfer of an active service booking, a relationship request in the my NDIS portal, or the participant telling the agency; claims from providers who are not recorded take longer; and some claims are rejected automatically.

Every payment request is a statement that we delivered an agreed support at an allowed price. This lesson covers the checks we make before claiming and the two ways to claim. Key points: confirm the support was agreed and delivered, the booking or my provider record is in place, the funding type and available budget are right, the dates fit the correct plan, the item and price follow the pricing rules, and it is not a duplicate; single requests are only for old system plans; PACE claims go by bulk upload; and the agency recommends claiming within 90 days.

Bulk upload is how most of our claims reach the agency, and the only way for PACE participants. This lesson explains how a bulk file works and how to fix errors safely. Key points: download the current template from the myplace portal; each row creates one payment request; use either quantity or hours for a claim, never both; include our own claim reference; never delete template columns; check the results after upload; a rejected payment request cannot be fixed, so a new one is needed; and resubmit only the failed lines in a newly named file.

Getting paid is only finished when we have matched what was paid against what we claimed. This lesson explains where to find payment information and how we reconcile it. Key points: a claim moves through validation to pending payment and then paid, or it is rejected with a reason; payment runs happen at least once a day on business days; the payment summary shows requests over up to a 30 day period; recipient created tax invoices are generated for each request or upload and batched by day; the bulk results show where payment was capped at the price limit; and every payment is matched to our invoice.

Most rejected claims come from a small number of causes, and most can be fixed by us. This lesson covers the common reasons and our response. Key points: claims are rejected for wrong dates or details, duplicates, prices above the limit, a missing booking or my provider record, the wrong management type, insufficient funds, missing banking or ABN details, or the participant saying the support was not received; read the reject reason, check our records, fix the cause and submit a new request; pending or paid claims made in error can be cancelled; and enquiries go through the my NDIS portal.

The agency can check any claim against our records, so every claim needs records behind it. This lesson explains what to keep. Key points: records must include at least the participant's name and NDIS number, the dates of support, the amount and quantity or hours delivered, and the support type; the agency names invoices, support logs, rosters, case notes and service agreements as records; each invoice is for one participant; during a manual payment review payments stop until evidence is assessed; and failing to provide complete records during a review may mean funds must be repaid.

The portals hold some of the most personal information we handle, so privacy rules apply to every search, download and conversation. This lesson explains our obligations. Key points: the NDIS Code of Conduct requires us to respect the privacy of people with disability; the Practice Standards include a privacy and dignity outcome; each portal has its own collection or privacy notice; our privacy policy sets how we collect, store, share and dispose of information; look up only participants we support; keep downloads in our secure systems; and never confirm plan details to someone without authority.

Each person's myID is the key to the portals, so protecting it protects participants and our organisation. This lesson covers login security. Key points: never share your myID or its password, which the myID terms of use forbid; every myID login is confirmed with a code in the app on your own device, a second step that only works if nobody else has it; use a strong password and your device's security features; turn on push notifications and check your devices list; avoid Remember me on shared devices; treat requests for codes with suspicion; and report any suspected compromise straight away.

This case study follows Joel and Farah in our finance team as they reconcile a month end bulk upload and chase a slow payment. Key points: a capped line means the price claimed was above the limit, so we fix the price in our system and never charge the participant the difference for agency or plan managed supports; a long pending claim is followed up with a claim and payment enquiry in the my NDIS portal, not a second claim; reconciling by claim reference finds problems early; and every finding is recorded with an owner and a due date.

This final case study follows our operations manager through an access review and a privacy slip, and ends with the course wrap up. Key points: an access review compares RAM authorisations with the staff list; authorisations for people who have left are removed immediately and recent activity is checked; the leaver process is fixed so it does not happen again; a participant report sent to a personal email is reported straight away through our incident process rather than quietly deleted; and the lesson ends with a summary of the course and the final assessment.