How this works

A client project register is the index of engagements the company is responsible for delivering. It connects the client, agreed scope, delivery owner, milestone dates and commercial context without replacing the task tracker or accounting ledger. A useful first version makes missing ownership and conflicting commitments visible rather than presenting every row as complete.

Treat a client, opportunity, contract, project, workstream and invoice as different objects. One contract may fund several projects, and one project may have several invoices. Use stable IDs and explicit relationships so a duplicated document or changed project title does not create duplicate engagements. AI can extract and reconcile candidate facts; confirmed scope and status remain owned by the delivery and account teams.

Before you start

Prepare the inputs

project_records

Required

Rows with existing project ID, client ID, title and source reference

Preserve existing stable IDs; flag duplicate IDs with conflicting client or scope values.

scope_documents

Required

Approved agreement or change record, version and effective date

Distinguish signed scope from sales proposals and unapproved change requests.

delivery_updates

Required

Project ID, milestone, status, status date and owner role

A status requires an as-of date and evidence. A passed due date alone is not proof of completion.

commercial_records

Optional / conditional

Contract ID, amount if authorized, currency, billing model and invoice references

Do not mix currencies or combine contract value, invoiced value and collected cash into one field.

owners

Required

Internal owner IDs or role aliases

Each active project needs a confirmed accountable delivery owner or an explicit missing-owner exception.

snapshot_date

Required

ISO date with freshness expectations

All views show the same snapshot date; identify updates older than the agreed review cadence.

Implementation, step by step

1. 01

   Define the register and its views

   • Write a compact data dictionary covering the project unit, unique identifier, status vocabulary and mandatory fields. Separate planned, active, paused, completed and archived work according to the team's definitions.
   • Choose the initial views: active portfolio, upcoming milestones, missing owners and unresolved scope changes. Keep sensitive commercial fields in a restricted view when the audience differs.

   Checkpoint: The schema and included population are agreed before records are consolidated.

2. 02

   Collect evidence without losing provenance

   • Read authorized project exports, agreements and recent updates. Preserve original source IDs, versions and update dates in a source map.
   • Extract candidate facts into staging rows. Mark missing scope, unapproved proposals and stale status explicitly; do not fill them from plausible-sounding summaries.

   Checkpoint: Every staged engagement has traceable source records and a completeness status.

3. 03

   Resolve entities and duplicates

   • Match exact project and client IDs first, then review ambiguous aliases using contract references and scope. Two projects with the same client and similar titles are not automatically duplicates.
   • Link multiple contracts, amendments or invoices through separate relation tables when necessary. Keep the canonical project ID stable across renames and owner changes.

   Checkpoint: Each included engagement has one canonical project row; uncertain matches remain in a review queue.

4. 04

   Reconcile scope, dates and status

   • Compare the latest approved scope and amendments with delivery notes. Track proposed additions separately until an authorized owner confirms them.
   • Store delivery status and commercial status in different fields. Retain conflicting milestone dates with their sources and ask the owner to resolve material disagreements.

   Checkpoint: The row distinguishes confirmed facts, proposed changes, unknowns and disagreements.

5. 05

   Build useful operating views

   • Create a milestone table keyed to projects, with due date, completion evidence, owner and dependency. Sort actionable exceptions by decision need rather than inventing an unsupported risk score.
   • Prepare filters for active projects, unassigned owners, overdue uncompleted milestones and stale updates. Any totals must use consistent units and currencies, with denominators and exclusions stated.

   Checkpoint: A reviewer can trace each highlighted issue back to the project and original evidence.

6. 06

   Validate the snapshot and update process

   • Reconcile the canonical project count with source exports and explain merges and exclusions. Ask delivery and account owners to confirm only the rows that require their decisions.
   • Save the draft or approved register with a maintenance owner and review cadence. Record changes by stable ID; if asked to sync a destination, use idempotent updates and verify the resulting rows before marking them synchronized.

   Checkpoint: The handoff contains the register, source map, exceptions and an explicit next update owner.

Decisions along the way

What you will produce

Check the result

• Assert unique project IDs and valid client/project references across all linked tables.
• Reconcile included projects against every source list; account for archived records, duplicates and excluded opportunities.
• Check every active project for scope evidence, owner and dated status, recording exceptions instead of hiding blanks.
• Confirm that project value is not repeated in each milestone row or counted once per invoice.
• Review date conflicts, stale statuses and future milestones marked complete without evidence.
• Check that all exported views expose only the fields appropriate for their intended audience.
• Use snapshot_date for the common reporting snapshot and status_as_of for the original status evidence date; do not overwrite one with the other. Verify that every source_ref resolves in the source map.

When something goes wrong

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Run a small pilot

Keep the scope clear

• The register records commitments; it does not authorize new scope, change contract terms or promise delivery dates.
• Do not publish client identities, confidential project descriptions or commercial values beyond the authorized audience.
• Local register preparation is allowed within the request. Writes to operational systems or client communications need existing authorization for those destinations.