Demos, integrations and POCs are sales work. On most P&Ls that engineering time is coded to R&D, which means reported CAC excludes it.
Demos, integrations and proof-of-concepts are sales work. On most P&Ls the engineers who run them are coded to R&D instead of Sales & Marketing, so the cost of winning the deal sits one line away from where it gets measured.
Expenses are classified by the nature of the activity, not by the department that books them. R&D tax guidance makes the same distinction: only work aimed at developing or improving a product qualifies, and engineering time has to be tracked to separate the qualifying half from the rest. Running a demo does not develop anything. It closes a deal.
Our working estimate is that correcting the coding moves reported CAC by up to 40%. That is our own figure from the engagements we have run, not a published benchmark, and we would rather you tested it against your own books than took it from us.
Your own inputs will land somewhere else, most likely in the 1.6x to 2.7x range this calculator produces across its bounds. It computes the ratio from your numbers, not from an industry average, and it prices only this half. The R&D row above has no equivalent figure because none exists that we can stand behind.
Unit economics are only as good as the coding underneath them. When pre-sales engineering time sits inside R&D instead of Sales & Marketing, the R&D vs S&M coding produces misallocated costs, and reported CAC never sees the difference. Loaded cost per engineer belongs in the same column as loaded cost per SDR, because both are being spent to close the same deals. Until that split is corrected, P&L accuracy is the thing actually at stake, not the CAC number itself.
The board narrative you're presenting assumes reported CAC is the real cost per new logo. A due-diligence team will not take that on trust; they will trace engineering allocation back through the P&L and recompute true CAC themselves. Whatever number comes out the other side becomes the one that matters, and the gap between it and what's in the deck is due-diligence risk you carry into exit readiness conversations without knowing its size. Left uncorrected, it also sets a scaling ceiling: a growth plan priced on the wrong CAC is a growth plan that runs out of runway earlier than the model says.
Ask five reps and you'll get five different answers, because nobody on the team is tracking the technical evaluation timeline as its own stage. That gap shows up everywhere: in deal velocity nobody can explain, in an AE-to-SE ratio that keeps drifting without a stated reason, in a win rate at evaluation stage that gets attributed to the deal instead of the process. Forecast accuracy assumes every stage takes a knowable amount of time, and this is the one stage where that assumption has never been tested.
Spec review, integration scoping and technical qualification happen before anything reaches an engineer's calendar. A human engineer joins when the deal is qualified, not when the question arrives.
Six different tasks, one line on the P&L. All of it books to R&D, and none of it is research or development.
The method, in full, before you enter anything. If a step here does not hold up, the output does not either. You should be able to see that from the outside.
Headcount, base salary, OTE, which overheads you carry, turnover over the last two years, ramp time, and current meeting volume. Team aggregates, never individual employee records.
Employer taxes and benefits as a percentage of base, tooling and workspace per head, management time allocated across the team, and turnover priced as separation plus ramp. Every rate is visible in the tool and every figure is derived from what you entered.
Budgeted cost, fully loaded cost, the ratio between them, and cost per meeting. No comparison against a peer set we have not shown you, and no benchmark we cannot source.
What the tool does not yet measure is engineering time spent on demos, integrations and technical evaluations. That is the larger half of the argument on this page, and it is the part an audit adds. Run the audit to price the visible half first.
Lorenzo Pecora
Founder
I’m personally accountable for every audit this site produces and every agent we put into production. Demos, integration scoping and technical qualification are sales work, but on most P&Ls that time is coded to R&D, so it never shows up in CAC and never gets fixed. I built Upsimplify to move that cost back onto the right line and to run each deployment myself, so there is one person, not a delivery team, who answers for the number.
Every figure below states its source or its method. Where neither exists, the figure is not here.
Bridge Group 2025 SDR report, n=351 B2B companies. Midpoint $130k. A US benchmark, quoted in USD rather than silently converted.
The range this calculator produces across its input bounds. Not an average of anyone: your inputs decide where you land in it.
Manufacturing and Fintech. Outcome averages across these are not published here, because the sample is too small to report honestly as a range.
Encrypted in transit and at rest, hosted on AWS.
Still have questions about your specific environment?
Book a technical deep-diveStop leaking margin on admin work. Get the precise 12-point infrastructure audit we use to identify €1M+ in hidden sales waste.