Comparing quote versions: which one did the customer approve?

It is 4:20 on a Thursday afternoon. A sales rep tells a customer "I'm turning the quote you approved into a contract," then opens the folder on their desktop. Inside are four files: quote_v2.pdf, quote_v2_final.pdf, quote_v2_final_revised.pdf and quote_current.pdf. Three carry different totals, two list a different number of line items, and one sets payment terms at 60 days instead of 30. The customer's "we accept" email arrived eleven days ago with no attachment — just the sentence "we approve the attached quote." The rep does not know which version was approved. Finance is asking for the number to invoice, and the customer assumes the discount discussed in round two still stands. Two parties are describing two different documents before a contract has even been drafted.

This article turns quote version comparison from a file-naming habit into a traceable record discipline. We start with why a quote changes and how often, then look at why "which version did you approve" is almost always asked too late. From there we cover what counts as a new version, the order in which you should read the difference between two versions, the records that lock an approved version, and how a discount approval leaves a trail. We close with partial acceptance, the reports version data feeds, and a thirty-day rollout order.

How many times does a quote change before it closes?

Quotes accepted on the first send are the exception. In a mid-market B2B deal the document typically changes hands three to five times: scope narrows or widens after round one, price and payment terms get negotiated in round two, and procurement or legal adds a clause in round three. The total is not the only thing that moves either. Line item descriptions, delivery windows, warranty coverage, currency, payment schedules and sometimes even the signing legal entity shift between rounds.

The real problem is not the change; it is where the change gets written down. Written into a filename, it becomes a pile of copies with no date, no reason and no approval attached. Written into an email thread, only the people on that thread know. Building the process around a record rather than a document — treating the quote as a managed record instead of a stage — stops that pile from forming. In a record-based flow every send leaves its own snapshot, and no version overwrites the one before it.

What gets lost when versions go untracked is concrete:

• What each discount was traded for — longer terms, wider scope, a reference commitment?
• Which line item the customer had removed, and whether it quietly came back later.
• Which round the price dropped in, and therefore where the next renewal negotiation will start.
• The exchange rate at the moment of quoting, and the true margin that follows from it.
• Who approved the exception, when, and on what grounds.

Why is "which version did you approve" always asked too late?

Almost nobody asks it during the sales cycle, because approval feels like an ending. When the buyer says "great, let's move forward," the rep exhales and closes the file. The question surfaces later — at invoicing, at delivery planning, or six months on in a renewal conversation. By then the person who built the document is deep in another deal, the email thread has split across two inboxes, and the contact on the customer side has changed jobs.

The cost is not the argument itself; it is rework. Finance goes back to sales for the right number, sales goes back to the customer, and the customer digs through their own archive. The same document gets read three times and nothing new is produced. That loop makes the post-quote stage look far longer than it is, when carrying a sent quote through to a close is a measurable process whose delays usually come from your own ambiguity rather than the buyer's hesitation.

There is a quieter risk too. Customers work from the copy in their archive, and if that copy differs from yours, the gap almost always favors them — because people keep the version they liked best.

What counts as a new version, and what is just a fix?

One rule ends most of the debate: anything that reaches the customer is a new version, and anything that does not is a draft. Fixing a typo on a quote you have not sent yet does not earn a version number. Changing a single unit price after you sent it does, because from that moment the customer's copy and yours no longer match.

To apply that rule you need to know which parts of a quote carry version weight. Line items, quantities, unit prices, line discounts, tax, currency, validity date, payment schedule and terms text — every field a proper price quote should carry is also a field you can compare. In a free-text proposal those values are buried inside sentences, and comparing two documents falls back on the human eye.

It gets cleaner still when line items are produced by rules. In a flow built on configure, price, quote logic, every line is the result of a selection, so the difference between two versions reduces to "which selection changed." In free text the question becomes "which sentence was rewritten," and that one usually has no answer.

In what order should you read the difference between two versions?

Replace eyeballing with a fixed reading order. Start with the total and the currency: if those match, a nasty surprise deeper down is less likely. Then the line count — was a row added or dropped? Then unit prices and line discounts, because the total can stay identical while the internal mix shifts, which is the most dangerous case for margin. Terms text goes last: payment days, delivery window, warranty and validity date.

Inside a Rocketly quote record that reading order does not have to be assembled by hand. The version history and comparison feature stores every revision as its own snapshot, and you can put two to four quotes side by side and read the difference line by line. The answer to "what did we give away in round two" then rests on a record rather than on memory, and the account manager heading into a renewal reads the same screen to see how earlier rounds actually progressed.

Text fields are harder to diff, because the same meaning can be written two ways. If your narrative sections are drafted from deal context — the approach behind generating a persuasive proposal from the context you already hold — store which inputs produced which version of that text. Otherwise, two rounds later, nobody can say whether a given sentence was written by a person or suggested by the system.

Which changes require a new version, a resend, and a fresh approval?

Not every change carries the same weight. Without a shared threshold table, one rep opens a new version for a comma while another edits the total and resends the same document. The table below is a sample decision rule showing what a change should trigger on the version, send and approval sides; you set the thresholds against your own margin structure.

Change	New version	Resend to customer	Manager approval
Typo or formatting fix before sending	No	No	No
Clarifying a line item description	Yes	Yes	No
Adding or removing a line item	Yes	Yes	Depends on scope threshold
Unit price or line discount change	Yes	Yes	Yes if it breaks the margin floor
Currency or payment schedule change	Yes	Yes	Yes
Extending the validity date	Yes	Yes	Yes where FX exposure applies

The healthiest place for that table is inside the template itself: put the trigger next to the field it governs. A proposal template that actually wins carries more than a visual layout — it carries rules like these. When the template is disciplined, version discipline follows on its own.

Which records lock an approved version?

For a version to count as approved, four things must be on the record: who approved it, when, which document they approved, and the exchange rate in force at that moment. Without those four, an approval is just a sentence in an email, and six months later nobody can prove which attachment that sentence referred to.

When a contract is signed on screen in Rocketly, a signed PDF is produced and the signer's name, the time of signature and their IP address go into the record. That takes "who approved this" out of the realm of recollection. On the multi-currency and live rate side, the exchange rate at the moment of quoting is sealed into the quote, so the margin on a deal priced in USD or EUR does not change retroactively when the rate moves — and you can separate how much of the gap between two versions came from FX and how much came from a discount.

The fourth lock sits at the handover to contract. Only an accepted quote can be converted, the title, total, currency and parties carry over as they are, and the same quote cannot be converted twice into a duplicate contract. "Which version was approved" is then answered by the contract itself: whichever version it was derived from.

Who approved the discount, when, and on what grounds?

Most version disputes are really discount disputes. An extra concession given in round three that survives into round four after the scope shrank erodes margin silently. That is why discount approval has to be attached to the quote itself rather than to a side conversation.

This is exactly where the manager approval gate earns its place: a quote that crosses an amount threshold or drops below the margin floor goes to approval automatically and cannot be sent to the customer until it clears. The approval queue then lists every pending quote in one place along with how long it has been waiting, and the manager approves from the queue or sends it back with a reason. Because the decision is written into the quote's version history, "who signed off on this discount" never becomes a debate later.

Setting those thresholds on amount alone is misleading. A small, service-heavy engagement can carry a far more fragile margin than a large hardware order. Tying the thresholds to an analysis of which customers actually make you money turns the approval gate from bureaucracy into a real filter.

What happens when the customer accepts only part of the quote?

Partial acceptance is where version chaos is manufactured most reliably. The buyer says "let's take the licenses and onboarding, skip training for now"; the rep builds a new PDF and sends it; the buyer replies "approved" on the old email. Now there are two documents and one approval sentence.

The way around it is to let the customer make the selection on their own screen. With package selection and partial acceptance, the customer picks between packages or approves only the line items they want, and that selection is written straight into the quote. The accepted scope lives inside the approved version rather than in a separate file. Messaging on the quote works on the same principle: the customer asks from the quote page and the team answers in the same thread, so questions and answers stay in the document's context.

Partial acceptance is also a signal. A deal where scope keeps narrowing, rounds keep stretching and the decision maker never joins a call is risky whatever the number on it. A health score that shows whether a deal is stalling can take version count as an input: a quote on its fourth version with no signature date discussed needs a different intervention than one that closed on its second.

What reporting does version history feed?

Version records do more than prevent arguments; they are a dataset in their own right. Quote analytics and export shows how many quotes were accepted and at which value range you keep getting stuck, and you can export to CSV or Excel and pull it into your own model. Add version count to that and four new questions become answerable.

• How many versions do won deals take to close, and at which version do lost deals stop?
• Does a discount given after version two actually move the win rate?
• Which line item is removed most often — is it priced too high, or explained too poorly?
• How much of your cycle time is spent sitting in the approval queue?

These only pay off if the numbers are read properly. An average version count is easily dragged upward by a handful of long negotiations; the median usually speaks more honestly. Knowing which chart says what and which numbers to trust is what turns version data from dashboard decoration into a decision input.

How do you build version discipline in thirty days?

Week one: measure where you stand. Take ten quotes closed in the last quarter and, for each, write down how many files were produced, where the approval is recorded, and which document the contract total came from. That list makes the size of the problem impossible to argue with.

Week two: write the version rule and embed it in the template. Put "anything that reaches the customer is a new version," the threshold table above, and the approval triggers on a single page. That page becomes the team's shared vocabulary, and "should I open a new version" stops being a question.

Week three: switch on the approval gate and the queue. Set the amount threshold and the margin floor, and keep them slightly loose for the first two weeks so the queue does not jam. Watch waiting time in the queue closely: a quote awaiting approval is a quote sitting still in the buyer's eyes. Alongside it, set a clear order for what a rep opens first — a ranking that decides which deal gets touched first — and put quotes waiting on approval near the top of it.

Week four: tie the close to the record. Derive contracts from the approved version, check the signed PDF archive, and produce the first report: mean and median version count, time spent in the queue, and the version at which lost deals stopped. If you want to run this loop on your own quote flow, you can open a free account and set up your first template and approval threshold in an afternoon.

FAQ

What should I do if the customer approves an old version?

Do not reject the approval — verify it. Open the version they approved, place it next to the current one, and summarize the difference in a single message: which line changed, what the total gap is, and which one should stand. Leave the decision with the customer, but put the difference in writing. Then resend whichever version you agree on, collect a fresh approval, and derive the contract only from that one.

How many versions is too many?

There is no fixed number, but version count exposes a pattern. If scope is still being negotiated after version three, the problem is discovery, not price. If the total keeps falling after version four, the deal has usually collapsed into a price fight. Compare the median version count of your won and lost deals; your threshold sits somewhere between those two numbers.

Should the customer see the version history too?

Not all of it. What belongs to the customer is the set of versions sent to them plus the one they approved. Internal revisions, approval queue comments and margin calculations are internal records. That line protects your negotiating position and spares the buyer a pile of documents that means nothing to them.

Is version comparison useful at renewal?

Very. Walking into a renewal knowing what was conceded in which round of the previous term sets the starting point of the negotiation. A line item asked for but never granted in the original quote can be a good trade at renewal, and a discount whose justification has since disappeared can be reclaimed. Without version history, that conversation restarts from zero.