The Four Versions of Every Client Project: Sold, Promised, Delivered, Billed

A client project is rarely one thing.

It exists in at least four versions.

There is the project that was sold.

The project the client believes was promised.

The project the team actually delivers.

And the project that eventually gets billed.

In a healthy engagement, those four versions remain close enough to one another that everybody is operating from roughly the same commercial reality.

In an unhealthy one, they begin to drift.

Usually not dramatically.

A sentence in a sales call.

An assumption in a proposal.

A client request accepted in the interest of goodwill.

An extra revision that nobody formally approves.

A senior person stepping in to rescue something.

A piece of work that gets delivered because challenging it feels more cumbersome than doing it.

An invoice that reflects the original agreement even though the engagement stopped resembling that agreement weeks ago.

Individually, each deviation can appear reasonable.

Collectively, they can turn one project into four.

And the business often notices only when the economics no longer make sense.

Version 1: Sold

This is the cleanest version.

At least in theory.

It is the commercial proposition at the point of agreement:

the outcome;

the scope;

the fee;

the timeline;

the assumptions;

the people involved;

the exclusions;

the revision limits;

the responsibilities on each side.

This is the version most likely to exist neatly inside a proposal, contract or statement of work.

It is also the version businesses tend to return to when something later goes wrong.

“What did we actually agree?”

That is an important question.

But it is not always the most useful one.

Because the project may already have changed.

Version 2: Promised

This is where commercial reality becomes less tidy.

The promised project is what the client reasonably believes they are going to receive.

Sometimes it is identical to what was sold.

Sometimes it is not.

A salesperson says:

“We can probably accommodate that.”

An account manager says:

“Don’t worry, we’ll take care of it.”

Someone on WhatsApp responds:

“Sure, send it across.”

A presentation implies a capability or level of involvement that the formal scope never explicitly contains.

A conversation creates an expectation nobody writes down.

None of these moments necessarily amount to deception or poor intent.

Quite the opposite.

Many are created by people trying to be helpful.

But the client does not experience an organisation through its internal distinction between a formal scope and an informal reassurance.

The client experiences a promise.

That makes the promised version particularly dangerous.

The sold version usually has documentation.

The promised version may exist only in memory.

And yet it can be just as real to the customer.

Version 3: Delivered

Then comes the version the operating system actually produces.

This is where the team enters the story.

Perhaps delivery interprets the brief differently from sales.

Perhaps the client supplies material late.

Perhaps a revision exposes an issue nobody anticipated.

Perhaps a senior team member spends six hours fixing work that was priced assuming a junior resource.

Perhaps the team delivers extra work because the alternative is to disappoint the client.

Perhaps the original solution simply turns out to be insufficient once execution begins.

Again, none of this automatically indicates bad management.

Complex work changes.

Professional judgment exists partly because not everything can be predicted at the start.

But every meaningful change creates a question:

Has the commercial version of the project changed with it?

If not, delivery can quietly create a new project while the rest of the organisation continues administering the old one.

Version 4: Billed

Finally, there is the project the business invoices.

This may be the most revealing version of all.

Because billing forces a commercial decision that the organisation may have postponed throughout delivery.

Was the additional work included?

Was it approved?

Did anybody price it?

Was there a change order?

Did the client understand it would be charged?

Is the business willing to charge for it now?

Does finance even know it happened?

By the time these questions reach billing, much of the leverage has disappeared.

The work is complete.

The time has been spent.

The client may have incorporated the additional output into their understanding of what the original fee purchased.

What could have been a simple commercial decision three weeks earlier now risks becoming a relationship conversation.

So businesses often absorb it.

The invoice returns to the version that was sold.

Even though delivery moved somewhere else entirely.

The problem is not scope creep. It is version drift.

“Scope creep” is a useful term.

But it often compresses several different operating failures into one phrase.

The client asked for more.

The team did more.

Margin suffered.

That description starts too late.

The more interesting problem is version drift.

The moment when the project sold stops matching the project promised.

The moment when the project promised stops matching the project being delivered.

The moment when the project delivered stops matching the project that can credibly be billed.

Each gap has a different cause.

And therefore requires a different control.

Sold → Promised

This is usually a commercial communication problem.

What did the organisation imply beyond the formal agreement?

Who has authority to extend the promise?

How are informal commitments captured?

Promised → Delivered

This is usually an execution and handoff problem.

Did delivery inherit the same understanding the customer did?

Did the team know what had been promised outside the proposal?

Did reality force the scope to change?

Delivered → Billed

This is usually an ownership and commercial follow-through problem.

Was added effort visible?

Was it approved?

Did somebody decide whether it should be charged?

Did finance receive that decision?

Calling all three “scope creep” makes the diagnosis easier to name but harder to solve.

The most dangerous work lives in the gaps

Notice something else about the four versions.

They often belong to four different parts of the organisation.

Sales knows what was sold.

The account or relationship owner often knows what was promised.

Delivery knows what was actually done.

Finance knows what was billed.

Each function may be doing its own job correctly.

And the project can still lose money.

Because nobody necessarily owns the reconciliation between the versions.

That is an operating-system problem.

Not a competence problem.

Not necessarily a pricing problem.

Not necessarily a client problem.

The individual functions can all perform well while the spaces between them remain commercially weak.

This is one reason cross-functional operating failures are so easy to misdiagnose.

The damage appears inside a department.

The cause may sit between departments.

The founder often becomes the reconciliation engine

In a small founder-led business, this problem can remain hidden for surprisingly long.

The founder sold the work.

The founder joined the client call.

The founder knows what was promised.

The founder knows why delivery did something differently.

The founder remembers the pricing logic.

And the founder sees the invoice before it goes out.

All four versions coexist inside one person’s head.

The operating system looks functional because the missing integration is being performed manually.

Growth changes that.

Sales moves to one person.

Account management to another.

Delivery grows into a team.

Finance becomes more formal.

The information separates.

What once existed as one continuous commercial context becomes several records held by several people in several systems.

The founder then begins receiving questions:

“Was this included?”

“Did we promise this?”

“Can we charge for that?”

“What did the client mean here?”

“Why are we doing another round?”

The founder appears to have become a decision bottleneck.

But another interpretation is possible.

The organisation has lost its reconciliation layer.

The founder is simply continuing to perform a job that the operating model has not yet learned how to perform without them.

No single system contains the commercial truth

This is where technology can create false confidence.

The CRM contains what was sold.

The proposal contains the formal scope.

Email and WhatsApp contain what may have been promised.

The project-management system contains what was delivered.

Timesheets contain some version of the effort.

Accounting software contains what was billed.

Every system can be accurate.

And the organisation can still lack a reliable answer to:

What happened commercially on this project?

Data is not the same as reconciliation.

The commercial truth often exists in the relationship between records, not inside one of them.

This is why adding another dashboard rarely solves the underlying problem.

The business may not need more visibility into each individual version.

It may need a point at which the versions are deliberately compared.

Overdelivery is not automatically a failure

There is an important counter-case.

Not every difference between sold and delivered should trigger a change order.

Sometimes the business should overdeliver.

A small additional piece of work may create enormous goodwill.

A senior person may intervene because the long-term relationship justifies it.

A team may discover a better answer than the one originally scoped.

A strategic customer may deserve flexibility that would make little sense elsewhere.

The goal is not to turn every client relationship into a contractual negotiation.

That would simply replace leakage with bureaucracy.

The distinction is between deliberate generosity and invisible generosity.

One is a commercial choice.

The other becomes a habit nobody has priced.

A healthy operating system should be capable of saying:

“We know this sits outside the original scope. We are choosing to include it.”

That sentence preserves both flexibility and commercial awareness.

Without it, goodwill can slowly become the business model.

Review the project four times

There is a simple way to expose this problem.

Take three recently completed client projects.

Not only the bad ones.

Preferably one that felt excellent, one average, and one uncomfortable.

Then reconstruct four versions.

What was sold?

What did the proposal and fee actually cover?

What assumptions underpinned the price?

What was promised?

What additional expectations emerged through calls, messages, meetings or relationship management?

What was delivered?

What did the team actually produce?

Where did effort, seniority, revisions or timelines differ from the original assumption?

What was billed?

What portion of the delivered work appeared commercially?

What was deliberately included?

What simply disappeared?

Then examine the differences.

The interesting question is not merely:

“How much unbilled work was there?”

It is:

Where did the versions first separate?

That is usually the more useful place to intervene.

The best control sits before the work

By the time finance notices the difference, the business has relatively few choices.

Charge.

Absorb.

Negotiate.

Write it off.

The stronger operating moment happens earlier.

Someone close to the work notices:

The project we are about to deliver is no longer the project we sold.

That should trigger reconciliation.

What changed?

Was the change promised?

Does it alter effort?

Does the client understand the implication?

Does the fee change?

If not, is the business deliberately choosing to absorb it?

Who owns that choice?

This does not require a committee.

For many businesses, it may require only a lightweight rule:

When one version materially changes, reconcile the other three before work continues.

That is much more useful than discovering six weeks later that everybody was operating correctly against a different project.

Four versions do not need to be identical

Client work is dynamic.

The sold project can evolve.

The promise can improve.

Delivery can reveal a better answer.

Billing can legitimately reflect something different from the original estimate.

Perfect sameness is neither realistic nor desirable.

What matters is whether the divergence is visible and owned.

Because there is a profound difference between:

“We changed the project.”

and:

“The project changed.”

The first describes a decision.

The second often describes an operating failure.

A healthy client engagement therefore does not require all four versions to remain identical.

It requires every meaningful difference between them to become visible before the difference becomes expensive.

That is the reconciliation discipline.

And in many service businesses, it may reveal more about commercial control than any margin report produced after the project is already over.