What file types can I upload?

PDF, PNG, JPG, and WEBP. Both digital statements downloaded from your bank and photos or scans of a paper statement are supported.

Does it work on a photo or scan of a statement?

Yes. Docyield runs OCR on images before extracting, so a clear photo of a mailed statement works much like a downloaded PDF. The sharper and straighter the image, the better the result.

Will it capture every transaction, including those spread over several pages?

Yes. The parser reads the whole document and collects transactions wherever they appear, including lists that continue across page breaks.

Are refunds and payments handled differently from purchases?

Each transaction keeps its own amount with the correct sign, so credits, payments, and refunds are distinguishable from charges when you sum or filter the column.

How accurate is the conversion?

Accuracy is high on clean statements. To verify, check that the extracted new balance matches the statement; if it does, the transaction list is almost certainly complete. Missing values are left blank rather than guessed.

Is my statement kept private?

Files are used only to produce your result and are not used to train models. For regulated or high-volume work, the API and paid plans add further controls.

Can I convert many statements at once?

The free tool handles one file at a time. For bulk conversion across multiple cards or months, the API and batch dashboard process them at scale with webhooks.

Does it read statements in other currencies and languages?

Yes. The converter is not tied to a single bank template or language and returns the currency-bearing amounts as numbers with the currency captured where shown.

Credit Card Statement Converter

Convert credit card statements into clean transaction tables.

Drag & drop your document here

Supports PDF, JPG, PNG, WEBP

Credit card statements bury the only thing most people actually want — the list of transactions — inside pages of promotional inserts, interest disclosures, and reward summaries. Docyield pulls that list out cleanly. Upload a statement as a PDF or a photo and you get back every charge and credit as a tidy table, alongside the cardholder, issuer, statement period, and balances, ready to open in Excel or feed into your bookkeeping.

The default output here is CSV because that is what most people reach for: one row per transaction, with date, description, and amount in their own columns. You can also export JSON for code, an XLSX workbook for finance, or XML for legacy imports. Whatever the format, the figures arrive as real numbers and dates, not text that merely looks numeric — so totals, sorting, and category formulas work the moment the file lands in your spreadsheet.

Inputs

PDF, JPG, PNG, WEBP

Outputs

JSON · CSV · Excel · XML

Price

Free · no signup

From a billing statement to a transaction table

A credit card statement is built for a human reading it once a month, not for software. The transaction list might wrap across two pages, mix posted and pending entries, and sit between marketing boxes and a payment slip. Converting it by hand means scrolling, squinting at small print, and copying figures one at a time — exactly the kind of repetitive work where a transposed digit slips through unnoticed.

Docyield treats the statement as a structured document rather than a picture. It locates the running list of purchases, payments, fees, and refunds, separates them from the summary box at the top, and returns each as its own record with a date, a description, and a signed amount. The header details — who holds the card, which bank issued it, the last four digits, the billing cycle, and the balances — come back as their own fields so you never have to scrape them out of a paragraph.

Why this beats copy-paste and raw OCR

Selecting text in a PDF and pasting it into a spreadsheet rarely gives you columns. Amounts collide with descriptions, dates land in the wrong cell, and a multi-line merchant name shatters across rows. Plain OCR on a scanned statement is worse still: it hands back a stream of characters with no idea which token is a date and which is a dollar figure.

Structured extraction fixes the alignment problem at the source. Because each transaction is modelled as an object with named fields, the date is always a date and the amount is always a number — there is no column drift to clean up afterwards. That reliability is what makes the output safe to import in volume rather than something you still have to proofread cell by cell.

Who converts credit card statements

Sole traders and freelancers separating business spend from personal charges at tax time.
Bookkeepers importing card activity into Xero, QuickBooks, Wave, or a custom ledger.
Small businesses that reconcile a company card against receipts each month.
Budgeters and personal-finance enthusiasts who track spending in a spreadsheet.
Accountants preparing year-end accounts from a stack of monthly statements.
Expense and fintech apps that let users upload a statement to categorise transactions automatically.

Categorising and reconciling the data

Once transactions are in columns, the work that used to take an evening becomes a few formulas. You can sort by amount to find the largest charges, filter by a merchant name, or pivot the descriptions into spending categories. Because amounts keep their sign, payments and refunds are easy to net out against purchases.

Reconciliation gets simpler too. The statement carries a previous balance, a new balance, and a minimum payment, and the transactions between them should explain the change. Keeping those summary figures as separate fields lets you check that the sum of activity ties back to the new balance — a quick sanity test that flags a missed or mis-read line before it reaches your books.

Accuracy and what to double-check

On a clear statement the extraction is dependable, but no parser is infallible and we will not pretend otherwise. Densely printed statements, faint thermal-style fonts, and photos taken at an angle are where character recognition can stumble — a sharp, straight scan always reads better than a hurried snapshot. Where a value genuinely is not present, Docyield leaves the field empty instead of inventing a figure, because a blank cell is far cheaper to fix than a confident wrong number in a financial record.

A sensible habit is to compare the extracted new balance against the statement total before importing. If they match, the transaction list is almost certainly complete; if they do not, that points you straight at the row to review. For the small share of statements with unusual layouts, that one check is all the review most people ever need.

Statement layouts and why templates fail

Card issuers each lay their statements out differently, and even a single issuer redesigns the format from time to time. The transaction table might carry posting and transaction dates in separate columns, group purchases under headings, or split foreign-currency charges into two lines. A tool built around a fixed template has to be tuned for each issuer and breaks the moment the layout shifts, which is why template approaches age badly.

Docyield reads the statement for meaning instead of matching a grid, so it returns the same clean transaction table whether the document came from a high-street bank, a credit union, or a fintech app. That generality is what lets one tool handle the mix of cards a typical person or business actually holds, rather than working only for the one issuer it was configured against.

Output formats, API, and batch

Every conversion is available as CSV, Excel, JSON, or XML from the same result, so you can switch formats without re-uploading. CSV and XLSX drop straight into accounting tools and pivot tables; JSON suits developers wiring statements into an app; XML covers older finance systems that expect it.

The free tool processes one statement at a time, which is perfect for the occasional month. When you are handling many cards or many months, the Docyield API and batch dashboard run the same extraction at scale, returning identical fields with webhook delivery and your own validation rules. Nothing about the schema changes between the free page and the API, so prototyping here translates directly to production.

What the converter extracts

Each statement is returned against a fixed schema. Anything not printed on the document comes back empty rather than guessed.

Card holder: The name of the person the card is issued to.
Card issuer: The bank or institution that issued the card.
Card last 4: The last four digits of the card number shown on the statement.
Statement period: The billing cycle or date range the statement covers.
Payment due date: The date by which the payment must be made.
Previous balance: The balance carried over from the prior statement.
New balance: The new balance due for this billing cycle.
Minimum payment: The minimum amount due for the period.
Transactions: Every charge, payment, fee, and refund, each with its date, description, and amount.

How to convert a credit card statement to CSV or Excel

1Upload your statement — drop a PDF, PNG, JPG, or WEBP onto the box above, or click to choose a file.
2Give Docyield a few seconds to read the document and pull out the transactions and balances.
3Scan the transaction table and compare the new balance against the statement to confirm nothing is missing.
4Pick your output tab — CSV, Excel, JSON, or XML.
5Download the file or copy the data, then import it into your spreadsheet or accounting software.