← All outputs
Achieve Australia — Systems Scoping · Interconnected Process View

Revenue Process & Client Journey — Adjacent Halves of the Same Reality

The client journey and the revenue pipeline were designed entirely separately. They cover adjacent halves of the same service delivery — the client journey creates the SOS; the revenue process depends on it. This page maps both together: every IT system named at each step, every gap in information flow, and the SOS as the fragile join point between them. Source of record: feedback-loops/achieve-funding-billing-claims-loop.md and Revenue Project Process Maps Released.pdf.

Revenue pending at join point (Nov 2024)
$1.2M
case files stuck in "Pending" — billing not started
Accounts receivable — invoices up to 6 months late
$4M
downstream consequence of the same join-point failure
Claim errors requiring manual investigation
1,100
~4 hours/week; many traceable to upstream SOS or setup errors
SOS format — as at June 2026
PDF
non-searchable, non-machine-readable; manually re-keyed into every downstream system
The core design problem
These two process maps were built by different teams at different times for different purposes. The client journey describes how Achieve brings a participant into service. The revenue process describes how Achieve gets paid. Neither was designed with the other in mind. The SOS is the single point where they must connect — and it is a static PDF, manually re-entered into every system that needs it, with no embedded alert when it needs updating. Every gap downstream of the SOS is either a direct consequence of this design failure or is amplified by it.

Pre-SOS — The Client Journey

Everything before the SOS is client-journey territory only. The revenue process cannot begin until the SOS is signed. This is the phase where the information that billing depends on is gathered — and where many of the downstream revenue errors originate.

Stage 0
Vacancy created / Site marketed
Service Development Team HubSpot
Vacancy is created in HubSpot and marketed. This is the pipeline's starting point — no revenue activity is possible until a participant is matched to the vacancy.
Stage 1
Enquiry received — "new deal" created
Service Development Team NDIS Admin HubSpot PACE / NDIS portal
Enquiry logged in HubSpot as a "new deal." Funding type confirmed here: Agency managed, Self managed, or Plan managed. This determination controls the entire claiming pathway downstream — yet it is captured informally at this early stage and may change multiple times during the participant's tenure.
CRITICALClinical and Behaviour Support data is NOT captured in HubSpot. It is saved to a separate OpsHub folder and communicated by email and an internal MS Form. This means the clinical picture that informs the SOS lives outside the primary CRM from the start.
PROCESSHow the fund will be managed (Agency / Self / Plan) must be confirmed here — but this often changes throughout the client's time with Achieve. Each change requires a new claiming pathway update on the revenue side and is not automatically triggered.
Stage 1 (continued)
Clinical / Behaviour Support review
Clinical Team Service Manager Email MS Form OpsHub (SharePoint)
Clinical and Behaviour Support team reviews suitability. Their data lives in OpsHub folder, email, and an MS Form — three separate locations, none of which is HubSpot or VisiCase.
TECHNOLOGYClinical team is NOT consistently notified via HubSpot. The notification travels by email or internal MS Form and the review data is stored outside the primary CRM — creating a siloed clinical record that must be manually reconciled when the SOS is drafted.
Stage 1 → 2
Home viewing / match assessment
Service Development Team Service Manager HubSpot Email
Participant and family view the site. Suitability is confirmed. This is the point where the Service Manager becomes the central coordination hub — a role they carry for the entire subsequent journey.
PEOPLEThe Customer Journey Map marks this step with # — institutional knowledge. The handoff from the Service Development Team to the Service Manager is not documented as a formal process step anywhere in the source documents.
⚠ CRITICAL HANDOVER — HubSpot "new deal" → VisiCase "service user"
This transition is fully manual, non-automated, and dependent on institutional knowledge. The Customer Journey Map marks it with a # symbol. ME Services confirms: "a manual, non-automated workflow, leading to potential data loss or delays." Every piece of data gathered in HubSpot must be re-entered into VisiCase by hand. There is no integration, no validation, no error catch.
Stage 2
Transition planning — VisiCase takes over
Service Manager (central hub from here) VisiCase Email
VisiCase case file created. From this point the SM owns transition planning, risk assessment, move-in date, and all subsequent check-ins. The SM coordination load identified by ME Services as "disproportionate" begins here.
TECHNOLOGYVisiCase case file is created here but set to PENDING — billing cannot start until it is moved to APPROVED after the signed SOS is received. The gap between PENDING and APPROVED is where $1.2M sat outstanding as of November 2024.
Stage 2
SOS drafted — two spreadsheets, not VisiCase
NDIS Administrator Service Manager Excel — SOS Spreadsheet Excel — Roster of Care Tool (SIL) VisiCase (reference only)
The SOS is drafted in a separate SOS Spreadsheet quote (based on the prior year) plus a Roster of Care Tool for SIL. VisiCase has a quoting functionality that could reduce manual effort — it is not used. The draft is reviewed by the Service Manager; different SMs sign off on quotes depending on service type, with no clear rationale for why this step remains in the process.
TECHNOLOGYQuotes use two different complex spreadsheets. Calculation for Quick Logs is a manual process on the Roster of Care spreadsheet — causes human error and inaccuracies. VisiCase quoting functionality exists but is not being used.
PROCESSQuotes signed off by different Service Managers depending on service type. No documented rationale for which SM signs off. The SOS is "very complicated and hard to read and interpret for the client."
PROCESSPlan notifications from NDIS may arrive with as little as one day's notice before a new plan starts — meaning the SOS must sometimes be drafted and agreed under urgent time pressure with incomplete information.
Stage 2
COO approval → client sign-off (DocuSign or otherwise)
COO / Ops Management NDIS Administrator DocuSign OpsHub (SharePoint) VisiCase Email / phone / in-person
COO approval obtained to proceed. SOS sent to Plan Nominee for signature via DocuSign where possible. Multiple follow-up attempts are common — different email addresses, phone, in-person. Once signed, the SOS is attached to each open case file one by one and also uploaded to OpsHub.
PROCESSDocuSign is not always used. When it is not, the person receiving the SOS must notify the NDIS Administrator separately — sometimes they upload to SharePoint without advising. No systematic confirmation that the SOS has been received and is in the right system.
TECHNOLOGYSOS must be attached to each individual open case file one by one — not bulk-attached. Also attached separately to OpsHub. Duplication of effort with no automation.
PROCESS"Numerous amounts of client follow-ups are carried out to obtain signed SOS" — different email addresses, in-person attempts, phone. No documented escalation path if follow-up fails within a timeframe.
↓
SOS
Statement of Service — The Join Point
The SOS is the formal agreement of what support Achieve will deliver, at what rate, under which funding categories. It is the single point that both the client journey and the revenue pipeline depend on. Everything before it is client-side. Everything after it runs on both sides simultaneously. When it is wrong, outdated, or missing, both sides break.
⚠ Format as at June 2026: static PDF — non-searchable, non-machine-readable. Manually re-keyed into VisiCase, PRODA, and the Roster of Care Tool. The CFO names this explicitly as a barrier to revenue reconciliation (Sustainability Report, 25 June 2026). The same gap was identified in November 2024. It has not been resolved post-Connect.
What the SOS contains
  • Support types being delivered
  • Hours and schedule per support type
  • NDIS funding categories and line items
  • Agreed rates (NDIS price guide)
  • Service delivery model (SIL / Group / Individual / Drop-in)
  • Funding management type (Agency / Self / Plan managed)
  • Plan dates and budget period
SOS update triggers — each one restarts the manual cascade
  • NDIS plan review (annual or mid-plan change)
  • Support level change (new SIL assessment, different hours)
  • Funding category added or removed
  • Participant requests different supports
  • Temporary pause — hospital, holiday, family break (VisiCase pause functionality exists but underused)
  • Pricing/rate change — annual NDIS price guide update, CPI increase (up to 5 months of manual work)
  • Funding management type change — Agency ↔ Self ↔ Plan managed (requires new claiming pathway)
  • Property or accommodation change (SIL-specific)
  • New Support Coordinator or Plan Manager
  • Participant circumstances change — health, behaviour, goals
Every SOS update cascades manually to both sides — nothing is automated
Client journey side must update:
  • New SOS document (drafted in Excel, signed by client)
  • Updated case file in VisiCase (one by one per open file)
  • Updated record in OpsHub
  • SM notified of service change
  • Support plan reviewed if goals change
Revenue side must update:
  • VisiCase case file budget re-entered manually
  • PRODA service booking updated (cancel and redo if incorrect)
  • Roster of Care Tool recalculated
  • Quick Logs / Action Rosters recreated for new schedule
  • Finance notified of funding management type change
  • Old case files closed after all shifts approved and claimed
No system triggers these updates automatically. They depend on the NDIS Administrator being notified, and on whoever receives the notification acting on it correctly and completely. Spreadsheets serve as manual reminders; plans are driven by a person to remember, not a system.
↓

Post-SOS — Two Parallel Realities

From the moment the SOS is signed, both pipelines run simultaneously. They share the SOS as their foundation document. When anything changes on the client side that affects what is delivered, the revenue side must be updated manually — there is no automated link between them.

⟵ Client Journey continues
Move-in / Commencement
Service commences
Service Manager Support Workers VisiCase
Participant moves in or begins attending. Shift notes recorded in VisiCase against the client's case file. The SM continues to own all coordination — fortnightly check-ins begin.
TECHNOLOGYCase notes are often written against the incorrect case file — a documented pain point in the Revenue Maps. This creates downstream errors in reporting, goal tracking, and claiming.
Ongoing
Goal tracking / shift notes
Support Workers Service Manager VisiCase Excel (CSV export) Email
Goals established in VisiCase. Progress recorded in shift notes. When a progress report is needed, notes are exported to CSV, filtered in Excel, and emailed — with no documented destination for that report.
PROCESSGoal-tracking data (the emailed Excel export) has no documented destination. It does not visibly reach the CI Register, inform service design, or feed any reporting above SM level. The loop does not close.
Every 90 days
Case / plan review
Service Manager NDIS Administrator VisiCase
90-day review cycle. If goals, support types, or hours change, the SOS must be updated.
⟳ SOS UPDATE TRIGGER — if service changes, a new SOS is required. Revenue side must be notified and all systems updated manually.
Annual / mid-plan
NDIS plan review
Support Coordinator NDIS Administrator PACE Excel — SOS Spreadsheet VisiCase
Participant's NDIS plan is reviewed by the NDIA. New funding may change categories, amounts, or plan management type. A new SOS must be prepared.
CRITICALNDIS plan change notifications may arrive with as little as one day's notice before the new plan starts. A new SOS must be drafted, agreed, signed, and all downstream systems updated within that window — or the old SOS continues to be billed against an expired plan.
⟳ SOS UPDATE REQUIRED — new plan = new SOS = full revenue-side manual cascade. This is the highest-frequency source of SOS updates and the one with the tightest time pressure.
Ad hoc
Service or circumstance change
Service Manager NDIS Administrator VisiCase Email
Participant's health changes, behaviour support needs change, support type requested changes, or participant is hospitalised / takes a break. Each scenario may require an SOS update or at minimum a case file update.
TECHNOLOGYVisiCase has a "pause" status for hospital visits or service pauses — documented as underused. The more common approach is changes to case file dates, which causes downstream claiming errors (Quick Logs from different date ranges duplicating or mismatching).
⟳ SOS UPDATE TRIGGER — if support type, hours, or management type changes, a new SOS is required. Spreadsheets serve as manual reminders — driven by a person, not the system.
Exit
Participant departs
COO (sign-off required) NDIS Administrator Finance VisiCase HubSpot PRODA
CRITICAL"Participant leaves SIL Accommodation (undocumented)" — the Customer Journey Map's own label. COO sign-off is required for the decision to exit per the Client Exit Procedure, but no process document connects the CJM exit point to the Departure Management process. The vacancy update in HubSpot is the only documented loop-close.
PROCESSRevenue side must close old case files only "once all shifts have been approved and claiming has been completed" — an undefined timeframe that can extend for months. No documented trigger from the client journey side to the revenue side to initiate this.
Revenue Pipeline ⟶
Immediately post-SOS
SOS received — manual re-entry into VisiCase
NDIS Administrator VisiCase OpsHub (SharePoint)
Signed SOS received. Budget information manually entered into VisiCase. Case file status moved from PENDING → APPROVED. SOS attached to each open case file individually and separately to OpsHub.
TECHNOLOGYSOS is a static PDF — every field must be manually keyed into VisiCase. No validation that the VisiCase entry matches the signed SOS until the Revenue Accountant runs a budget report. The 6-week window to complete this is tracked only by a manual "pending status report" spreadsheet — this process was not documented at time of the Revenue Maps.
PROCESSAttaching the SOS to each case file individually was a new process as of August 2024 — "only implemented for the last 4 months, which means it can sometimes be forgotten." As of November 2024, $1.2M in revenue was sitting in PENDING status.
Post-SOS approval
PRODA service booking created
NDIS Administrator PRODA / PACE VisiCase Excel (Roster of Care Tool)
Service booking created in PRODA to match the SOS. Using a spreadsheet, NDIS Admin goes through and transfers claim amounts to the booking in VisiCase. Separate line items created per service type.
TECHNOLOGYVisiCase does not have a line item called "Funding for Irregular SIL supports." If the Irregular Support process is not completed correctly, funding comes out of existing service bookings — potentially causing other services to run out of money and generating claim rejections.
TECHNOLOGYIf a service booking is set up incorrectly, it must be cancelled and redone in PRODA — no correction path. VisiCase has no warning when an early exit happens and a quick log is being closed or dates changed.
CRITICAL — SINGLE PERSONIrregular Support processing (~20/week) depends on one named individual. When she is away, no one completes this. No documented backup or coverage process.
Setup
Rosters created / Quick Logs set up
Frontline Rostering Officer Service Manager VisiCase (Quick Logs / Action Roster) RosterOn Excel — Roster of Care Tool
Action Roster and Quick Logs created to reflect the case file. Calculation is manual using the Roster of Care spreadsheet. Frontline Rostering Officers complete budget and adjust rosters based on funding.
TECHNOLOGYCalculation for Quick Logs is manual via Roster of Care spreadsheet — causes human error and inaccuracies. Northern Rivers uses group activity function in VisiCase; Sydney uses Quick Logs — same service type, two different methods, no consistency.
PROCESSNo set process for other service types (Day Programs, Supported Employment) at this stage — managed individually by Service Managers with no documented standard.
Ongoing
Shift delivery → timesheet approval
Support Workers Service Manager Frontline Rostering Officer VisiCase
Shifts delivered. Timesheets approved. VisiCase status moves: Planned → Delivered → Approved. Finance bulk-approves Quick Logs to "Approved Not Claimed." System auto-unapproves timesheets when funding is unavailable.
TECHNOLOGY — $5k/monthVisiCase auto-unapproves timesheets when funding is not available — and it is "not often that we are able to find funding." This causes $5,000/month in leakage from services delivered but not claimed.
TECHNOLOGYCase notes are frequently recorded against the incorrect case file. VisiCase does not warn the user when a quick log is being closed against a case file with mismatched dates.
Weekly (Tuesdays)
VisiCase → Excel → NDIS Portal upload
Finance VisiCase (FinIntfcLog export) Excel (2 pivot tables) NDIS Portal / PACE
Finance downloads the VisiCase Financial Interface Excel file (FinIntfcLog). Data is filtered, sorted, adjusted for BC template formatting, and manipulated via two pivot tables before upload to the NDIS Portal. Portal processing takes up to 30 minutes. Results downloaded and uploaded back into VisiCase.
TECHNOLOGYVisiCase headers are not aligned with Business Central — requiring "extensive" manual manipulation in Excel before each upload. Two pivot tables required every week to format correctly.
TECHNOLOGYService code description from VisiCase does not include "non face to face" wording. Finance manually adds this for plan managers every cycle.
TECHNOLOGYMYOB interface is still being run despite Achieve no longer using MYOB. An additional legacy step in every weekly billing cycle.
Weekly
BC upload → invoices generated → emailed
Finance Business Central (BC) Excel OpsHub (batch record) Email (200–300 invoices/week)
Edited file uploaded to BC. Validations run. Sales invoices generated. 200–300 invoices individually emailed per week using a BC template. Batch record copied to OpsHub.
CRITICAL — AR $4MInvoices are sometimes issued 6 months after the service has been delivered. Clients are "not always paying" invoices this late. Current Accounts Receivable: $4M. Finance is "cutting invoices in weekly batches to stay under delegation limits."
PROCESSNew clients are not always notified to Finance — meaning Finance may not know to generate invoices for a new participant until the gap is discovered.
Where the loop should close — but doesn't
Reconciliation — Ledger (BC) vs Sub-ledger (VisiCase)
Role: TBC — unassigned in source process map Business Central VisiCase
CONFIRMED NOT HAPPENING"Reconciliation is not currently being done between: Ledger–BC / Sub-ledger–VisiCase." The swimlane owner for this step is "Role TBC" in the Revenue Process Maps. The process map itself is annotated "OLD MAP – Awaiting Confirmation." Five downstream process endpoints (Accounts Receivable, Finance Reporting, Clearing Process, Payroll Processing, Accounts Payable) are all marked "not mapped."
Ongoing error management
Rejected claims — investigate and remedy
NDIS Administrator Finance Service Manager VisiCase NDIS Portal BC
Rejected claims investigated. Common causes: service booking missing or not updated in NDIS, wrong debtor number, insufficient funds, Achieve not nominated as provider on PACE, terminated plan.
TECHNOLOGYOnce a claim is approved in VisiCase, it cannot be reversed. A whole new claim must be created. Credit note also required in BC. Each error generates duplication of effort across three systems.
VOLUME1,100 claims with open issues at time of revenue review — requiring approximately 4 hours per week to investigate and resolve. Many are traceable to upstream SOS or PRODA setup errors.
PROCESSIf a participant does not turn up to a group session, they cannot be removed from the group action and the claim still proceeds. Group claiming does not reflect actual attendance.

Quantified information flow failures

These figures come from the Revenue Process Maps (November–December 2024 workshop). They represent the financial cost of the information gaps above. Updated figures post-Connect have not been provided — the structural causes of each remain in place as of June 2026.

$1.2M
Pending-status revenue — case files approved but billing not started at join point
$4M
Accounts receivable — invoices sometimes issued 6 months post-service
$5k/mo
Timesheet leakage — VisiCase auto-unapproving timesheets when funding unavailable
1,100
Open claim errors — ~4 hours/week; many traceable to SOS or PRODA setup failures

Systems reference — where each system sits and what's known

Where used: Client Journey Revenue Pipeline Both
System Where What it does in this flow Known issues / rating
HubSpot Client Journey Front-door CRM. Enquiry logged, "new deal" created, vacancy managed. Should be the source of truth for lead-to-participant data. Red (ME Services) — Underutilised. Clinical data not captured. HubSpot → VisiCase handover is fully manual with no integration. Used for SIL only — Day Programs and Respite usage unconfirmed.
VisiCase Both Primary case management system. Case file, shift notes, Quick Logs, budget entry, Financial Interface export. Central to both sides post-SOS. Amber (ME Services). Headers misaligned with BC. No line item for Irregular SIL supports. Cannot reverse an approved claim. Auto-unapproves timesheets when funding unavailable. Connect is the planned successor — migration status for Day Programs and Respite unknown.
Connect Both VisiCase successor. Went live 2 June 2026 (SIL / accommodation). Intended to eventually deliver embedded workflow, document currency alerts, and billing automation — not yet delivered. Payroll bug 15 June 2026 — manual workaround required. SOS as non-searchable PDF gap persists post-Connect (confirmed Sustainability Report, 25 June 2026). Migration scope for Day Programs and Respite not documented.
Excel Spreadsheets Both SOS Spreadsheet (quoting), Roster of Care Tool (SIL rostering), Pending Status Report (tracking), FinIntfcLog manipulation, two pivot tables for BC formatting, claim tracking, goal reporting. Excel is the connective tissue of the entire pipeline. Not rated — but the most-used system in the process. Manual, error-prone, undocumented in places, and not integrated with any other system. Every Excel step is a potential data loss or error introduction point.
PRODA / NDIS Portal (PACE) Revenue Pipeline NDIS service bookings and claim submission. Upload of claiming file (FinIntfcLog), download of results, reconciliation of batch numbers. Service bookings must be cancelled and redone if set up incorrectly. Some participants not nominated on PACE — causing rejected claims. Processing time up to 30 minutes per upload cycle.
Business Central (BC) Revenue Pipeline General ledger. Invoice generation from VisiCase data. Sales invoices posted and emailed (~200–300/week). Headers not aligned with VisiCase — extensive manual Excel manipulation required before every BC upload. Ledger–BC / Sub-ledger–VisiCase reconciliation is confirmed not happening. MYOB interface still being run despite MYOB no longer in use.
DocuSign Client Journey Electronic signature for SOS. When used, provides a documented confirmation of receipt. Not always used. Alternative is email, phone, or in-person. When DocuSign is not used, notification that the SOS has been received and filed depends on the recipient remembering to advise the NDIS Administrator.
OpsHub (SharePoint) Both Repository for signed SOS documents, clinical data (separate folder), batch record copies. Secondary filing location alongside VisiCase. Amber (ME Services). Clinical/BS data is stored here in a separate folder — outside HubSpot and VisiCase — creating a third parallel record for clinical information. Batch records are copied here manually each week.
RosterOn Revenue Pipeline Staff rostering and time/attendance. Used alongside VisiCase for shift scheduling. Referenced in Frontline Rostering Officer Guide as the operative rostering tool. Manual multi-step setup process for new starters documented in Frontline Rostering Officer Guide. Explicitly excluded from the HRIS reform project scope — sits in the gap between HRIS and the case management system.
MS Form / MS Lists Client Journey Internal form used to notify the Clinical/Behaviour Support team of new referrals. One of three parallel channels for clinical data (alongside email and OpsHub folder). Not integrated with HubSpot, VisiCase, or Connect. Creates a third parallel data stream for clinical information that must be manually consolidated into the SOS at draft stage.
The unresolved loop — what "reconciliation not happening" actually means

The Reconcile Payments step (03.03.04) is where the revenue pipeline should close: matching what was invoiced against what was actually paid, surfacing variances, and feeding corrections back into VisiCase and BC. In the source Revenue Process Map, the entire swimlane is labelled "Role TBC" and the map is annotated "OLD MAP — Awaiting Confirmation." Five downstream steps are explicitly marked "not mapped."

What this means in practice: nobody knows with system-level certainty whether Achieve has been paid for every service it delivered. The VisiCase sub-ledger and the BC general ledger are not being compared. Overclaiming and underclaiming both exist in the data and are not being systematically identified.

This gap has been in place since at least November 2024 and was not resolved by the Connect go-live of June 2026. The structural cause — an unowned reconciliation step between two misaligned systems — is a process and accountability gap, not a technology one.

Sources: Revenue Project Process Maps Released.pdf (Revenue Process Review, Nov–Dec 2024) achieve-funding-billing-claims-loop.md Customer Journey Map Final.pdf Funding Procedure.pdf 03.03.01–03.03.05 Billing/Claims (To-Be).pdf series ME Services Assessment for Achieve Australia Final Draft.pdf 5.4 Sustainability Reporting 1.pdf (SOS PDF gap, June 2026) 6.1 CEO Report.pdf (Connect payroll bug, June 2026) achieve-client-lifecycle-loop.md

All quantified figures (revenue leakage, AR, claim error count) are from the November–December 2024 Revenue Process Maps workshop. Updated figures post-Connect have not been provided. The structural causes of each figure remain documented as active as of June 2026 board reporting. No participant identifying detail appears in this document.