On this page
The short version
MQL vs SQL comes down to who has judged the lead: a marketing qualified lead (MQL) has met marketing's criteria for fit and engagement, and a sales qualified lead (SQL) has been checked by sales and confirmed as a real buying opportunity. RevSure, the agentic GTM platform built on the Full Funnel Data Graph, matches leads, contacts and accounts across CRM and marketing records so both counts trace back to the same people.
In September, the marketing operations team at a security awareness software company held a working session with RevSure on one question: did the MQL count RevSure reported match the count in the team's own reports? The marketing lead driving the rollout described years of everyone questioning whether the funnel numbers they saw were accurate, and nothing would go to a wider audience until the numbers held up lead by lead.
The first comparison left 662 leads in the team's reports that did not line up with RevSure's MQL count. The gap came from how the company's records were matched and dated, which is where MQL and SQL counts usually drift apart.
MQL vs SQL: what is the difference?
A marketing qualified lead is a person marketing has judged ready for a sales conversation, based on who they are and what they have done, while a sales qualified lead is a person sales has spoken to or reviewed and confirmed as a potential deal. In other words, the SQL is sales' verdict on marketing's prediction, and two more stages are worth defining before any numbers are compared.
Marketing qualified lead (MQL). A lead that has passed a threshold marketing owns, usually a score built from fit (title, company size, industry, region) and engagement (form fills, demo requests, content downloads, event attendance). RevSure's post on why the MQL stopped predicting revenue covers the case for moving beyond it, but most teams still report it.
Sales accepted lead (SAL). An MQL that a sales development rep or account executive has reviewed and agreed to work.
Sales qualified lead (SQL). A lead sales has qualified after contact, usually against a framework covering need, authority, budget and timing. An SQL is the point where sales puts its own judgment on the record.
Sales qualified opportunity (SQO). An SQL that has been converted into an opportunity in the CRM and meets the entry criteria for pipeline, such as a confirmed use case and a next meeting booked. RevSure's sales pipeline guide covers the stages after it.
How do MQL, SAL, SQL and SQO compare?
Each stage has a different owner, and each count fails in its own way.
The last column of the SQO row is the one that breaks most funnel reports. When an opportunity has no lead or contact on it, marketing's MQLs and sales' pipeline sit in two unconnected sets of records, and every conversion rate between them becomes an estimate.
What happens at the MQL to SQL handoff?
The handoff is the moment an MQL leaves marketing's queue and lands with a named person in sales. Ownership changes hands there, and the record often changes object too, from lead to contact or onto an opportunity.
A service level agreement between marketing and sales makes the handoff measurable. A useful SLA covers both sides:
- Marketing's commitment: the MQL definition in writing, the volume expected per month or quarter, and the fields every MQL arrives with (source, campaign, score reason, account).
- Sales' commitment: a time limit for first contact, a time limit for accepting or rejecting the lead, and a required rejection reason chosen from a fixed list.
- Recycling rules: what happens to a rejected or unresponsive lead, how long it rests in nurture, and what it must do to qualify again.
- Review rhythm: a shared monthly look at acceptance rates, rejection reasons and leads that breached the SLA.
The rejection reason is the field most teams leave optional and most regret. Without it, a falling MQL to SQL rate cannot be split into "marketing sent the wrong people" and "sales did not follow up".
How do you calculate the MQL to SQL conversion rate?
The MQL to SQL conversion rate is the share of MQLs that go on to become SQLs:
MQL to SQL conversion rate = SQLs that came from the MQL cohort ÷ MQLs in the cohort × 100
The word that matters is cohort. Take an illustrative company with these Q3 numbers:
- 1,200 leads became MQLs between 1 July and 30 September.
- By 31 October, 840 of those had been accepted by sales (SALs) and 300 had become SQLs.
- Inside Q3 itself, sales recorded 330 SQLs: 270 from those leads and 60 from leads that first became MQLs in Q2.
The cohort method gives 300 ÷ 1,200 = 25%. The period method, dividing all SQLs created in Q3 by all MQLs created in Q3, gives 330 ÷ 1,200 = 27.5%. The two answer different questions: the cohort rate tells you what happened to the leads marketing produced, and the period rate tells you how busy sales was. Report the cohort rate for funnel quality, give the cohort time to mature before reading it, and label which method a slide uses.
The same example yields two more rates worth watching. MQL to SAL is 840 ÷ 1,200 = 70%, which measures how many leads sales agreed to work. SAL to SQL is 300 ÷ 840, about 36%, which measures how many accepted leads qualified. A drop in the first points at lead quality or routing; a drop in the second points at qualification or follow-up.
Published benchmarks rarely state their stage definitions or counting method, so your own cohort rate over several quarters is the more useful comparison. RevSure's post on trusting MQL pipeline forecasts covers how those rates feed a forecast.
Why do marketing and sales count MQLs differently?
Most disagreements between marketing's MQL number and sales' number trace to six causes, and only one of them involves the definition itself.
Leads and contacts are different objects. Marketing automation often counts people, while the CRM may hold the same person as a lead, then as a contact once converted. A report built on the lead object loses everyone converted during the quarter; one built on contacts misses everyone still unconverted.
Duplicates and secondary emails. The same person signs up with a personal address and later with a work address, or exists twice after a list import. One system merges them and the other counts two MQLs.
Lead-to-account matching. A lead with no account attached cannot be rolled up to the account a sales team reports on. When matching depends on exact company names or one email domain, subsidiaries and regional domains fall out of the account view.
Definition drift. The score threshold or the fast-track list changes mid-quarter. Reports built before the change and reports built after it count different populations, and neither says so.
Recycled leads. A lead that qualifies, goes quiet and qualifies again can produce several MQL events. One report counts every event; another counts the person once; a third dates the MQL to the latest event and moves it into a different quarter.
Timing. The MQL date, the date sales received the lead and the SQL date can fall in different weeks or quarters. A report on "MQLs this month" in one tool and "leads handed to sales this month" in another will rarely agree.
These causes sit in the data model, the matching rules and the way stages are timestamped, which is why reconciliation happens record by record.
How do you reconcile MQL and SQL counts?
Reconciliation explains the differing records group by group until what remains is small enough to accept or fix.
The security awareness software company's 662 unmatched leads were people in the team's own reports who did not appear in RevSure's MQL count. The first pass worked through how the company's records were matched, including secondary email addresses the team had pointed out, so a person filed under a second address was no longer counted as missing. After it, 154 of the 662 were left.
The next group came from the way the company had recorded MQL movements. A RevSure analyst opened one lead's history on screen: a pre-MQL event in 2025, a Salesforce lead created, then a run of MQL events back to back over six or seven months with no other stage change between them. In the team's reports, leads like this carried a different MQL date. RevSure treated the run as one qualification and kept a single MQL timestamp, so the lead was in both counts, dated differently. Adding that timestamp to the comparison left 63.
The team member from marketing operations who ran the validation summed up where that left them: "Things are so low now that I'm pretty confident in in the data." They signed off on the MQL numbers on the call, and sales accepted leads were next in line, since the team's SAL logic builds on the MQLs.
The method generalizes to any team:
- Write down both definitions exactly as each report applies them: object, threshold, date field and whether repeats count.
- Export the records, not the totals. Compare lists of people with their IDs and emails, so every difference is a named record.
- Match on more than one key. Primary email, secondary email, CRM ID and account, in that order, before calling a record missing.
- Group the differences by cause using the six causes above, and fix the largest group first.
- Choose one timestamp rule for repeat MQLs and apply it in every report.
- Have the owners sign off. Marketing and sales operations approve the definition and remaining exceptions in writing.
Lead-to-account matching deserves its own check. RevSure's guide to buying groups covers the same problem from the account side.
Where does the Digital RevOps Analyst help?
The reconciliation above took a RevSure analyst and the customer's team several calls in one week, and its checks need repeating whenever data, definitions or routing change. Several of those checks match jobs listed for RevSure's Digital RevOps Analyst.
Its data quality job is described on RevSure's page as: "Monitor data health, deduplicate records, enrich missing fields, and check process compliance across the funnel." That covers the duplicate and secondary-email work. People keep the decision: the page says the human role "Approves fixes and owns policy exceptions."
Its funnel job analyzes conversion, velocity and leakage from lead through MQL, SQL, opportunity and pipeline, refreshed daily, with conversion reports and leakage diagnoses as outputs. The definitions stay with the team, which "Decides on process redesign and funnel-definition changes." For the handoff, the routing job recommends changes to assignment rules and SLAs and alerts on SLA breaches, while the team "Sets routing policy and escalation judgment."
On supervision, RevSure's digital workers page says: "Your team sets the strategy and approves exceptions. RevSure's own GTM engineers manage the digital worker day to day and are accountable for the completion and quality of the work it delivers." For the step before the handoff, the Digital SDR post on lead ranking shows how leads are prioritized once they qualify.
What a reconciled MQL count changes
Once two teams accept the same MQL count, a drop in the MQL to SQL rate becomes a question about lead quality or follow-up that someone can answer, instead of a figure each side discounts.
For the security awareness software company, sign-off on MQLs ended a debate the team had carried for years. The remaining 63 did not need to reach zero. The large gaps had ordinary, named causes in the company's own records, and a short list of outliers is something a team can work through and defend to anyone who asks.
FAQs
What is an MQL?
An MQL, or marketing qualified lead, is a lead that has met marketing's criteria for being ready to talk to sales. The criteria usually combine fit, such as title and company size, with engagement, such as a demo request or repeated content downloads. Marketing operations typically owns the definition and the scoring threshold behind it.
What is the difference between a SAL and an SQL?
A sales accepted lead is an MQL that sales has reviewed and agreed to work, usually within an SLA time limit. A sales qualified lead has gone further: sales has made contact and confirmed need, authority, budget and timing or an equivalent. Acceptance says a lead deserves a conversation, and qualification says the conversation found a possible deal.
How do you calculate the MQL to SQL conversion rate?
Divide the SQLs that came from a group of MQLs by the number of MQLs in that group, then multiply by 100. For example, 300 SQLs from 1,200 MQLs created in one quarter is 25%. Track the rate by cohort, give the cohort time to mature, and say which counting method each report uses.
Why don't marketing and sales MQL counts match?
The usual causes are leads and contacts stored as different CRM objects, duplicate people with more than one email address, leads not matched to accounts, a definition that changed mid-period, recycled leads counted once or several times, and different date fields. Comparing the underlying records rather than the totals shows which cause is behind each difference.
How does RevSure help reconcile MQL and SQL numbers?
RevSure matches leads, contacts and accounts across CRM and marketing data in the Full Funnel Data Graph, so funnel counts trace to named records. Its Digital RevOps Analyst monitors data quality, deduplicates records and analyzes conversion and leakage from lead to pipeline. People on the customer's team approve fixes and decide any change to funnel definitions.