Two Verification Providers Disagree: Compare the Entity and Evidence Before Choosing a Result

Executive Summary: Verification providers disagree more often than risk teams expect, and the disagreement usually says more about what each product was asked than about which one is wrong. This article gives US alternative business lenders a reconciliation method: compare the underlying entity, source date, and returned fields before ranking one provider's label above another, using a worked example, a decision table, and a reviewer worksheet built for that purpose.

Why Do Two Business Verification Results Ever Disagree?

What actually differs between two providers answering the same question?

When Provider X returns "active" and Provider Y returns "not found" for what looks like the same business, the first assumption on many desks is that one vendor is simply wrong. That framing skips a prior question: did both providers search the same identifier, in the same jurisdiction, on the same date? A state search can be run by business name, by state entity ID, or by a person's name, and each entry point can surface a different candidate set^[1]. Name-based search in particular depends on how the query string was normalized before submission, since raw client input and the validated legal name copied from a state site are not always identical^[2].

Why can a single official source produce two different answers?

New York's own guidance to searchers illustrates why this matters even for a single official source. The state's corporation and business entity database is explicitly described as a status-inquiry tool, not a name-availability determination, and users are cautioned against treating a search result as proof that a name is or is not in use^[3]. The same database is stated to update daily, and its completeness depends on filing history ranges that vary by entity type and formation era^[3]. A provider pulling from that database at 8 a.m. and a provider pulling at 6 p.m. the same day can legitimately return different snapshots without either being defective.

• Different identifiers. A search keyed to a state entity ID will not necessarily return the same candidate as one keyed to a business name, since name matching and ID lookup are distinct request modes^[1].

• Different jurisdictions searched. A provider checking only the formation state will miss a foreign-qualification filing that another provider checked in a second state.

• Different point in time. State systems are updated on their own schedule, and a same-day comparison can still straddle a filing event.

• Different candidate selection. When several similarly named entities exist, one provider's matching logic may promote a different top result than another's^[4].

• Different scope of fields returned. One product may expose officer names, filing history, or UCC data while another returns only status and address, making the disagreement partly a coverage gap rather than a factual conflict.

A workable operating principle: treat any provider conflict as an entity-and-date mismatch until both underlying source queries are confirmed identical, not as a verdict on either vendor's accuracy.

How Should a Reviewer Compare What Each Provider Actually Searched?

What identifiers need to match before a disagreement is even meaningful?

Before debating which status label to trust, a reviewer should confirm four identifiers line up across both results: the legal name string actually submitted, the state or states searched, the entity type filter applied, and the state-assigned identifier if one was returned. Cobalt's documented search endpoint accepts a business name query, a state entity ID (sosId), or a person's first and last name, with state required for any of these unless a retryId is supplied to check on a prior request^[1]. A reviewer who only knows "we searched Entity B" without recording which of these three entry points was used cannot later explain why two systems produced different candidates.

Tracking the literal input matters for exactly this reason. A workable internal practice is to keep a field for the raw client-submitted name and a separate field for the name actually run against the source, since the two are often not the same string once a DBA, abbreviation, or punctuation difference is involved^[2]. This also makes it possible to rerun the same query later and know whether a changed result reflects a state-side update or simply a different input.

How does address information change what gets returned?

Address parameters change scope, not just precision. When a street, city, or zip is included in a Cobalt request, the API checks the top candidate set and returns fuller detail for those matches, including entity status, filing number, and date; without an address, the response is limited to what appears on the immediate search results page, meaning names and URLs without deeper expansion^[4]. Two providers configured differently on this single parameter can legitimately return different depth of evidence for the same underlying entity, which looks like disagreement but is really a scope difference.

• Search identifier used. Name string, state ID, or person name, each following a different match path^[1].

• State or states queried. Formation state alone versus formation plus foreign-qualification states.

• Address parameters supplied. Presence of street, city, or zip expands candidate detail; absence limits the response to page-level data^[4].

• Entity type filter. New York's own database allows filtering by entity type, which can silently exclude a valid match if set incorrectly^[5].

• Candidate count reviewed. A vendor showing only its top match versus one showing up to roughly ten alternatives^[4] will disagree simply because one truncated the list.

What Role Does the Source Date Play in a Disagreement?

Why can the same state record produce two different snapshots?

A record's currency is not guaranteed to be identical across two calls even to the same official source. New York states that its corporate database is updated daily, and cautions that a name-availability determination applies only to the date and time the search was completed^[3]. That single sentence is a useful discipline for any provider comparison: a status is a statement about a moment, not a permanent fact. When Provider X and Provider Y disagree on entity status, the first question is not which one is correct but which one is more recent, and whether either result reflects a live pull versus a stored one.

Cobalt's API distinguishes these explicitly through the liveData parameter. By default the parameter is true and returns live, fresh data; sending false requests cached data instead^[1]. When liveData is true but a live lookup fails, or the state site is down for maintenance, the response can include a message field stating that a live search could not be completed but recent data exists, or that the state is currently down for maintenance but recent data is available^[1]. A reviewer who sees this message and treats the returned result as equivalent to a fresh live pull is making an error the API itself flagged.

How should a reviewer record the timestamp difference?

The response body also carries createdAt and updatedAt fields, which populate when liveData is set to false, giving a reviewer a way to check how old a cached record is^[1]. Log that timestamp alongside every provider result used in a credit or onboarding file, so a later disagreement traces to a stale cache rather than reopening as a fresh dispute. Related internal commentary describes cached responses as faster but limited to periodic snapshots that can miss very recent registration or status changes, while live retrieval reflects current state but can take longer depending on the state queried^[6]. That is a documentation-level tradeoff description, not a claim that any state completes in a fixed number of seconds.

• Record the pull mode. Was liveData true or false for this specific call^[1]?

• Record any fallback message. A returned message about failed live lookup or state maintenance changes how the result should be weighted^[1].

• Record createdAt/updatedAt when present. These only populate on cached responses and establish an age for the record^[1].

• Record the calendar date of comparison. Two pulls on different days are not directly comparable even from the same source^[3].

• Note state-side update cadence. New York's own site states daily updates; other states may differ, so do not assume uniform freshness^[3].

What Does a Worked Reconciliation Case Look Like?

How would a reviewer walk through Borrower A and Entity B?

The following is a hypothetical illustrative case, not an observed customer or transaction. Borrower A submits a loan application listing "Entity B LLC" as the operating business. An internal analyst runs one verification provider that returns an "inactive" status, while a second provider, queried the same afternoon, returns "active." Before treating this as a fraud flag or an accuracy failure, the analyst works the comparison in order.

The identifiers differ. Provider one was queried by the raw name "Entity B" with no state entity ID; provider two used a state ID captured from a prior filing. Cobalt's search endpoint treats sosId and searchQuery as distinct entry points that can each surface a different top candidate^[1], so this alone could explain why the two results describe different rows, particularly if "Entity B" resolves to more than one similarly named filer.

The jurisdictions differ too. Provider one searched only the state on Borrower A's mailing address; provider two also searched the state of formation named on an older document Borrower A supplied, a common mismatch when a business is foreign-qualified away from where it was formed. So does the pull mode: provider two's response carries a message saying the live lookup failed and recent stored data was returned instead^[1], so its "active" label may reflect an older snapshot rather than the current afternoon. Provider one's was a live pull with no fallback message.

What resolves the case once the four points are logged?

The field scope differs last: provider one returned only status and address, while provider two also returned a filing date and registered agent, because an address parameter in that request expanded the alternatives detail returned^[4]. The disagreement is therefore explained by a stale cached pull on provider two combined with a narrower jurisdiction search on provider one, not by either vendor's fundamental inaccuracy. The analyst then reruns a live, address-qualified search against the correct jurisdiction as the resolving step, and documents that decision in the customer-owned file rather than simply picking whichever label looked more favorable.

Which Decision Table Helps a Reviewer Choose a Result?

How should conflicting fields be weighed against each other?

A decision table gives a reviewer a repeatable way to rank evidence rather than defaulting to whichever provider was queried first or whichever label is more convenient. The table below is a proposed internal tool, not a Cobalt feature, and should be adapted to each lender's own file-documentation standard.

What should a reviewer do when the table produces a tie?

Ties happen, particularly when both results are cached and both carry a fallback message. In that scenario, a workable next step is to attempt a fresh live pull against the correct jurisdiction and identifier rather than splitting the difference between two stale answers. If a live pull is not immediately available, a documented decision to hold the file for manual confirmation, referencing the specific unresolved fields, is preferable to silently accepting either provider's label.

How far to take any of this depends on what the disagreement actually changes. When the conflicting field does not move the decision, say both results agree the entity exists and is registered in the state that matters and the conflict is a formatting difference in the agent's name, log the conflict on the worksheet and proceed. Reserve the full reconciliation for files where the conflicting field is the one the credit decision rests on. The paths also differ sharply in what they cost. A fresh live pull and a direct state portal check both return inside the reviewer's own session. Asking Borrower A for the certificate of formation or a recent annual report usually returns faster than the state does, because the borrower already holds the paperwork. A written request to the Department for copies or a Certificate of Status carries a per-copy fee and its own processing queue, with expedited handling available for an additional fee^[7], which places it on files that cannot move without it. A second-analyst review costs another reviewer's time and adds no new evidence, so it belongs at the end of that ladder rather than the start. The obvious objection is that a reviewer should just take a majority vote when a third provider is available. That assumes an independence between sources that often does not exist, since multiple commercial products draw from overlapping state portals, so three vendors agreeing can mean three vendors hit the same stale snapshot on the same day.

What Belongs on a Reviewer Worksheet for Disagreement Cases?

What fields should the worksheet capture for every conflicting result?

A structured worksheet keeps the reconciliation from becoming an ad hoc argument between two analysts who each prefer a different vendor. The fields below are a proposed customer-owned template, to be stored in the applicant's file alongside whatever underlying documents Borrower A submitted.

• Applicant and entity identifiers. Borrower A's application ID and every string used for Entity B, including any DBA variant.

• Provider and query mode per result. Provider, identifier type (sosId, name, or person name), and the state passed^[1].

• Pull mode and fallback text. Whether liveData was true or false, and the exact wording of any fallback message^[1].

• Timestamp evidence. Date and time of each pull, plus createdAt/updatedAt when cached^[1].

• Fields actually returned. Including whether address parameters were supplied to expand the response^[4].

• Reviewer's resolving action. Rerun live, request a borrower document, or escalate, with the reason recorded.

How should the resolving decision be recorded for later audit?

Recording the decision, not just the raw results, is what makes the worksheet defensible later if a regulator, auditor, or internal quality reviewer asks why a file was approved despite a documented discrepancy. The record below is an illustrative customer-owned review record, not a Cobalt request or response, and shows the level of detail a workable policy would capture.

{
  "review_id": "application-example-1",
  "borrower_name": "Borrower A",
  "entity_name_searched": "Entity B LLC",
  "provider_results": [
    {
      "provider": "provider_one",
      "identifier_type": "name_string",
      "state_searched": "state_x",
      "pull_mode": "live",
      "fallback_message": null,
      "status_returned": "inactive",
      "fields_returned": ["status", "address"]
    },
    {
      "provider": "provider_two",
      "identifier_type": "sos_id",
      "state_searched": "state_x",
      "pull_mode": "cached",
      "fallback_message": "recent data returned after failed live lookup",
      "status_returned": "active",
      "fields_returned": ["status", "filingDate", "agentName"]
    }
  ],
  "reviewer_action": "rerun_live_with_address_parameter",
  "resolution_notes": "cached result likely stale; live rerun requested before final file decision",
  "reviewed_by": "analyst_example",
  "reviewed_date": "example_date_only"
}

Which Alternative Approaches Exist Before Escalating a Provider Dispute?

What can a reviewer do directly with the state source?

Before treating a provider disagreement as unresolved, a reviewer has at least three independent paths available, and none require a new vendor contract. The first is a direct authority lookup against the relevant Secretary of State site. New York's own corporation and business entity database is publicly searchable by name or ID and filterable by entity type^[5], and the Department describes that online search as intended for status inquiries of entities already on file^[3]. This direct check will not resolve every ambiguity, since the Department also cautions customers against reading database search information as an indication that a name is or is not available for use^[3], but it does let a reviewer see the same field set a vendor drew from, on the current date.

The second path is certified documentation from the state. New York allows written requests for copies of filed documents, including certificates of incorporation or amendment, for a stated per-copy fee^[7], and a Certificate of Status can be requested in writing for a stated fee^[3]. These carry more evidentiary weight than any vendor's cached snapshot, and they are specific to the requesting state.

What can a reviewer request from the borrower directly?

The third path is asking Borrower A directly for source documents: the certificate of formation, a recent annual report filing, or a registered agent confirmation letter. Treat what comes back as a corroborating input to be dated and filed, not as an automatic override of either provider's result, since self-supplied documents can also be outdated or altered.

• Direct state portal check. Confirms the current field set at the reviewer's own query time^[5].

• Certified document request. Provides a state-issued document with its own fee and processing timeline^[7].

• Certificate of Status request. A written request to the Department for a stated fee, sometimes called a Certificate of Good Standing^[3].

• Borrower document request. Corroborating but not conclusive; date and file any documents received.

• Internal escalation to a second analyst. Useful when the worksheet fields alone do not clearly favor one result.

How Does a Cobalt-Style Product Bridge Fit Into This Process?

What documented product behavior actually supports reconciliation work?

Once the manual comparison paths above have been exhausted or judged too slow for volume, a documented API can add structure without replacing the reconciliation judgment itself. Cobalt's search endpoint supports the same three identifier types discussed earlier: business name, state entity ID, or person name, always paired with a required state parameter^[1]. This matters directly for the worksheet, since recording which identifier type was used is one of the core reconciliation fields.

The liveData parameter, defaulting to true, is how a reviewer distinguishes a fresh pull from a cached one, and the fallback message when a live lookup fails or a state is under maintenance makes that an explicit signal rather than an inferred one^[1]. The alternatives list, capped at roughly the top ten candidates, lets a reviewer see more than a single top match and filter by city, zip, or entity type^[4], which supports the identifier-matching step in the decision table. Some requests take longer than 30 seconds, in which case a retryId is returned, and longer-running work can route through a callbackUrl so the result posts asynchronously^[1].

What scope limits should a reviewer keep in mind when using this product?

These are documentation-described behaviors, not guarantees for every state or query. Coverage parity with a state's own site is an ongoing effort rather than a fixed claim, and Cobalt asks users who find a record its search does not return to report the example so the discrepancy can be investigated^[8]. Document links are described as time-limited by default, with an extension available on request^[9], and the screenshot option returns a short-lived URL^[1], so a reviewer who wants a source image should save the retrieved content rather than the link. None of this output is a credit decision, a sanctions determination, or a legal clearance. It is one documented input into a reconciliation the reviewer is already performing.

For broader context on structuring these situations as workflow states rather than an undifferentiated queue, related commentary on classifying no-match causes is worth reviewing as background reading, though it is editorial material and not itself evidence of current product behavior^[10].

How Should a Lender Structure an Exception When the Comparison Method Itself Fails?

What happens when neither provider's evidence is sufficient to decide?

Not every disagreement resolves cleanly through the worksheet and decision table. Consider a contrasting exception: Provider one and Provider two both return "active" status for what appears to be the same business, so on the surface there is no disagreement at all. But a closer field-by-field check shows the registered agent name differs materially between the two results, and neither provider's response includes a filing date recent enough to confirm which agent is current. This is a case where apparent agreement masks an unresolved discrepancy in a different field, and a reviewer who stops at the status label alone would miss it.

In this exception, the worksheet's field-level comparison matters more than the top-line status match, because two providers can agree on the headline field while conflicting on a supporting one. Run the same comparison already described against the agent name specifically, rather than treating status agreement as full reconciliation.

Why does this exception argue against a simple vote-based rule?

This exception is also the clearest answer to the majority-vote objection: a vote only works if the disagreement is visible at the field being voted on, and two providers agreeing on status while conflicting on agent name would look like consensus to any vote count. A sandbox-style evaluation that tests only the easy case, a well-known active entity that resolves quickly, will not surface a masked field conflict, because that pattern confirms only the one thing every vendor already does well^[11]. Run the full field-comparison worksheet on a sample of agreeing results periodically, not only when the top-line label conflicts, and record it in the same customer-owned format used for outright disagreements.

If your team is weighing how to formalize this kind of reconciliation for your own application volume, bring a concrete scenario, including the specific identifiers and states involved, to a walkthrough at Cobalt Intelligence's demo page so the discussion can work from your actual comparison cases rather than a generic one.