How to Extract Data From a Check: MICR Line, Amounts and the Fields That Matter

Last updated July 2026.

To extract data from a check, an OCR pipeline reads five things: the MICR line at the bottom, which encodes the routing number, account number and check number; the courtesy amount, the amount written in digits; the legal amount, the same amount written in words; the payee; and the date. The hard part is not reading the text, it is reliably lifting the MICR line, which is printed in the E-13B magnetic font, and reconciling the two amounts so a wrong figure never reaches a payment. A check is a single page, so the OCR itself is cheap. The value, and the risk, is in the fields. Here is how check data extraction works, where it breaks, and how to do it accurately for accounts payable, accounts receivable and remote deposit.

What data is on a check

Every US check carries the same core fields in roughly the same places, which is what makes automated extraction possible. Reading them in order:

A useful check extraction returns all of these as labeled, validated fields, not as a wall of text you then have to locate and parse.

The MICR line and the E-13B font

The MICR line is the row of stylized numbers along the bottom of a check. MICR stands for Magnetic Ink Character Recognition, and the characters are printed in a font called E-13B, designed in the 1950s so that machines could read checks by the magnetic signature of the ink. Modern check OCR reads E-13B optically rather than magnetically, which works well but introduces a specific risk: the E-13B digits and the transit, amount, on-us and dash symbols are easy to confuse with ordinary characters if the OCR engine was not tuned for them. A general-purpose OCR model may read a routing number correctly most of the time and then flip a digit on a faxed or low-contrast check. Because a wrong routing or account number sends money to the wrong place, the MICR line is the field where accuracy is not optional. Test any check OCR on real, imperfect checks, not clean samples, and measure MICR accuracy specifically.

Reconciling the courtesy and legal amounts

Checks carry the amount twice on purpose: once in digits (the courtesy amount) and once in words (the legal amount). A good extraction pipeline reads both and reconciles them. If the digits say $1,250.00 and the words say one thousand two hundred fifty, they agree and the amount is trusted. If they disagree, the check should be flagged for a person, because on a legal instrument the written amount governs, and a mismatch usually means the OCR misread one of them or the check itself is inconsistent. Skipping this reconciliation is the most common reason an automated check workflow posts a wrong amount.

How to extract check data reliably, step by step

1. Capture a clean image. Deskew, correct the orientation and boost contrast. Check images from mobile capture and scanners vary wildly, and MICR accuracy tracks image quality closely.
2. Locate the zones. Find the MICR band, the courtesy amount box, the legal amount line and the payee line by layout, so the model reads each field from the right region rather than guessing.
3. Read the MICR line with a check-aware model. Parse the routing, account and check numbers out of the E-13B string, respecting the transit and on-us symbols that delimit them.
4. Read and reconcile the amounts. Capture the courtesy and legal amounts and compare them; flag any mismatch.
5. Extract payee, date and payer. These are ordinary print or handwriting, so handwriting recognition quality matters on the payee and the signature area.
6. Validate and review. Check the routing number against the ABA checksum, flag stale or post-dated checks, and route anything low-confidence to a person before it becomes a payment.

What check OCR costs, and why the cheap rate is misleading

A check is one page, so reading it as text is inexpensive: generic OCR runs about $1.50 per 1,000 pages, and Mistral reads a check at $0.005. But those rates only buy text. Almost no cloud vendor has a dedicated check model, Azure, Google and AWS do not, so with the cheap options you build the MICR parsing, the amount reconciliation and the field validation yourself. Veryfi is the exception, with a check-native rate of about $0.25 a check that returns the fields ready to use. The honest way to budget is to separate the API cost to read the image from the engineering cost to turn that text into validated fields. The full per-vendor breakdown, including why the MICR line is the real cost, is on our check OCR API pricing page.

Common use cases

Check extraction shows up wherever paper or imaged checks still flow. Accounts payable teams capture checks they are about to void or reissue. Treasury and remote deposit workflows read the MICR line to initiate a deposit without a physical scanner. On the receiving side, accounts receivable teams process incoming check payments and need the payer, amount and check number to apply cash to the right invoice; software that automates applying incoming payments to open invoices depends on a clean, validated read of exactly those fields. In each case the workflow only works if the MICR line and the amount are right, which is why validation and review are part of the pipeline, not an afterthought.

The bottom line

Extracting data from a check is straightforward in outline, read the MICR line, the two amounts, the payee and the date, and hard in the details that matter: the E-13B font on the MICR line, the reconciliation of the courtesy and legal amounts, and the validation that keeps a wrong routing number from becoming a wrong payment. Because checks have almost no prebuilt cloud model, the choice is between cheap OCR where you own that logic and a check-native option or product that owns it for you. Upload a real check, look at whether the routing number, account number, amount and payee come back correct, and let that, not the headline per-page rate, decide your pipeline.