# Scope creep records: cross-system ID map | SourceX

Canonical: https://refer.sourcex.si/guides/scope-creep-adjudication-records-across-systems
Last updated: 2026-10-19

Reconstructing a scope creep decision needs four joins: the client request to the project and task where the work was logged, the task to the change request that named the drift, the change request to the SOW version it produced, and that SOW version to the billing line or contract limit it changed. The change request is the hinge, because it is the only record that refers to both the delivery and the contract. Where any join is missing, the decision becomes a pile of unconnected hours and amendments.

This system map is part of the [scope creep adjudication guide](/guides/workflow-scope-creep-adjudication), which covers what to inventory before a PSA migration. The [worked hard case](/guides/scope-creep-adjudication-exception-examples) walks one fixed-fee exception step by step. This page does a different job: it shows which tool holds each record, the identifier that carries the case between tools, and what a fully joined case looks like on a capped time and material engagement.

## Five tools behind one scope decision

At most services firms the records of a single scope decision are spread across five places:

- **Email, chat or a ticket queue.** Where the client asks for something extra, usually in plain language.
- **PSA time and tasks.** Where people log hours against project and task codes. In Microsoft Project Operations, for example, team members submit time entries for approval, approvers approve them, and approved time becomes actuals.
- **PSA or project tool change requests.** Where someone names the drift, requests hours and records an approver. Some firms keep these in a spreadsheet or a shared form instead.
- **Contract tool (CLM) or document library.** Where each SOW version and amendment is signed and filed.
- **PSA or ERP billing.** Where contract lines, billing rules and limits turn the decision into revenue.

## The ID map: system, record, linking key, owner

This table is the evidence asset for the page. Each row says how to get from one record to the next.

| System | Record | Linking key it should carry | Joins to | Usual owner |
|---|---|---|---|---|
| Email, chat or tickets | Client request | Project ID or name in the thread or ticket | Task where the work was logged | Delivery lead |
| PSA | Time entries | Project ID, task code, narrative | Change request | PMO lead |
| PSA or project tool | Change request | Project ID, task code, CR ID, approver | SOW version | Delivery director |
| CLM or document library | SOW version or amendment | Agreement ID, version number, CR ID in the recitals | Contract line | Legal operations |
| PSA or ERP | Contract line, limit or billing rule | Agreement ID and version, line ID | Invoices | Finance |
| CRM or review deck | Outcome note | Account and service name | Renewal or dispute | Account lead |

Two keys do most of the work. The **project and task code** joins delivery to the change request, and the **change request ID** joins the change request to the contract. A firm that writes the CR ID into each SOW amendment can be traced in both directions. A firm that does not has to match by date and client name, which is guesswork.

## How contract type changes what the map shows

The same scope decision leaves different traces depending on the contract. Microsoft's documentation describes not-to-exceed limits on time and material contract lines, evaluated against actuals after spent and committed amounts and capping actual revenue, while fixed-price lines carry a value that does not move with costs. In practice:

| Contract type | How creep shows up | Where the decision lands | Join to check |
|---|---|---|---|
| Time and material with a cap | Actuals approaching the not-to-exceed limit | A raised limit or a new contract line | Limit change to change request |
| Fixed price | Hours with no revenue behind them | A new SOW version adding scope or fee | SOW version to change request |
| Retainer or managed service | Tickets above the agreed volume | An agreement addition or a declined request | Ticket to agreement change |

Ask which pattern the firm's contracts follow before judging what its records will reveal. For managed services firms, [ConnectWise PSA data](/systems/connectwise-psa-data) and [Autotask ticket history](/systems/autotask-psa-ticket-history-export) cover the ticket side.

## One fully joined case, Illustrative

Illustrative only; the firm, IDs and figures are fictional. A 240-person ERP implementation partner runs a time and material engagement with a not-to-exceed limit of 1,600 hours. The client asks for three extra custom reports partway through.

| Step | System | Record | Key that reaches the next step |
|---|---|---|---|
| 1 | Ticket queue | Client ticket asking for three custom reports, tagged with the project ID | Project ID |
| 2 | PSA | 64 hours logged to a new "Custom reports" task over five weeks | Task code |
| 3 | PSA | Actuals reach 1,520 of 1,600 hours; PM raises change request CR-12 for 120 hours | CR-12 |
| 4 | PSA | Delivery director approves CR-12 with a comment: reports are new scope, not rework | CR-12 |
| 5 | CLM | Amendment 2 signed, citing CR-12, raising the limit to 1,720 hours | Agreement ID, amendment 2 |
| 6 | PSA billing | Contract line limit updated to 1,720 hours, referencing amendment 2 | Line ID |
| 7 | CRM | Account review notes the client accepted the reports at go-live | Account and service name |

Every step resolves to the next. Remove the project ID from the ticket in step 1, and nobody can show the extra reports were the client's request rather than the firm's own overrun. Remove the CR ID from the amendment in step 5, and the raised limit looks like an unexplained concession. The director's comment in step 4 is the adjudication itself; [project histories that include decisions and outcomes](/guides/how-to-recognize-project-histories-that-include-decisions-and-outcomes) explains why that kind of note is what makes a project file worth describing.

## Where the joins break

| Break | Typical cause | What the history loses |
|---|---|---|
| Request without a project ID | Client emails a person, not a queue | The origin of the extra work |
| Creep logged to an in-scope task | No task created for the new work | The difference between overrun and new scope |
| Change request kept off-system | Approvals by spreadsheet or email | The decision and its reason |
| Only the latest SOW kept | Versions overwritten in the library | What the contract said before the change |
| Limit changed with no reference | Finance edits the line directly | Why the cap moved |

New tooling does not repair old breaks. Microsoft lists a planned Project Operations change order feature that would record each change order's rationale, financial impact and approval history and compare contract versions, with public preview shown for September 2026 and timelines subject to change. A firm adopting a structured feature like that gets joined records from go-live onward; everything before it is still only as joined as the old tools allowed.

## Questions for the delivery director

Keep it to whether each key exists and for how long:

1. Do client requests reach a queue that tags the project, or individual inboxes?
2. Is new work given its own task code?
3. Where do change requests live, and do they record approver and reason?
4. Do SOW amendments cite the change request?
5. Are past contract limits and their changes kept?
6. How many change requests a year, and how many years back?

Counts and date ranges fit the [data scope worksheet](/resources/data-scope-worksheet). Rights sit higher than the delivery director, since SOWs and client tickets carry confidentiality terms; the [who-can-license page](/questions/who-can-license-scope-creep-adjudication-records) names the executive, and [IT due diligence](/questions/it-due-diligence-meaning) covers the same systems from a buyer's side.

The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Unknown until SourceX reviews it: buyer interest, the rights review result and any terms. Partners sign the Channel Partner Agreement before submitting introductions; the first valid introduction within the 90-day window is credited when the company submits a verified application.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If the delivery director confirms that change requests carry project, task and SOW references, [register as a partner](/register), check the firm on [who qualifies](/who-qualifies) and read the [program terms](/terms) before the introduction.

## Sources

- https://learn.microsoft.com/en-us/dynamics365/project-operations/pro/sales/manage-contract-values-project-based-sales
- https://learn.microsoft.com/en-us/dynamics365/project-operations/time/time-entry-overview
- https://learn.microsoft.com/en-us/dynamics365/release-plan/2026wave1/enterprise-resource-planning/dynamics365-project-operations/enable-change-order-management
- https://refer.sourcex.si/terms