01
Scheduled value has a parent
It is the contract line plus approved change orders for that cost code. A pending change is listed and not counted.
Contracts
Contracts, then change orders, payment applications, and the schedule of values.
The contracts register feeds Committed. A change order sits on the parent contract. A payment application is the period claim. The schedule of values reads all three on one row per cost code — generators, racks, PDUs, switchgear and liquid cooling stay on that row.
01
Contract
Counterparty, value, terms, retention. Feeds Committed.
02
Change order
Raised on the contract. Only approved changes enter scheduled value.
03
Pay application
Period, amount, workflow. Approval moves completed and stored.
04
Schedule of values
One row per cost code. The place the commercial lead runs the contract.
02
Actuals are the application
Completed and stored moves when a payment application is approved. Balance to finish is scheduled minus completed.
03
Retention is on the row
Held, released and net sit beside the cost code. Click any amount and the records behind it open.
Contracts register
The list that feeds Committed.
The contracts register is the list behind the schedule of values. Total contract value, approved budget, committed, spent and variance sit on one page, in the organisation currency. On this demonstration portfolio that currency is US dollars.
Each row is a contract on a project: a data hall fit-out, a network room, critical power. Open the row and the change orders, the payment applications and the schedule of values are that same record.
Change orders
A change sits on the parent contract.
The change-order register is the same family. Status, workflow, the parent contract, the reason and the project. A pending change is listed. An approved change enters scheduled value. It is not a side tracker.
Payment applications
The claim that moves completed and stored.
Payment applications are the period claim against the contract. The register shows what is claimed, the budget, committed, spent and variance. Approval is its own workflow. Until that workflow approves the application, completed and stored does not move.
Schedule of values
Contract plus approved changes, against approved applications.
The schedule of values is a read-only view: contract plus approved change orders versus approved payment applications. The header carries contract value, completed and stored, balance to finish, and net retention. Under that sit the contract card, the change orders raised on it, and the payment applications submitted against it.
Each cost-code row shows scheduled value, completed and stored to date, percent complete, balance to finish, retention held, retention released and net retention. A code that exists only on a change order is still a full row. Percent complete above 100 marks the row. A new application cannot over-claim. Every amount drills to the contract line, the change order or the application that made it.
On a data hall the lines are the ones the owner is buying: diesel and gas generators, server racks, rack PDUs, and design contingency. The demonstration frame is that contract, in US dollars. The arithmetic is the product.
- Scheduled value
- Contract line plus approved change orders for the code.
- Completed and stored
- Claimed on approved payment applications only.
- Balance to finish
- Scheduled minus completed.
- Retention
- Held, released and net, on the row and in the totals.
- Pending stays pending
- A pending change or application is listed. It does not move the columns.
- Drill
- Click the figure. The records behind it open, and you come back to the same contract.
On the project
Change orders and payment applications are linked records.
The project dashboard keeps the contract, its change orders and its payment applications in one strip, with budget, cash flow and the risk heat map beside them. Open the change order or the application from the tile. The schedule of values is the same family, not a report someone rebuilt.
A change order is against the parent contract. A payment application draws the period. Both carry their own workflow. Approving one does not approve the other.
The programme team owns it. Same navigation at portfolio, programme and project. Same My Tasks inbox. App Builder publishes the next step on a Tuesday, without a vendor ticket.
Workflow
The payment application has a path. The change order has its own.
App Builder publishes the payment application workflow: finance approval, reject, send for revision, resubmit. The same designer holds the change order workflow. Ball-in-court lands in My Tasks. The sheet does not get typed over.
When the application is approved, completed and stored moves. When the change order is approved, scheduled value moves. Until then both sit in their pending columns on the cost sheet.
What ships
Turnkey on arrival. Configurable after go-live.
Contracts
- Contracts
- Counterparty, value, terms and retention. The feed into Committed.
- Change orders
- On the parent contract. Pending listed. Approved enters scheduled value.
- Payment applications
- The period claim. Approved enters completed and stored.
- Schedule of values
- Scheduled, completed, balance, retention. Drill to the source records.
- Workflows
- Separate paths for the application and the change. My Tasks holds the ball.
- Cost sheet
- Pending and approved columns. The SOV is not a second ledger.
See the full PMIS against your campus programme.
Your cost codes, your workflow, your campuses. Write sales@terraforge.build.