Best Case & bankruptcy software

Getting client data into Best Case: manual entry, questionnaires, and OCR

Best Case will produce a clean petition once the data is in it. Getting the data in is the part nobody budgets for. Every consumer case starts as a stack of paper and PDFs — a completed intake questionnaire, pay stubs, tax returns, a vehicle title, a shoebox of collection letters — and none of that is machine-readable in a form the petition software can consume. Something has to convert it into fields.

There are three realistic paths: a person re-keys the packet by hand, the client types their own answers into an online questionnaire, or software reads the paper form and generates a case file the petition software can open. Each shifts the work to a different party and produces a different failure mode. This article walks through all three, then covers how to evaluate any import path before you route live cases through it.

Petition prep starts with data entry, not with the petition

A consumer Chapter 7 with forty creditors requires several hundred discrete data points: names, addresses, account numbers, balances, claim classifications, income detail for Schedules I and J, asset descriptions and values, exemption citations, transfer history for the Statement of Financial Affairs, and every entry that becomes the creditor matrix. On most cases, assembling and entering that consumes more staff hours than reviewing the finished schedules. Any efficiency conversation that starts at the petition software has already skipped the expensive part.

Option 1: manual re-keying from the intake packet

The default nearly everywhere. A paralegal opens the intake packet, opens Best Case, and types. It requires no new tooling, works with any packet in any condition, and puts a trained human eye on every figure — which is a genuine quality control benefit, not just a fallback. An experienced preparer will also catch what is missing: no landlord listed but rent claimed on Schedule J, a co-signed loan mentioned in conversation but absent from Schedule D.

The costs are time and a predictable set of transcription errors. The failures cluster in specific places:

  • Transposed digits in account balances and account numbers — the single most common error and the hardest to catch by re-reading.
  • Creditor addresses copied from an old statement rather than the current notice address, producing undeliverable matrix mail.
  • Ambiguous handwriting resolved by guessing instead of by calling the client.
  • Income figures entered as gross where net is required, or a biweekly figure entered as semimonthly.
  • Items on the intake form that are simply skipped because a page stuck to the one behind it.

None of these are exotic. They surface at the 341 meeting, in a trustee’s document request, or in an amendment the firm absorbs at its own cost — the patterns are catalogued in our guide to petition data entry errors. The other cost is opportunity: at meaningful volume, keying is the constraint that determines how many cases a firm can take without another hire.

Option 2: client-facing online questionnaires

The obvious fix is to make the client do the typing. Several vendors offer web questionnaires that walk a debtor through the same territory as a paper intake form and feed the answers into the petition product. Check what your version of Best Case supports directly with Stretto’s current documentation, since available integrations and the fields they cover change between releases.

When it works, it works well: the client answers at their own pace, validation catches blank required fields, and the data arrives structured. It works best with organized clients who are comfortable online, have their documents at hand, and have a reason to be thorough — often the higher-income Chapter 13 filer.

It works less well across a general consumer practice. A meaningful share of debtors will not finish a long web form: no reliable computer, a phone-only household, low literacy, or simply the exhaustion that brought them to a bankruptcy attorney. Firms that adopt questionnaires generally end up running both systems, because paper never fully goes away — see why handwritten intake forms persist. A half-finished submission also creates its own work: staff must reconcile what the client entered against what they brought to the appointment.

Option 3: reading the paper form with OCR and human confirmation

The third path keeps the paper form the client is willing to fill out and moves the transcription off staff. The completed packet is scanned, software reads the handwriting and printed text, and the extracted fields are mapped to petition fields and written into a case file the petition software can open — for Best Case, its own .BCB case file format. Casewell works this way: multi-pass OCR with consensus scoring, a review screen where staff confirm low-confidence fields against a crop of the original handwriting, and an exported .BCB that imports into Best Case.

The important design point is not the OCR accuracy number a vendor quotes. It is that handwriting recognition is probabilistic, so any responsible implementation has to surface its own uncertainty rather than silently guess. A “7” that might be a “1” in a loan balance must be flagged for a human, shown next to the original image, and confirmed — not averaged into a plausible-looking number. Evaluate this category on the quality of the confirmation step and the review trail, not on the extraction claim.

Comparing the three paths

Most firms end up using more than one path, matched to the client rather than applied uniformly.
ApproachStaff timeTypical failure modeClient burdenSetup cost
Manual re-keyingHighest; scales with volume.Transposition and omission errors that surface after filing.Low — one form to fill out.None.
Client online questionnaireLow when completed, high when abandoned.Non-completion, plus unverified self-reported data.High — the client does the data entry.Moderate — configuration and instructions.
OCR plus human confirmationModerate — review rather than type.Misread handwriting confirmed without checking the image.Low — the same paper form.Moderate — scanning and a review habit.

How to evaluate any import path

Whatever route you consider, test it the same way. Vendor demos use clean data; your clients do not produce clean data.

  1. Confirm the file actually imports. Run a real generated file into your version of Best Case and open the case. A file that drops a schedule or needs manual repair every time is not an import path.
  2. Check field coverage explicitly. Ask which fields are populated and which are left blank. Schedules D, E/F, I, and J and the matrix are where the volume is; the Statement of Financial Affairs and exemption citations are often thinner.
  3. Look for a review trail. You need to know what was extracted, at what confidence, who confirmed it, and what the original showed. Without that, an attorney signing under penalty of perjury is trusting a black box.
  4. Test with your worst packet. Cramped handwriting, cross-outs, two different pens, an addendum stapled to the back.
  5. Time the whole loop. Measure scan through reviewed, importable case — not extraction alone. A tool that reads in ten seconds and needs forty minutes of correction has saved nothing.
  6. Keep the attorney review step. No import path removes the obligation to review the schedules before signing.

One structural note: the source form matters as much as the software reading it. A packet organized in the order of the schedules, with unambiguous fields and enough writing space, produces better results through every path — including a paralegal typing it by hand. Fixing the form is the cheapest improvement available, and the current Official Forms on uscourts.gov are the right structure to mirror.

What is a .BCB file?

It is the Best Case case file format. Any tool that claims to hand data to Best Case should be able to produce a file that opens cleanly in your version — ask to see that happen during evaluation rather than taking it on description.

Can I import a spreadsheet of creditors?

Support for spreadsheet or matrix imports varies by version and configuration. Check Stretto’s current documentation for what your installation accepts, and test with a real matrix before relying on it.

Does OCR mean the paralegal stops reviewing the data?

No. It changes the task from typing to verifying. The paralegal confirms flagged fields against the original handwriting and still reviews the assembled schedules for completeness and internal consistency.

Is client-entered data more reliable than staff-entered data?

Not inherently. Clients avoid transcription errors but introduce misunderstanding — a gross figure listed as net, an omitted debt, a misclassified secured claim. Both paths need review.

This guide is general information for law-firm staff, not legal advice for any particular case.