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.
The lesson
These lists usually reward the same discipline: parse by coordinates, count by the field that defines a row (here, the sale date), and cross-check every count a second way before you trust it. An empty-looking row or a floating dollar sign is the file telling you how it was built. Read the construction, not just the content.
If your county publishes an equivalent list, pull it and run the same checks. Find the column that defines a row, count those, and see if a second method agrees.
This is education, not legal advice — operators find and verify; licensed counsel files.