One Project Type for Four Different Project Populations

The in-place switch is not possible. On a project, the project type is fixed at creation. It is the master switch that determines which subledgers and pages exist for that project (billing, capitalization, burdening, cross-charge), so once budgets, costs, invoices or assignments exist the application exposes no supported conversion. Flipping the type would orphan cost, invoice and asset data created under the old rules, so the request has to be answered by design, not by a setting change.

Design one type per population, not one type for the company:

• P1 T&M billable (260): billing enabled, rate-based bill plans, burdening on, capitalization off.
• P2 Fixed price (90): billing enabled, amount/percent-complete plans, capitalization off.
• P3 Internal capital (70): billing off, capitalization on, burdening per the company's indirect policy.
• P4 Cross-charge (15): cross-charge/intercompany processing enabled. These are usually also billable, so decide whether P4 is a fourth type or a setting layered onto P1/P2.

Why this works: project-level and template-level settings can narrow what the type allows (for example, suppress a feature on one project) but they cannot widen it. If the type has capitalization disabled, no project-level checkbox will ever build asset lines; if billing is disabled, no bill plan can be created. So each type must be the superset of everything any project in that population needs, and everything else is trimmed per project or per template.

Remediation: in test, recreate the 70 projects from the new type. In production, create replacement projects of the correct type, re-book remaining budget and forecast, migrate open commitments so new POs hit the new project, and change the old projects' status so no new transactions can post while history and reporting are preserved.

Separate the gates from the content:

Gates that only the project type can open

• Track billable costs (controls whether bill plans, invoice formats and billing pages exist at all).
• Track capitalizable costs (controls whether the project can participate in asset capitalization and asset lines).
• Cost burdening / indirect cost processing.
• Cross-charge and intercompany processing.
• Budgetary control being available for the project at all.

Content that a project can still restrict, even when the type allows it

• The capitalizable indicator carried on the expenditure type and the expenditure item: an item only becomes an asset cost candidate if both the project can capitalize and the expenditure is flagged capitalizable. Internal R&D labour booked to a capitalizable expenditure type is the usual source of surprise asset lines.
• The billable indicator on expenditure types and items; a billable expenditure item on a project whose plan is not billing anything simply sits as unbilled.
• Asset-related setup (capitalization thresholds, asset cost allocation, constructed-asset rules) and the capitalization process itself.

Practical controls to stop cross-contamination on a shared type:

1. Create a project template per population that pre-sets per-project options, the budget control level, default expenditure types and bill plan defaults. Templates are where narrow-by-default behaviour belongs.
2. Use expenditure type security and expenditure type usage rules so internal projects cannot select client-billable or capitalizable expenditure types.
3. Restrict the billing and asset privileges by project role so an R&D project manager has no billing responsibility and therefore no bill plan page.
4. Where a specific population must never bill or capitalize, give it its own project type anyway. Templates cannot close a gate the type has opened, and this is exactly the trap GTS fell into.

A warning-only outcome almost never has a single cause; work through the chain in order:

1. Control level. Budget control levels are typically None / Advisory (warn, notify) / Absolute (reject). A warning is the signature of Advisory. Set the level to Absolute on the projects that must hard-stop. Note that the level is held per project (or on the template pre-setting it); changing it on the project type or on one project does not retroactively raise it on the other 419.

2. No baselined budget. Control is evaluated against a baselined budget. A budget that was entered, submitted or approved but not baselined, or a budget whose baseline was superseded, gives control nothing to enforce. Confirm the baseline exists and includes the tasks where the overspend occurred.

3. Control scope versus where the spend happened. If control is set at the top task only, overspend buried at a lower-level task can still pass because the controlled total is not yet breached. If control is at the lowest task, every task in the spending path needs budget. Decide deliberately and be consistent between the parent and child tasks.

4. The transaction was never tested. Projects controls costs when they are processed (distribution, import validation) and commitments when Procurement's budgetary control runs for the project document. Items sitting unprocessed, or POs created before control was enabled and never re-submitted, have not been tested at all. The pilot's overspend may simply have been invisible until the next process run.

5. Bypass paths. Costs interfaced straight to the general ledger, or posted to tasks outside the controlled branch, never pass the project check.

Fix: set Absolute, baseline, align the control scope, confirm the distribution and Procurement control processes actually run, then re-test with a deliberately over-budget transaction before go-live.