Bank statement PDFs and messy CSVs: getting any input into the ledger

A bank feed is the tidy case. The work that eats a Monday morning is the other case: a client sends a PDF they downloaded from internet banking, a phone photo of a printed statement, a spreadsheet they have been tweaking for a year, or a file you cannot immediately classify. This post answers one question: when the input is not a clean feed, what is a sensible way to get it into the ledger and trust what lands?

It is general information about a workflow, not advice on how any particular client should be treated for tax.

Start by choosing the path, not the tool

Before you open anything, sort the incoming file into one of four buckets. The bucket decides how much checking it needs.

1. The bank is already connected. Transactions arrive through a feed and you only need to bring them into the client's ledger.
2. A PDF statement, either text-based or a scan.
3. A spreadsheet or pasted text whose columns, dates or headings are inconsistent.
4. Something else: a document where you are not even sure what it contains.

MYLEDGER has a route for each of these, and the point of separating them is that each has a different failure mode.

Bucket 1: a connected bank feed

If the bank is already feeding transactions, the job is to bring synced transactions into the client's ledger. MYLEDGER imports them and skips the ones that were already imported. That skipping matters when you re-run an import for an overlapping period: the check you still owe is whether the opening and closing position of the period agrees with the bank, not whether duplicates crept in.

Bucket 2: PDF bank statements, including scans

This is the common one. You upload the PDF statement, and for scans text recognition converts the pages into transactions. You can then check them page by page before import. That last clause is where the value is. A conversion you cannot inspect is a conversion you have to redo by hand anyway. Page-by-page checking lets you compare what was read against what the page shows, and fix a line before it becomes part of the books.

A short routine that works for statement PDFs:

• Check the first and last line of every page. Page breaks are where tables most often split badly. Make sure a transaction that runs across the break is one line, not two.
• Scan the amounts column for sign problems. Debits and credits in separate columns, or a running balance column, are easy places for a misread.
• Compare the closing balance on the statement with your total. If you are working from the converted lines, your opening balance plus the converted movements should land on the closing balance printed on the last page. If it does not, find the page where it first diverges rather than guessing.
• Look at dates around month and year ends. A day and month swapped, or a line dated in the wrong year, is the kind of error that survives a quick look.
• Treat scans as less certain than text PDFs. Text recognition on a photographed page can mistake similar characters. Slow down on anything with a crease, a shadow or a fax-style header.

Only import once a page reads cleanly. If a page is badly damaged, say so to the client and ask for a clean copy of that page, rather than importing a guess.

Bucket 3: messy CSV text and workbooks

Clients and bookkeepers produce spreadsheets with merged header rows, dates in three formats, amounts stored as text and notes typed into the amount column. Rather than rebuilding the sheet, you can paste messy CSV text or upload a workbook, and AI turns it into transactions for review. Two habits keep this safe:

• Review is the control, so do it properly. The AI proposes the transactions; you decide whether they are right. Read a sample from the top, the middle and the bottom of the file, and any row that looked odd in the source.
• Reconcile to something outside the file. A spreadsheet is only as good as whoever typed it. If there is a bank statement or a feed for the same period, compare the totals against it.

If the sheet mixes bank lines with commentary rows, remove or ignore the commentary before you trust the transaction count.

Bucket 4: a document you cannot classify

Sometimes you are handed something that is not obviously a statement or a spreadsheet. Universal upload is the catch-all for unusual documents: AI decides what the file is and what to extract, and shows a preview for you to confirm. The preview is the safeguard. Confirm that the document type it chose matches what you can see, and that the fields it extracted are the ones you wanted. If it has misjudged the file, do not confirm; fall back to one of the more specific routes above.

After import: coding the lines

Getting the lines in is half the job. In MYLEDGER the working surface is the AutoRecon grid, where each bank line is coded, commented, split, filtered and reviewed, with undo, a status bar and keyboard shortcuts. Because the grid supports undo, a wrong coding decision is cheap to reverse during review.

Three things help you move through freshly imported lines without losing control:

Let the client's own history do the first pass. MYLEDGER remembers how you coded transactions for each client and suggests the same coding on new ones. You still decide, but repeat payees stop being a decision you make from scratch each month.

Use AI suggestions in batches, then confirm selectively. You can ask AI to suggest accounts for selected or filtered transactions in a batch, then confirm the suggestions you agree with. The useful part is the word confirm: nothing is accepted just because it was suggested. Filter to a group of similar lines first, and your review of the suggestions is quicker and more consistent.

Deal with transfers deliberately. Matching transfers between the client's own accounts are detected for you to confirm or dismiss. This matters most when you have imported more than one statement for the same client: a transfer coded as an expense in one account and as income in the other will distort both. Confirm real transfers, and dismiss any match that only looks like one.

Keep the paperwork attached to the line. Each bank line shows an evidence indicator and preview, and you can link receipts or documents to it. If a client sends the statement PDF and a handful of receipts together, link them as you code so the support is there when someone asks about the line later.

A checklist you can reuse

When a non-feed input arrives:

1. Decide the bucket: connected feed, PDF, spreadsheet or text, or unclassified document.
2. Import through the matching route, and use the preview or page-by-page check before anything lands.
3. Reconcile the imported period to a figure outside the import: the closing balance on the statement or in the bank.
4. Code the lines, using the client's coding history and batch suggestions as a starting point and your own confirmation as the control.
5. Confirm or dismiss detected transfers.
6. Link evidence to anything you may be asked about.

What this does and does not do

These tools turn an awkward input into transactions that you review. They do not remove the review. The page-by-page check, the preview and the confirmation steps are where your professional judgement goes, and that is by design.

Where to look next

See how the import, coding and review steps fit together on the AI reconciliation page at https://home.fedix.ai/features/ai-reconciliation.