Running fixed-price projects in Autotask without billing late
Fixed-price projects are good business for an MSP that delivers well. The client gets certainty, you get paid for knowing how long a migration really takes, and a well-run project earns more than the same work billed by the hour.
They are also where cash quietly goes missing. Not through overruns, which everyone watches, but through billing late: the stage is finished, the team has moved on, and the milestone sits unbilled for weeks because nobody owned the moment it became billable.
This is a practical guide to running fixed-price work in Datto Autotask so that milestones go out on time. Most of it is process. The PSA holds the records (contracts, contract milestones, project tasks and project charges); the discipline is in how you use them.
Design the billing plan when you write the quote
Late billing starts at the quote. A statement of work that says “50% on commencement, 50% on completion” leaves two questions open: what counts as commencement, and who decides completion?
Write the billing plan at the same time as the scope, and give every milestone three things:
- An amount, as a share of the contract value or a fixed figure.
- A trigger that is a fact, not an opinion. “Kick-off meeting held” or “the 1st of next month” is a fact. “Phase 2 substantially complete” is an argument.
- A link to the plan. The trigger is either a date, or a specific task in the project plan reaching done.
A common shape for an MSP infrastructure project:
| Milestone | Share | Trigger |
|---|---|---|
| Deposit | 30% | A date: the agreed start date |
| Build complete | 40% | A task: “Build signed off by client” is done |
| Go-live and acceptance | 30% | A task: “Client acceptance received” is done |
The acceptance task matters. If the final payment waits on a client signature, make getting that signature a task with an owner and a due date, not something that happens to you.
Make the trigger visible to the people doing the work
The engineer who finishes the build does not think about billing, and should not need to. What they do think about is moving their task to done. If the milestone’s trigger is that task, billing follows the work automatically, and the person who needs to know (the project manager, or whoever raises invoices) can see it.
In Autotask terms, the project should be linked to the contract the milestones live on from the start. A project that is not on a contract is a project whose fixed-price billing will be done by hand, which in practice means late.
Separate “ready to bill” from “billed”
A milestone moves through three states that are worth keeping distinct:
- Planned: agreed in the billing plan, trigger not yet reached.
- Ready to bill: the trigger has fired. The work is earned.
- Billed: it has been on an invoice.
The gap between ready and billed is your billing lag, and it is the number to watch. A healthy fixed-price practice keeps it to days. If milestones routinely sit ready for weeks, the problem is not delivery, it is the handover between delivery and billing.
Run a weekly billing check
Fifteen minutes, once a week, with whoever owns project billing:
- Triggers passed, not yet ready. Any milestone whose date has passed or whose task is done, still marked planned. Fix the status, or find out why the trigger fired early.
- Ready, not yet billed. Anything in this list older than your normal billing cycle is lag.
- Next two weeks. Milestones whose triggers are coming up, so nobody is surprised.
- Unbilled costs. Hardware, licences and travel bought for the project that have not become project charges.
Add up the planned, ready and billed amounts by month and you also have the most useful revenue forecast in the business: fixed-price income you have already won, by the month it will land.
Watch the budget, not just the billing
Billing on time protects cash. Margin is protected by the budget. For fixed-price work that means tracking, by phase:
- Actual: approved time at cost, plus approved costs.
- Forecast at completion: actual, plus the remaining estimate on open tasks.
- Variance: budget less forecast.
The moment to act is when the forecast passes about 90% of budget with work still open. That is early enough to raise a change request for the extra scope the client asked for in week three, and early enough to have the conversation while the client still remembers asking.
Handle change requests as new milestones
When scope changes, resist the urge to absorb it. Price the change, get it agreed, and add it to the billing plan as its own milestone with its own trigger. Folding it into an existing milestone hides it, and hidden scope is how fixed-price projects end up with a healthy margin on paper and a thin one in reality.
Don’t forget the costs
Fixed price usually means fixed labour, not fixed everything. If the statement of work says hardware, licences or travel are billed at cost, each purchase should become a project charge the day it is approved. Costs left until the end of the project are the costs that never get billed.
Where ProjectSmith fits
ProjectSmith runs this process on your Autotask data. Each project has a budget by phase with burn, forecast and variance, and a billing plan whose milestones trigger on a date or when a task is done. When a trigger fires, ProjectSmith marks the milestone ready to bill on the project’s Autotask contract, so your normal Autotask billing run picks it up. Approved costs become Autotask project charges. Read more about fixed-price project billing in Autotask, or the related piece on where MSP project margin leaks.