%20-%20Cropped.png?width=135&name=BS%20Consulting%20Logo%20-%20White%20(Transparent%20Background)%20-%20Cropped.png "BS Consulting Logo"){kind=logo}
%20-%20Cropped.png?width=160&name=BS%20Consulting%20Logo%20-%20Blue%20(Transparent%20Background)%20-%20Cropped.png "BS Consulting Logo"){kind=logo}
One of the most common Autotask billing problems I see is legitimate work ending up with no deliberate contract path. A technician records the work correctly, but the time sits off contract, someone removes a contract manually, or finance has to decide afterwards whether it should have been included.
The fix is not another billing checklist. It is contract architecture that gives normal managed work, exclusions and genuine time-and-materials work an intentional route.
The operating principle
Let the contract structure make the commercial decision
The technician should primarily describe the work. The contract structure should make the commercial decision wherever possible.
If technicians have to decide whether a time entry is commercially included every time they work a ticket, too much billing logic lives in human memory.
A simple managed-service structure
Why off-contract work is dangerous
An off-contract time entry is ambiguous. It may be intentionally billable, incorrectly configured, missing a contract, or the result of a technician choosing the wrong work type.
That ambiguity pushes a commercial decision downstream into Approve & Post, often weeks after the work happened. The reviewer has to reconstruct context from the ticket and decide what the technician or account manager meant.
- Billable work can be missed.
- Included work can be charged incorrectly.
- Finance spends time interpreting tickets.
- Technicians learn inconsistent workarounds.
- Profitability reporting becomes harder to trust.
Managed-service clients still need a billable fallback
A managed-service agreement rarely includes every possible type of labour. Project work, after-hours activity, site visits, third-party coordination or specialist tasks may sit outside the recurring agreement.
If those exclusions simply remove the managed-service contract, Autotask can leave the work without a controlled billing container. A deliberate T&M fallback contract gives excluded work somewhere to go.
Part of the managed-service design
It does not turn the client into a T&M client. It provides a controlled destination for work that the managed-service agreement excludes.
True T&M clients are different
A client whose normal support model is time and materials should usually route directly to a T&M contract. That may look similar in Autotask to an exclusion fallback, but the commercial meaning is different.
| Contract path | What it means | Review mindset |
|---|---|---|
| Managed service | Normal covered work is included in recurring fees. | Look for exceptions or incorrect work classification. |
| Managed-service exclusion to T&M fallback | The client is managed, but this specific work is outside scope. | Confirm the exclusion and billing rule are appropriate. |
| True T&M client | Labour is normally billed as used. | Review completeness, rates, minimums and invoice presentation. |
Keeping those categories distinct makes reporting and billing review easier even if both ultimately generate chargeable labour.
Exclusions should be designed as a path
An exclusion is not merely a list of things the client does not get. In Autotask it can be part of the routing logic that determines which contract picks up the work.
For example, a managed-service contract may include normal remote support but exclude scheduled on-site work. The exclusion should send that activity to the agreed billable fallback rather than relying on the technician to remove the contract or finance to notice it later.
Work types are part of the architecture
Contract logic only works when technicians can describe the activity consistently. Work types should therefore represent business rules, not an uncontrolled list of labels.
Describe the activity, then let the rules work
A useful work type tells the system enough to make a predictable decision.
- Remote or on-site
- Normal-hours or after-hours
- Support, project or another defined class of work
- Any special minimum or billing increment where the commercial model requires it
The fewer commercial judgements technicians have to make, the more consistent the data becomes.
Where recurring services fit
Recurring services usually belong on the contract that represents the revenue stream they relate to. That could be a managed-service contract, a separate licence contract, or another deliberate billing container.
The same principle applies to exclusions. If a SaaS or service exclusion needs to fall back to T&M, the fallback should be explicit. The important point is that the contract family works as one system rather than a collection of unrelated records.
What I normally check in an Autotask contract review
- Every active client has the expected billing path.
- Managed-service contracts include the intended work types.
- Exclusions have deliberate fallback destinations.
- True T&M and excluded T&M can be distinguished.
- Rates, minimums and increments are applied predictably.
- Recurring services sit on the correct contract type.
- Contract categories support useful billing review and reporting.
- Unusual agreements are explicitly flagged for careful review rather than hidden in the normal process.
Automate the normal, review the unusual
The goal is not to eliminate billing review. It is to stop the reviewer spending time on decisions the system could already have made.
A well-structured Autotask environment lets normal covered work flow to the managed contract, normal T&M work flow to the T&M contract, and excluded managed work flow to its fallback. The pre-billing process can then focus on genuine exceptions: unusual agreements, unexpected quantities, incorrect classifications or work that does not fit the model.
A practical test
- Did the technician describe the work correctly?
- Did Autotask attach the contract you would expect?
- If the work was excluded, did it land on the intended fallback?
- Could finance understand why it is billable without rereading the whole ticket?
- Would the same type of work follow the same path next month?
If the answers vary by technician or reviewer, the architecture is still relying on people to compensate for the configuration.
Related reading
Need to fix the contract paths?
If Autotask regularly leaves legitimate time off contract or your team has to decide billing treatment manually, I can help map the contract, exclusion and work-type rules before changing the configuration.