Should I Audit the Project or the Vendor? Wrong Question.

There is a question I hear surprisingly often: “Should we audit the project, or should we audit the vendor?”

My answer is simple: Yes. Both.

Auditing the project without looking closely at the vendor can leave an enormous hole in your understanding of what is really happening. On the other hand, auditing the vendor without understanding the project can give you a beautifully detailed review of invoices, rates, and contract compliance without answering the bigger question: Are we actually getting what we paid for?

This becomes even more important when the same vendor is working on multiple projects for your organization. At that point, you are no longer simply asking whether an invoice is accurate. You need to know whether the costs are accurate and whether they have been charged to the right place (and only charged ONCE).

Welcome to one of my favorite audit dilemmas, where the correct answer isn't either/or. It is both.

Meet the Project

Let's say your organization is implementing a shiny new technology platform. The project was approved at $8 million. Nine months later, the forecast is $11.4 million, the completion date has moved twice, change requests are multiplying, and people keep using the phrase “unexpected complexity.”

“Unexpected complexity” is one of those wonderful project phrases that can mean anything from “we genuinely discovered something nobody could have reasonably anticipated” to “something has gone sideways and we'd rather not discuss it just yet.”

Internal Audit decides to review the project. Excellent.

You look at governance, budget, schedule, risk management, change control, reporting, resources, decision-making, and benefits realization. You interview the project manager, examine steering committee minutes, review the risk register, and try to determine whether those beautiful green dashboard indicators bear any resemblance to what is actually happening.

Eventually someone says, “Well, a lot of the delays and cost increases are really coming from the vendor.”

Ah.

Hello, Vendor. We've been expecting you.

Now Meet the Vendor

Our vendor won the contract after promising experienced resources, an aggressive implementation schedule, and enough expertise to make the entire project sound practically effortless.

That was during the sales presentation.

Sales presentations are magical places. Everything is possible. Timelines are achievable. Integration will be seamless. Every risk has been anticipated. The proposed team appears to contain twelve people who have each implemented this exact system approximately 400 times.

Then the contract gets signed.

Somehow, several of those people disappear into the mist. The A-Team introduced during procurement becomes a somewhat different team during delivery. Additional resources are needed, invoices start containing descriptions such as “professional services,” schedules begin slipping, and change requests start reproducing like rabbits.  I like to call this "Promise the President, Deliver the Intern"

The project team may say, “That's a vendor issue.”

Maybe. But the vendor is delivering your project. There isn't an invisible wall separating vendor performance from project performance.

A Project Audit and Vendor Audit Answer Different Questions

A project audit looks at the health of the overall mission. We want to understand whether objectives remain clear, governance is working, risks are being managed, the schedule is realistic, costs are controlled, changes are properly evaluated, and management is receiving accurate information.

Most importantly, we want to know whether the organization is still likely to receive the outcome it originally expected.

A vendor audit zooms in on a different part of the picture. Now we are asking whether the vendor is actually doing what it promised to do and whether we are paying what we agreed to pay.

That may include reviewing:

• Contracted versus billed labor rates and labor categories.

• Hours charged and the supporting documentation.

• Whether named or key personnel are actually performing the work.

• Subcontractor usage, approvals, and markups.

• Travel, expenses, materials, and other reimbursable costs.

• Achievement of milestones, deliverables, and service levels.

• Change orders and the underlying reasons for them.

• Compliance with contract terms and payment provisions.

• Credits, rebates, discounts, and other amounts due back to the organization.

And here's one I particularly enjoy asking: Are we paying the vendor to fix problems the vendor created?

That question can make a meeting become remarkably quiet.

One Vendor, Five Projects...Now What?

This is where things get really interesting.

Suppose Vendor Wonderful isn't working on just one project for your organization. They're working on five.

Perhaps they have different teams assigned to each project. Perhaps some specialists float between projects. Maybe the same project manager oversees several engagements. Perhaps one master services agreement covers everything, while separate statements of work establish different rates, budgets, deliverables, or billing arrangements.

Now your audit risk has changed.

You don't just need to ask “Is this charge valid?”

You also need to ask “Is this charge valid for this project?”

Imagine a consultant works eight hours on Project A but accidentally charges the time to Project B. That may be an innocent coding error, but Project A is now understated and Project B is overstated. Management is making decisions using inaccurate project costs.

Now imagine that the consultant charges those same eight hours to both Project A and Project B.

That's an entirely different conversation.

If you audit only Project A, the eight hours may look perfectly legitimate. If another audit team reviews Project B six months later, those eight hours may also look perfectly legitimate.

The problem becomes visible only when someone looks across the vendor relationship.

Duplicate Billing Doesn't Always Look Like a Duplicate Invoice

When auditors hear “duplicate payment,” we sometimes picture Invoice 12345 being paid twice. That's certainly worth testing, but duplicate billing can be much more subtle.

When a vendor serves multiple projects, consider whether:

• The same employee is charging overlapping hours to different projects.

• The same travel expense has been allocated to multiple engagements.

• A subcontractor cost appears under more than one project.

• The same deliverable is being billed separately under different statements of work.

• Shared administrative costs are being allocated inconsistently.

• Labor charged directly to a project is also included in an overhead or management fee.

• Costs moved from an over-budget project into one with available budget.

• Credits associated with one project are applied elsewhere, or never applied at all.

Individually, each invoice may pass your audit test.

Collectively, the invoices may tell a very different story.

This is one of the strongest arguments for occasionally auditing the vendor relationship across projects, rather than limiting every review to individual project silos.

The Change Order Bermuda Triangle

Change orders are another reason the project and vendor audits need to speak to each other.

A project audit may tell you that change orders are driving the budget overrun. A vendor audit may help you understand why.

Perhaps the original scope was poorly defined. That's a project governance issue. Perhaps the vendor underestimated the work. That's potentially a vendor performance issue. Perhaps management continually changed requirements. Back to the project.

Perhaps the vendor submitted an aggressive original bid and is now recovering margin through changes. Back to the vendor.

Or perhaps nobody can determine exactly why the change was necessary because the documentation consists of three emails, a meeting nobody minuted, and someone saying, “I'm pretty sure we agreed to that.”

Welcome back to governance.

This is why separating project risk from vendor risk can create such an incomplete picture. The risks don't politely stay in their assigned audit scopes.

Who Actually Owns the Problem?

Suppose the project is six months late.

The vendor says the client didn't provide requirements on time. The project team says the vendor didn't ask the right questions. The vendor says there were too many scope changes. Management insists those weren't scope changes; they were “clarifications.” The vendor says it was waiting for approvals. Management says the submissions weren't complete enough to approve.

And somewhere in the middle sits Internal Audit with a cup of coffee wondering whether it's too early to add something stronger.  His neck cramped from bounces back and forth from this tennis match dialogue.

This is where evidence matters more than blame.

Look at the contract. Look at the project plan. Determine who was responsible for each activity, when deliverables were submitted, when decisions were required, when they were actually made, what changed, who authorized the change, and what the change ultimately cost.

Once you connect those pieces, the audit stops being a debate between two parties and starts becoming an examination of what actually happened.

Please Read the Contract

If you are auditing a major project involving an external vendor, please don't leave the contract sitting in Procurement gathering dust.

The contract isn't merely a procurement document. It is part of your audit criteria.

Among other things, determine:

1. What exactly did the vendor promise to deliver?

2. What resources, qualifications, and labor categories were specified?

3. What rates, markups, and reimbursable expenses were agreed?

4. What are the acceptance criteria for deliverables?

5. What happens when milestones or service levels are missed?

6. What documentation must the vendor maintain?

7. Can subcontractors be used, and under what conditions?

8. What audit rights does your organization have?

9. What are the invoicing and cost-allocation requirements?

10. Does the contract address how shared resources and expenses across multiple projects should be handled?

Then ask one of my favorite questions: Does the project team actually know what's in the contract?

You might be surprised by the answer.

Follow the Invoice Trail Across Projects

Vendor invoices are not simply pieces of paper waiting to be approved. Collectively, they are data, and that data can tell quite a story.

If a vendor is working on multiple projects, don't necessarily analyze each project in isolation. Consider combining the billing data and looking across the entire vendor population.

You may suddenly see things that were invisible at the individual project level: an employee apparently working 19 hours in one day (my record so far is the architect who routinely worked 32 hours EACH day), travel appearing on two projects during the same week, identical descriptions across different invoices, suspiciously similar amounts, or resources consistently charging right up to project budget limits.

You might also discover something less sinister but equally important: your project accounting is wrong.

If Project A is absorbing Project B's costs, management may incorrectly conclude that one project is failing while another is performing beautifully. Forecasts become distorted. Earned value calculations can become misleading. Business cases become unreliable. Future budgets may be based on bad historical information.

Accurate billing isn't simply an Accounts Payable issue. It affects project governance and decision-making.

And Then There Is Fraud

Major projects create an attractive environment for fraud because they combine large amounts of money, complicated contracts, multiple parties, specialized technical language, changing scope, subcontractors, change orders, emergency work, and tremendous pressure to keep things moving.

When a $200 million project is already late, a questionable $75,000 charge can suddenly feel insignificant.

It isn't.

It may be telling you something.

Fraud often hides inside complexity. A questionable vendor charge can look like a project issue. A project failure can look like poor vendor performance. A vendor performance problem can generate change orders. A change order can create opportunities for inflated pricing. Multiple projects can provide opportunities to shift or duplicate costs.

Everything connects.

So Which One Should You Audit First?

Here's where I'll give the frustrating auditor answer: It depends.

If a project is experiencing major cost overruns, schedule delays, governance problems, or repeated changes, I would probably begin with the project and follow the evidence into the vendor relationship.

If you're seeing questionable billing, unusual rates, unexplained subcontractors, repeated change orders, or concerns about vendor performance, I might begin with the vendor and work outward into the projects.

But if that vendor is performing significant work across multiple projects, I would seriously consider adding a cross-project vendor review. Looking at the vendor holistically can identify patterns that no single project audit will ever see.

Your audit scope might begin in one place. Your thinking shouldn't end there.

Stop Asking Either/Or

Instead of asking, “Should we audit the project or the vendor?” ask:

“Where is the risk, and how far does it travel?”

If it crosses from project governance into vendor management, follow it. If it crosses from vendor invoices into change management, follow it. If it moves from schedule delays into contract performance, follow it. If it travels across three different projects through the same vendor, follow that too.

And if someone says, “That's outside the scope of this audit,” perhaps they're right.

Or perhaps you've just discovered exactly where the next audit needs to begin.

Audit the Relationship, Not Just the Pieces

Projects and vendors don't operate independently. They create a relationship.

The project depends upon the vendor to perform. The vendor depends upon the organization to provide information, approvals, access, and decisions. Contracts establish responsibilities. Governance establishes accountability. Invoices reflect activity. Changes reflect reality.

When a vendor works across several projects, those relationships overlap even further.

Somewhere in all of that sits the question Internal Audit should really be asking:

Are we getting the outcome we expected, at the price we agreed, from the people we trusted to deliver it, and are we absolutely certain we're only paying for it once?

You cannot always answer that by auditing the project.

You cannot always answer it by auditing the vendor.

Sometimes you need both.

So the next time someone asks, “Should we audit the project or the vendor?” smile, take another sip of coffee, and give them that wonderfully irritating auditor answer:

Yes.

LG3 helps professionals look beyond individual checklists and understand how risks connect. Because sometimes the most important audit finding is hiding in the space between two things everyone else is reviewing separately.