A Court Case Is Closed: Read the Disposition Before Updating the Credit File

September 11, 2026
September 11, 2026
14 Minutes Read
Business Verificationblog main image

Executive Summary: A court case is closed does not tell a reviewer whether the borrower won, lost, settled, paid, or walked away from an obligation, and treating a closed status as a stand-in for any of those outcomes creates a credit file that cannot be defended later. This article works through how closed dispositions actually vary, why a single closed label hides several different legal and financial endings, and how a reviewer can build a documented process that separates what the record says from what the file assumes.

What Does a Closed Case Actually Tell a Reviewer?

Is closed the same as resolved in the borrower's favor?

No. Under New York's official glossary, a disposition is the result of a judicial proceeding, and that result can arrive through withdrawal, settlement, order, judgment, or sentence[1]. Each of those five paths closes the case, but they describe entirely different outcomes for the parties. A withdrawal means the plaintiff dropped the matter, which says nothing about whether money changed hands. A settlement means the parties reached an agreement whose terms may not appear in a summary record. An order or judgment means a court made a determination, and a judgment specifically determines the rights of the parties[1]. A reviewer who sees "closed" and stops there has learned only that the litigation stage ended, not which of these five doors the case walked through.

Does dismissed always mean the debt disappeared?

Not necessarily, and the distinction matters more than most closed-status labels convey. The New York glossary defines a dismissal as the termination of a proceeding for a procedurally prescribed reason, then separates dismissal with prejudice, which is on the merits and prevents renewal of the same claim, from dismissal without prejudice, which is not on the merits and may be re-instituted[1]. By the glossary's own terms, a dismissal without prejudice does not decide the merits of a claim; the current filing ended and the claimant retains the option to bring it again. A reviewer who reads "dismissed" as "dispute over" has conflated a procedural outcome with a financial one. The docket summarizes the case, but the judgment is what actually determines rights[1], so a docket summary showing dismissal is not equivalent to a judgment showing no liability. These are New York definitions describing New York procedure, not a universal statement of legal consequence across every jurisdiction[1], so a reviewer working outside New York should confirm local terminology before applying this framework.

Why Does Closed Not Equal Paid?

What is the gap between a disposition and evidence of payment?

The disposition answers a procedural question: how did the litigation end. It does not answer a financial question: did money actually move. A judgment determines the rights of the parties[1], but a judgment in the plaintiff's favor is a legal entitlement to collect, not proof that collection happened. The glossary makes this visible in its definition of execution, which includes supplementary proceedings to enforce a judgment and, for a monetary judgment, a direction to the sheriff to take the steps needed to collect it[1]. In other words, the entry of a money judgment can be the start of a collection process, not its end. Settlement agreements close a case, but a docket is defined as a document which summarizes a case[1], so the agreement's payment terms, schedule, and whether the debtor actually performed may not be visible in that summary at all. A reviewer treating "settled" as "paid in full" is filling a gap with an assumption the record does not support. The honest posture is to label the payment question as unresolved until separate evidence, such as a satisfaction of judgment, a release, or borrower-provided documentation, actually answers it.

Why does the objection "closed means settled and settled means paid" fail?

This is the exact chain a reviewer should resist. Closed only confirms the litigation stage ended[1]. Settled only confirms the parties reached an agreement, not its content or its performance. Paid is a separate factual claim that requires its own evidence. Collapsing three distinct questions into one inference is the most common failure mode in credit file updates built from court search hits, and it is the reason a documented review step should require the reviewer to name which of the three questions the available record actually answers before the file is updated.

How does an illustrative worked case apply these three questions?

This is an illustrative worked case, not an actual customer or transaction. Borrower A applied for financing through Entity B. A court search returned a case captioned with Entity B as defendant, with a status field showing "closed." The reviewer's first instinct was to mark the file as showing resolved litigation with no further obligation. Applying the framework above, the reviewer instead asked three separate questions. First, what disposition path closed the case: the available record showed a settlement, not a judgment or dismissal[1]. Second, what did the settlement actually say about payment: the summary record did not disclose settlement terms, so this question remained unanswered from the court record alone. Third, was there separate evidence of performance: none was yet in the file. Rather than updating the credit file to reflect a cleared obligation, the reviewer logged the case as "settled, payment terms unknown" and flagged the file for a request to Borrower A for documentation, such as a settlement agreement or release, before any credit conclusion was recorded. This kept the file's language matched to what the source actually supported.

How Do Different Case Types Reach Closure?

What basic procedural stages lead to a closed case?

New York's official guidance on the basic steps in a court case describes a plaintiff starting the case and a defendant responding, with the matter potentially proceeding through motions and trial before any disposition is reached[2]. A counterclaim, where the defendant brings its own claim against the plaintiff, can also be part of the same case[1]. This matters for credit review because a case captioned with the applicant's business as defendant may actually resolve with a counterclaim in the applicant's favor, or the case may never reach a merits decision at all if it settles or is withdrawn early. The procedural stage at which a case closes shapes how much can reasonably be inferred from the closure itself.

Should procedural orientation be mistaken for proof of liability?

No. The basic steps page is procedural orientation for people representing themselves, not a source for proving liability or collection outcomes[2]. A reviewer who wants to know whether Borrower A actually owes money after a case closes needs the disposition type, and ideally the underlying order or judgment document, not just confirmation that a case existed and proceeded through the ordinary stages. Where the record shows only that a case was filed and later closed, without specifying which of the five disposition paths applied, the reviewer should treat the outcome as undetermined rather than defaulting to either a favorable or unfavorable assumption.

Which glossary terms separate a decision, an order, and a judgment?

Three terms that look interchangeable on a status screen are defined separately in the New York glossary, and the differences change what a reviewer may record. A motion is a request by a party for a ruling or order, and an order is an oral or written direction of a court or judge[1]. An order can therefore resolve one motion inside a live case without ending the case. A decision is the determination reached by a court in a proceeding and is described as the basis of the judgment, while the judgment itself is the determination of the rights of the parties that refers to and states the result of a verdict or decision[1]. For a credit reviewer, this sequence matters: a docket note showing a decision means the court has ruled, but the file should still locate the judgment that states the result before recording an amount owed or a finding of no liability. Recording "order" when the source says "judgment," or the reverse, changes the meaning of the entry, so the worksheet described later in this article asks for the source's own term rather than a paraphrase.

How Should a Reviewer Compare Source Status to Order?

What decision table separates disposition types from appropriate next steps?

The table below is a proposed reviewer reference, not a Cobalt feature or an automated decision. It maps disposition language a reviewer might encounter to the appropriate handling, based on the New York glossary's categories[1].

Disposition Language SeenWhat It EstablishesWhat It Does Not EstablishRecommended Reviewer Action
WithdrawalPlaintiff dropped the caseWhether any payment occurredNote as withdrawn; request confirmation if material to underwriting
SettlementParties reached an agreementPayment terms or performanceRequest settlement documentation before crediting resolution
OrderCourt issued a direction on a specific matterFull case resolution unless the order closes the caseRead the order text; do not assume final outcome
DecisionCourt reached a determination that is the basis of a judgmentThat a judgment has been entered or satisfiedLocate the judgment that states the result of the decision
JudgmentCourt determined the parties' rightsWhether the judgment was satisfiedCheck for satisfaction of judgment or release
Dismissal with prejudiceClaim was dismissed on the merits and cannot be renewedWhether any amount was ever paidNote as final on this claim; payment status still separate
Dismissal without prejudiceClaim was dismissed not on the merits and can be re-institutedThat the matter is overTreat as unresolved; monitor for refiling

How does this table change what gets written into the file?

The table forces the reviewer to write two separate lines into the file: the disposition category and the payment status, rather than one combined "closed, resolved" note. This separation is what allows a later reviewer, or an auditor, to see exactly what evidence supported each conclusion, rather than inheriting an assumption baked into a single vague status word.

What Should a Reviewer Worksheet Include Before a File Update?

What fields belong on a proposed review checklist?

A workable policy is to require a documented worksheet entry for every court hit that could affect a credit decision, before the credit file is changed. We recommend the following as a proposed control, owned and applied by the lender's own review process, not a Cobalt feature:

• Disposition type. Record the specific category shown, whether withdrawal, settlement, order, judgment, or sentence, using the source's own language rather than a paraphrase[1].

• Prejudice status if dismissed. Record whether a dismissal was with or without prejudice, since only the former forecloses re-filing of the same claim[1].

• Payment evidence present or absent. Record whether the file contains a satisfaction of judgment, release, or borrower-provided proof of performance, separate from the disposition entry.

• Source completeness. Record whether the case record includes case details and documents, or only top-level fields, since Cobalt's documented New York response gives the first result more fields than later results in the same array[3].

• Reviewer conclusion and open items. State plainly what remains unknown, rather than defaulting to a resolved status when evidence is incomplete.

An operating principle worth adopting: never let a single status word carry more weight in the credit file than the underlying order or document actually supports.

How should incomplete records be handled on the worksheet?

Where a record shows only a caption and a status with no documents attached, the worksheet should mark that field as incomplete rather than inferring the missing detail from the pattern seen in other, more complete records. A related discussion of court search detail levels makes the same point: applying the interpretation supported by a detailed first result to every later result is the practical mistake to avoid[4]. A worksheet that does not separately track completeness risks treating a thin record with the same confidence as a fully documented one. Retained documents raise a second housekeeping point. Settlement agreements, judgment papers, and releases often contain personal information about principals or guarantors, and the Federal Trade Commission's business guidance recommends keeping only the personal information a business needs, protecting what it keeps, and writing a records retention policy that states what must be kept, how long, and how it will be disposed of[5]. A court-hit worksheet should therefore point to where the supporting document is stored and under which retention rule, rather than pasting the document contents into the credit note.

What does an illustrative customer-owned review record look like?

Below is an illustrative customer-owned review record, not a Cobalt request or response, showing how a lender might structure the worksheet output for a single court hit tied to application-example-1.

{
  "recordType": "illustrative-customer-owned-review-record",
  "applicationReference": "application-example-1",
  "borrowerLabel": "Borrower A",
  "entityLabel": "Entity B",
  "caseCaptionAsReturned": "Entity B, defendant",
  "sourceCompleteness": "top-level-only-no-documents",
  "dispositionCategory": "settlement",
  "dispositionTermAsShown": "settled",
  "prejudiceStatus": "not-applicable",
  "paymentEvidencePresent": false,
  "supportingDocumentLocation": "not yet obtained",
  "openItems": [
    "request settlement agreement from borrower",
    "confirm legal entity name against state registry"
  ],
  "reviewerConclusion": "unresolved-pending-documentation",
  "reviewDate": "internal-use-placeholder"
}

Keeping dispositionCategory and paymentEvidencePresent as distinct fields, rather than a single combined status, is what allows the file to show exactly what was known at the time of review. If a settlement document later arrives showing full payment, the record is updated by changing paymentEvidencePresent and supportingDocumentLocation, not by rewriting the disposition history, which preserves an accurate timeline for anyone auditing the file later.

What Alternative Approaches Exist Before Any Product Bridge?

What can a reviewer do using direct authority lookups?

A reviewer can go to the state's own registry or court portal directly. For New York business entities, the Department of State's Corporation and Business Entity Search Database returns current entity name, date of organization, jurisdiction if other than New York, county location, service of process address, registered agent if any, and current status, and the state says this information is updated daily[6]. This does not substitute for a court disposition, but it helps confirm which legal entity is actually named in a case caption, since the Department describes that online search as intended for status inquiries of entities already on file[6], and the search page itself cautions that the information's completeness and accuracy cannot be guaranteed[7]. Certified or plain copies of filed entity documents can be requested from the Division of Corporations for a fee, which gives a reviewer a primary document rather than a summary field[8]. On the court side, the glossary defines a caption as the heading of a court paper showing the names of the parties, the court, and the case number, and an index number as the county clerk's identifier for a civil case[1]. We recommend recording the caption and index number from any court hit, because those identifiers are what a reviewer needs to locate the order or judgment itself rather than relying on a status word.

What can borrower-provided documents and internal review add?

A second approach is requesting the underlying documents directly from the borrower: the settlement agreement, the judgment itself, or a satisfaction of judgment or release. This shifts the evidentiary burden to a document the reviewer can read in full, rather than a status word summarized by a third party. A third approach is internal review discipline: requiring a second reviewer to independently name the disposition category and payment status before a file update is finalized, which catches cases where the first reviewer's shorthand notes collapsed a settlement into an assumed payoff. Both approaches are proposed controls that a lender designs and owns; they do not depend on any particular data vendor.

Where Does a Bounded Product Bridge Fit in This Workflow?

What does Cobalt's Court Cases endpoint actually return?

Cobalt's documented Court Cases API accepts a required business name, a required jurisdiction of newYork or miamiDade, and a required callback URL, because the search is processed asynchronously and the result is delivered to that callback rather than in the initial response[3]. The documentation notes that sample data can be returned with the testNewYork or testMiamiDade jurisdiction values, and the documented 400 response for a missing jurisdiction states that the available jurisdictions are newYork and miamiDade[3]. The New York response example returns a first, most detailed result with url, status, caption, courtCaseType, searchType, a documents array, caseDetails, plaintiff, petitioner, and defendants fields, while subsequent results in the same array carry only url, status, caption, courtCaseType, and searchType[3]. The Miami-Dade response example returns a different field set, including caseInfo, caseType, caseStatus, caseFiled, local, state, and consolidated case numbers, and a judicial section[3]. This is documented scope: two jurisdictions, asynchronous delivery, and fields that vary in completeness by result position, not a claim of nationwide court coverage or automatic disposition interpretation.

How should a reviewer use this data without over-reading it?

A related internal discussion of repeat defendant detection describes Cobalt's court data as covering New York State and Miami-Dade County, while stating plainly that the customer owns the matching logic, escalation policy, and final decision, and that the API should be read as a data source rather than a decisioning engine[9]. Applied to closed-case review, this means a caseStatus or status field returned by the API is an input to the worksheet described above, not a replacement for reading the disposition and any attached documents. Where the New York response includes a documents array, each entry carries a document name, URL, the party that filed it, and a document status[3]; those are the pointers a reviewer follows to the order or judgment rather than evidence of the outcome by themselves. The reviewer still separates disposition category from payment evidence, still checks whether a given result is the detailed first record or a thinner subsequent one[4], and still resolves borrower identity carefully, since a DBA on an application may not match the legal entity name the court or state registry actually shows[10].

What Exception Should a Reviewer Watch For?

When does a closed status carry less signal than usual?

Contrast the worked case above with a narrower exception. Suppose a court search for Entity B returns a later result in the array with a status and caption but no documents, no case details, and no party fields beyond what the caption shows. This is the thin-record pattern in Cobalt's documented New York example, where results after the first carry only top-level fields[3]. In this exception, the reviewer cannot even confirm which disposition category applies, let alone the payment question. The correct handling is not to guess based on the status word alone, but to mark the case as unidentified-pending-further-record, use the caption and index number to locate the court's own record, and pursue a document request from the Division of Corporations if the entity identity itself needs confirmation[8].

Why does this exception change the reviewer's obligation?

This exception matters because it shows the worksheet is not just for well-documented cases. A thin record with only a status field is exactly the situation where a reviewer is most tempted to fill the gap with an inference, since there is so little else to go on. The proposed control here is to require that thin records receive the same "unresolved, pending documentation" label as ambiguous settlements, rather than a lighter review simply because less data is available. Less evidence should never translate into more confident conclusions recorded in the file.

If your team is working through closed-case review for an active credit file and wants to see how Cobalt's documented Court Cases endpoint fits into a workflow like the one described here, bring your specific scenario to the Cobalt Intelligence demo page and walk through the jurisdictions and record types most relevant to your applications.

References

1. Glossary, New York State Unified Court System

2. Basic Steps in a Court Case, New York State Unified Court System

3. Cobalt API documentation: Court Cases, Cobalt Intelligence

4. Court Search Results Have Different Detail Levels: Do Not Review Every Hit as a Full Case, Cobalt Intelligence

5. Protecting Personal Information: A Guide for Business, Federal Trade Commission

6. FAQs: Corporations & Business Entities, New York Department of State

7. Corporation and Business Entity Search Database, New York Department of State

8. Copies of Corporation or Business Entity Documents, New York Department of State

9. Detecting Repeat Defendants in Lending Applications, Cobalt Intelligence

10. DBA vs Legal Entity: Resolve the Borrower Before Business Verification, Cobalt Intelligence