Common mistakes when auditing IT and professional services

Executive Summary

IT and professional services invoices fail review for a narrow set of reasons that repeat across vendors: the reviewer matches the invoice to the purchase order instead of the statement of work, treats a milestone payment as self-certifying, and never rebuilds the true-up math behind an annual license reconciliation. None of these are visibility problems. The contract terms exist.

The invoice line items exist. What is missing is the step that puts them side by side.

The fix is not more scrutiny in general, it is a fixed list of fields to pull from the contract before the invoice is approved: the rate card by role, the milestone acceptance criteria, the true-up formula and its inputs, and the SLA credit schedule. A reviewer who pulls those four things before opening the invoice catches most of what this page describes.

What follows is that list, organized by where the mismatch actually occurs: rate application, milestone billing, license true-ups, change orders, and SLA credits. Each section names the specific document to pull and the specific comparison to make.

1. Why does a purchase order match still let a wrong invoice through?

A purchase order match confirms the invoice total sits within an approved dollar amount. It does not confirm the rate applied per resource, the role classification billed, or whether the hours billed map to a deliverable. An invoice can match its PO exactly and still bill a senior consultant's rate for work performed by a junior one, or bill hours against a phase never started, and the PO match will not catch either.

Three-way matching checks the invoice against the purchase order and the receipt of goods or services. For a hardware line item, receipt is unambiguous. For a consulting hour, receipt is whatever the approver signs off on, and the approver usually works from the invoice total, not the underlying rate table.

The check that closes this gap is a role-by-role rate comparison: pull the rate card from the master service agreement, list the role titles and their contracted rates, then match each line item's billed role and rate against that table. A title mismatch, a rate that has crept up without a corresponding contract amendment, or a blended rate applied where the contract specifies role-based rates are all visible at this step and invisible at PO match.

The same gap applies to expense pass-throughs. A PO match confirms the total is within budget. It does not confirm travel was billed at cost, as most contracts require, rather than with a markup the contract does not authorize.

What a PO match confirms versus what it misses on a services invoice.

2. What should you check before approving a milestone payment?

Pull the acceptance criteria written into the statement of work before the invoice arrives, not after. A milestone invoice should reference a specific deliverable and a specific completion date. Compare both against the SOW's defined milestone, not against the vendor's own description of what was completed, and confirm any partial deliverable is billed as a percentage the contract actually permits rather than a full milestone fee for partial work.

A statement of work usually defines milestones as concrete deliverables tied to acceptance criteria: a signed-off design document, a completed data migration, a system passing a specific test. The invoice, in practice, often just names the milestone and bills the full associated fee.

The review step this needs is a written acceptance record, independent of the invoice, confirming the deliverable actually met the SOW's criteria on the date claimed. Without that record, the business is paying on the vendor's assertion rather than its own confirmation.

Watch specifically for milestone payments billed ahead of the contracted trigger, for a milestone split into partial payments the SOW did not structure that way, and for a deliverable rejected in one cycle and rebilled without documented remediation in the next.

A. Fields to pull from the SOW

The milestone name and number as defined in the SOW, the acceptance criteria attached to it, the fee associated with that specific milestone, and any dependency on a prior milestone's sign-off. All four should be checkable against the invoice line by line, not inferred from the invoice's own labeling.

3. How do software true-up invoices get approved without a recount?

A true-up invoice bills for usage growth against a license baseline, and the annual bill is accepted at face value because reconstructing the count requires pulling deployment records the AP team does not hold. The check that closes this is matching the vendor's claimed user or unit count against your own license management or HR system for the same period, not against the vendor's prior invoice.

A true-up calculation has three inputs: the baseline count from the last reconciliation, the current count the vendor is claiming, and the contracted per-unit rate for the increment. Most true-up review only checks that the rate applied is correct. It does not independently verify the count.

The count is verifiable against internal records: active user counts in an identity management system, device counts in an asset register, or seat counts against actual headcount for role-based licensing. A vendor's true-up count that runs materially ahead of your own internal growth for the same period is a discrepancy worth a formal request for the vendor's counting methodology.

A related and separate check: true-up invoices should apply the rate tier the contract specifies at the new volume level, not the rate tier from the original baseline, if the agreement includes volume-based pricing.

• Baseline count source: Confirm it matches the count agreed at the last true-up, not a number the vendor is asserting fresh this cycle.
• Current count source: Cross-check against your own identity management, asset register, or headcount system for the same period.
• Rate tier applied: Confirm the contract's volume tier for the new count, not the tier from the prior baseline.
• Proration: Confirm any mid-term additions are prorated for the period actually used, not billed a full annual fee from the true-up date.

4. Which change order terms get missed when scope shifts mid-engagement?

A change order should restate the rate card and payment terms already in the master agreement, but many are drafted as a standalone document with its own rate language, and a reviewer approving the change order on scope alone can miss a rate that no longer matches the MSA. The check is confirming every change order explicitly references and inherits the MSA's rate and payment terms rather than setting new ones silently.

A change order exists to modify scope: add a deliverable, extend a timeline, add resources. It should not be the vehicle for changing commercial terms, but in practice a vendor-drafted change order sometimes carries a new rate, a new payment schedule, or a new expense policy embedded in its boilerplate.

The review step is reading the change order's commercial terms section independently of its scope section, and flagging any rate, payment term, or expense policy that differs from the MSA it is supposed to sit under. If a rate change is genuinely intended, it should be documented as an amendment to the MSA, not buried in a change order meant to cover added scope.

A second, related check: confirm the change order's added hours or deliverables do not overlap with work already billed under the original SOW. Overlapping scope billed twice, once under the original SOW and once under the change order, is a duplicate charge that a scope-only review will not surface.

A. Where to check

Read the change order's payment terms, rate table, and expense clause against the MSA's equivalent sections. Any deviation should carry its own written justification, separate from the scope justification, because scope change and commercial change are two different approvals even when one document covers both.

5. How do SLA credits get missed on IT services invoices?

An SLA credit is owed when a vendor misses a defined performance threshold, but most contracts put the burden of claiming it on the client, not the vendor. If nobody tracks the SLA metrics against the invoice period and files the credit claim within the contract's claim window, the credit expires unclaimed and the invoice is paid at full rate for degraded service.

The mechanics: an MSA or SOW defines a service level, such as response time or uptime, and a credit schedule tied to specific breach thresholds. The vendor is rarely obligated to self-report a breach. The client is obligated to notice it and file a claim, usually within a stated number of days of the invoice period closing.

The check this needs is a standing comparison between the vendor's own performance reports, where they exist, and the SLA thresholds in the contract, run before the invoice for that period is approved rather than after the claim window has closed.

Where the vendor does not proactively supply performance data, request it as a condition of invoice approval. A vendor unwilling to supply the data the contract's own SLA depends on is itself worth flagging to the contract owner.

6. What does a full IT and professional services invoice review actually require?

A complete review pulls four documents before opening the invoice: the rate card by role, the SOW's milestone and acceptance criteria, the true-up formula and its baseline count, and the SLA credit schedule with its claim window. Matching the invoice against all four, rather than against the purchase order alone, is what separates a review that catches drift from one that only confirms the total.

None of the checks above require new software or a new approval workflow. They require pulling the underlying contract terms into the same review step where the invoice is currently matched only to its PO or budget line.

The volume of IT and professional services spend at a company above $100M in revenue makes manual, line-by-line matching hard to sustain past a handful of vendors. That is a resourcing problem, not a reason to skip the checks. Where the checks are not run at all, the invoices above pass at face value regardless of what the underlying contract says.

A structured review of this category, applied retrospectively across a year or more of invoices, is exactly the kind of audit that surfaces recoveries a routine AP process was not built to catch.

1. Pull the rate card: Match role and rate on every line item, not just the invoice total.
2. Pull the SOW milestones: Confirm acceptance criteria were independently met before paying a milestone fee.
3. Pull the true-up formula: Verify the count against internal records, not the vendor's prior invoice.
4. Pull the SLA schedule: Check performance against thresholds before the claim window closes.

For the wider pattern this sits inside, start with the margin drift guide.

7. Frequently Asked Questions (People Also Ask)

What is the single most checkable mistake on an IT services invoice?

Matching the invoice to the purchase order total instead of the rate card by role. A PO match confirms the amount is within budget. It does not confirm the rate or role billed matches what the master service agreement specifies for that resource.

How do I verify a software true-up count without vendor cooperation?

Cross-check the vendor's claimed count against your own identity management system, asset register, or headcount records for the same period. A material gap between your internal count and the vendor's claimed count is grounds for requesting their counting methodology.

Can a change order legally alter rates set in the master agreement?

This is a contract interpretation question specific to your agreement's language, and this is general information, not legal advice. Operationally, treat any rate change in a change order as a flag requiring its own review, since change orders are meant to modify scope, not commercial terms.

Who is responsible for claiming an SLA credit, the vendor or the client?

Most master service agreements place the burden of claiming an SLA credit on the client, within a stated window after the invoice period closes. The vendor is rarely obligated to self-report a missed service level.

What documents do I need before reviewing a milestone invoice?

The statement of work's defined milestone name, its acceptance criteria, the fee tied specifically to that milestone, and any dependency on a prior milestone's sign-off. Compare the invoice against these fields rather than the vendor's own description of completion.

Does a signed statement of work protect against overbilling automatically?

No. A signed SOW defines the terms that should govern billing, but it does not enforce itself. Someone still has to compare each invoice's rates, roles, and milestones against the SOW's specific language, invoice by invoice.

How often should true-up formulas be reverified?

Each time a true-up invoice is issued, since the formula depends on a current count that changes every period. Reverifying only at contract renewal misses interim true-ups billed on an uncorrected baseline.

What is the difference between a rate card audit and a true-up audit?

A rate card audit checks that the price per role or unit matches the contract. A true-up audit checks that the quantity being billed, such as license seats or usage volume, matches what was actually deployed or used. Both matter, and neither substitutes for the other.

Should expense pass-throughs on consulting invoices be audited separately?

Yes. Expense line items typically carry their own contract terms, such as billing at cost with no markup, that a rate card review does not cover. Treat expense pass-throughs as a distinct check within the same invoice review.