DeepSeek OCR API, Pricing and the Bank Statement to Excel Alternative

DeepSeek OCR vs BankXLSX for bank statements: which one fits the job

DeepSeek OCR is a genuinely impressive piece of research, and this page is not going to pretend otherwise. It was released in October 2025 as an investigation into compressing long contexts by rendering text as pixels, it is MIT licensed, and it has been downloaded more than 2.4 million times from Hugging Face in the last 30 days. It reads scanned pages, it handles tables, and it does it with strikingly few vision tokens. If you are building a document pipeline for a language model, it deserves a look.

None of that makes it a bank statement converter. DeepSeek OCR turns a page into Markdown so a model can read it. BankXLSX turns a bank statement into a workbook so an accountant can reconcile it. Those are different jobs, and the distance between them is a piece of software somebody has to write and then keep writing.

DeepSeek OCR details verified on 31 August 2026 against the GitHub repository, the Hugging Face model card, the arXiv paper and the official DeepSeek API documentation. Open-source projects move quickly, so check the current sources before you commit to an approach.

What is DeepSeek OCR?

DeepSeek OCR is an open-source vision language model released by DeepSeek in October 2025. The paper behind it, DeepSeek-OCR: Contexts Optical Compression, is not really an OCR product announcement. It is an experiment asking how much text you can pack into a small number of vision tokens and still read back accurately. The model has two parts: a vision encoder the authors call DeepEncoder, and a 3 billion parameter mixture of experts decoder. The published weights come to roughly 3.34 billion parameters in a single file.

You give it a page image and a prompt. The documented prompts are short and blunt: convert the document to markdown, free OCR, parse the figure, or locate a phrase in the image. What comes back is text. The sample PDF script rasterizes each page at 144 DPI, runs the model, and writes Markdown files to an output directory alongside any figures it cropped out.

The reason people found it is the efficiency claim. The authors report that when the text is under ten times the vision token count, the model reads back at about 97 percent precision, and that on the OmniDocBench benchmark it beats GOT-OCR2.0 while spending 100 vision tokens per page against GOT-OCR2.0 at 256. Those numbers are self-published by the authors, as benchmark numbers in model papers usually are, so treat them as a starting point and test on your own documents.

Can DeepSeek OCR convert a bank statement to Excel?

No, not on its own. DeepSeek OCR will read the statement and it will lay the transaction table out for you, but what it writes is a Markdown file. There is no XLSX writer, no CSV writer, and no pandas anywhere in the repository. We checked the source rather than assuming: a search across the whole project for csv, xlsx, excel, pandas and openpyxl returns nothing. The PDF runner writes two Markdown files per document, one plain and one with layout grounding, and that is the end of the pipeline.

There is one nuance worth knowing, because it is the difference between useful output and mush. The example code whitelists the table cell tokens in its repetition filter, which means the model is allowed to emit HTML table markup and the sample scripts will not truncate long tables. So a statement register does survive as a table, it just survives as HTML inside a Markdown file. Turning that into a workbook with dates parsed, amounts signed and a running balance in its own column is code you write.

Is there a DeepSeek OCR API?

Not from DeepSeek. This is the single most common wrong assumption about this model, and it is worth being precise. DeepSeek does run a commercial API at api.deepseek.com, and as of 31 August 2026 that API serves three models: deepseek-v4-flash, deepseek-v4-pro and deepseek-v4-flash-vision-exp. DeepSeek OCR is not one of them. The OCR model is distributed as weights on Hugging Face under an MIT license, and running it means standing up your own GPU inference, typically with vLLM.

You can send an image to the general vision model instead, and for some jobs that is a perfectly reasonable substitute. Two limits matter if you try it. It is flagged experimental in the model name. And it accepts JPEG, PNG, GIF and WebP only, so a PDF statement has to be rasterized to images before it goes anywhere near the API, with a 48 MiB cap on the request body.

DeepSeek API pricing, per 1 million tokens

DeepSeek prices in tokens rather than pages, and it charges different rates by time of day. Off-peak is exactly half of peak. Peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC, Monday through Friday, which for a US buyer means most of the working day is billed at the cheaper off-peak rate. Images are converted to tokens based on their dimensions and billed as input.

DeepSeek list pricing read from the official API documentation on 31 August 2026. All three models carry a 1 million token context window and a 384K maximum output. DeepSeek states it may adjust prices, so confirm before you budget.

Token pricing is genuinely cheap, and that is the honest headline. The catch for statement work is that tokens are a poor proxy for pages. A dense statement page rendered as an image can run to a few thousand input tokens before the model writes a word, and the output Markdown is billed on top. Budgeting a per-page number means measuring it on your own files first.

What are the DeepSeek OCR resolution modes?

The compression idea shows up as a resolution setting, and picking it is the main tuning decision you make. Fewer vision tokens is cheaper and faster, and it is also where accuracy goes when it goes.

A bank statement is the dense end of that table. Six point type, forty or more rows to a page, numbers that differ from each other by a single digit. If you test this model on statements, start at Large or Gundam rather than the token counts that make the benchmark headlines.

The accuracy question nobody asks until later

The paper is admirably direct about the tradeoff. Under roughly ten times compression the model reads back at about 97 percent precision. Push to twenty times compression and accuracy falls to around 60 percent. That is the authors reporting the limits of their own method, and it is exactly the number you should be looking at.

Think about what 97 percent means on a financial register rather than on prose. A page of narrative text at 97 percent is readable and nobody notices. A statement page with forty transactions, each carrying a date, a description and an amount, will on average land a few characters wrong per page, and a wrong character in an amount is not a typo, it is a number. Three percent of a year of statements is a lot of small errors scattered where nothing flags them.

This is why the footing check matters more than the extraction score. Adding opening balance plus credits minus debits and comparing it against the printed closing balance is what turns extraction from something that looks right into something you can sign off. A general OCR model has no reason to do that arithmetic, because it does not know it is looking at money.

What you still have to build on top of DeepSeek OCR

This list is the same regardless of which model you start from, and it is where the project time actually goes.

• GPU inference to run at all. The documented environment is CUDA 11.8 with PyTorch 2.6, flash attention, and either vLLM or Transformers. There is no CPU path worth using and no hosted endpoint from the vendor.
• Markdown back into rows. The model writes HTML tables inside Markdown. Parsing that back into typed columns, and doing it reliably when a cell is empty or a row wrapped, is your code.
• Tables into one register. A statement is one continuous ledger printed across pages. You get a result per page, with repeated column headers that must be dropped rather than treated as transactions.
• Sign normalization. Some banks print separate debit and credit columns, some a single signed column, some a trailing CR marker. Each needs its own rule, and the rules do not generalize between institutions.
• Dates with no year. Registers print 12/28 and then 01/03. The year comes from the statement period, and a period crossing December means incrementing partway down the column.
• Summary blocks that look like transactions. Fee summaries, interest tables and daily balance grids are also tables on the page, and a general model has no reason to treat them differently from the register.
• Footing the balance. Without that arithmetic check, an extraction that silently drops one row in four hundred looks perfect and is wrong in a way that is expensive to find during an audit.
• Spreadsheet and ledger writers. XLSX formatting, and QBO, OFX, QFX or QIF if the data is going into QuickBooks, Xero or Quicken.

None of these are hard in isolation. Together they are a small product with an owner, and every new bank layout arrives as an edge case without warning.

What DeepSeek OCR is genuinely better at

Several things, and they are real advantages rather than consolation prizes.

It runs on your own hardware. The weights are MIT licensed and sit on your GPU. For a lender or a firm whose policy forbids client financial PDFs leaving the building, that is the deciding factor, and no hosted converter can match it.

Throughput at scale is remarkable. The authors report generating training data at more than 200,000 pages per day on a single A100-40G, and the sample PDF script reports roughly 2,500 tokens per second on the same card. If your problem is millions of pages rather than hundreds, that economics is hard to argue with.

There is no per-page fee. MIT licensed, free forever, no metering. At very large volume the only cost is hardware you may already own.

It handles far more than statements. Contracts, papers, forms, figures, and it will locate a phrase in an image on request. A statement converter covers one document type by design.

It is cheap to experiment with. Weights, sample scripts and upstream vLLM support mean an engineer can have it running in an afternoon.

If you are an engineering team with GPUs and bank statements are one document type among many, DeepSeek OCR is a sound foundation and you should use it.

Is DeepSeek OCR still maintained?

The original repository has not received a push to its main branch since 27 January 2026, which sounds alarming until you see what happened that day. That is the date DeepSeek announced the successor, DeepSeek-OCR2, described as Visual Causal Flow, in a separate repository under an Apache 2.0 license. Attention moved rather than stopped.

Two things follow from that if you are choosing a stack. The v1 model is stable and widely deployed, with more than 23,000 GitHub stars and 2.4 million Hugging Face downloads in the last month, so it is not going anywhere. But most of what has been written about DeepSeek OCR online describes v1, and the license changed between versions, from MIT to Apache 2.0. If license terms matter to your legal review, check which version you are actually looking at.

How to decide between them

Ask who is going to operate it. If the answer is a machine learning engineer, inside software your team owns, with GPUs already provisioned, on a document corpus wider than bank statements, and especially if the files cannot leave your network, use DeepSeek OCR. If the answer is a bookkeeper, an accountant or an analyst whose deliverable is a file that has to foot, buy the finished converter and spend the engineering time on something that differentiates your business.

Volume rarely decides this, and neither does raw reading accuracy. Both approaches read the page well. What differs is how much of the distance to a usable spreadsheet is already covered, and whether anything checks the arithmetic at the end.

Plenty of teams end up doing both: an open model for the general document corpus, a purpose-built converter for the financial documents where the numbers have to hold. If you want to see more of the field, the best bank statement converter roundup lines the options up, and the best open source OCR for bank statements comparison covers the other free models in this lane. For the closest open-source parsers, the Docling alternative and the Unstructured.io alternative cover libraries rather than raw model weights, while the Reducto alternative and LlamaParse alternative cover the commercial platforms. For managed cloud services, see the Amazon Textract alternative, the Google Document AI alternative and the Azure Document Intelligence alternative. For a per-page cost comparison across vendors, see OCR API pricing for bank statements.

If you want API convenience without owning the statement layer, the bank statement converter API returns statement-shaped output directly. If the spreadsheet is the deliverable, the bank statement converter is free to try on a real file, and once the data is in a sheet you can categorize the transactions or run a bank reconciliation.