Several SOS Records Look Right: How to Review Alternative Matches Before Funding

Executive Summary: SOS records returned during business entity verification sometimes fail to produce one clean, unique match, leaving underwriters with a short list of similarly named candidates instead of a single confirmed entity. This article gives an underwriting lead a concrete way to compare those candidates against a borrower's stated identity, a worksheet to record why one entity was selected over another, and an honest look at what a confidence value can and cannot resolve on its own.

Why Do Several SOS Records Look Equally Plausible?

What causes a search to return more than one candidate?

A secretary of state search can return a documented possible-alternative-results response when no exact match exists for the submitted name; the response message says no result was found with the exact name and asks whether one of the alternativeResults was intended, and the documentation notes that the array may be empty^[1]. Separately, when several close candidates exist, Cobalt's help documentation says the API returns up to roughly the top ten alternatives so a team can filter and select the best match by its own logic, for example by city, ZIP, or entity type when several results look similar^[2]. These are two related but distinct situations: a no-exact-match response with possible near matches, and a resolved search accompanied by other similarly named entities worth ruling out. Both put the burden of selection on the reviewer, not the API.

Multiple plausible entities are an expected outcome of how state registries are built and searched. New York's Corporation and Business Entity Database, for example, includes assumed name filings alongside corporations, limited liability companies, and limited partnerships, so a name search there can surface a DBA and a legal entity together^[3]. The same page says the system should not be used to determine the acceptability of an entity name, which is a reminder that the registry is a status-inquiry tool rather than a uniqueness check^[3]. A lender searching a common name in a populous state should expect a short list rather than treat it as unusual.

Why can't the lender just pick the top-ranked result?

Fields in an alternatives response vary by state and by whether an address was supplied with the search. When an address is included, Cobalt retrieves fuller detail for those alternatives, including entity status, filing number, and date; without an address, the response is limited to what is visible on the search results page, meaning names and URLs, with no deeper expansion^[2]. The documented alternative record carries businessName, status, sosId, url, agentName, agentTitle, street, city, zip, state, and a confidenceLevel, plus person fields for a person-name search^[1]. A ranked list built from partial fields cannot substitute for a field-by-field comparison against what the borrower actually submitted. State expansion limits also apply, and Cobalt notes these limits may change if a state system slows down or alters its structure^[2]. A workable policy is to treat the top-ranked candidate as a starting point for review, not as a resolved identity, and to document the specific fields that supported the final selection.

How Should an Underwriter Compare Candidates Against the Borrower?

What borrower-side evidence resolves an ambiguous list?

Several sources of borrower-side evidence can narrow a candidate list before any funding decision references entity status. We recommend treating these as complementary checks rather than a single test:

• Borrower-submitted formation documents. Articles of organization or incorporation carry the exact legal name and formation date the borrower claims, which can be checked against each candidate's name and, once a candidate is expanded into a full record, its filingDate^[1].

• Direct state portal lookup. Running the same query manually on the state's own search database lets a reviewer see the underlying listing and confirm whether the API's candidate list matches what the state actually shows^[3].

• Registered agent and address cross-check. Comparing each alternative's agentName, street, city, and zip against the borrower's stated business address can eliminate look-alike entities registered by unrelated parties^[1].

• State entity ID confirmation. If the borrower can supply a state-issued entity ID from a formation certificate, a lookup by sosId searches on that identifier rather than a name string^[1].

• Written certificate of status request. For a genuinely disputed New York file, a Certificate of Status is issued only by written request naming the exact entity and its DOS ID or formation date, for a fee, so it is reserved for high-value or high-doubt files^[4].

How does an internal document review differ from a direct lookup?

An internal document review relies on what the borrower chooses to submit, which is convenient but incomplete if the borrower supplies an outdated certificate or an assumed name rather than the legal entity name. A direct state portal lookup avoids that dependency but requires staff time per file and does not scale well across a queue of ambiguous matches. For a New York entity, a reviewer can also order copies of filed documents such as certificates of amendment from the Department of State online or by written request, which gives the file the state's own copy of the filing rather than the borrower's copy of it^[5]. Neither approach alone resolves every case; a workable policy combines them, using borrower documents to generate a hypothesis about the correct entity and a direct or API-based lookup to test it against current state data.

What Does an Illustrative Worked Case Look Like?

How would a reviewer walk through a mixed-signal application?

Illustrative worked case, application-example-1, not an observed transaction. Borrower A applies for financing under the legal name "Borrower A LLC." A search returns the documented no-exact-match response with an alternativeResults array containing three candidates: "Borrower A LLC" registered in a neighboring state, "Borrower A Solutions LLC" in the borrower's stated state, and "Borrower A Group LLC" with an inactive status^[1]. None of these is confirmed as Borrower A's entity from the list alone, because the array can return partial fields and does not itself assert which candidate is correct^[2].

The reviewer requests Borrower A's articles of organization, which show a formation date and a registered agent address in the borrower's stated state. Comparing that address against the street, city, and zip fields on the second candidate, "Borrower A Solutions LLC," shows a match on city and ZIP but a discrepancy in the exact legal name. This is the contradiction point: the loan application spells the name without "Solutions," while the state filing includes it. One documented field can help. When a record is expanded, the API returns a searchResultTitle only when the name on the state's results page differs from the name inside the details, which the documentation says can happen when the results list a DBA and the details page lists the legal name^[1]. If that field is present on the expanded record, the reviewer has a documented explanation to test against the borrower's paperwork. If it is absent, the reviewer records the discrepancy as an open item rather than resolving it by inference, and orders a copy of the borrower's most recent amendment filing from the state to confirm whether "Solutions" was added, dropped, or always present^[5].

What should the reviewer avoid doing at this stage?

The reviewer should avoid using the inactive-status candidate, "Borrower A Group LLC," as evidence about Borrower A at all, since an unrelated entity's status carries no information about the applicant. The reviewer should also avoid treating the near-address match on the second candidate as sufficient by itself, because a name discrepancy between application and filing is exactly the kind of contradiction that a numeric confidence value does not settle. This is the practical form of the objection addressed later in this article: a ranking can order which candidate to look at first, but it does not adjudicate a legal-name mismatch.

Which Fields Actually Distinguish One Candidate From Another?

What fields carry the most discriminating value?

Not every field returned in a candidate record is equally useful for distinguishing entities. Entity name and sosId are the strongest discriminators when present; New York, for example, asks for the DOS ID number or exact formation date when processing certificate and copy requests, which shows how the state itself keys its records^[4]. Address fields (street, city, zip, agentName) are the next most useful, particularly when the borrower has supplied a matching address independently through an application form or lease document. Filing date and entity type are useful confirmatory fields but rarely decisive alone, since two unrelated entities can share a formation year and a common entity type such as LLC.

Status fields deserve caution. A candidate's status, or the normalizedStatus on an expanded record, describes that specific listed entity, not the borrower, and should never be read as evidence about which candidate is correct^[1]. New York's guidance cautions searchers not to interpret database results as an indication that a name is or is not available for use^[4]; the same restraint applies to borrowing status from an unconfirmed alternative to describe the applicant.

How should missing or blank fields be treated?

An address-less search returns a shallower version of alternative candidates, limited to names and URLs, because deeper expansion only happens when an address is supplied with the query^[2]. A blank field in that scenario is not evidence of an inactive or missing record; it reflects the scope of the search that was run. We recommend that reviewers re-run ambiguous searches with a known address whenever one is available from the loan application, since this can convert a shallow candidate list into one with filing number and status detail sufficient for comparison. The documentation also shows that a cached search which finds nothing returns a message suggesting a live search of the registry^[1], so an empty cached result is not a finding about the entity either. The documentation also lists a 400 response for a search query that is too short, so a truncated name fragment is rejected rather than matched loosely^[1]. If a record appears on the state's own site but is not returned by the API at all, Cobalt asks that the example be reported directly so coverage can be checked against the state source^[6].

What Decision Table Should Guide the Review?

How can common alternative-match scenarios be organized for consistent handling?

A decision table gives reviewers a consistent reference point instead of relying on case-by-case judgment calls that vary between analysts. The table below is a proposed internal control that organizes common scenarios by the pattern of evidence available and the recommended next step, without assigning a numeric score threshold to any of them.

How does this table change when the search itself is still processing?

Some state searches take longer than 30 seconds to complete. In that case the API returns a documented 202 response with a status of Incomplete, a retryId, and a message that the state is taking longer to acquire the data; the reviewer must check back using that ID, or receive the completed data at a configured callbackUrl, before any comparison against the table above can begin^[1]. Treating a pending retryId response as a no-match or as an empty alternatives list is a process error, not a data finding, and should be handled as a queued item rather than escalated as ambiguous.

What Should a Reviewer Worksheet Capture?

What fields belong on a usable comparison worksheet?

A structured worksheet keeps candidate comparison consistent across analysts and creates a record that a second reviewer or auditor can follow later. We recommend the following as a proposed control, to be adapted to each lender's own file-retention practice, not as a Cobalt feature:

Recommended operating principle: no alternative-match candidate should be treated as the borrower's entity in a funding file until the specific fields that support that conclusion, and any fields that contradict it, are both written down in the same record.

A workable worksheet row includes: the raw name searched, the validated legal name actually used for the query (tracked separately, since Cobalt's batch guidance says keeping the two apart improves reproducibility and lets a team re-run consistently)^[7], each candidate's sosId, address fields, filing date, and status, the borrower document used for comparison, the specific field-level match or mismatch, and the reviewer's decision with a short rationale.

How should the worksheet be stored and referenced later?

The worksheet entry should be saved as part of the underwriting file rather than left inside a search tool's session history, since document URLs returned by lookups are time-limited by default and can be extended only on request, so they will not remain retrievable indefinitely^[8]. Below is an illustrative customer-owned review record showing the shape of a completed worksheet entry, not a Cobalt request or response format.

{
  "recordType": "illustrative customer-owned review record",
  "reviewRecordId": "application-example-1",
  "borrowerStatedName": "Borrower A LLC",
  "actualNameSearched": "Borrower A LLC",
  "candidatesReviewed": [
    {
      "sosId": "SOS-CANDIDATE-01",
      "businessName": "Borrower A Solutions LLC",
      "state": "state-of-formation-example",
      "addressMatch": true,
      "nameMatch": false,
      "searchResultTitlePresent": false,
      "notes": "Street, city and ZIP align with borrower lease document; legal name includes Solutions, application omits it"
    },
    {
      "sosId": "SOS-CANDIDATE-02",
      "businessName": "Borrower A Group LLC",
      "state": "neighboring-state-example",
      "addressMatch": false,
      "nameMatch": false,
      "searchResultTitlePresent": false,
      "notes": "Status inactive; unrelated to borrower address, excluded from further review"
    }
  ],
  "openItems": ["Order amendment filing from the state confirming name history for candidate 01"],
  "reviewerDecision": "unresolved pending state document",
  "reviewedBy": "underwriting-lead-example"
}

How Should the Ranking Objection Actually Be Handled?

Why not just automate selection of the highest-ranked candidate?

The strongest objection to a manual comparison step is straightforward: choose the highest-confidence result and move on, since it will be right most of the time. A confidenceLevel on each alternative, and an aiConfidenceLevel on an expanded record, can order which candidate deserves the first look, and that ordering has real value when a reviewer has ten candidates and limited time^[1]. But the documentation lists those fields without describing how they are calculated, and neither is a comparison against the borrower's own documents. A score cannot detect a discrepancy between an application's stated legal name and a filed amendment, and it cannot substitute for checking whether a matched address belongs to the borrower's business or to an unrelated tenant at the same commercial address.

What is the honest limit of a ranked score?

A score may order review, but it cannot settle an unresolved state ID or a contradiction between the borrower's documents and a candidate record's own fields. Automating candidate selection at the point of highest confidence pushes an unresolved factual question into a funding decision without a written basis for it. This matters most in exactly the case that made the search ambiguous in the first place, when two or more entities share enough of a name that ordinary keyword matching cannot tell them apart. We recommend keeping the ranking as one input on the worksheet, not as the final decision rule, and requiring a documented reason whenever a lower-ranked candidate is selected over a higher-ranked one, since that reversal is where the strongest borrower-document evidence tends to live.

When Does a Confirmed Record Still Fail to Settle the File?

What is a contrasting exception where SOS confirmation is not enough?

Contrasting exception, also illustrative. Entity B searches cleanly with a single exact-match result: one record, correct legal name, active status, and an sosId that matches the state entity ID printed on Entity B's certificate of formation. On the surface this looks like the resolved case the worksheet above is built to reach. But the borrower's loan application lists a different registered agent address than the one shown in the SOS record, and the difference is not a typo, it is a different city entirely. A single confirmed SOS match answers the entity-identity question; it does not answer whether the address discrepancy reflects a recent unfiled move, a data-entry error on the application, or a sign that the applicant is operating under a name that belongs to someone else's registered business.

This exception matters because it shows that a clean match and an ambiguous match can both leave open questions, just different ones. Ambiguous matches raise an identity question. Clean matches can still raise a consistency question between the confirmed record and other parts of the file.

How should this kind of exception be routed differently from an alternatives-list case?

Because the entity identity itself is not in doubt here, this exception does not belong in the candidate-comparison worksheet described earlier; it belongs in a separate address-verification step, since re-running the SOS search will keep returning the same confirmed record and will not resolve an address inconsistency. A workable policy separates these two failure modes explicitly: unresolved candidate identity goes through the comparison worksheet, while a confirmed identity with an inconsistent secondary field goes through a targeted follow-up request to the borrower, such as a recent utility bill or lease agreement showing the current operating address. Treating both problems with the same escalation path tends to slow down the clean-match case without actually adding rigor to it.

How does this fit into a broader verification approach?

An SOS search, resolved or ambiguous, confirms registration-related facts as reported by a state source: name, status, filing history, and related fields as returned by that state's system. It does not by itself establish beneficial ownership, tax identity, or litigation exposure; those are separate questions with their own sources, and mixing them into a single ambiguous status defeats the purpose of a documented review, an idea also raised in related editorial coverage of no-match handling in verification workflows^[9]. The API defaults to live data and accepts a liveData value of false to return cached results^[1]; the tradeoffs between those two modes are discussed in a related piece on primary-source access patterns^[10], and this article's worksheet approach assumes the reviewer records which mode was used for a given search.

Before relying on any lookup as part of a production workflow, we recommend testing it against difficult cases rather than a single clean example, an evaluation approach discussed separately in related coverage of sandbox testing for SOS integrations^[11]. These three references are offered as related reading only; they do not themselves establish current product capability or legal meaning, which rests on the government and API sources cited throughout this article.

A workable closing policy treats every unresolved alternatives list as an open file item with an owner and a next action, not a queue to clear by volume. It records which specific fields supported the final entity selection, keeps the worksheet as part of the underwriting record subject to the lender's own retention practice, and reserves written certificate-of-status requests for cases where borrower documents and SOS fields remain in genuine conflict after the steps above. None of this requires treating a single API response as a funding decision on its own; it requires a documented reason for whichever candidate the file ultimately relies on.

If your team is working through a real batch of ambiguous SOS candidates, bring a specific example to a walkthrough of Cobalt's documented search and alternatives fields at the Cobalt Intelligence demo so the discussion can center on your actual file pattern rather than a generic scenario.