1. How it usually happens
A proposal almost always builds up progressively. First an exploratory call, then an email follow-up, then a more structured document: a term sheet, a memo, a presentation. Each step adds details.
Meanwhile, the conversation evolves. The investor says "interesting, but at a different valuation", the founder replies "ok, we can talk about it", someone introduces a clause, someone else interprets it differently. After a few exchanges, multiple "mental versions" of the same proposal exist.
A typical anecdote: a founder sends an "indicative" term sheet after a call. The investor reads it as a formal proposal. The founder meant it as a basis for discussion. Weeks later, when negotiations get tough, both parties revert to that document... with different expectations.
A less obvious perspective: in early stages, many proposals are hybrids. Part document, part conversation. Some terms are clearly written, others are implicit or scattered across emails, messages, and slides. That is where ambiguity breeds.
Furthermore, subsequent modifications are often poorly tracked. You change a percentage, add a clause, alter a timeline. If you don't keep versions, after a few iterations it becomes hard to know which was the "correct" proposal at any given moment.
Finally, there is the matter of perception. A proposal might be technically coherent but communicated unclearly. Documenting also serves to prove that what was sent was understandable and complete given the context.
2. What you need to prove
The goal is to prove that the proposal was formulated clearly, completely, and coherently, in a specific version and at a precise moment.
It can be useful to prove:
- the existence of the proposal document;
- the proposal's content (valuation, equity, conditions);
- the specific version sent;
- any changes made over time;
- the context in which it was formulated;
- the accompanying communications (emails, messages);
- any clarifications provided post-submission;
- the distinction between an indicative proposal and a formal one;
- the counterparty's replies or reactions;
- the chronological sequence of exchanges.
In practice, you must be able to say: "this is the proposal I formulated, with these terms, in this context".
3. What to collect
Collect everything that represents the proposal and its evolution. Even tiny details can be relevant.
Collect:
- term sheet or proposal document;
- prior and subsequent versions of the document;
- submission and accompanying emails;
- exported chats showing proposal discussions;
- linked presentations or pitches;
- internal notes or memos on offer structure;
- any technical or financial annexes;
- screenshots of relevant messages;
- call recordings, if available;
- comments or revisions received;
- files with tracked changes;
- meeting calendar;
- any NDAs or preliminary agreements;
- documents clarifying context (metrics, data, assumptions).
A helpful tip: always keep the exact version sent. Even a tiny change can alter the meaning.
4. How to proceed
Treat the proposal like a versioned document, not a file evolving without a trace. Every submission must correspond to a precise version.
Create a folder dedicated to the proposal, with subfolders for versions or iterations. Use clear names with dates and context, e.g. TermSheet_v1_2026-05-01.
Add a brief README or note explaining:
- who the version was sent to;
- in what context (call, follow-up, negotiation);
- what changed compared to the previous version.
Practical procedure:
- gather all proposal versions;
- organise files chronologically;
- link sending communications to each version;
- highlight changes and differences;
- create a timeline of exchanges;
- prepare a clear proposal summary;
- create ZIP archives of key versions;
- certify main documents and packages;
- keep unaltered copies;
- log recipients and sending dates.
Before sending a proposal, pause for a second and save the definitive version. After sending, keep all replies and clarifications. This creates a full trail of the negotiation.
5. Mistakes to avoid
Many difficulties stem from informal handling and lack of versioning.
Common mistakes:
- sending documents without keeping a copy;
- modifying the same file without version tracking;
- failing to distinguish between indicative and formal proposals;
- not accompanying the document with clear explanations;
- relying purely on verbal conversations;
- not saving relevant emails and chats;
- using generic names like final_term_sheet;
- not tracking changes and revisions;
- losing the context in which the proposal was made.
Besides technical certification, adopting simple habits is useful: versioning, clear communication, written summaries, and neat archiving. Free certification is useful because it allows you to quickly secure a proposal version before sending, without burdening the process.
6. After the documentation
Once documentation is organised, use it as a reference for the negotiation's next stages. Every new proposal version should link back to the previous one.
Share the material internally with co-founders, the finance team, or advisors, so everyone shares the same vision. If talks evolve or complicate, having a clear trail helps maintain coherence and transparency.
If disputes arise, documentation allows you to rapidly reconstruct what was proposed and how it was communicated. In the investment world, where much relies on interpretation and expectations, having a concrete version of the facts makes a very practical difference.