# How to track actual costs against a fixed price statement of work Source: https://korrel.ai/blog/tracking-costs-against-a-fixed-price-sow Published: 2026-08-06 Updated: 2026-08-04 Topic: how to track actual costs against a fixed price statement of work Tags: cost-tracking, project-costs, change-control --- ## Key points - A fixed price SOW prices the work but never names the cost lines a delivery team has to watch. - Map every priced line item to one tracked category and one owner before delivery starts. - Licences and unplanned integration work are the two lines that drift first on IT services jobs. - Reconcile weekly so a variance becomes a change request while the client can still agree it. Tracking actual costs against a fixed price statement of work means converting the priced SOW into a cost ledger, then reconciling real spend against those lines while the job runs. Not at closeout. The SOW gets signed and the price stops moving. Nothing else about the job does. Time and materials never has this problem, because of how it bills. Every invoice is a reconciliation in itself: hours booked, rate applied, both sides reading the same number in the same week. A fixed price SOW gives you a total and a payment schedule instead. Nothing arrives monthly to check yourself against. So delivery teams find out what the job cost at closeout, which is roughly the point where the finding stops being useful. ## What does a signed SOW leave you to reconcile against? A priced scope, and very little else. Outcomes, in-scope and out-of-scope items, deliverables with acceptance checks, a KPI pack, change control, exit criteria: that is what a well-built [consulting SOW template](https://nmsconsulting.com/consulting-sow-template/) covers. All of it describes the work. None of it describes your cost base. So the document that defines the job says almost nothing about whether the job pays. Deliverables get acceptance criteria. Labour grades do not. The licence you pass through at cost sits in the commercial terms with no owner anywhere in delivery. Milestone payments confuse this further. Money moving on a date looks like a cost signal. It is only a statement of when the client pays. Bill 40% at design sign-off and you have banked 40% of the price. You may have burned 60% of the cost getting there, and nothing in the SOW will tell you which. Two numbers exist at signature. One is the price, and it is contractual. The other is the estimate underneath it, built by whoever priced the deal. That estimate is the only thing your actuals can be measured against. Firms do this analysis eventually. Working out [which implementation projects are actually profitable once licences and rework are counted](/blog/which-implementation-projects-are-actually-profitable) is a closeout exercise in most businesses. The ledger below is the same arithmetic, run forward instead of backward. ## How do you track actual costs against a fixed price statement of work? Convert the priced SOW into a cost ledger, then reconcile against it weekly. Four steps, and none of them need new software: 1. **Split the price into cost lines.** Labour by role, third-party licences, integration work, rework, expenses, contingency. Work from the estimate that produced the price, not from the price. 2. **Give each line a tracked category.** A timesheet code, a purchase order tag, an expense type. A cost with nowhere to land gets booked to "project" and stops being visible. 3. **Write the trigger beside each line.** Decide the variance that makes you act before anyone has a reason to be defensive about it. 4. **Name one owner per line.** Licences belong to whoever raises the purchase order. Interfaces belong to the technical lead. The ledger is not the estimate in a new font. It is the estimate rewritten so that a cost arriving on a Tuesday has exactly one place to go. ## Which SOW line items map to which tracked category? Each priced line needs a category and an owner. This mapping holds up on IT services delivery: | SOW line item | Tracked as | Drifts because of | |---|---|---| | Labour by role | Hours at internal cost rate, per grade | A senior doing a junior's work | | Third-party licences | Purchase orders against a named seat count | Seats added mid-delivery | | Integration and interfaces | Hours booked per named interface | An interface nobody counted | | Rework after acceptance | Its own category, never the deliverable's | Round two, then round three | | Travel and expenses | Receipts against the SOW allowance | Extra site visits | | Contingency | Drawn down explicitly, with a stated reason | Quiet absorption | Two rules make that table useful. Rework never gets booked against the deliverable it repairs, because a deliverable that took three attempts should not look identical on the ledger to one that took a single pass. Contingency is drawn, not absorbed. Spend it quietly and the ledger reports you as on budget right up to the week it cannot. ## Where do fixed price jobs leak money first? Licences and integration work, well before labour. Coderio's guide to [preventing project cost overruns](https://www.coderio.com/blog/software-development/strategies-to-prevent-project-cost-overruns/) makes the point plainly: extra integrations, additional reporting requirements and non-functional constraints expand the backlog long before anyone formally changes the budget. Interfaces are the worst of these. They get counted once, in a discovery workshop, and then discovered again in build. The SOW said "integration with the client's finance system". That finance system turns out to have a sandbox, a production instance and a middleware layer with its own authentication. Three interfaces, one priced line. Licences drift differently. Nobody tracks a renewal date on a delivery plan. Seat counts get agreed verbally in week two and ordered in week five. Then they are invoiced to you in full, whether or not the client ever agreed to pay for the extra seats. Rework is the third line, and it is the one nobody wants to name. A deliverable comes back from acceptance testing with fourteen comments. The team clears them, because clearing them is quicker than arguing about which ones were in scope. Those hours get booked to the original deliverable. Nothing in the ledger moves. Six weeks later the same deliverable comes back a third time, with no record anywhere that the first two rounds happened. A separate rework category costs nothing to create and turns that pattern into a number you can put in front of the client. One narrower point is worth borrowing from BigTime's guide to [selling fixed-price projects profitably](https://www.bigtime.net/blogs/fixed-price-projects/). Build the cost side from the wages and rates of the people who will actually be assigned, rather than from blended rates. Blended rates hide grade substitution. Your ledger should not. ## When does a variance become a change request? When the cause sits outside the scope you priced, and you can name the clause it falls outside of. That is the whole test, and it is the trigger for [a change request process for a fixed price implementation project](/blog/change-request-process-fixed-price-projects): once you can name the clause, price the change and get it approved before the team builds it anyway. A labour line running hot because your team is slower than the estimate is not a change request. That is a delivery problem, and the client is not paying for it. A line running hot because the client's ERP has three interfaces where the SOW named one is a change request. It stays one only while the work is still ahead of you. Set thresholds per line, not per project. A 10% overrun on labour and a 10% overrun on licences are different events with different fixes. One project-level tolerance hides both until they are large. Add 10 to 25% headroom on any line where the client controls the dependency. Weekly reconciliation surfaces both problems. The leading indicators that tell you [a fixed-price job is losing money before it finishes](/blog/job-losing-money-before-it-finishes) are exactly the ones that make a change request timely rather than awkward. ## What does the weekly reconciliation involve? Four questions per line, answered in order. None of them require a finance system. - **What was booked this week?** Hours, purchase orders, expenses, against the category and no other. - **What is the line at now, as a percentage of what was priced?** Spent against planned, not spent against remaining. - **Is the burn ahead of the delivery?** A licence line at 90% with two months of delivery left is a variance, whatever the total says. - **Does anything cross a trigger?** If it does, name the owner and the date, then write the change request or the recovery action the same week. Four numbers and a sentence. Keep them on the same page every week so the trend is readable at a glance. Recovery actions and change requests both get harder to raise the longer they sit. A partner who has been quietly absorbing an interface for six weeks has already conceded it. ## What does weekly reconciliation buy you? Time. A licence overrun found in week three is a conversation with a client who has not yet spent the budget. Found at closeout, the same overrun is a discount request dressed up as an invoice query. Those get granted. There is a number attached to this. The 2026 Professional Services Maturity Benchmark from SPI Research and Rocketlane [reports revenue leakage at a five-year low of 4.5%](https://www.rocketlane.com/blogs/professional-services-maturity-index-2026), with high-performing organisations at 3.6% against 4.8% for everyone else. Those rates are organisation-wide. Applied to a $400,000 SOW, the distance between the two groups is $4,800 of delivered work that nobody bills. Leakage is not one dramatic write-off. It is a seat here, a rework round there, an interface built because arguing about it felt more expensive than building it. ## What to do on the next SOW you sign Take the SOW currently sitting with your commercial team. Open the estimate behind it. Copy the cost lines into a sheet with four columns: line, category, owner, trigger. That is the ledger. Half an hour of work, and it has to exist before kickoff, because a category invented in week six cannot collect the costs from weeks one to five. Then book one week against it. Friday afternoon, twenty minutes, every line reconciled to actuals with a variance and a reason. The first Friday will tell you which categories nobody can fill in. Those gaps are the real finding. ## Common questions ### What is a cost ledger for a fixed price SOW? A cost ledger is the priced SOW rewritten as cost lines you can book real spend to. Labour by grade, licences, integration work, rework, expenses and contingency each get a category and an owner. The price stays contractual. The ledger is internal. It is the only thing your actuals can be compared with once the document is signed. ### How often should you reconcile actuals against a fixed price SOW? Weekly, on a fixed day, for the whole delivery. Monthly is too slow on a three-month engagement, because a licence overrun or a second integration interface can absorb a month of margin before anyone opens the report. The reconciliation itself takes about twenty minutes once the categories exist. ### What if the SOW has no cost breakdown at all? Build the ledger from the estimate that produced the price, not from the SOW. The client never needs to see it. What matters is that each internal cost line ties back to something the SOW promised, so a variance can be traced to a clause when you raise the change request.