What it means
A client asks a developer to add a feature midway through a project, which affects cost and launch date, and a change log records the request, decision and final implementation so the team does not rely on memory. The log can serve different purposes: a project log tracks scope, budget and schedule decisions, a product release log tells users which features or fixes shipped, and a finance-model log records changes to assumptions and formulas.
Atlassian's change-control guidance describes documenting proposed changes, assessing impact and approving them before implementation, and GitHub's release-note guidance links a release overview to its full changelog, which shows why a change record should connect to the underlying decision or work. Give each item a unique identifier and date, and record the originator, description, reason, affected area and current status, with a reference to the approval, ticket or version so the entry can be verified later.
Use plain language: 'Updated model' tells a future reader little, while 'changed 2027 volume assumption from 10,000 to 8,000 units after revised customer forecast' tells them what moved and why. Do not hide a material scope change under a vague line.
Proposed, approved, rejected, implemented and rolled back are different states, and a manager should not count a requested feature as part of the contract until the correct party has approved it. For a customer project, record the cost and schedule effect before seeking approval, because a seemingly small request can require testing, design and rework.
The log should show the agreed price or state that the amount remains to be decided. An illustrative total of three approved changes costing $10,000, $4,000 and $6,000 is $20,000, excluding rejected or pending requests.
It is not a new contract amount until the proper change-order process is complete. Attach or link evidence such as a signed change order, reviewed pull request or approved model version rather than copying sensitive documents into every row, and keep links accessible to the team responsible for the work.
Do not overwrite older entries when plans change again; add a new item that supersedes or reverses the earlier one and link the two, so the audit trail shows the sequence and not only the latest state. A document's automatic version history can help, but it may show every spelling edit without explaining the business reason for a substantive revision.
A concise human summary gives context that a list of timestamps lacks. Set a threshold for detail, since not every punctuation fix needs a committee decision but material changes to prices, permissions, scope or financial assumptions deserve a clear record, and the process should be light enough that people use it.
Review the log at project checkpoints, giving open approved changes owners and expected completion dates and verifying that a completed change landed in the delivered version. A log can help with disputes but cannot replace a required signed contract amendment, because a company-only spreadsheet is evidence of internal discussion, not proof of customer consent.
In practice
Real-world examples.
Example
A project records a requested feature, its cost estimate and the customer's later approved change order. The log links to the signed document. When the invoice arrives, finance can match it to the approved entry.
Example
A finance model log explains a revised sales-growth assumption and identifies the data used. A new analyst can see why the forecast moved between versions. The old assumption stays in the history.
Example
A software release record links a shipped fix to the reviewed issue and version. Support staff use it to tell a customer which release solved the problem. It also helps engineers trace the fix if a later release causes a regression.
Formula
Calculation
Approved change cost = sum of costs for approved changes in scope.
Worked example: three approved changes cost $10,000, $4,000 and $6,000, so the total is $10,000 + $4,000 + $6,000 = $20,000. A fourth request worth $8,000 is still pending and a fifth worth $3,000 was rejected, so neither is included. If the original contract was $100,000, the revised figure would be $120,000 only once the contract mechanism has been completed.Case study
Seen in the real world.
This entirely fictional example follows Oasis Software, an invented developer. A customer disputed an extra invoice because several feature requests were discussed informally. The team reviewed the signed scope and found that one request had never been approved. Oasis introduced a shared log linked to change orders and stopped treating a pending request as authorised work. The case does not claim the log itself became a signed customer agreement.
Watch out
Common mistakes.
- Recording a request as completed or approved before the right person agrees.
- Using vague descriptions without cost, version or reason.
- Keeping the log in a private file or overwriting history after a reversal.
Questions
People also ask.
What is a change log?
A dated record of changes, their reasons, status and supporting decisions.
Where is it used?
Projects, software releases, documents, systems and financial models.
Why keep one?
It helps trace decisions and handovers, but it does not replace formal approval where required.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%