Pay stub OCR turns the printed figures on a stub into data: earnings lines, taxes withheld, deductions, net pay and the pay period dates, each in both its current and year-to-date column. A read holds up when the numbers check themselves. Gross minus taxes and deductions must equal net, and every year-to-date figure must be at least last period's.
What pay stub OCR has to read: current and year-to-date columns
Pay stub OCR has to read two numbers for nearly every line on a stub: the amount for this pay period and the running total for the year so far. The current column shows one paycheck. The year-to-date column shows every paycheck since January 1 added together. Reading only one of the two loses half of what the stub proves.
A pay stub is the statement an employee receives with each paycheck. No single federal format exists for it. The U.S. Department of Labor Fact Sheet #21 on FLSA recordkeeping lists what employers must record, including "all additions to or deductions from the employee's wages," "total wages paid each pay period," and the "date of payment and the pay period covered by the payment." It does not set a layout for the stub itself, so each payroll system prints its own.
The fields to capture, with the check for each
The example values below come from one fictional biweekly stub for an employee of Example Dental Group. Each field carries the arithmetic that proves it was read correctly.
- Pay period start and end: 09/07/2026 to 09/20/2026. Check: the span matches the pay frequency, here 14 days.
- Pay date: 09/25/2026. Check: falls on or after the period end, and one frequency after the previous stub's pay date.
- Regular earnings: 80.00 hours at $31.25, current $2,500.00. Check: hours times rate equals the amount.
- Overtime earnings: 4.00 hours at $46.875, current $187.50. Check: hours times rate equals the amount.
- Gross pay: current $2,687.50, year to date $50,312.50. Check: equals the sum of the earnings lines.
- Pre-tax deductions: 401(k) $161.25, health premium $94.00. Check: each year-to-date amount is last stub's plus this one.
- Federal income tax withheld: current $241.80. Check: year to date rises by exactly this amount.
- Social security and Medicare wages: current $2,593.50, gross less the health premium. Check: matches the stub's taxable-wage line.
- Social security tax: current $160.80. Check: 6.2% of $2,593.50, rounded to the cent.
- Medicare tax: current $37.61. Check: 1.45% of $2,593.50, rounded to the cent.
- State income tax: current $98.14. Check: year to date rises by exactly this amount.
- Post-tax deductions: union dues $25.00. Check: year to date rises by exactly this amount.
- Net pay: current $1,868.90. Check: gross minus every tax and deduction.
The 6.2% and 1.45% employee rates for 2026 come from the IRS Instructions for Form 941 (Rev. March 2026), which also set the social security wage base at $184,500. Social security wages on a stub can be lower than gross, as they are in this example. That is why the check uses the taxable-wage figure the stub prints, not gross.
Net pay is the anchor. In the example, $2,687.50 minus $161.25, $94.00, $241.80, $160.80, $37.61, $98.14 and $25.00 leaves $1,868.90. If the read says anything else, at least one field is wrong.
Why pay stub layouts differ by payroll provider
Pay stub layouts differ by payroll provider because no rule fixes them. Each payroll system chooses its own column order, its own labels and its own page count. The same employee's earnings can appear as "Current / YTD" on one stub and "This Period / Year to Date" on the next if the employer switches providers mid-year.
Column order is the first trap. Some stubs put hours, rate, current and year to date left to right. Others put year to date before current, or drop hours into a separate block. A reader that assumes the second number on a line is year to date will swap the two on a stub that orders them the other way.
Abbreviations are the second. Federal income tax can print as "FIT," "Fed W/H," "Federal" or "FITW." Social security can be "OASDI," "SS" or "FICA-SS." Medicare can be "MED" or "FICA-MED." Deductions are worse, because employers name their own plans. Mapping these labels to one set of fields is a step of its own, and the post on mapping deduction names into one sheet covers it.
Multi-page stubs are the third. A stub with many deduction lines can run onto a second page, with net pay on page two and earnings on page one. Treating each page as its own stub produces two half-stubs that both fail the net pay check. Join the pages by pay date and employee before checking.
Some stubs also show employer-paid items, such as the employer's share of a health premium or a retirement match. These do not reduce net pay. Capture them in a separate group so they do not enter the gross-minus-deductions arithmetic.
Can pay stub data extraction handle phone photos and screenshots?
Pay stub data extraction can handle phone photos and screenshots when the figures are sharp, the page is flat and every column is in the frame. What does not survive is a cropped edge, a fold through a number, glare over the year-to-date column, or a screenshot that cuts off part of a long stub.
Clients send what they have. A paper stub becomes a phone photo on the kitchen table. A stub from an employee app becomes a screenshot, often several screenshots for one stub because the app scrolls. A stub downloaded from an employer portal becomes a PDF, which is the best of the three because the text is usually already there.
Photos fail in predictable places. Decimal points vanish in low light, turning $1,868.90 into $186,890. A 3 and an 8 blur together. A shadow across one column hides the right-hand digits. The arithmetic checks catch most of these, because a misread digit almost never leaves net pay still balancing.
Screenshots fail differently. The text is crisp, but the stub is often split across images with no overlap, or the year-to-date column sits off-screen to the right. Ask clients for the PDF download when one exists, and for one image per screen with a little overlap when it does not.
How documents reach the firm in the first place, from upload links to emailed attachments, is the subject of the client document collection category. Schema CPA takes phone photos, screenshots and PDFs through the same client upload link, reads each stub, and exports the figures to Excel or CSV for review.
Which checks catch a wrong pay stub OCR read?
Two checks catch most wrong pay stub OCR reads. The first is that gross pay minus every tax and deduction equals net pay on the same stub. The second is that every year-to-date figure is at least the previous stub's figure, and rises by exactly this period's amount when nothing unusual happened.
The net pay check works within one stub. It needs every line read, because one missed deduction breaks the balance. When it fails by a round amount, such as $25.00, look for a deduction line the reader skipped. When it fails by a power of ten, look for a lost decimal point.
The year-to-date check works across stubs. For a run of stubs from one employer, each year-to-date value equals the prior stub's value plus the current amount. A year-to-date figure that drops means two stubs are out of order, a stub belongs to another year, or a digit was misread. A year-to-date figure that jumps by more than the current amount means a stub between them is missing.
Three smaller checks add cover:
- Hours times rate: each earnings line equals its hours times its rate.
- Tax rates: social security tax is 6.2% of social security wages, and Medicare is 1.45% of Medicare wages, within a cent of rounding.
- Dates: each pay date is one pay frequency after the last.
Some failures are not misreads. A voided check, a manual adjustment or a retroactive pay correction can print a stub whose year-to-date figures jump or fall for a real reason. These stubs usually carry a label such as "adjustment" or "void" near the pay date. Keep them in the run, mark them, and check the stubs on either side against each other instead.
Rounding is the last small source of noise. Taxes are figured to the cent on each check, so a year-to-date tax figure can differ from the sum of the current amounts by a cent or two. Treat a gap of a few cents as rounding, and anything larger as a read to recheck.
A stub that passes every check can still be the wrong stub, such as a spouse's stub or last year's December stub. Read the employee name and the pay date before trusting the numbers. Laying a year of checked stubs out in rows is covered in a pay stub to Excel layout with one row per pay date.
When pay stub OCR is the wrong tool
Pay stub OCR is the wrong tool when the employer or its payroll provider can export a payroll register. A register lists every pay date for every employee in one report, already totaled, so it replaces dozens of stubs with one file. For a business client's own payroll, ask for the register instead.
Stub reading fits individual clients: a wage earner documenting income, a client whose employer will not send anything else, or a mid-year check on withholding before the W-2 arrives. In those cases the stubs are the only record the client holds.
For a business that runs payroll, the stubs are the least efficient source. The provider's reports already hold the register, the period summary and the tax liability, and reading them is covered in payroll provider reports for bookkeeping: register, summary and tax liability. The broader process of payroll report extraction covers journal entries and tie-outs.
The final stub of the year is a special case. Its year-to-date column is the closest thing to a W-2 the client has in December, but the two rarely match line for line, because W-2 Box 1 leaves out pre-tax deferrals and benefits that the stub's gross includes. Tracing that gap line by line is covered in W-2 Box 1 versus final pay stub year to date gross.
A sensible split for a firm:
- Individual client with a few stubs: read the stubs.
- Individual client with a full year of stubs: read them, then lay them out in one sheet and run the year-to-date check.
- Business client with payroll: ask for the register and the quarterly reports.
Schema CPA reads both pay stubs and payroll provider reports, so either path ends in the same Excel or CSV export. The document categories it reads are listed on the homepage.