ExistBefore
IT

Professional

How to prove what was included in a commercial offer

When a client says "but this was included, right?" and you feel a slight shiver down your spine, it is already too late to improvise. This guide helps you document solidly what your offer truly contained. If you start today, the next discussion will be much shorter.

4 min read

1. How it usually happens

It always happens like this: a quick call, enthusiasm, "I'll send you a proposal by tonight". You prepare a flawless PDF, maybe with three options. Client replies from mobile, approves with an "ok perfect, let's go", and you actually start.

Two weeks later:

"Can we also add X? It was included, right?"

And there the short circuit starts.

In the freelance and consulting world, a commercial offer is often:

  • a PDF attached to an email
  • a link to a presentation
  • a chat message
  • a combination of all this

The problem is not just what you wrote, but which version was actually shared and accepted.

A classic anecdote: creative agency, three versions of quote saved as "final", "final2", "final_def". Client opened the first. Team worked on the third. The misalignment became a two-hour meeting with pixelated screenshots.

There are also subtler cases:

  • client remembers a call, not the document
  • an "on the fly" modification was never resent
  • an attachment was replaced without changing file name

This is not about bad faith. It is about memory, context, and intertwining versions.

2. What you need to prove

The central point is simple: what content existed at a precise moment and in what form it was shared.

Concretely, you must be able to prove:

  • existence of commercial offer
  • exact version of document
  • what was included and what wasn't
  • any options or exclusions
  • context in which it was sent (email, chat, platform)
  • any subsequent modifications

If there is a dispute, the question will always be:

"Was this thing really written in there?"

3. What to collect

Here you need to be practical and slightly obsessive (in a good way).

Collect everything defining the offer and its context:

  • PDF of commercial offer (all versions, not just last)
  • Source file (Word, Google Docs, Keynote, etc.)
  • Sending email with subject and timestamp
  • Screenshot of opened email (with visible attachment)
  • Chat where offer was discussed or approved
  • Any links to online documents
  • Exported or printed versions
  • Voice notes or recordings of relevant calls
  • Secondary attachments (brief, scope, appendices)

A small operational trick:

if you send an important offer, immediately take a screenshot of sent email, with date, time, and attachment visible. It's a 10-second gesture that often saves hours of discussion.

4. How to proceed

Here comes the truly useful part: creating a clear and coherent trail.

As soon as you finalise an offer:

  • save a definitive copy of document
  • rename it clearly (e.g., "Offer_Client_X_v1_2026-05-01.pdf")
  • also keep source file
  • export any online versions to PDF

Right after sending:

  • keep complete email
  • take screenshot of sent email
  • archive any client replies

Then take an extra step few people do:

  • create a "package" with all materials (document + email + screenshot)
  • timestamp these files in the state they exist at that moment

If there are subsequent modifications:

  • do not overwrite previous file
  • create a new version
  • document the change (even with a short note)
  • timestamp new version too

Over time, this creates a very clear timeline:

first version → revision → approval → any changes

And when someone says "it was included", you can reply with something very concrete, not memories.

5. Mistakes to avoid

Mistakes here are almost always organisational, not technical.

  • working on a single file constantly modified
  • sending documents without keeping an exact copy
  • changing contents without updating file name
  • relying only on call memories
  • leaving important approvals inside vague messages like "ok sounds good"

There is also a subtler mistake:

assuming that "anyway it's clear".

What is clear to you, in a week can become ambiguous to everyone.

Useful precautions besides timestamping:

  • use explicit "Included / Excluded" sections
  • avoid generic formulas
  • always summarise agreement in writing after a call

Good documentation reduces discussion before it even starts. And free timestamping adds a solid time reference to what you collected.

6. After documenting

If a dispute arises:

  • share documented version of offer
  • show context (email, date, version)
  • simply highlight relevant points

Avoid going into defensive mode. Often just reconstructing facts orderly is enough.

If situation complicates:

  • involve an internal client referent (project manager, procurement)
  • prepare a clear timeline summary
  • evaluate a structured confrontation, not a fragmented chat

In most delicate cases:

  • you can share documentation with a consultant or mediation service
  • having orderly materials accelerates any verification

In the end, the real advantage is not "being right", but reducing time and friction needed to prove it.