BS Consulting Insights

How to Structure Autotask Contracts So Billable Work Never Falls Off Contract | BS Consulting

Written by Ben Spector | 10 Aug 2026, 22:23:00

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

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.

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.

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.

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

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

  1. Did the technician describe the work correctly?
  2. Did Autotask attach the contract you would expect?
  3. If the work was excluded, did it land on the intended fallback?
  4. Could finance understand why it is billable without rereading the whole ticket?
  5. 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.