A statement built for reading, not spreadsheets
A dealer statement from a floorplan lender is designed to be read top to bottom by a person — every financed VIN listed with its payoff amount, floor date, and curtailment schedule, formatted as a PDF or a portal export. What it isn't designed for is being dropped straight into a spreadsheet for matching against a lot inventory or a cost report.
That gap — a document readable by eye but not directly usable in a spreadsheet — is what this tool closes. Upload the statement, get back a structured file with one row per unit, ready for the reconciliation work that actually needs it in that form.
Why copy-paste doesn't work
Selecting text out of a dealer statement PDF and pasting it into a spreadsheet usually produces a mess — VINs split across two lines, columns for financed amount and curtailment date collapsed into one, dollar formatting stripped or shifted. Fixing that by hand, for a statement listing dozens or hundreds of units, takes longer than most people expect before they try it once.
The underlying problem is that a PDF encodes visual position, not table structure — a converter has to reconstruct which numbers belong to which column, which is exactly the part copy-paste skips.
What gets extracted
Every unit's VIN, financed amount, floor date, curtailment schedule, and any fees shown on the statement, plus statement-level totals for cross-checking the row-level data against.
Why VIN accuracy is the whole point
Every other field on a dealer statement can tolerate a small extraction error without breaking anything downstream — a financed amount off by a rounding difference gets caught the moment it's checked against a total. A VIN doesn't have that safety net. A single wrong character produces a string that either matches nothing in your inventory or, worse, happens to look plausible while being wrong.
That's why VIN extraction here is treated differently from every other field. Every seventeen- character VIN is run through the standard checksum calculation before it's accepted, and any VIN that fails is flagged with the source image shown alongside it rather than silently passed through as if it were reliable.
This matters more than it might seem, because a converted spreadsheet is rarely the end of the workflow — it's almost always a starting point for a VIN match against lot inventory. A conversion tool that gets every other field right but lets VIN errors through quietly would be worse than one that's slower but catches them.
Formats this handles
Standard PDF dealer statements, scanned or photographed statements, and portal exports saved as PDF — the layout is read directly from whatever's uploaded rather than matched against one fixed template, so different lenders' statement designs are handled the same way.
Scanned and photographed statements
Not every dealer statement arrives as a clean digital PDF. Some lenders still fax or mail printed statements, which get scanned in at the dealership, and some office managers photograph a page on a phone when a digital copy isn't handy. Both are handled the same way as a native PDF, with OCR applied first to recover the text before the same layout-reading and field-extraction process runs.
Image quality does affect confidence scores — a low-resolution photo with glare across a VIN column is more likely to produce a flagged field than a clean scan — but it doesn't change the workflow. A flagged VIN on a photographed statement gets the same side-by-side source image for a quick manual check as a flagged VIN on a digital PDF.
How it works
Upload the statement
Drag in a PDF, scanned file, or portal export.
Layout is read
Columns and rows reconstructed from the document's actual structure.
Fields extracted
VIN, amounts and dates pulled with a confidence score on each.
VINs checksum-validated
Any VIN that fails validation is flagged, not guessed at.
Exported
Excel, CSV or JSON, one row per financed unit.
A statement, converted
A 12-page dealer statement listing 74 financed units is uploaded as a PDF. All 74 rows are extracted in under a minute, with 71 VINs passing checksum validation cleanly and 3 flagged for a quick visual check — two turn out to be correct on inspection, one had a genuine OCR misread on a smudged digit, corrected by referring back to the source page shown alongside the flagged row.
| Result | Count |
|---|---|
| Rows extracted | 74 |
| VINs passing checksum cleanly | 71 |
| Flagged for review | 3 |
| Genuine correction needed | 1 |
Manual vs. automatic
| Manual | Automatic |
|---|---|
| Copy-paste breaks columns and splits VINs | Layout reconstructed into proper columns |
| VIN typos caught only when matching fails later | Every VIN checksum-validated on extraction |
| Redone by hand for every statement page | A multi-page statement converted in one pass |
| Hours for a large statement | Under a minute for most statements |
What people do with the spreadsheet
Most commonly, the converted statement feeds straight into a VIN match against a lot inventory export — see the floor plan audit tool for that specific workflow. Others use it to feed curtailment due dates into a calendar or reminder system, or to bring per-unit financed amounts into a per-VIN cost report — see unit-level cost matching.
Who uses this
Dealer principals and controllers who need statement data in a spreadsheet without retyping it, office managers preparing audit documentation, and multi-rooftop groups consolidating statements from several lenders into one working file.
Edge cases worth knowing
A statement spanning multiple pages with units split across the page break is reassembled correctly — a unit isn't treated as two separate partial rows just because its line happened to fall at a page boundary.
A statement that includes non-vehicle line items, like a flat account fee not tied to a specific VIN, is extracted separately from the per-unit rows rather than forced into a row that doesn't actually represent a vehicle.
Consolidating statements from several lenders
A dealer group running more than one floorplan line ends up with statements in different formats arriving on different cycles from different lenders. Converting each independently and combining the results into one working spreadsheet is a common pattern — each statement is read for its own layout, so a difference in how one lender presents curtailment dates versus another doesn't require a separate setup step.
The output columns stay consistent across lenders even when the source documents don't, which is what makes combining them into one consolidated file straightforward rather than another manual reformatting exercise.
Building a statement history over time
Converting a single statement solves the immediate need. Converting every statement on a recurring cycle — weekly or monthly, depending on how often the lender issues one — builds something more useful: a running history of financed amounts, curtailment activity and fees per unit over the unit's entire time on the lot.
That history is what turns a one-off conversion into a dataset worth keeping. A unit's full carrying-cost trajectory, not just its most recent statement line, is what actually explains why one vehicle's true cost diverged from another's over time.
What this doesn't do
Doesn't match the statement to your inventory automatically
That's a separate step — see the floor plan audit tool for VIN-by-VIN matching.
Doesn't calculate curtailment amounts owed
It extracts the schedule as reported on the statement; it doesn't recompute it.
Doesn't submit anything to your lender
It's a read-only conversion of the document you upload.
Security and privacy
Uploads are encrypted with TLS from end to end.
Processing runs on infrastructure with SOC 2-aligned controls.
Original documents are deleted shortly after processing.
Nothing you upload is ever used to train AI models.
Details are on the security page.