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 |
The whole exercise, including the manual check on the three flagged rows, takes under five minutes. Doing the same 74-row extraction by copying and pasting from the PDF, then manually reformatting the columns and eyeballing every VIN by hand, is realistically closer to an hour and a half for someone working carefully — and considerably longer for someone doing it for the first time.
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.
How accuracy is actually measured
A field accuracy figure only means something if it's clear what counts as correct. Here, a field is scored against the actual text on the source document — a financed amount, a date, or a VIN is correct if it matches what's printed, not if it matches what a downstream match expects it to be. That distinction matters because a statement itself can occasionally contain an error, and the conversion's job is to report what the document says, not to silently correct it toward what seems plausible.
VINs are held to a stricter standard than other fields, since a checksum gives an objective pass/fail test that dollar amounts and dates don't have. A VIN that passes checksum validation is reported with high confidence; one that fails is flagged regardless of how legible it otherwise looks, because a checksum failure means at least one character is provably wrong even when it's not obvious which one.
Why speed matters beyond convenience
Converting a statement in under a minute instead of an afternoon isn't just a time savings — it changes when the conversion happens at all. A task that takes an afternoon gets scheduled, batched, and often delayed until several statements have piled up. A task that takes a minute gets done the moment the statement arrives, which means the data behind it is current rather than a week or two stale by the time anyone looks at it.
That shift matters most for anything time-sensitive downstream — a curtailment due date is only useful as a warning if it's surfaced with enough lead time to act on it, and a VIN match ahead of an audit is only useful if it's run close enough to the audit date that the inventory snapshot is still accurate.
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.
It's also useful for anyone building a historical record of floorplan activity — a bookkeeper closing out a month who needs curtailment fees broken out by unit, or a controller assembling a year's worth of statements ahead of an annual credit review who would otherwise be retyping the same columns from a dozen separate PDFs.
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.
A statement showing a partial curtailment payment — an amount less than the full scheduled curtailment, sometimes applied when a dealership pays down part of a balance without a full scheduled payment — is captured as its own line rather than merged into the regular curtailment figure, since collapsing the two would make it impossible to tell later whether a unit's curtailment obligation was actually met in full.
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.
This is also what makes a year-end or credit-review request painless rather than a scramble — instead of pulling twelve months of PDFs and reformatting them under deadline, the structured history is already there, ready to filter or summarize however the request actually needs it.
What a flagged field actually looks like
A flagged field doesn't mean the conversion failed — it means the tool is deliberately declining to guess. The review interface shows the extracted value directly alongside the cropped source image for that specific field, so confirming or correcting it takes a glance rather than a hunt back through the original PDF to find where the number came from.
Most flags resolve in seconds once the source image is visible next to the value — a smudge on a printed statement, a digit partially obscured by a fold line, or simply a font that renders one character ambiguously. The flag exists precisely so that kind of ambiguity gets a human decision instead of a silent guess baked into the output spreadsheet.
On a typical statement, flagged fields are the exception rather than the rule — a handful out of dozens or hundreds of rows, not a constant back-and-forth. That ratio is what makes the review step fast in practice rather than just fast in theory: most of the spreadsheet needs no attention at all, and the few rows that do are easy to spot and quick to resolve.
Over repeated use, the flag rate on a given lender's statement format tends to drop further still, as the underlying extraction adapts to that lender's specific layout quirks — the second statement from a given source is typically cleaner than the first, and it keeps improving the more that lender's specific format gets processed, since there's less about the layout left to be unfamiliar.
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.