Read handwritten receipts and invoices, not just printed ones. Handwriting is genuinely harder for OCR, and every major engine restricts it: AWS Textract reads handwriting in English only, Azure supports 12 languages against more than 300 for print. Upload a handwritten slip below and see what comes back.
Upload your receipts and invoices
Drop files here or click to upload
Upload failed, please try again
Up to 50 files
Uploading...
Classic OCR was built to match shapes against known fonts. Handwriting has no fonts. Every writer produces a different letterform, strokes join, baselines drift, and the same person writes a 7 differently on a Monday than on a Friday. That is why the vendors who publish 300 languages for printed text publish barely a dozen for handwriting.
Printed text is drawn from a finite set of glyph shapes. Handwriting is continuous and personal, so an engine has to infer characters from context rather than recognize them outright. Ambiguous pairs like 1 and 7, 0 and 6, or 5 and S are decided by what makes sense in the field, not by the pixels alone.
A misread letter in a vendor name is cosmetic. A misread digit in a total is a wrong number in your books. Handwritten receipts concentrate the hardest characters, digits and decimal points, in exactly the field that has to be right.
Handwriting support is a small subset of printed support at every vendor that publishes both. If your documents are not in one of the handful of supported languages, the engine falls back to guessing or returns nothing usable.
Handwritten receipts are usually thermal paper photographed on a dashboard or a kitchen table. Faded ink, glare, folds, and shadows remove the stroke detail the model needs, and the engine has less redundancy to recover from than it does with printed text.
ReceiptOCR is built for business documents, not for transcribing notebooks. It reads the handwritten receipts and invoices US businesses actually collect, contractor slips, cash receipts, delivery dockets, mileage logs, and returns the fields you need rather than a wall of loose text.
Most real receipts are mixed: a printed letterhead with a handwritten total, or a preprinted book with the amount filled in by hand. Both are read in the same pass, so you do not choose a mode before uploading.
Generic handwriting OCR gives you a transcript. You still have to work out which number was the total. ReceiptOCR returns merchant, date, subtotal, tax, total, and line items as named fields you can export directly.
Every field comes back with a confidence score, and the values the model is unsure about are marked for review before you export. On handwriting that matters more than on printed text, because the error rate is genuinely higher.
Download a clean spreadsheet with consistent headers, ready to import into QuickBooks, Xero, or whatever your bookkeeper uses. No retyping between the OCR step and the books.
Upload a folder of photographed slips at once instead of one at a time. Handwritten receipts arrive in piles at quarter end, not one by one.
Nothing reaches your accounting system until you have looked at it. Automation removes the typing, not your judgment about a smudged 3.
Four steps, and the first one determines most of your accuracy.
Photograph flat, in even light, with the whole receipt in frame and no shadow across the writing. If you are scanning, use 300 DPI or higher. Capture quality does more for handwriting accuracy than any setting further down the pipeline.
Tip: AWS publishes a minimum text height of 15 pixels for detection, which is roughly 8 point type at 150 DPI. Handwriting is usually larger than that, but a distant phone photo can still fall below it.
Drag the image or PDF into the uploader above. Mixed batches of handwritten and printed receipts are fine, and multi page documents are handled in one go.
The extraction comes back as named fields with confidence scores. Check the ones marked low confidence, which on handwriting are usually digits in the total or a scrawled vendor name, and correct them in place.
Download the structured file and import it into your accounting system. The column headers stay the same across batches, so you map the import once.
US businesses that still receive paper filled in by hand, and the bookkeepers and accountants who have to get it into the books.
Plumbers, electricians, landscapers, and mobile mechanics hand over receipts written in a duplicate book. Those slips are deductible and they have to be recorded somewhere.
Client envelopes arrive with handwritten cash receipts mixed into the printed ones. Keying them is the slowest part of a cleanup engagement.
Signed delivery dockets, fuel slips, and job sheets completed by hand in a truck, then photographed and sent back to the office.
Anyone substantiating deductions from a mix of printed and handwritten receipts collected across a tax year.
Handwriting OCR is optical character recognition applied to handwritten text, converting the writing in a scan or photo into machine readable characters. It differs from printed OCR because there are no fixed letterforms to match, so modern engines predict characters from stroke shape and surrounding context instead. Vendors sometimes call the same capability handwritten text recognition or intelligent character recognition.
Yes, but with real limits that vendors publish. Amazon Textract states that it supports both handwritten and printed character recognition, and that handwritten recognition is supported in English only. Azure AI Document Intelligence reads handwritten text in 12 languages against more than 300 for printed text. So handwriting works, in far fewer languages, and less reliably than print.
This is the comparison the marketing pages skip. Every figure below comes from the vendor documentation itself, checked in August 2026. Note how far handwriting support falls behind printed support at the same vendor.
| Engine | Printed text | Handwritten text | Vendor source |
|---|---|---|---|
| Azure AI Document Intelligence, Read v4.0 | 300+ languages | 12 languages: English, Chinese Simplified, French, German, Italian, Thai, Japanese, Korean, Portuguese, Spanish, Russian, Arabic | learn.microsoft.com language support |
| Azure AI Document Intelligence v3.1 | 300+ languages | 9 languages, no Russian, Thai, or Arabic | learn.microsoft.com language support |
| Azure AI Document Intelligence v2.1 | Supported | Not supported. Microsoft states that v2.1 does not support handwritten text extraction | learn.microsoft.com language support |
| AWS Textract | 6 languages: English, French, German, Italian, Portuguese, Spanish | English only | docs.aws.amazon.com set quotas |
| Google Cloud Vision | 200+ languages | Handled by DOCUMENT_TEXT_DETECTION; Google publishes no separate handwriting language list | docs.cloud.google.com handwriting |
| Tesseract | Supported, open source | No handwriting model ships with it. Its trained data is built from rendered printed fonts | tesseract-ocr documentation |
Two things follow from that table. First, if your documents are not in a supported handwriting language, no amount of image cleanup will help, because the model was never trained for it. Second, a vendor claiming to read handwriting in every language it lists for print is describing its printed capability, not its handwriting one.
Nobody publishes a number, and that is the honest answer. Google states that Document AI does not provide a metric for accuracy. AWS Textract returns a per block confidence score rather than an accuracy rate. Azure publishes an estimated accuracy score only for custom template models trained on your own data. Every 99 percent handwriting claim in this market comes from a marketing page, not a vendor specification.
What you can reason about is compounding. Character level errors multiply across a field. If each character is read correctly 99 percent of the time and errors are independent, a nine character total comes back fully correct about 91.4 percent of the time. At 99.5 percent per character that rises to about 95.6 percent, and at 99.9 percent to about 99.1 percent. Handwriting sits below printed text on that scale, which is exactly why a review step before export is not optional. Our OCR accuracy page works through the arithmetic and what confidence scores actually mean.
Printed characters come from a finite set of glyphs rendered the same way every time, so recognition is close to a lookup. Handwriting varies between writers and within the same writer, letters join and overlap, and baselines and letter heights drift. The engine has to infer characters from context, which means ambiguity in a total can only be resolved by what is plausible, not by the pixels.
Cursive is the hardest case because the letters connect, so the engine cannot rely on gaps to segment characters. Modern sequence models handle joined writing far better than the shape matching engines of a decade ago, but accuracy still falls compared with hand printed block capitals. If you control how the document is filled in, asking for block capitals is the single cheapest accuracy improvement available.
Not usefully. Tesseract is an open source engine for printed text and ships no handwriting model. Its trained language files are generated from rendered printed fonts, so handwriting falls outside what it learned. You can train custom data, but that means collecting and labeling handwriting samples yourself. Our LLM OCR vs Tesseract comparison covers where the gap shows up.
Acrobat text recognition is built for printed and typewritten pages, and handwriting is not what it was designed to read. Scanning a handwritten receipt in Acrobat generally produces a searchable PDF where the printed parts are recognized and the handwritten parts are not. Our guide to whether Adobe Acrobat does OCR walks through what it does and does not handle.
It depends on what you need back. For raw handwritten transcription in a supported language, Azure Read covers the most languages of the major APIs. For receipts and invoices, a raw transcript is the wrong output, because you still have to decide which number was the total. A document specific tool returns merchant, date, tax, and total as named fields, which is the job most businesses are actually trying to do.
Yes. Upload a photo or scan of the receipt, let the extraction read merchant, date, tax, and total into named fields, check anything flagged as low confidence, then export the batch as XLSX or CSV. The output uses the same column headers every time, so you can reuse one import mapping in QuickBooks, Xero, or your spreadsheet. See receipt to Excel for the export step in detail.
Fix the capture first, because nothing downstream recovers detail the image never had. Photograph flat in even light with the whole document in frame, avoid glare on thermal paper, and scan at 300 DPI or higher rather than 150. Keep the original file rather than a compressed screenshot, and do not photograph a receipt at an angle that shrinks the writing below the engine minimum. AWS publishes 15 pixels as its minimum detectable text height, about 8 point type at 150 DPI.
After capture, the lever is review rather than reprocessing. Confidence scores exist precisely so you can spend attention on the fields that need it. On handwritten receipts, that is almost always the total and the date. If you are handling these at volume across a tax year, the bulk receipt scanner workflow lets you batch the pile and review once instead of opening slips one at a time, and IRS receipt requirements covers what the record has to show to stand up.
Yes, and for handwritten receipts a phone photo is usually the only capture available. The constraints are the ones that affect any camera capture: get the whole document in frame, keep the paper flat, avoid shadows falling across the writing, and do not shoot from so far away that the text renders small. A steady photo in daylight beats a rushed scan.
Yes. Handwritten and printed content on the same document are read in one pass, which matters because most real receipts are mixed: a preprinted book or letterhead with the amount and date filled in by hand. You get merchant, date, tax, and total as named fields rather than a loose transcript.
No, and any vendor telling you otherwise is selling. Handwriting has no fixed letterforms, so recognition is inference rather than matching. That is why the review step, with low confidence fields flagged before export, is part of the workflow rather than an optional extra.
PDFs, photos, and scans. For handwritten documents a phone photo is usually what you have, and that is fine as long as the paper is flat, the whole receipt is in frame, and no shadow crosses the writing.
Handwriting language coverage is narrower than printed coverage across the whole industry. AWS Textract publishes English only for handwriting; Azure publishes 12 languages. ReceiptOCR is built and tuned for US business documents, so English handwriting is where it is strongest.
No. There is no mode to choose before uploading. The same extraction runs on printed, handwritten, and mixed documents, which is what you want when a batch of receipts contains all three.
Yes. Upload the whole folder and get one spreadsheet back with consistent columns. Handwritten slips tend to arrive as a pile at quarter end or tax time rather than one at a time, so batch review is faster than opening each file.
A digital image of a receipt is acceptable as long as the record establishes the amount, date, place, and essential character of the expense. Handwriting does not change that standard. What matters is that the record is legible and complete, which is a good reason to check flagged fields.
Stop typing receipts by hand
Upload your receipts and invoices and get a clean Excel or CSV file in minutes.
Extract my receipts nowFree to try, no sign up required
What confidence scores mean and why no vendor publishes an accuracy rate.
The main receipt extraction workflow, printed and handwritten.
Batch a whole pile of slips in one upload.
What a receipt record has to show to stand up.
The wider category, from raw text to structured fields.
Turn paper receipts into searchable, exportable records.