Your most expensive salespeople
are engineers.
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.
The sales cost sitting in your R&D line.
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.
Reported CAC vs. true CAC.
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 number due diligence will recalculate.
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.
How long does a technical evaluation actually take?
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.
Your engineers stop being the qualification layer.
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.
One audit, start to finish.
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.
You supply the inputs
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.
The model applies published rates to your numbers
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.
You get the reconciliation
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.
One person is accountable for your audit.
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.
What we've measured, and how.
Every figure below states its source or its method. Where neither exists, the figure is not here.
Fully loaded cost per SDR
Bridge Group 2025 SDR report, n=351 B2B companies. Midpoint $130k. A US benchmark, quoted in USD rather than silently converted.
Loaded cost ÷ budgeted cost
The range this calculator produces across its input bounds. Not an average of anyone: your inputs decide where you land in it.
Mid-market audits
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.
Questions from finance and revenue leaders.
Still have questions about your specific environment?
Book a technical deep-diveThe 2026 Sales
Infrastructure Checklist
Stop leaking margin on admin work. Get the precise 12-point infrastructure audit we use to identify €1M+ in hidden sales waste.
- Hidden SDR overhead benchmarks
- CRM data integrity audit protocol
- AI Agent integration readiness map