Automated bankruptcy-filing reader
Creditor List Extractor
Hundreds of pages of creditors become an auditable spreadsheet in minutes, with tax IDs validated and liability deviation down from 46% to 0%.
- faster on a 120-page PDF (45 → 5.5 min)
- 8×
- deviation in extracted liabilities (was 46%)
- 0%
- automated tests
- 354
- file extensions accepted
- 10
Figures measured from the repository.
Processing time
120-page PDF, ~7,000 creditors
- AI on every page~45 min
- Native text first~5.5 min
Extracted vs. printed liabilities deviation
same document
- Before the reader fix46%
- After0%
Context and problem
In Brazilian judicial-recovery filings, the creditor list arrives as PDFs hundreds of pages long, sometimes scanned, with the same list printed in several layers (consolidated, per company, related parties) and totals and subtotals mixed in. To assess exposure, someone had to transcribe creditors, tax IDs and amounts by hand: slow and full of traps, from duplicated creditors to postal codes summed as amounts.
The processor reads PDFs, images and spreadsheets, extracts creditors and amounts, validates tax IDs, merges by company-ID root and attaches an analysis-ready spreadsheet to the CRM, with a review queue for whatever does not add up.
Constraints I set myself
- Extraction output is a guess, not data. Everything is validated before it reaches the CRM, and failures become human review.
- The sum must close. The extracted total is compared with the total printed in the document.
- AI only where needed. It is costly and slow, and it gets amounts wrong where native text already works.
- An auditable list. Every row must be traceable back to its source page.
Decisions that shaped the product
Architecture
The file is read as native text first, using coordinates and tables. OCR only runs on pages with no text, at higher resolution when needed. Pages are classified so the same list is never summed twice, and AI only looks at what is still suspicious. Then come normalization, validation, merging by company-ID root and a spreadsheet attached to the CRM.Invalid check digit, unresolved document, zero or out-of-range amount, or an amount above the printed total: the row goes to a human review queue and never reaches the CRM. A file whose company under recovery cannot be identified is blocked entirely.
Spreadsheets skip PDF reading and go straight to normalization. Pages are processed in parallel, with workers capped to the container’s available CPUs, and a cache keyed by the file hash avoids reprocessing the same document.
My role
Everything: from the prototype, a simple script with a minimal UI, to the current version, with a modular extraction core, an API, a React interface, a scheduler, the quality gate and 354 tests, including per-case regression tests.
What the product delivers
- Flexible input: native or scanned PDFs, six image extensions and spreadsheets.
- Single and batch processing, with history and a scheduled mode that deduplicates repeated files.
- A final spreadsheet for the CRM, plus CSV and an executive PDF summary.
- A review screen for the rows the quality gate held back.
What I would do differently
- Test against the extractor’s real output. A regression test passed for weeks with hand-injected data while the real fix never ran in production.
- One schema for the creditor record. A new field had to be remembered in five places, and forgetting one made the data disappear silently.
- An end-to-end smoke test for every export. One endpoint failed on every call until someone actually used it.