pace-vs-legacy-plan-flexibility

PACE vs Legacy Plan Flexibility and Digital Locks

KB Type: Research Theme
Domain Area: Billing / Plan Architecture
Confidence: Researched (Andrew)
Depth Hint: Standard
Version: 1.0 — 2026-04-26
Status: Active


Grounding Summary

The transition from the NDIS Legacy system to the PACE system fundamentally changes how plan budget flexibility and "digital locks" are managed. In Legacy plans accessed via the myplace portal, funding flexibility within a support category was generally the default unless a support was explicitly marked as a "Stated Support" or specifically allocated. Conversely, PACE plans hosted on the my NDIS portal utilize an explicit "Allocated Items" table to strictly enforce these digital locks and visually outline restrictions. When a support is designated as "Stated" or "Allocated" in either system, funds are ring-fenced entirely to that specific 15-digit item code, preventing flexible use.


Detail

Evolution of Budget Management

In the NDIS, navigating the difference between flexible funding and strict "digital locks" is a primary operational challenge for providers attempting to submit compliant claims.

Legacy plans (managed through the myplace portal) handled budget flexibility with a degree of structural ambiguity. Planners often listed specific item codes simply to calculate the total budget awarded for a category (e.g., multiplying 50 hours by a Level 2 coordination rate). If a plan merely "mentioned" a specific support code but the funds remained at the broader Category Level, the funding was generally flexible. For example, if Support Category 07 showed "Allocated Items(0): None", a participant could flexibly use those funds across Level 1 Support Connection, Level 2 Support Coordination, or Psychosocial Recovery Coaching (PRC). This flexibility exists because these three supports share the identical 0106 registration group. A hard digital lock in the Legacy system only occurred if an item was explicitly marked as a "Stated Support" or placed in an "Allocated" table, meaning the NDIA portal would literally reject a claim for a different item code. Due to the lack of granular digital controls in older plans, providers sometimes relied on mathematical heuristics — such as checking if the total funding was an exact multiple of a specific hourly rate — to deduce if funds were ring-fenced.

The PACE system (accessed via the modern my NDIS provider portal) replaced mathematical guesswork with explicit digital controls. PACE plans feature a prominent "Allocated Items" table to define budget restrictions clearly. If a support code, such as plan management fees, is listed with the status "Stated", PACE applies a definitive digital lock. The modern system explicitly warns users that "Stated supports are intended solely for the purpose of that support" and cannot be swapped for other supports. However, if the broader category lists no stated allocated items, the flexibility to fluidly choose between different supports like Level 1, Level 2, and PRC remains completely intact.

The Mechanics of Digital Locks

When a digital lock is applied through a "Stated" or "Allocated" designation, the portal ring-fences those exact dollars strictly to that specific 15-digit item code. For example, if a planner allocates 100% of a Category 07 budget exclusively to Level 2 Coordination (07_002_0106_8_3), the system will physically block claims against other codes within that same category. This strict allocation will cause claims for separate line items — such as 07_799_0106_6_3 for non-labour provider travel costs — to be rejected with "Insufficient Funds" or "Support Not in Plan" errors, as the system sees a $0 budget available for flexible category use. In these highly locked scenarios, providers must utilize cross-category billing rules (such as billing travel from a Core budget using code 01_799_0106_1_1) to ensure they are paid for non-labour travel without requiring a formal plan reassessment.

The Unique Ring-Fence of Level 3 Coordination

Level 3 Specialist Support Coordination possesses a natural, inherent ring-fence due to its unique registration group, R132 (or 0132). Because this level requires distinct allied health qualifications, providers cannot bill Level 3 against flexible Category 07 funding unless their organisation holds this specific registration. Consequently, if an NDIS planner intends for a participant to receive Level 3 coordination, they will almost universally apply the "Stated" digital lock to guarantee those highly specialised funds are protected and cannot be inadvertently drained by standard Level 1, Level 2, or PRC supports.

Legacy vs PACE Comparison

Feature Legacy (myplace) PACE (my NDIS)
Digital lock visibility Mathematical heuristics required Explicit "Allocated Items" table
Stated support warning Implicit through claim rejection Explicit portal warning text
Flexibility default Flexible unless stated Flexible unless stated
Sub-budget tracking Manual estimation required Portal-managed (emerging)
Cross-category claiming Available but undocumented Available, documented in PAPL

Legislative Basis

Reference Provision Relevance to this article
NDIS Pricing Arrangements 2025-26 V1.1 Cross-category claiming rules Determines systemic parameters for payment rejections
NDIS Support Catalogue 15-digit item codes Foundation for Stated/Allocated ring-fencing
NDIS Act 2013 s33(2A) Categorisation of supports Legislative basis for flexible vs stated designations


Open Questions

  • Is there a mechanism within the PACE portal for participants to easily request an "Un-stating" of a support without triggering a full plan reassessment?
  • How frequently do historical Legacy plans lack an explicit "Allocated Items" table, leading to ongoing reliance on mathematical heuristics?

Entity Tags

  • entity: pace-vs-legacy-plan-flexibility
  • type: Research Theme
  • domain: Billing / Plan Architecture
  • confidence: Researched
  • links: [[concepts/digital-lock]] via enriches, [[concepts/legacy-crm]] via enriches, [[concepts/pace-framework]] via explains

Change History

Date Change Source
2026-04-26 Initial article created RS-06 Type A ingest