Process
Ticket to invoice reconciliation, step by step
Ticket to invoice reconciliation proves that every hour delivered either reached an invoice or was written off on purpose. It runs as four gates: ticket to time entry (was the work recorded), time entry to entitlement (which agreement covers it), entitlement to charge (did it produce a line), and charge to invoice (did that line go out). Anything failing a gate lands on an exceptions report with a named owner and a decision. Run it monthly before the invoice run, and weekly for the two gates that move fastest.
Kyslan finds the unbilled work in your own PSA, then writes the change order that bills it. First report free, read-only. Claim it back →
Why the gap exists
An MSP has a complete record of what it did and a complete record of what it charged, and no automatic connection between the two. Between the closed ticket and the sent invoice sit four separate human decisions, each of which can go wrong quietly:
- Whether to log the time at all.
- What to charge it to.
- Whether that produces a charge.
- Whether the charge makes it onto an invoice.
None of these failures produce an error. Each one produces an absence, and absences do not appear in reports. That is the whole problem in one sentence: you cannot review a list of the invoices you did not raise.
Reconciliation exists to turn those absences into a list.
The four gates
| Gate | Question | Failure | Owner |
|---|---|---|---|
| 1 | Did the work get recorded? | Closed ticket, no time entry | Service desk lead |
| 2 | What covers it? | No agreement, expired agreement, exhausted block | Account owner |
| 3 | Did it produce a charge? | Marked non-billable, wrong rate, no overage raised | Service desk lead |
| 4 | Did the charge go out? | Charge exists, no invoice line | Finance |
The gates are ordered deliberately. A failure at gate 1 makes gates 2 to 4 unanswerable for that ticket, so fixing gate 1 first is what makes the rest of the exercise meaningful.
Gate 1: ticket to time entry
The query: every ticket closed in the period with no time entry attached.
Cut by engineer and by ticket type. What the shape tells you:
- Concentrated on one engineer: a habit, fixable in one conversation.
- Concentrated on one ticket type: a workflow problem. Auto-close rules, monitoring alerts resolving themselves, or a type where closing does not prompt for time.
- Spread evenly: a cultural issue about when time gets entered, usually meaning it is reconstructed at the end of the week rather than logged as the work happens.
Some zero-time tickets are legitimate: automated alerts that cleared, duplicates, tickets merged into another. Exclude those types explicitly and by name in the query rather than mentally each month, or the report becomes noisy and stops being read. A report nobody reads is worse than no report, because it looks like coverage.
Gate 2: time entry to entitlement
The query: every time entry in the period, joined to the agreement or block it was charged against.
Four failures to flag:
- No agreement at all. Work for a client with nothing covering it.
- Agreement past its end date. Time recorded after the term ended.
- Block exhausted. Hours drawn against a zero or negative balance.
- Wrong agreement. Time charged to a managed services agreement when the work was clearly a project or out of scope. This is the hardest to detect automatically and the most common in absolute terms.
The fourth needs a proxy rather than a rule. Comparing the ticket's type and its summary against the agreement's scope wording catches most of it, and the remainder is caught by the volume signal: a client whose hours rose sharply against a flat contract value is absorbing something.
Gate 3: entitlement to charge
The query: every time entry with a valid entitlement, and whether it produced a charge.
Three checks:
- Billable flag. Non-billable hours grouped by ticket type, board and engineer. Look for a default set wrongly before you look at people.
- Rate applied. Out of hours work carries a timestamp, so premium rates are fully mechanical. Any entry outside contracted hours at the standard rate is under-billed by the difference.
- Overage. Retainer or prepaid periods where hours exceeded the allowance and no overage charge was raised.
Gate 4: charge to invoice
The query: every charge generated in the period, and whether it appears on an invoice that was actually sent.
Also check the reverse direction, which most reconciliations forget: recurring agreements that should have invoiced this cycle and did not. That failure produces no charge at all, so it is invisible to a charge-first query. List every active agreement, its cycle, and whether an invoice exists for the current period. A cycle of a real agreement is usually the single largest line on the whole exceptions report.
The exceptions report
One report, one owner per line, four columns that matter:
| Column | Contents |
|---|---|
| Evidence | Ticket numbers, dates, engineer, hours. Never a total on its own |
| Value | Annualised. A recurring gap priced monthly gets dismissed as small |
| Gate | Which of the four it failed, so the fix is obvious |
| Decision | Invoice, correct forward, or write off deliberately |
Write off is a legitimate decision and should be available on the form. What must never be available is leaving the line blank, because an undecided exception is functionally identical to a leak, and it is the state most exceptions end up in when nobody owns them.
Cadence and ownership
| Gate | Cadence | Why |
|---|---|---|
| 1. Ticket to time | Weekly | Memory fades. A ticket queried on Monday can still be reconstructed. One from six weeks ago cannot |
| 2. Time to entitlement | Weekly | Block balances move daily and go negative silently |
| 3. Entitlement to charge | Monthly, pre-invoice | Must be settled before invoices generate |
| 4. Charge to invoice | Monthly, post-invoice | Can only run once invoices exist |
Gate 1 weekly is the highest-value change most MSPs can make to this process, and it is the one most often set to monthly. The difference is not the query, it is that a ticket queried within a few days still has a recoverable answer.
Making it survive a busy month
Reconciliation processes die in exactly the same way every time: they are built with enthusiasm, run three times, and then a busy month arrives and nobody notices they stopped. Five things that keep one alive:
- The queries run themselves. Anything requiring a person to remember to run it will not survive a quarter.
- The report arrives in an inbox, addressed to a named person, on a schedule. Not a dashboard somebody has to visit.
- Exclusions are in the query, not in someone's head. Noise kills reports faster than inaccuracy.
- Every line has an owner and a decision field. No blanks allowed.
- The total is reported monthly to whoever runs the business. Found, recovered, written off. Three numbers. It takes one line in a board pack and it is the only thing that keeps the process funded.
If building and scheduling those queries is not something you want to own, that is precisely what Kyslan does: it runs all four gates against your PSA read-only, prices every exception, and re-scans weekly. See the sample report for what the output looks like, or read the full audit checklist if you would rather build it yourself.
Common questions
What is ticket to invoice reconciliation?
It is a repeatable check proving that every hour an MSP delivered either reached an invoice or was written off deliberately. It runs as four gates: whether the work was recorded as a time entry, which agreement or block covers it, whether that produced a charge, and whether the charge appeared on an invoice that was sent. Anything failing a gate becomes an exception with a named owner and a decision.
How do I find tickets closed with no time logged?
Query closed tickets in the period with no attached time entry, cut by engineer and ticket type. Exclude legitimate zero-time types such as automated alerts that cleared, duplicates and merged tickets explicitly in the query rather than mentally, or the report becomes noisy and stops being read. Concentration on one ticket type usually indicates a workflow problem rather than a person.
How often should ticket to invoice reconciliation run?
Weekly for the first two gates, recording and entitlement, because block balances move daily and a ticket queried within a few days can still be reconstructed from memory while one from six weeks ago cannot. Monthly for the charge gates, one immediately before the invoice run and one after it, since the final gate can only be checked once invoices exist.
Who should own MSP billing reconciliation?
Split by gate rather than giving it to one person. The service desk lead owns recording and billing flags, the account owner owns entitlement questions such as expired agreements and exhausted blocks, and finance owns whether a charge reached an invoice. Every exception line needs a named owner, because the state most exceptions end up in without one is undecided, which is indistinguishable from a leak.
Why do MSP reconciliation processes stop being run?
Because they depend on somebody remembering. The ones that survive have queries that run on a schedule, a report that lands in a named person's inbox rather than sitting on a dashboard, exclusions written into the query so the output stays clean, a decision field on every line, and a monthly total reported to whoever runs the business.
Keep reading
See your own number, then send the invoice for it
Kyslan reads 90 days of your tickets, time entries and contracts, finds the work you delivered and never billed, then writes the change order that puts it back on the invoice. Read only, nothing installed, first report free.
Claim it backFree · read-only key · no card · HaloPSA, ConnectWise Manage, Autotask PSA or a CSV export