A retroactive baseline change adjusts budget, earned value, actual cost, or related records associated with a previously reported period. It is not automatically prohibited. However, it should remain exceptional, receive the required approval, and preserve visibility into the program’s actual performance history.
In most Earned Value Management System (EVMS) implementations, the program records the cumulative effect of an authorized prior-period correction in the current reporting period. It does not silently rewrite previously delivered reports. Valid reasons can include correcting an error, processing a routine accounting adjustment, implementing a customer-directed action, or restoring the integrity of performance data.
A retroactive change becomes improper when the program uses it to erase unfavorable variances, move unused budget away from completed work, or make the original plan appear consistent with actual execution. Approval of a baseline change request does not make those practices acceptable.
What Counts as a Retroactive Baseline Change?
The Performance Measurement Baseline is the time-phased budget against which the program measures performance. Therefore, moving planned value in a closed period is a retroactive PMB change. The same control concern applies when a correction changes previously reported earned value or actual cost, even though actual cost is not part of the PMB.
Examples include:
- Moving budget from one control account to another after the original budget period has closed.
- Correcting planned value that was loaded under the wrong Work Breakdown Structure element.
- Removing earned value that the program recorded before the completion criteria were met.
- Replacing estimated actual costs with accounting-system actuals.
- Applying an approved indirect-rate adjustment that affects cumulative actual cost.
- Implementing the cumulative effect of a customer-directed termination or change to work already underway.
The phrase can cause confusion because not every prior-period adjustment changes the baseline. For example, replacing estimated actuals affects actual cost but may leave planned value and earned value unchanged. A disciplined process identifies exactly which data elements change instead of labeling every correction as a rebaseline.
What EIA-748 Guideline 30 Is Designed to Prevent
EIA-748 Guideline 30 addresses changes to records for work already performed. The guideline limits adjustments to error corrections, routine accounting adjustments, customer- or management-directed changes, and actions that improve baseline integrity or performance measurement accuracy.
The Department of Energy’s EVMS Interpretation Handbook explains the core control principle: management should authorize the adjustment, and the program should normally record its effect in the current reporting period. This approach preserves the visibility of prior reporting while correcting cumulative values.
However, agency guidance does not replace the contract. The applicable EIA-748 version, contract clauses, Contract Data Requirements List, EVMS system description, and customer direction determine the specific process for a program. DOE implementation details, for example, should not be presented as universal Department of Defense requirements.
Contract Requirements Versus Internal Baseline Procedures
The distinction between contract requirements and company procedures matters. Federal Acquisition Regulation 52.234-4, when included in a contract, requires the contractor to use a compliant EVMS and addresses approval or disclosure of proposed EVMS changes. For applicable DoD contracts, Defense Federal Acquisition Regulation Supplement 252.234-7002 establishes related EVMS criteria, surveillance access, system-change notification, Integrated Baseline Review provisions, and over-target baseline controls.
Those clauses do not establish one universal approval path for every individual baseline transaction. A change to the contractor’s EVMS procedures is also different from a baseline change processed under existing approved procedures.
Transaction-level approval may come from the program manager, change control board, control account manager, program controls manager, contracting officer, or another designated authority. The required path depends on the contract and the contractor’s approved system description. Therefore, teams should verify the governing documents before deciding who must approve a specific baseline change request.
When a Retroactive Baseline Change May Be Appropriate
Correction of a documented error
A clerical, coding, calculation, or data-entry error can justify a prior-period correction. For example, the cost processor may have mapped one work package to the wrong control account. The correction should identify the original transaction, affected periods, cause, and resulting changes to planned value, earned value, actual cost, and Budget at Completion.
The program should also determine whether the error affected the Integrated Master Schedule (IMS), work authorization documents, accounting records, or customer reports. Correcting one system while leaving another unchanged creates a new reconciliation problem.
Routine accounting adjustments
Actual costs may change when estimated actuals are replaced, costs are transferred to the correct account, or approved rates are applied. These adjustments should remain traceable to the accounting system.
A baseline change request must never serve as an unsupported method for editing actual cost. The cost processor and accounting organization should control the accounting entry, while program controls verifies that the EVMS reflects it correctly.
Customer- or management-directed action
A stop-work direction, partial termination, definitization, or other authorized scope action may affect work already in progress. In that case, the program may need to adjust an open work package or close it and plan the remaining scope in a new work package.
The preferred method depends on the contractor’s system description and the nature of the change. However, the program should not start changed work without appropriate authorization merely because the baseline paperwork is still moving through review.
Correction of invalid earned value
The program may need to reverse earned value if it credited performance that did not satisfy the approved completion criteria. Examples can include a material item returned for repair or work that requires substantial rework.
This correction is not the same as adding budget to cover the rework. Unless the scope has changed through an authorized action, poor execution does not create additional budget entitlement.
Practices That Normally Fail the Baseline-Integrity Test
A retroactive change should not turn the PMB into a record of what happened instead of what the program planned. The following practices are strong warning signs:
- Eliminating variances after the fact. Moving past planned value to match actual execution destroys the comparison between plan and performance.
- Moving unused budget from completed work to overrunning work. A favorable variance is not automatically available budget for another control account.
- Using management reserve to offset an existing overrun. Management reserve supports realized, in-scope risks under the approved process. It should not erase historical cost or schedule variance.
- Backdating approval. A late signature does not prove that management authorized the change before implementation.
- Overwriting prior submissions. Replacing archived reports or schedule files prevents reviewers from reconstructing what management knew at each status date.
- Changing actual dates to improve schedule metrics. Actual dates may be corrected when they are factually wrong. They should not be moved merely to remove out-of-sequence progress or repair logic after the fact.
- Editing tools without integrated reconciliation. A change entered only in the cost engine, IMS, or work authorization system leaves the EVMS internally inconsistent.
Frequent adjustments also deserve attention even when each one has an explanation. A high volume of corrections can indicate weak planning, poor status discipline, delayed accounting integration, or ineffective change control.
How to Process the Change Without Rewriting History
The exact workflow varies, but a defensible process should include the following steps.
- Identify the triggering event. State what was wrong or what authorized action occurred. Avoid explanations such as “realign the baseline” without describing the cause.
- Determine the affected records. Identify the control accounts, work packages, schedule activities, periods, resources, and reporting elements involved.
- Separate baseline, performance, and accounting effects. Show the changes to planned value, earned value, actual cost, Budget at Completion, Estimate to Complete, and schedule dates independently.
- Calculate the current-period adjustment. Preserve the prior submission and show the cumulative correction in the current period unless the governing procedure directs another treatment.
- Obtain approval before implementation. Follow the thresholds and authorities in the contract and EVMS system description.
- Update all integrated systems. Reconcile the IMS, EVMS cost tool, work authorization documents, budget logs, accounting interfaces, and reporting extracts.
- Explain the reporting impact. Address material negative or unusual current-period values in the required variance analysis or management narrative.
- Retain an audit trail. Preserve the original values, approved change package, implementation evidence, and before-and-after reconciliation.
The GAO Schedule Assessment Guide also recommends subjecting baseline and current schedules to a documented change control process. Without that control, teams can continually revise the schedule to match performance and obscure the causes of variance.
Fictional Example: Correcting Budget Loaded to the Wrong Account
The fictional Asteria communications program assigned $300,000 of January and February planned value to the Antenna Design control account. In May, the team discovered that the authorized scope and budget belonged to the Signal Processing control account. The total contract budget and scope were correct, but the internal mapping was wrong.
The program should not silently revise the January and February reports. Instead, the control account managers prepare a baseline change request that documents the mapping error and shows the affected budget, earned value, actual cost, schedule activities, and work authorization records.
After approval, program controls records the cumulative transfer in May. As a result, May may show negative planned value in Antenna Design and positive planned value in Signal Processing. If earned value or actual cost was also reported against the wrong account, the team processes those corrections through the appropriate performance and accounting controls.
The total PMB remains unchanged. However, the control account history now reconciles through a visible current-period adjustment. The May narrative explains the unusual values, and the change log links them to the approved request.
Now consider a different situation. Antenna Design is three months late, and the control account manager wants to move January through March planned value into the future to remove the schedule variance. That is not an error correction. It is an attempt to replace the original plan with actual execution. Any legitimate replan should focus on remaining work and retain visibility into past performance. The distinction is explored further in replanning versus rebaselining.
Questions Reviewers Should Ask
A scheduler, program controls analyst, or customer reviewer can evaluate a proposed retroactive change by asking:
- What specific error, accounting event, or authorized direction caused the change?
- Was the original information wrong, or has the program simply performed differently from plan?
- Does the change correct cumulative data while preserving prior reports?
- Does it eliminate or reduce a variance without a corresponding scope correction?
- Does the request alter actual cost without support from accounting records?
- Are the IMS, cost system, work authorization documents, and baseline logs consistent?
- Did the correct authority approve the change before implementation?
- Will the current-period report explain negative or unusual values?
- Does the volume of similar changes indicate a broader process weakness?
These questions help distinguish a necessary correction from variance management disguised as baseline maintenance.
Practical Interpretation for Program Controls
The central issue is not whether a change touches a prior period. The issue is whether the change improves data accuracy without concealing the program’s performance record.
Therefore, preserve the original submissions, process approved cumulative corrections visibly, and reconcile every affected system. Meanwhile, keep future replanning separate from prior-period corrections. The IMS and EVMS must remain integrated so that schedule status, time-phased budget, earned value, and forecast dates tell the same management story.
A well-controlled retroactive change can restore confidence in the data. An undocumented or variance-driven change does the opposite. It weakens the PMB, disrupts trend analysis, and makes both the contractor and customer question which version of program performance is credible.
Frequently Asked Questions
Are all retroactive baseline changes prohibited?
No. Controlled corrections may be valid for documented errors, routine accounting adjustments, authorized scope actions, or improvements to data integrity. The applicable contract and EVMS procedures govern the approval and implementation process.
Can a valid adjustment create negative current-period values?
Yes. Recording the cumulative effect in the current period can produce negative planned value, earned value, or actual cost. The program should verify and explain those values rather than automatically treating them as errors.
Does an approved BCR allow the program to eliminate variances?
No. Approval alone does not make an improper adjustment acceptable. The change must have a valid basis and comply with the program’s baseline control procedures.
Should a scheduler overwrite the prior IMS?
No. The program should retain prior statused and submitted schedules. If a factual error requires correction in the current IMS, the scheduler should document the change and preserve the files needed to reconstruct the reporting history.