Which signed contracts never updated the opportunity

It is the second working day of the quarter. The VP of Sales wants a clean number, and two people are staring at two different screens trying to produce one.

On the first screen is DocuSign. The revenue operations analyst has the Envelopes view filtered to the last ninety days, status Completed. There are 214 of them. Each row has a subject line, a sender, a list of recipients, and a completion timestamp. Some subject lines are tidy: "Northwind Traders MSA 2026". Others are what a rushed account executive typed at 4:50pm on a Friday: "contract v4 FINAL (updated pricing)".

On the second screen is Salesforce. The sales operations manager has a report of Closed Won opportunities for the same ninety days. There are 187 of them. The gap is 27, and the meeting is in an hour.

The gap is not necessarily 27 real problems. Some completed envelopes are order forms attached to opportunities that closed last quarter. Some are NDAs, which never had an opportunity. Some are renewals booked under a parent account. And some, the ones that matter, are genuinely signed deals sitting in a customer's countersigned PDF while the opportunity in Salesforce still says Negotiation, or Verbal Commit, or Proposal Sent, with a close date that has already passed.

Nobody can tell which is which by looking at either screen. So the analyst starts opening envelopes one at a time, copying the customer name out of the subject line, pasting it into Salesforce global search, and squinting at whatever comes back. Three hours later there is a spreadsheet, and it is stale the moment it is saved.

What DocuSign shows on its own, and where it stops

DocuSign is authoritative about one thing and it is authoritative in a way nothing else in the stack can match: it knows, to the second, that a specific human at a specific email address applied a signature to a specific document, and it holds the certificate of completion to prove it.

The Envelopes view will filter by status, date range, sender, and recipient. It will show you the audit trail: sent, viewed, signed, completed. Custom envelope fields, if your team fills them in, can carry structured metadata alongside the document. DocuSign Reports will chart completion rates and time to sign, and DocuSign CLM will manage the document lifecycle around it. The DocuSign for Salesforce package will write envelope status back onto a record and, configured well, can push the envelope to the right object.

Where it stops is not a reporting shortfall. It is a scope boundary. DocuSign's job ends at "this document was executed." It does not have an opinion about whether that execution should have moved a pipeline stage, because it does not know what a pipeline stage is. Even in a well-run instance where every envelope carries a Salesforce record ID in a custom field, that field tells you which record the envelope was launched from. It does not tell you what happened to that record afterwards. The envelope completed, the integration wrote back a status, and then a human either updated the opportunity or did not. DocuSign never sees the "did not."

And where the integration is not perfectly configured, which is most places, the connection to the deal exists only inside the subject line and the recipient's email domain. Both of those are free text written by a person in a hurry.

What Salesforce shows on its own, and where it stops

Salesforce is authoritative about a different thing: the state of the deal as the company has agreed to represent it. Stage, amount, close date, owner, forecast category, and the full field history of how those values changed and who changed them.

Reports and dashboards over that are genuinely strong. You can build a report of opportunities where Stage is not Closed Won and Close Date is in the past. You can add a filter for opportunities with an attached file, or with a related envelope record if the DocuSign package is installed and writing to a custom object. Einstein and the newer conversational layers will let you ask for a lot of that in something close to plain English.

Where Salesforce stops is at the edge of its own object model. A report can only filter on what has been written into a field. If the envelope status was never written back, or was written to a custom object that the report does not join, the opportunity looks exactly like every other stalled deal. There is no field on the opportunity that says "a countersigned MSA for this customer exists in a system I cannot see."

The strongest available proxy inside Salesforce, opportunities past close date and not closed, is far too broad. It returns every deal that slipped for ordinary reasons alongside the handful that are actually signed. It is a list of suspects, not a list of findings.

Why the gap exists structurally

Line the two halves up and the shape of the problem is clear.

Half the evidence is a record. Half the evidence is a sentence somebody wrote. That is the whole problem, and it is why this is not a missing feature in either product.

Consider what the two categories of adjacent tooling can and cannot reach here. Automation platforms like Zapier and Make are excellent at this exact pairing, and plenty of teams run a Zap that fires on envelope completed and updates the opportunity. That is real and it works. But a trigger based automation acts at the moment an event arrives. It moves the next record forward. It has no view backwards over the 214 envelopes that already completed while the Zap was misconfigured, or before anyone built it, or on the envelopes that were sent from a personal DocuSign account outside the integration. The question here is retrospective by nature: which ones already fell through. Trigger based systems answer "what should happen next," not "what already failed to happen."

BI tools have the opposite constraint. Power BI Copilot and Looker Conversational Analytics are strong over modelled data, and if your DocuSign envelope metadata is landing in a warehouse table then a semantic model over it will join cleanly to Salesforce objects. But the deciding evidence in the ambiguous cases is not in any column. It is the subject line a rep typed, the body of the covering email, and sometimes a line inside the PDF that says this order form supersedes the one executed in March. A semantic layer models tables. A sentence somebody wrote is not a table, and evidence that only exists as prose is outside what a BI tool can see at all.

The gap is not inside either product. It is in the space between a document and a record.

What the join actually requires

The join has one workable key and one unavoidable judgement call.

The key is the recipient email domain plus the signer's email address. Every completed envelope has recipients. Every Salesforce opportunity has contacts and an account with a website. Matching procurement@northwindtraders.com to the Northwind Traders account is reliable in the large majority of cases, and it survives the messy subject line entirely, which is why it beats matching on customer names. Where an explicit Salesforce record ID exists in an envelope custom field, that is better still, and you use it first.

Domain matching breaks in the predictable places: signers using personal addresses, contracts signed by a parent entity for a subsidiary, and shared domains at holding companies and franchise groups. Those need a second pass, usually on the amount in the document or the names of the individuals involved.

The judgement call is harder and it cannot be matched, only read. Once you have paired an envelope to an account, you have to decide what kind of document this was. An NDA signed with a prospect is not a closed deal. An order form for a $40,000 expansion signed against an existing customer is a new opportunity, or an amendment to an open one, depending on how your team books expansions. A renewal executed forty days early may correctly belong to next quarter. A statement of work under an existing MSA may or may not carry its own revenue.

The only place that information reliably lives is the language of the document itself, and the amount fields inside it. Deciding it requires reading the subject line and the first page and then reasoning about which case this is. There is no join key for that, in any system.

Answering it with Skopx

Skopx connects to nearly 1,000 SaaS tools plus databases, DocuSign and Salesforce among them, and you ask it questions in chat. The realistic sentence someone types on that second day of the quarter looks like this:

Pull every DocuSign envelope completed in the last 90 days. For each one, find the matching Salesforce account by signer email domain, then check whether there is an opportunity that closed within 14 days of the signature date. List the ones where there is no matching Closed Won opportunity, and for each, tell me what the document appears to be and which open opportunity on that account it most likely belongs to.

What comes back is a list, not a number, with a citation on every line: the envelope, the completion timestamp, the account, the open opportunity, and the reasoning for the match. Because it reads the subject lines and the document text rather than only the fields, it will separate the NDAs from the order forms, and it will tell you when it is unsure rather than guessing silently. The 27 becomes something like nine genuine misses, eleven NDAs and mutual confidentiality agreements, four renewals booked to a parent account, and three it flags for a human because the signer used a Gmail address.

Once that question is worth asking every week, you can say so in the same chat and get a standing console instead of a repeated conversation. Skopx's Internal Apps feature builds one from a sentence: describe the view you want and it assembles a console over the same live connections. In this case a single table of unreconciled signatures, sorted by document date, with columns for envelope, account, days since signature, likely opportunity, and confidence. Filters for owner and for document type, so a regional manager sees only their own. And next to each confident row, a button that sets the opportunity stage to Closed Won, which does nothing until a person clicks it and confirms.

Honest limits

This does not fix your data at the source. It finds the misses; it does not stop them happening. If the underlying cause is that half your team sends contracts from a personal DocuSign account, the right fix is a configuration change, not a report.

The console stores nothing. It holds no records of its own, keeps no history of what it showed you last Tuesday, and builds no database. It reads live from DocuSign and Salesforce every time it loads, and the single write it can perform is the stage update behind that confirmation button. There are no forms, no scheduled runs, no alerts, and no public links. If a signature comes in on Saturday, nobody hears about it until someone opens the console.

Document classification is a judgement and judgements are sometimes wrong. An order form written in unusual language can be read as an amendment. The confidence flag exists because of this, and the rows it flags need a human. Treat the output as a prioritised worklist, not as an authority.

Access follows your existing permissions. Each person sees what their own connected DocuSign and Salesforce accounts can see, nothing more, which also means a console built by an administrator will look different to a rep. Skopx has SOC 2 controls in place, and contract documents are sensitive enough that it is worth confirming with your own security team before connecting a production DocuSign instance.

And if the reconciliation is genuinely clean already, because the DocuSign for Salesforce package is well configured and every envelope carries a record ID, then you do not need this. Run the question once. If it comes back with nothing, that is a good answer, and it took a sentence.