Today's rep runs a short, fixed motion on a one-page county list: the Richland County, Ohio Clerk of Courts foreclosure excess-funds list (fetched live for this rep; the file's last-modified stamp is August 4, 2026). Source: the Richland County, OH Clerk of Courts excess-funds PDF at richlandcourtsoh.us (one page, last modified August 4, 2026). The page: a single PDF, seven columns — case number, parties name, last known address, property address, date of sale, date paid in, unclaimed amount. What the rep logs, in order: **1. The two dates.** This office pairs a sale date with a "date paid in" — the sale and the money arriving are different events, and this list prints both. Read them row by row: one row on this page prints a paid-in date EARLIER than its sale date. Whatever the explanation is, the record as printed disagrees with itself. The rep: copy both dates exactly as printed and flag the contradiction in your log. Never silently fix a source — a corrected number you can't defend is worse than a flagged one you can. **2. The row count.** Nineteen case rows, nineteen amount cells — every row carries a figure, so no zero-blanks to trip over here. But the page also carries five "Claimed" notes, each hand-dated by the office, and the page's own line reads "ENTRIES IN BOLD ARE NO LONGER ELIGIBLE TO BE CLAIMED." The county is telling you disposition is part of the data. Log each note verbatim and treat the eligibility line as the county's own instruction — do not assume which rows it applies to, because the formatting it refers to is not something you can confirm from a text copy. **3. The two address columns.** This is the part worth the most attention. The page gives you a "last known address" AND a "property address" — and on multiple rows the two strings are different. One party's last known address is out of state entirely. The county hands you where the person WAS and where the property IS. That gap between the two columns is the whole research problem, printed on the page.

This teardown: Hall County, Georgia. Their tax commissioner posts a tax sale excess funds list as a PDF, and it has one of the stranger extraction quirks we've run into. Counts, dates, and column names only below. The file The list is a three-page PDF, and the file identifies itself as a spreadsheet export. It was live-fetched October 24 — HTTP 200, three pages. The filename carries a date of its own, so there are three date sources and two distinct values: the server stamp and the PDF's internal timestamp agree with each other, and the filename date matches neither. The columns: TAX SALE DATE, BUYER, MAPCODE, ORIGINAL OWNER, PROPERTY ADDRESS, CITY, EXCESS FUNDS. The rows Sixty-five dated rows. Sale dates run from November 1, 2016 to July 1, 2025 — a span of eight years and eight months. The distribution isn't even: one year alone accounts for twenty of the sixty-five rows. The newest entry is dated about fifteen months before the file's own timestamps. That gap is data; we're not inferring anything further from it. Every one of the sixty-five rows carries an amount in the excess funds column — verified with a coordinate-based parse, not a glance. We publish counts, never the amounts themselves. The quirk Open the raw text layer and the dollar signs are not attached to the numbers. Each "$" is its own text element, sitting in a fixed right-hand column of the page, and in extraction order it comes out after the number it labels. Flat text extraction hands you the amount, then a stray dollar sign. That's not corruption — that is the order the text layer carries. It's the difference between a PDF's visual layout and its text layer. If you parse by coordinates, your amounts come out separated from their currency marks — expected, not an error. And a pattern expecting a currency mark immediately before the digits won't line up with this file's token order; matches, if any, will be mis-paired. One more trap: the file's last two rows are effectively blank. No sale date, no buyer — just two floating dollar signs and two lone dashes. Count rows by counting dollar signs and you get sixty-seven. Count rows by counting sale dates and you get sixty-five. The two extra rows carry only a currency mark and a dash — stubs, not listings. Any script that aggregates this file needs to know that before it reports a row count or a total.