Give each property one ID in one register

Create one official property register with one identifier per property and one place where updates are made. This is the backbone reform that stops duplicate records, split files, and competing lists from undermining billing and later valuation work.

• The city has multiple lists or spreadsheets that do not match.

• Coverage and billing work are constantly undone by duplicate or conflicting records.

• The administration is ready to move from fragmented records to one system of record.

• Basic digital infrastructure, data-cleaning plan, and agreement on who owns the register.

• Procedures for adding, changing, and retiring records with an audit trail.

• Do not overspecify the system before agreeing a simple data model and update process.

• This is not the best first move for tiny jurisdictions that can still manage a simpler list.

Cities often underestimate the governance side of this reform. The hard part is not creating the ID itself; it is making sure every team uses the same record and that the register stays alive after the first clean-up.

The full card would help the city plan the unique ID structure, data migration, governance rules, staff responsibilities, and the maintenance procedures needed so that the register stays usable after the initial clean-up.

• Link the roll to permits, sales, and new service connections

• Put routine coverage audits on the calendar

• Send bills people can understand.

Many cities think they have a coverage problem when they also have a register-governance problem. If different teams continue to use different lists, every discovery or clean-up exercise gets undone. One identifier and one recognised register do not solve everything, but they are the backbone for stable maintenance, better billing, and later system integration.

Create a single operational record for each property, supported by one stable identifier and one recognised register of record.

A city where duplicate records, parallel spreadsheets, and inconsistent updates are undermining coverage, billing, and trust in the data.

A cleaned pilot register with stable identifiers and a visible reduction in duplicate or conflicting records.

Approve the master data model, the unique-ID logic, and the rule that one register becomes the record of reference for property tax operations.

Revenue administration with IT, data-management, and governance support from related departments.

• The administration already has multiple lists or spreadsheets that do not match.

• Duplicate and conflicting records keep disrupting normal operations.

• The city is ready to move from fragmented records to a more disciplined master register.

• Keep the first data model lean. The city should agree core fields, ownership rules, and update procedures before adding complexity.

• Map existing sources and decide which fields can be trusted, which require cleaning, and which should not be migrated yet.

• If digital infrastructure is weak, start with a simpler but still disciplined master list rather than waiting for a perfect system.

• Settle whether the ID attaches to the parcel, the structure, or a layered system that can deal with both.

• Choose a stable coding logic that does not need frequent re-numbering when streets or administrative areas change.

• Decide how legacy records will be merged, retired, or preserved for audit purposes.

First 90 days

• Agree the minimum data model, ID logic, and ownership of the master register.

• Select the priority dataset or pilot area for cleaning and migration.

• Document the rules for adding, editing, merging, and retiring records.

6 to 12 months

• Clean and migrate the priority records into the new master structure.

• Resolve duplicates and ambiguous records with defined review rules rather than case-by-case improvisation.

• Train the main operational teams to use the same record rather than maintaining shadow lists.

12 to 24 months and beyond

• Expand to more wards or datasets once the first migration logic has stabilised.

• Connect the master register to billing, field updates, and later event-trigger feeds.

• Retire or strictly control legacy lists so the city does not drift back into parallel systems.

• Some contexts require recognition of electronic records or a formal internal directive naming the system of record.

• Data access, change authority, and audit trails should be explicit so the register remains trusted internally.

• The city needs a business owner for the register, not just an IT custodian.

• Data cleaning and migration require close operational judgement; they should not be treated as purely technical tasks.

• Staff training and change management are essential because the reform changes how teams work, not just where data sit.

• Overdesigned systems can delay the shift to a usable master register.

• If departments keep shadow lists, the reform becomes cosmetic rather than operational.

• Weak migration rules can carry old errors into a new system at scale.

• Share of properties with a stable unique ID.

• Number of duplicates resolved or legacy records retired.

• Number of operational teams using the same register of record.

• Time required to create, update, or correct a property record.

• This card is foundational for PT-COV-08 on external triggers, PT-COV-09 on routine audits, PT-COV-13 on location references, and later compliance and valuation cards that need one clean property spine.

• Who owns the master register operationally?

• What makes an ID stable in your context?

• Which legacy records should be migrated first and which should be quarantined for review?

• How will the city stop departments from rebuilding parallel lists?