Scope creep adjudication across systems: a map of the IDs that join email, PSA, CLM and billing records

Short answer

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.

Visual briefFull-size diagram
A left-to-right chain of five system nodes (email or tickets, PSA time, PSA change request, CLM SOW versions and billing) with linking keys hopping between them: project ID, task code, change request ID and SOW version, and a broken link marked where an email request carries no project ID.
Illustrative. Typical tools at a services firm; field names and the systems used differ by firm.

This system map is part of the scope creep adjudication guide, which covers what to inventory before a PSA migration. The worked hard case 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.

SystemRecordLinking key it should carryJoins toUsual owner
Email, chat or ticketsClient requestProject ID or name in the thread or ticketTask where the work was loggedDelivery lead
PSATime entriesProject ID, task code, narrativeChange requestPMO lead
PSA or project toolChange requestProject ID, task code, CR ID, approverSOW versionDelivery director
CLM or document librarySOW version or amendmentAgreement ID, version number, CR ID in the recitalsContract lineLegal operations
PSA or ERPContract line, limit or billing ruleAgreement ID and version, line IDInvoicesFinance
CRM or review deckOutcome noteAccount and service nameRenewal or disputeAccount 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 typeHow creep shows upWhere the decision landsJoin to check
Time and material with a capActuals approaching the not-to-exceed limitA raised limit or a new contract lineLimit change to change request
Fixed priceHours with no revenue behind themA new SOW version adding scope or feeSOW version to change request
Retainer or managed serviceTickets above the agreed volumeAn agreement addition or a declined requestTicket 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 and Autotask ticket history 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.

StepSystemRecordKey that reaches the next step
1Ticket queueClient ticket asking for three custom reports, tagged with the project IDProject ID
2PSA64 hours logged to a new "Custom reports" task over five weeksTask code
3PSAActuals reach 1,520 of 1,600 hours; PM raises change request CR-12 for 120 hoursCR-12
4PSADelivery director approves CR-12 with a comment: reports are new scope, not reworkCR-12
5CLMAmendment 2 signed, citing CR-12, raising the limit to 1,720 hoursAgreement ID, amendment 2
6PSA billingContract line limit updated to 1,720 hours, referencing amendment 2Line ID
7CRMAccount review notes the client accepted the reports at go-liveAccount 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 explains why that kind of note is what makes a project file worth describing.

Where the joins break

BreakTypical causeWhat the history loses
Request without a project IDClient emails a person, not a queueThe origin of the extra work
Creep logged to an in-scope taskNo task created for the new workThe difference between overrun and new scope
Change request kept off-systemApprovals by spreadsheet or emailThe decision and its reason
Only the latest SOW keptVersions overwritten in the libraryWhat the contract said before the change
Limit changed with no referenceFinance edits the line directlyWhy 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. Rights sit higher than the delivery director, since SOWs and client tickets carry confidentiality terms; the who-can-license page names the executive, and IT due diligence 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, check the firm on who qualifies and read the program terms before the introduction.

  1. Step 1Share your linkSend your personal link to a company you know.
  2. Step 2Company appliesThe company applies itself at /apply.
  3. Step 3Company signs and is paidThe company signs, delivers its data and is paid by SourceX under its agreement.
  4. Step 4You get your rewardYour 25% of the actual supplier payout. A reward becomes payable after SourceX has paid the referred company under its signed agreement and the payout conditions in the program terms are met, including finance approval and your tax and payment details.

Common questions

Which record is the most important join?

The change request. It is the only record that names both the drift in delivery and the change to the contract, so it should carry the project, task and SOW references. Where it lives outside any system, the map breaks in the middle.

Does a managed services firm have the same map?

Similar, but the request usually arrives as a ticket rather than an email, and the contract change may be an agreement addition in the PSA rather than a new SOW. The joins are the same idea with different field names.

Can the map be checked without exporting anything?

Yes. The PMO lead or delivery director can say whether each field exists and how many years it covers. That is all a partner needs.

Sources

  1. learn.microsoft.com/en-us/dynamics365/project-operations/pro/sal…
  2. learn.microsoft.com/en-us/dynamics365/project-operations/time/ti…
  3. learn.microsoft.com/en-us/dynamics365/release-plan/2026wave1/ent…
  4. refer.sourcex.si/terms

Free resources

Know a company with valuable proprietary data?

Become a referral partner, get your link and introduce the company’s CEO (in an owner-run company, usually the owner). Referral partners can join from most countries. We can't work with partners in countries or regions under U.S. sanctions or on U.S. restricted-party lists. The companies you introduce should be based in the U.S., Canada and the EU, or in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia with at least 90% of their data in English.

Refer a company →

I own a business

Explore licensing your company's data directly to SourceX for AI training and evaluation. Start a short assessment; no uploads needed.

Start an assessment