Cost of Getting Paid, Part 1: “Three Months.”
“Everything’s fine. We just haven’t been paid in three months.”
It sounds ridiculous when you say it out loud.
And yet, in construction, we operate this way all the time. The project is moving. The work is getting done. Pay applications are being reviewed. Everyone is doing something. Meanwhile, the contractor is still waiting to get paid.
This is Tim’s story.
In Part One of The Cost of Getting Paid, we’re going to investigate how that happens—and use it to explore ownership, responsibility, and accountability when the outcome belongs to everyone, but no single person controls the process.
So as you read, don’t just ask what Tim did wrong. Think about your own pay applications.
Is everything functioning as expected, but your contractors still aren’t getting paid on time?
When “Fine” Isn’t Fine
Your CEO calls you into their office.
They just got off the phone with one of your contractors. The project came up.
Then they said:
“Everything is fine. We just haven’t been paid in three months.”
Three months.
Your CEO wants to know what is going on.
You know Tim is the project manager. And you know Tim is busy.
You know there have been issues with this contractor’s pay applications. You know there are funding complications. You know some invoices are moving while others have gone back for corrections. And you know invoicing is only one part of Tim’s job.
None of that is new information.
But until someone says, “We haven’t been paid in three months,” you haven’t added it all up.
The CEO sees the consequence: a contractor hasn’t been paid for an entire quarter.
The contractor sees its invoices.
Finance sees what reaches Finance.
Tim sees the pile in front of him.
But you are Tim’s director. You have a view across his portfolio that none of them have.
And somehow, with that view, you still didn’t see this.
What you didn’t understand was what all that work was producing.
Three months.
Suddenly, all those conversations about corrections, funding, reviews, and pay applications sound different.
“Now Director, What did you think was happening to all this work?”
Your CEO wants to talk to Tim.
You understand why. Maybe Tim missed something. Maybe he should have escalated sooner. Maybe there is something sitting on his desk right now that should have moved weeks ago.
You don’t know yet.
And you aren’t going to make Tim the answer to a question you haven’t investigated.
You respond: “I know there’s a lot going on with these invoices. Let me see where everything is and get to the bottom of what happened.”
Then you go find Tim.
You Know More Than You Think
You find Tim.
“How long has it been since this contractor was paid?”
He knows exactly who you mean.
“Yeah. It’s been about three months.”
“Tim, is that the only one?”
Tim shakes his head, No.
There is another pay application already in the queue. The contractor is preparing the third.
Then Tim reminds you that this contractor has been behind on its pay applications almost from the beginning. At one point, they were so far behind that they bundled nearly two months of completed work into a single submission.
You knew about the corrections, the funding questions, and the back-and-forth over their pay applications.
You just hadn’t added it all up.
The contractor is still working. But they are still waiting to be paid for work they completed months ago. Since then, they've completed even more work, and some of it hasn't made it into the invoice queue yet.
There is a lag before the lag.
And that first invoice still hasn’t been paid.
You ask Tim to show you what else he has.
There are pay applications he is reviewing, others he has returned, some waiting on someone else, and more coming.
And invoices are only part of Tim’s job.
You could tell Tim to make this contractor the priority. Drop everything, find what is missing, and get these pay applications through.
And he probably could.
But Tim’s other work doesn’t disappear while he does it.
Prioritizing the contractor who made it to the CEO may get this invoice moving. It may also mean another contractor waits longer.
That isn’t a solution.
It’s a tradeoff.
There’s a problem and Tim working harder isn’t going to solve it.
Before you decide what needs to change, you need to understand what is actually happening.
Time to investigate.
Start at the Beginning: How Did We Get to 90 Days?
You have a 90-day problem.
Which is interesting, because your organization has a 30-day promise.
Submit a correct pay application, and payment should follow within 30 days.
So where did the other 60 days come from?
There is an easy answer available: the contractor’s pay application wasn’t correct.
And that matters. Contractors have a responsibility to submit what the contract requires. Missing documentation, unsupported costs, or incorrect calculations have to be addressed.
But “it wasn’t correct” is not a good enough explanation for 90 days.
Because if your organization says payment takes 30 days, you need to understand exactly how those 30 days are being counted.
Start with the first pay application and reconstruct what actually happened.
When did the contractor first submit it?
How long did it sit before someone reviewed it?
How much time was spent correcting it and moving it back through review?
What starts the 30-day clock, what stops it, and does it ever reset?
The contractor owns part of those 90 days. Tim owns part. Procurement, Finance, and others own part.
What you don't know yet is who should be held accountable for what.
And there is another problem.
Your system didn’t flag this invoice as having blown past 30 days.
So whatever happened during those 90 days, your organization wasn’t counting all of them.
The contractor was.
Now you aren’t just investigating the invoice.
You’re investigating the clock.
Where did the 90 days go?
And who’s counting?
Follow the Invoice
You open the first pay application with Tim and start tracing what actually happened.
The contractor submitted it 90 days ago.
Then you start adding up what happened next.
“The first review takes eight days.
The contractor makes corrections in three.
Tim reviews the resubmission and sends it forward. Compliance reviews it and finds another issue. It goes back through Tim to the contractor for additional documentation, then back through Tim and Compliance before finally reaching Finance.
By then, 48 days have passed.
Finance reviews it and has another question. It comes back to Tim. He researches the issue, resolves it, and sends the pay application back.
Finance clears it, and the payment moves through final processing.”
There it is.
Ninety days.
And something becomes obvious when you put the entire timeline in one place.
The contractor didn't have the pay application for most of that time.
Across two rounds of corrections, the contractor accounted for only six of the 90 days. They weren't perfect. There were legitimate problems with their submissions, and those problems contributed to the delay.
But six days of corrections do not explain a 90-day outcome.
The contractor has been counting from the day it submitted the first pay application.
The contractor never stopped counting. We did.
Internally, those same 90 days look very different.
When the pay application goes back to the contractor, your internal clock stops. When it comes back, review begins again. Compliance can tell you how long it had the pay application. Finance has its own clock and can tell you how long something has been in its hands.
Tim doesn't really have a clock.
He has a pay application that keeps moving.
It comes to him. He reviews it. He sends it forward. Compliance sends something back. Tim gets what is needed and sends it forward again. Finance has a question. It comes back to Tim. He resolves it. It moves again.
Tim can reconstruct that history. What he doesn't have is something sitting in front of him telling him that this contractor has now been waiting 30 days. Then 45. Then 60. Then 75.
The weekends counted. The time sitting in a queue counted. The days spent waiting for an internal answer counted. The contractor's correction time counted too.
By the time the contractor tells your CEO it has been waiting 90 days, everyone inside the organization can tell you what happened while the pay application was in their hands.
However, no one was tracking was what all of that time added up to.
That is the point of reconstructing the timeline. Not to assign each day to someone, but to see the time as a whole.
You weren't missing the activity. You were missing the total.
And once you see the total, assigning accountability actually gets harder.
It would almost be easier if Tim had simply let the pay application sit on his desk for 60 days. Then you would know what happened and where to start.
But he didn't.
Tim had it. The contractor had it. Compliance had it. Finance had it. Then parts of it came back around again.
There are places where someone could have moved faster. Maybe Tim could have escalated sooner. Maybe something sat too long in Finance. Maybe Compliance could have caught something earlier. Maybe the contractor could have submitted it correctly the first time.
But the timeline can't answer those questions.
It only tells you where the time went.
It doesn't tell you what anyone was doing with that time.
And now that you know what to look for, you check a few more invoices.
This contractor isn't the only one waiting.
Some are at 40 days. Some are past 50. Some have spent time back with the contractor, with a project manager, in Compliance, or in Finance.
Their stories are different.
The pattern isn't.
The total time is much longer than any one part of the organization is counting.
And suddenly the 90-day invoice looks different.
The invoice wasn't unusual. Its visibility was.
This wasn't the first invoice that took too long.
It was the first one that made it to the C-suite.
In fact, looking at the numbers now, you're starting to wonder why it took a contractor 90 days to complain.
And that's when the question changes.
You started by trying to figure out what happened with Tim's invoice.
Now you know this is bigger than Tim.
But that doesn't mean Tim has nothing to own. It doesn't mean Finance has nothing to own. Or Compliance. Or the contractors.
It means you don't know enough yet to decide.
Eight days with a project manager means very little until you understand what that project manager is expected to do. Eight days in Finance means very little until you understand what Finance is doing. Nine days in Compliance means very little until you understand what Compliance is responsible for checking.
If you're going to hold anyone accountable for the time, you need context for the work.
Visibility before accountability.
You know where the time is going.
Now you need to understand what everyone is doing with it.
What Are We Actually Asking Everyone to Do?
You bring the team together.
Project managers. Compliance. Finance. The people who actually touch these pay applications.
You don't put the 90-day invoice on the screen.
This isn't a meeting about Tim.
If you ask everyone to explain their part of it, people are likely to get defensive. The conversation can quickly become about who had it when, who sent it back, who should have caught what, and why each person did what they did.
That's not what you need.
You aren't trying to get people to defend the current process.
You want them to help you understand it.
So you ask about the work in general.
You pull up a typical pay application and ask the team to walk you through it.
You open it, and It is more than 1,000 pages.
The invoice itself is only the beginning. Behind it are:
Timesheets and labor documentation
Expense reports and receipts
Travel costs and per diem
Subcontractor documentation
Allocations
Supporting calculations
Signatures
Pages of backup meant to demonstrate that the amount being billed is allowable and accurate
Now you asked the team. You start with the project managers.
“What are you reviewing?”
The answers start coming:
Work performed
Quantities
Labor hours
Rates
Required documentation
Allowable expenses
Alignment with the contract and what happened in the field
Then you ask Compliance.
Then Finance.
And the simple process you had in your head starts getting less simple.
Because “Finance reviews the invoice” isn't really one thing.
Neither is “Compliance reviews it.”
And neither is “Tim reviews it.”
There are different kinds of knowledge and controls being applied at different points in the process:
Project knowledge
Contract knowledge
Financial controls
Compliance requirements
Administrative checks
So you ask another question.
“What makes you send one back?”
Again, the answers start coming:
Missing timesheet
Incorrect labor rate
Unallowable travel cost
Missing receipt
Unverifiable allocation
Quantity that doesn't match project records
Missing signature
Calculation that doesn't tie
Insufficient supporting documentation
Some of those problems are significant.
Others are not.
But then someone says something that makes you stop.
“It’s not the entire pay application that’s the problem.”
Sometimes it is only:
A line item
An expense
A person's timesheet
A calculation
A few hundred dollars inside a pay application worth tens or hundreds of thousands
And yet the entire pay application can still be sent back because of one thing.
So you ask:
“If the issue is with one charge, what happens to the rest of the pay application?”
The room gets quieter.
Because now you're asking a different question.
Not whether the review is necessary. Not whether the requirement matters. Not whether somebody should have caught the mistake.
You're asking why the rest of the pay application has to wait while one issue is being resolved.
Then you ask:
“And when it comes back, who reviews it again?”
That's when you start hearing the overlap.
A project manager reviews the pay application before sending it forward. Compliance reviews what it needs. Finance performs its review. If Finance has a question, the pay application may come back to the project manager, who may have to go back to the contractor before sending it forward again.
One issue can send the entire pay application back through multiple hands, adding days to an invoice that may otherwise be ready to move forward.
Now the 90 days make more sense.
You already knew where the time went.
Now you're beginning to understand why the process keeps producing so much of it.
And that leaves you with a different question:
Does the entire pay application have to move this way?
Understanding What You’re Actually Dealing With
By the end of the conversation, the 90 days make a lot more sense.
Not because you've found one thing that explains them.
You've found a process capable of producing them.
A thousand-page pay application enters the organization. Different people need different information from it. Some are reviewing the same information for different reasons. Questions send the package backward. A problem with one portion can delay everything else. Each handoff creates another queue, and no one is responsible for counting the total time across all of them.
Ninety days can accumulate this way even when everyone involved is actively doing their job.
You started this investigation with a project manager who appeared to have a contractor sitting unpaid for three months.
Now you can see the conditions surrounding his work.
There are still individual responsibilities throughout the process.
But this is no longer a question of whether one person should have worked faster.
The process itself is producing the delay.
And once you can see that, something else becomes clear.
It does not have to work this way.
The thousand pages do not have to travel together.
Every reviewer does not necessarily need the same information.
One questionable charge does not have to send everything backward.
Work that has already cleared review does not necessarily have to wait for work that hasn't.
The organization does not have to lose sight of the total time simply because the invoice changed hands.
Those are design choices.
Maybe no one sat in a room and deliberately chose them. Some probably accumulated over time. A requirement was added here. A control was added there. A problem happened, so another review was introduced.
Eventually, all of those reasonable pieces became the process Tim is trying to manage today.
Now you can see it.
The question is no longer what happened to the 90 days?
You know.
The question now is:
Who has the responsibility and authority to change the conditions that produced them?
The Accountability Test
This is where things get messy.
Usually, ownership is easier to find. One of the tests I use is:
If something goes wrong, whose excuse isn't going to be good enough?
In this case?
No one's.
The contractor can't say its submissions were incomplete. Tim can't say Finance had it. Finance can't say it was waiting on Compliance. Compliance can't say it was waiting on documentation.
Those things may explain what happened.
But when a contractor hasn't been paid in three months, none of those explanations are good enough.
Everybody owns a piece of the outcome.
But ownership isn't the same thing as responsibility.
When it comes to getting this contractor's invoice paid on behalf of the organization, Tim has that responsibility. He's the project manager. He has to manage the invoice, follow up, escalate, communicate with the contractor, and keep it moving.
But now you know something you didn't know when the CEO first walked into your office.
Tim cannot fix the larger problem.
He has the responsibility for getting the invoice paid, but he does not have the authority to change the conditions that are making it late.
He cannot change:
What contractors are required to submit
How information enters the payment process
What Finance or Compliance reviews
How work moves through functions outside his control
What happens when one portion of an invoice doesn't clear
How the organization tracks the total time from submission to payment
And that's where accountability becomes different from responsibility.
Accountability asks: Who is responsible for ensuring this gets addressed?
In this case, that's you.
As the director, you have more authority to change the conditions around the work. You can change some of them yourself. You can bring together the people who control other parts of the process. And where your authority stops, you can take the issue to the people above you who have the authority you need.
This is where Visibility Before Accountability matters.
At the beginning of this story, you had visibility of the outcome.
A contractor had not been paid in 90 days.
You did not yet have visibility of the conditions that produced it.
You didn't know where those 90 days went. You didn't know that the contractor only had the pay application for six of them. You didn't know how many times the pay application changed hands, what each person was reviewing, where reviews overlapped, or how one issue could send the entire pay application backward.
Without that visibility, Tim looked like the problem.
And that makes blame easy.
Blame asks: Who caused this?
Tim is the project manager. The contractor hasn't been paid. Call Tim into the office. Tell him to fix it. Tell him this cannot happen again.
You have a person.
But you don't have a solution.
Blame ends with a person. Accountability ends with a plan.
Accountability requires you to keep going.
What happened? What does Tim actually control? What depends on someone else? What is preventing the outcome? And who has the authority to change it?
That's what the investigation gave you.
It did not prove that Tim did everything right. It did not excuse the contractor's mistakes. It did not mean Finance or Compliance should not answer for the time the pay application spent with them.
Visibility does not remove individual responsibility. It tells you where to put it.
Now you can ask whether Tim escalated soon enough. Whether the contractor submitted what was required. Whether a review took longer than it should have. Whether an issue should have been caught earlier.
And you can ask a question that blame would have missed entirely:
What about this process needs to change?
Because Tim can work harder. He can follow up more. He can prioritize this contractor and get this particular pay application out the door.
There will still be another invoice behind it.
You could even replace Tim with someone faster.
The thousand-page pay application would still move through multiple reviews. One issue could still send the whole thing backward. Each function could still count its own time while no one counted the total.
The person changed. The system didn't.
Tim still has responsibility for getting the invoice paid.
But he cannot redesign his own working conditions.
You have more authority to change those conditions than he does.
And that is what visibility has changed.
You started with a 90-day invoice and a CEO asking who let it happen.
Now you know where the time went, what work was happening during it, what Tim could control, what he couldn't, and which conditions allowed 90 days to accumulate.
Visibility doesn't delay accountability. It makes accountability accurate.
And accurate accountability doesn't end with finding someone to blame.
It ends with knowing what each person owns—and having a plan for what needs to change.
