Convert PDF to CSV: which route works for the file you have?

It depends on how the PDF was made, and one test tells you which case you are in. Open it and try to select a line of text. If it selects cleanly the characters are in the file and a table extraction tool can reconstruct the columns. If nothing selects, the page is an image and optical character recognition has to invent the characters first, with verification required afterwards. If there are boxes you can type into, it is a form and the field data can be exported directly, which is the easiest case of all.

Because PDF does not store tables. It records where characters and lines go on a page, not that a group of characters is a cell or that a set of cells is a row. Every conversion infers a grid that was never recorded. Ruled tables convert better because the lines are objects in the file and give the tool real evidence about column boundaries. Whitespace-aligned tables are inferred from horizontal positions, which works until a value is wide enough to close the gap between two columns.

It is a decision worth making deliberately rather than by clicking. A statement contains personal and financial data, and uploading it to a service to convert makes that service a processor acting on your behalf. UK GDPR Article 28 requires that processing to be governed by a contract setting out its subject matter, duration, nature and purpose, the type of personal data and the categories of data subjects. A free converter found in a search result has none of that. Converting locally, on a machine you control, removes the question.

We publish no accuracy figure, because it depends entirely on the individual document and no authority measures it, so a percentage here would be a guess given the appearance of a benchmark. What is predictable is which characters go wrong: 0 and O, 1 and l, 5 and S, 8 and B, and decimal points that move or vanish. In a numeric column those errors are invisible. Treat recognition output as a draft requiring verification, check any totals, and validate fields with known formats such as dates and account numbers.

Statement and invoice layouts defeat general purpose converters for a structural reason: there is no consistent grid. Records wrap onto second lines, amounts change column by sign, and running totals sit between records and look like records. A converter produces plausible output that is unevenly wrong, which is worse than an obvious failure. What works is a rule set written for that specific layout, or getting the data from its source. For UK bank data in particular, asking whether a machine-readable feed exists is worth doing before writing a parser.

Six checks, in about five minutes. Count the rows against the source, including any that wrapped. Look for rows with fewer fields than the rest, which is the signature of a merged column. Confirm the numeric columns are numbers rather than text by sorting one. Sum them against any total in the source. Check the first and last rows, where headers arriving as data and off-by-one range errors both live. And spot check five records by eye from the middle of the document, which is the only check that catches reading-order errors.

Frequently, and it is the first thing to try. A PDF was generated by something, and that something held the data in a database, a spreadsheet or a report. Asking the supplier, the bank or the public body that produced it for a CSV or a data feed takes one email and succeeds more often than people expect. Every hour spent on extraction is an hour spent reconstructing something that already exists somewhere in a better form, and the reconstruction is never as good as the original.