Supporting document · For Essential Care Victoria

Spreadsheet revamp blueprint

A design specification for restructuring the three service-stream Google Sheets that currently function as Essential Care's production database. Normalises a colour-coded grid into a relational schema while preserving every workflow the team already runs.

MR Labs · Operational Audit May 2026 Author: Muq Rohaizak
Overview

Executive summary

EC's three service-stream Google Sheets are the de-facto production database. The current structure (rows = staff, columns = months, cells = colour-coded job status) works for manual scanning but breaks under filter, pivot, export, and audit operations. This revamp normalises the schema into a relational structure while maintaining all existing data fidelity and workflow.

Key outcomes

  • Colour coding becomes explicit status columns (job status and payment status separated)
  • Three monolithic sheets become four domain-specific tabs + one dashboard
  • Manual reconciliation gets a structured ledger with unique transaction IDs
  • Grant-unit visibility through a linked performance dashboard with monthly KPIs
Part 1

Current state analysis

Existing structure

Home Maintenance sheet

  • Rows: grouped by contractor name (gardening firms, gutter contractors, handyman), sub-grouped by worker/team
  • Columns: month, sub-columns for each week or job date
  • Cell content: client name, job type, hours worked, job status (colour: green = complete, yellow = incomplete, red = issue), payment status (colour: green = paid, yellow = pending, grey = unpaid)
  • Evidence tracking: hours often reported on the contractor's own sheet; before/after photos stored separately in email/Drive

DA & Transport sheets

  • Similar structure but simpler (fewer contractors)
  • Same colour coding (job status + payment method indicator)
  • DA: primary cleaning contractor; 2-hour jobs are atomic units
  • Transport: trip-level granularity; often 7–10% free trips (no charge)

Data quality issues observed

  • 82% of gutter jobs missing a client charge
  • Before/after photos often delayed (days or weeks after the job)
  • Manual QC happens after the fact; no invoice reference linked to the payment record
  • Colour-only status encoding breaks in exports, filters, and charts
  • Manual transcription from evidence to sheet (photos, hours, receipts) has a 2–5 day delay
  • No unique transaction IDs — reconciliation against bank/Xero requires manual name/date/amount matching
  • No separation of concerns: client master mixed with job ledger mixed with reconciliation notes
  • No data validation: free text for contractor, region, and job type leads to inconsistency
  • Grant-unit tracking requires manual counting (no built-in formulas)
Part 2

Target state schema

Four primary tabs — Client Master, Job Ledger, Reconciliation Ledger, Performance Dashboard — plus one Contractor Register tab for reference data. Each tab has a single, clearly-defined purpose. Validation rules and formulas live inside the sheet so the team's day-to-day workflow is the source of truth.

Tab 1

Client Master

Single source of truth for client demographic + grant eligibility + contact + regional allocation.

Refresh: Monthly — updated by Intake when new clients onboard.

Tab 2

Job Ledger

Atomic transaction log. One row = one completed job. The sole source of truth for what was delivered, who delivered it, when, and what the client owes.

Refresh: Real-time — updated by service teams as jobs complete.

Tab 3

Reconciliation Ledger

Transaction-level matching of client payments to invoices to bank deposits. Bridges Job Ledger ↔ Bank Feed ↔ Xero.

Refresh: Weekly bank reconciliation.

Tab 4

Performance Dashboard

Executive summary — grant commitment vs actual delivery, regional breakdowns, monthly trends, compliance status.

Refresh: Auto-calculated from Job Ledger (daily).

Tab 1 — Client Master schema

ColumnTypeNotes
ClientIDText (auto-increment)Format: CL-001, CL-002. Unique identifier.
ClientNameTextFull name.
AgeNumberReporting only; not used in calculations.
RegionDropdown[North Melbourne, Ascot Vale, Moonee Ponds, Essendon, Brunswick, …].
DAEligibleCheckboxTrue if client has DA allocation.
DAHoursAllocNumberAnnual DA hours from MyAgedCare allocation.
HMEligibleCheckboxTrue if client has HM allocation.
HMHoursAllocNumberAnnual HM hours from grant.
TransportEligibleCheckboxTrue if client has Transport allocation.
TransportTripsAllocNumberQuarterly trips from grant.
PreferredPaymentMethodDropdown[Card via SMS, Bank Transfer, Cash, BPAY, Cheque].
PhoneNumberTextFor booking confirmations.
EmailAddressTextIf available.
PreferredCntcWindowTexte.g. “mornings 9–12” or “anytime”.
EvidencePreferenceDropdown[Photos emailed, WhatsApp, GPS tracked, Paper signed].
OnboardDateDateWhen client first entered the system.
NotesTextDietary restrictions, access issues, preferred worker gender, etc.

Validation: Region and PreferredPaymentMethod use linked dropdowns; eligibility checkboxes gate which ledger rows are possible for the client; OnboardDate format enforced.

Tab 2 — Job Ledger schema

This is the operational heart of the system. Every completed job — whether DA, HM, or Transport — lands as one row.

ColumnTypeNotes
JobIDTextFormat: JOB-2026-04-00001. Unique, never reused.
DateCompletedDateWhen job was finished, not when entered into sheet.
ClientIDDropdownLink to Client Master. Governs downstream eligibility.
ServiceTypeDropdown[DA, HM-Garden, HM-Gutter, HM-Handyman, Transport].
ContractorIDDropdownLink to Contractor Register. Links to payment authority.
WorkerNameTextFirst name of actual worker (for client receipt).
LocationRegionDropdownFilled from ClientID; overridable if work done elsewhere.
StartTime / EndTimeTimeFor DA/HM jobs; optional for Transport. Duration calculated.
HoursWorkedNumberManual entry or auto-calculated from StartTime/EndTime.
TripsCompletedNumberFor Transport only.
BeforePhotos / AfterPhotosURLLink to Drive folder or image URL (auto-populated if GPS-tracked).
JobNotesTextFree text: “Client not home”, “Gutter blocked with leaves”, etc.
JobStatusDropdown[Complete, Incomplete, Issue]. Replaces colour coding.
IssueTypeConditional dropdownShows only if JobStatus = Issue. [Client absent, Safety concern, Contractor no-show, Incomplete scope, Other].
ClientChargeRateNumberHourly rate or flat fee from service agreement.
ClientChargeTotalNumber= HoursWorked × ClientChargeRate (or flat fee).
GrantUnitsUsedNumberCalculated: DA = 1 per job; HM = HoursWorked; Transport = TripsCompleted.
PaymentStatusDropdown[Unpaid, Partial, Paid]. Replaces colour coding.
PaymentMethodDropdown[Card via SMS, Bank Transfer, Cash, BPAY, Cheque, Not Requested].
AmountPaidNumberActual cash received (may differ from charge if partial).
PaymentDateDateWhen cash was banked (not promised date).
ReceiptRefTextInvoice number or Square receipt ID. For reconciliation against the bank feed.
XeroInvoiceIDTextLink to Xero invoice (auto-filled if Square-synced; manual if Xero-only).
ContractorCostNumberWhat EC paid the contractor for this job.
ContractorPaymentStatusDropdown[Unpaid, Paid].
ContractorPaymentDateDateWhen EC paid the contractor.
DEXSubmittedYNCheckboxTrue if this job was included in a DEX monthly report.
DEXSubmissionDateDateWhich DEX submission (month/year).
QCApprovedByDropdown[Alexis, Nawal, Alisya, blank if not yet QC'd].
QCApprovedDateDateWhen QC sign-off occurred.
CreatedDate / LastModifiedDateSystem timestamps (auto-filled).
ModifiedByDropdownWho last edited (audit trail).

Key formulas

  • HoursWorked: if StartTime and EndTime provided, = (EndTime − StartTime) × 24; else manual.
  • ClientChargeTotal: = IF(ServiceType = "Transport", TripsCompleted × ClientChargeRate, HoursWorked × ClientChargeRate).
  • GrantUnitsUsed: = IF(ServiceType = "DA", 1, IF(ServiceType = "Transport", TripsCompleted, HoursWorked)).
  • ContractorPaidStatus: auto-populated when ContractorPaymentDate is filled.

Tab 3 — Reconciliation Ledger schema

ColumnTypeNotes
TransactionIDTextFormat: TXN-2026-04-00001. Unique.
DateReconcilingDateWhen this reconciliation entry was created/updated.
JobIDDropdownLink to Job Ledger. May be blank for non-job payments (e.g. family-member advance).
ClientIDDropdownWhich client the payment relates to.
InvoiceIDTextXero or Square invoice number.
InvoiceAmountNumberWhat client was invoiced.
BankDepositDateDateWhen money arrived in EC bank account.
BankDepositAmountNumberAmount cleared. May differ from InvoiceAmount (partial payment).
BankTransactionRefTextBank statement reference or BSB/Account hint.
MatchStatusDropdown[Matched, Partial Match, Unmatched, Disputed].
MatchMethodDropdown[Invoice ref in bank memo, Fuzzy match (name+amount+date), Manual review].
MatchConfidenceDropdown[High, Medium, Low].
MatchingNotesTexte.g. “Family member Jane Smith transferred $50 from her account on behalf of John Smith (client). Matched via phone-call confirmation.”
OutstandingAmountNumber= InvoiceAmount − BankDepositAmount.
WriteOffYNCheckboxTrue if debt is deemed uncollectable and removed from AR.
WriteOffReasonConditional dropdownShows if WriteOffYN = True. [Client deceased, Uncontactable, Agreed discount, Other].
WriteOffApprovedByConditional dropdownCEO or CFO sign-off required.
XeroPostedDateDateWhen this transaction was posted to Xero.
ReconciliationApprovedByDropdown[Nawal, Elle, Mohamed].
ReconciliationApprovedDateDateSign-off.

Fuzzy matcher logic (embedded as hidden helper columns)

Input: Job Ledger (JobID, ClientChargeTotal), Bank CSV feed (Amount, Date, Memo).
Algorithm: IF (ABS(Amount − ClientChargeTotal) < 5) AND (DaysApart(BankDate, JobCompletedDate) ≤ 14) AND (TextSimilarity(Memo, ClientName) > 0.6) → “Fuzzy Match (High)”, else continue.
Output: MatchStatus column populated; rows with unmatched bank amounts highlighted in yellow.

Tab 4 — Performance Dashboard

One page. Six summary cards plus three charts. All values driven by SUMIF/COUNTIF formulas against the Job Ledger.

Card 1 — DA Performance

  • Grant commitment (from CHSP agreement)
  • YTD hours delivered
  • YTD jobs completed
  • Completion rate %
  • Red flag if completion < 85%

Card 2 — HM Performance

  • Grant commitment (hours)
  • YTD hours delivered (sum across HM-Garden, HM-Gutter, HM-Handyman)
  • YTD jobs completed
  • Completion rate %
  • Red flag if < 85%

Card 3 — Transport Performance

  • Grant commitment (trips)
  • YTD trips delivered
  • YTD jobs completed
  • Completion rate %
  • Red flag if < 85%

Card 4 — Invoice Reconciliation

  • Outstanding AR (sum of unpaid)
  • Average days outstanding
  • Reconciliation backlog (count unmatched)
  • % reconciled

Card 5 — Contractor Compliance

  • Active contractors
  • With current police check
  • With current WWVP
  • Compliance % (red if < 100%)

Card 6 — Monthly Finance Snapshot

  • Client invoices issued (this month)
  • Client payments received (this month)
  • Collection rate %
  • Contractor costs (this month)
  • Net margin (this month)

Charts

  • Chart 1 — Monthly grant units trend (stacked bar): X-axis month, Y-axis grant units delivered, stacks by service (DA, HM-Garden, HM-Gutter, HM-Handyman, Transport), overlay line showing the monthly target (commitment ÷ 12).
  • Chart 2 — Regional breakdown (pie): hours/trips per region. Identifies regional under/over-serving.
  • Chart 3 — Payment status waterfall (area): Invoiced (cumulative) → Paid → Outstanding → Write-off. Shows month-by-month aging of client receivables.
Reform-readiness caveat. Where this schema references per-claim mechanics, billable units, classification levels, or price caps that would feed the Support at Home (SAH) program, the equivalents are based on HCP-program rules published October 2025. Equivalent CHSP-to-SAH transition mechanics have not yet been published by the Department; we are using HCP as the best available proxy. The transition is currently flagged for no earlier than 1 July 2027.
Part 3

Contractor register (linked reference data)

One row per contractor firm or individual. Linked from Job Ledger via ContractorID. This tab gives EC its first auditable compliance register.

ColumnTypeNotes
ContractorIDTextFormat: CONT-001, CONT-002.
ContractorNameTextBusiness or individual name.
ServiceTypeDropdown[DA, HM-Garden, HM-Gutter, HM-Handyman, Transport].
BusinessStatusDropdown[Active, Paused, Inactive].
PoliceCheckRequiredCheckboxTrue per CHSP working-with-vulnerable-persons requirement.
PoliceCheckSightedDateWhen police check was physically sighted and recorded.
PoliceCheckExpiryDateExpiry date of police check.
PoliceCheckStatusFormula= IF(TODAY() < PoliceCheckExpiry, "Current", "EXPIRED"). Red flag if expired.
WWVPRequiredCheckboxTrue per CHSP.
WWVPSighted / Expiry / StatusDate / Date / FormulaSame pattern as Police Check.
InsuranceRequired / Sighted / Expiry / StatusCheckbox / Date / Date / FormulaPublic liability insurance. Same pattern.
ServiceAgreementYNCheckboxWritten service agreement on file.
ServiceAgreementDateDateWhen signed.
PricingBasisDropdown[Hourly rate, Flat fee per job, Retainer, Commission].
DefaultHourlyRateNumberUsed for DA/HM jobs if no override.
ContactName / PhoneNumber / EmailAddressTextPrimary contact, for dispatch and invoicing.
BankAccountTextBSB/Account (masked for security). For payments.
RelatedPartyYNCheckboxTrue if owner is related to EC leadership.
RelatedPartyNotesTextBrief description of the relationship.
RelatedPartyRegisterDateDateWhen declared to funder.
NotesTextAny issues, preferences, escalation.

Validation: Status formulas auto-update (no manual entry). Expiry columns have conditional formatting — yellow if < 30 days, red if expired.

Part 4

Migration strategy + data mapping

Phase 1

Parallel Build (weeks 1–2)

  1. Build all five new tabs in a separate sheet (“EC_Master_v2”) alongside existing sheets
  2. Populate Client Master from existing client names + MyAgedCare data
  3. Populate Contractor Register from historical contractor names; extract police-check / WWVP dates from Compliance files
  4. Migrate 3 months of historical Job Ledger data (Feb–Apr 2026) manually — highest-value recent data
  5. Set up Reconciliation Ledger with bank feed for Apr–May 2026
  6. Validate formulas; spot-check 20 random jobs
Phase 2

Team UAT (weeks 2–3)

  1. Alexis (HM) tests with the new Job Ledger; QC workflow unchanged, but data-entry format changes
  2. Alisya (Transport) tests booking-to-ledger flow
  3. Nawal tests Reconciliation Ledger + dashboard refresh
  4. Elle / Mohamed test bank-reconciliation workflow
  5. Kaltun spot-checks dashboard vs historical P&L
  6. Feedback loop; fix any data-entry UX issues
Phase 3

Cutover (Fri EOD week 3)

  1. Rename old sheets to “v1_Archive” (read-only)
  2. Rename new sheet to live names
  3. All new entries from Monday (week 4) go to new sheets only
  4. 1-week overlap period: any new entries on old sheets are manually migrated to new
  5. Kaltun sends team announcement with new workflow + quick-reference guide

Historical data retention

  • Old sheets archived but remain accessible (read-only) for audit trail
  • 2-year lookback available from new sheets (Reconciliation Ledger)
  • Dashboard will backfill with historical formula calculations once data is migrated
Part 5

Team training + workflows

How each role uses the new schema day-to-day.

Intake (Umar)

  • On MyAgedCare referral: add row to Client Master (auto-increment ClientID), fill eligibility + region + contact info
  • Link to Job Ledger when job scheduled

Domestic Assistance (Nawal + DA contractor)

  • Job completed: create Job Ledger row, fill ClientID, ServiceType, ContractorID, DateCompleted, StartTime, EndTime (or manual HoursWorked), photos URL, JobStatus
  • Payment collected: fill PaymentStatus, AmountPaid, PaymentDate, ReceiptRef
  • QC approval: Nawal marks QCApprovedBy and QCApprovedDate

Home Maintenance (Alexis + contractors)

  • Pre-job: create Job Ledger row with ClientID, ServiceType (HM-[type]), ContractorID, scheduled dates, notes
  • Post-job: contractor provides photos + hours; Alexis enters HoursWorked, BeforePhotos, AfterPhotos, JobNotes
  • QC: review, mark JobStatus = Complete or Issue; if Issue, fill IssueType
  • Approval: QCApprovedBy = Alexis, QCApprovedDate

Transport (Alisya + Nawal)

  • Booking: create Job Ledger row, ClientID, ServiceType = Transport, ContractorID, TripsCompleted = 1, DateCompleted
  • Receipt: Nawal logs PaymentMethod, AmountPaid, ReceiptRef when receipt arrives
  • QC: mark QCApprovedBy = Nawal

Accounts reconciliation (Elle / Mohamed)

  • Bank feed arrives: load into Reconciliation Ledger helper columns
  • Fuzzy matcher highlights likely matches; manual review of unmatched
  • For each matched transaction: fill TransactionID, InvoiceID, MatchStatus, MatchMethod, BankDepositDate, BankDepositAmount
  • Weekly sign-off: ReconciliationApprovedBy, ReconciliationApprovedDate

DEX reporting (Nawal / Kaltun)

  • Monthly: pull Job Ledger filtered by DateCompleted, ServiceType, GrantUnitsUsed
  • Dashboard automatically shows grant-units delivered; compare to commitment
  • If < 85%, alert Kaltun (conditional formatting)
  • Prepare DEX submission — now auditable, not cell-colour-based
Part 6

Implementation checklist

WhenWhat
Week 1, Day 1Share this blueprint with EC team; get feedback
Week 1, Day 2–3Design Google Sheets formulas in a separate test sheet
Week 1, Day 4Populate Client Master + Contractor Register
Week 1, Day 5Migrate Feb–Apr 2026 Job Ledger data
Week 2, Day 1–2Build Reconciliation Ledger + bank feed formulas
Week 2, Day 3Build Performance Dashboard; validate formulas
Week 2, Day 4Alexis, Nawal, Alisya UAT; collect feedback
Week 2, Day 5Fix bugs from UAT; finalise workflow docs
Week 3, Day 1–2Team training sessions (30 min per role)
Week 3, Day 3–5Overlap period (dual entry if needed); support calls
Friday EOD Week 3Cutover; archive old sheets; go live
Part 7

Success criteria + metrics

GoalMetricTargetMeasurement
Data consistency% of Job Ledger rows with complete required fields> 95%Weekly audit of new entries
Reconciliation timeDays from payment received to Reconciliation Ledger posted< 3 days (was ~7–14)Sample 10 jobs/week
Grant-unit visibilityMonthly dashboard refresh accuracy vs DEX submission100% matchCompare dashboard to DEX PDF each month
Contractor compliance% of active contractors with current police check + WWVP100% (was 0% tracked)Dashboard card, red flag if < 100%
Team adoption% of staff correctly filling Job Ledger (no reminders needed)> 90% by week 4Spot-check entry quality
AR aging reductionOutstanding invoices > 90 days old< 10% of AR (was 40%+)Reconciliation Ledger report
Part 8

Future enhancements (post-revamp)

  1. GPS-tracked evidence intake: if a contractor app is built, auto-populate BeforePhotos, AfterPhotos, StartTime, EndTime, HoursWorked from app telemetry.
  2. Automated fuzzy matcher: currently manual. Could be a daily script pulling bank CSV, running the match algorithm, and auto-populating the Reconciliation Ledger with high-confidence matches.
  3. DEX API integration: pull grant commitment directly from DEX instead of manual entry; auto-flag if trajectory misses.
  4. Xero sync: post-cutover, one-way sync from Reconciliation Ledger → Xero invoices (for unpaid) and bank transactions (for received).
  5. Contractor management app: supplement or replace the manual contractor register with app-based compliance tracking + photo evidence.
Part 9

Risks + mitigations

RiskImpactMitigation
Data entry errors during migrationBad historical data cascades to dashboardSpot-check 20 random rows manually; second pair of eyes on Feb–Apr 2026
Team resistance to new workflowAdoption fails; revert to old sheetsInvolve Alexis, Nawal, Alisya in blueprint feedback; 30-min training per role; first-week high support
Formula errors (esp. date calculations)Dashboard shows wrong KPIsTest all formulas with 10 sample rows before UAT; conditional formatting to catch blanks
Google Sheets permission issuesCollaboration breaks mid-revampEnsure all editors have full access to v2 sheet before starting; no view-only editors
Contractor data incompleteCompliance register missing key expiry datesProactive email to all contractors asking police check + WWVP info; cross-reference email + Drive
Part 10

Sign-off + next steps

  1. Kaltun reviews blueprint (1–2 day feedback window)
  2. Alexis spot-checks HM schema (especially IssueType dropdown options)
  3. Nawal spot-checks Reconciliation Ledger workflow
  4. MR Labs builds the test sheet with formulas + sample data (week 1)
  5. Team UAT (week 2)
  6. Cutover (Friday week 3)

Handover: once live, the team owns day-to-day data entry. MR Labs remains on-call for formula questions and issues during the first two weeks.