Short answer
A quote represents an offer, a sale represents a closed agreement and a payment represents cash received. They may belong to the same lead and must not be added as independent sales. Each basis feeds a different report: payment feeds cash flow, the accepted sale feeds ROAS, and the quote feeds forecasting. WhatConverts Quote Value and Sales Value are independent fields; verify payments against payment records.
Key verification: The same lead keeps a stable identifier and reports identify quote, sale or payment as their basis.
Sources and limitationsA business receives a call, issues a quote and accepts a partial payment. Copying every milestone into a column called revenue makes the campaign appear to produce more money than agreed. Start by defining the economic event each field represents, who may change it, and which report each basis is meant to feed.
One lead, three fictional amounts
| Milestone | Amount | Appropriate use |
|---|---|---|
| Quote sent | 400 EUR | Offered potential |
| Sale accepted | 300 EUR | Commercial agreement |
| Initial payment received | 100 EUR | Partial cash receipt |
Adding 400 + 300 + 100 gives 800 EUR, without establishing that revenue. In this example the agreed sale is 300 EUR and 200 EUR remains payable, assuming no other adjustments. Keep the earlier quotation as a version, rather than another sale. An accepted sale also does not establish profit: costs and the applicable accounting basis remain relevant.
What to update in WhatConverts
The Lead Manager documentation confirms that Quote Value and Sales Value are two independent fields: adding either one automatically marks the lead as "Quotable", and the overview panel at the top of the Lead Manager totals both values for the leads currently displayed under the active filter. Assign an owner to reconcile them with the CRM. Entering Sales Value does not establish bank receipt, and integrations should not be assumed to propagate every change automatically. Checked on 27 October 2026.
Acceptance exercise before reporting
Reproduce the table using a fictional record and change only the accepted sale. Check identifier, currency, date and the chosen report total. Then record a cancellation under a written rule, retaining the history. A spreadsheet with separate columns can handle a small caseload; WhatConverts becomes relevant when this distinction must accompany attribution. This is a proposed exercise, not a CallsIQ test in a product account.
Reconcile two sales without duplicating payments
This second fictional case lets you check an entire report. All amounts are EUR on a consistent tax basis; the exercise does not calculate accounting revenue recognition. One row represents one sale, even with multiple calls or payments. A call identifier helps attribute the source but cannot replace the sale identifier: one customer can buy two separate services.
| Sale | Current quote | Accepted sale | Payments received | Refunds paid | Agreed price reduction |
|---|---|---|---|---|---|
| V-01 | 400 | 300 | 100 | 0 | 0 |
| V-02 | 600 | 600 | 600 | 150 | 150 |
Quotes total 1000, original sales 900 and adjusted sales 750. Net cash received is 100 + 600 − 150 = 550. V-01 has 200 outstanding; V-02 is settled after reducing its price to 450 and refunding 150. Check: adjusted sales 750 = net cash 550 + outstanding balance 200. Do not add those three figures: they describe the same business from different positions.
Edge case: feeding ROAS with the wrong basis
Take sales V-01 and V-02 from the case above and add a fictional ad spend of 300 EUR for the two leads that produced them. If you enter the current quote (1,000 EUR) into the cost per lead and ROAS calculator as if it were the accepted sale, ROAS on revenue comes out at 3.33 (1,000 / 300). With the adjusted sale (750 EUR), which is the correct basis, ROAS drops to 2.50. With net cash received (550 EUR) it drops to 1.83: 82% lower than the figure calculated with the quote. ROAS on margin and break-even ROAS, offered by the same tool, are calculated on that same revenue figure, so they inherit the same distortion, and contribution after advertising ends up overstated in the same proportion. The calculator explicitly asks for the average value of the accepted sale, not of the quote sent or the partial payment: that field is the only correct entry point from this process.
Which basis to use for each report
| Report or decision | Correct basis | Why |
|---|---|---|
| ROAS and cost per lead in the calculator | Accepted sale | It is the field the tool requires; quote and payment distort the result |
| Forecasting future revenue | Current quote | It represents potential, not a closed fact |
| Cash and bank reconciliation | Net cash received | It is the money that has actually come in, after refunds |
| Sales commission, unless policy states otherwise | Accepted sale | It is paid on the closed agreement, not on what has been collected |
Always label the report with the basis it uses. A dashboard that mixes quotes from some leads with payments from others is not comparable with itself from one month to the next.
A minimal worksheet to copy and adapt
Keep a sales table containing sale_id, lead_id, quote version, accepted amount, adjustments and currency; and a movements table containing payment_id, sale_id, date, type and amount. Aggregate movements by sale before joining the commercial table. Joining each payment to each call first can turn two calls and two payments into four rows, duplicating the money.
- Export a period and decide whether the cutoff uses sale date or movement date. Retain both fields.
- Check that every payment identifier appears once. An import retry retains the same identifier.
- Investigate unmatched payments, mixed currencies and negative balances before publishing. A refund without a commercial adjustment may reflect a different situation; do not force reconciliation by deleting a row.
Common mistakes and how to spot them
| Mistake | Symptom | Check |
|---|---|---|
| Adding quote, sale and payment as independent revenue | The reported total exceeds any closed sale in the CRM | Compare the total with the sum of accepted sales for the period |
| Feeding the ROAS calculator with the quote instead of the accepted sale | ROAS rises without any extra closed sales | Check which field the report exports to the calculator or Google Ads |
| Treating Sales Value as confirmed bank receipt | The cash report does not match the bank | Cross-check the amount against the payment record, not only the CRM |
| Joining each payment to each call before grouping by sale | Two calls and two payments produce four rows | Group movements by sale_id before joining them with calls |
| Turning a cancellation into a zero-amount sale | The sales count rises even though business falls | Look for sales with a zero or negative amount with no recorded agreed reduction |
| Changing the basis between periods without noting it | ROAS improves or worsens without the business changing | Check the date the criterion changed in the report history |
When evaluating a campaign, label the indicator as adjusted sales value or cash received, together with its time window. The example does not make ROAS a profit measure or attribute every payment this month to ads from the same month.
From the author's experience
On when a spreadsheet with separate columns stops being enough, there's no universal threshold tied to company size or lead volume: in my experience, the point to move to a tool like WhatConverts arrives when keeping identities, statuses and reconciliations by hand starts producing errors and eating too much maintenance time. It's a reliability signal, not a fixed number of leads per month.
On sales commission policy, I would always document when the commission is earned and how cancellations get adjusted, because I wouldn't attribute a "typical" policy (on accepted sale or on payment received) to clients I haven't specifically identified; documenting each case this way avoids disputes later.
When reviewing integrations between payments and calls, the join error I've seen most often is matching by phone number without respecting one-to-many relationships: a sale with several payments can get multiplied when joined against several calls, inflating the total without anyone noticing until the numbers stop adding up. Of this type of mistake, the ones that most often lead to a wrong ad spend decision are counting quotes as revenue and these join duplicates; the first directly distorts profitability, and the second is the easiest to miss in a quick audit because it hides inside totals that look plausible.
When a revenue report doesn't match the bank, my first check isn't the sale identifier or the payment identifier, it's pinning down the cutoff date and the report's basis first: only after that does it make sense to reconcile payment and sale identifiers against each movement, because without that common ground you end up comparing things that aren't comparable.
Sources and limitations
Documentary review: . Content type: Documentation-based guide with original exercise.
Linked sources describe the terms and capabilities each provider publishes. Examples that use fictional data are labelled in the text.
Scope: Documentation reviewed on 16 October 2026. Examples are fictional and tests are proposed; CallsIQ has not performed product tests.
- Lead Manager documentationwww.whatconverts.com
Check current terms
Consider these options if they solve the problem described. Confirm features, limits and availability in your country.
WhatConvertsAffiliate linkThe labelled commercial links may earn CallsIQ a commission or referral reward. Our commercial policy.
Official sources, explained calculations and clearly labelled examples. Read about our methodology and use of AI in writing.