Convert Pay Stub PDFs to Excel

A pay stub carries several groups of figures at once: earnings for the period, deductions, taxes withheld, employer contributions in some formats, and year-to-date columns beside most of them. StackExtract extracts the fields the document prints and lays them out as structured data instead of leaving you to copy them across.

It reads the stub. It does not calculate payroll, form a view on withholding, advise on tax, or verify employment — and a stub is a statement by an employer, which StackExtract has no way to confirm. What you get is the document, structured and checked where checking is possible.

Year-to-date columns are extracted alongside the current-period figures where the stub prints them, and a blank year-to-date stays blank rather than becoming a zero. The difference matters: nothing printed and nothing earned are different facts, and a zero in a column the employer left empty is a number StackExtract would have invented.

Some relationships on a pay stub can be cross-checked because the document prints both sides of them: gross earnings against the sum of the earnings lines, net pay against gross less total deductions, a year-to-date column against the current period where the format supports it. Where those figures are present, StackExtract checks them and flags what does not hold.

Everything else is a single value with nothing to test it against. An employee name, an identifier, an address, a rate printed once — these are extracted and displayed, and no check has confirmed them. If one of them matters, read it against the stub. That gap is a property of the document, not a shortcoming in the extraction, and a tool that implied otherwise would be the more dangerous of the two.

Nothing is recalculated to make a check pass. Where the figures on the stub disagree with each other, both are shown as printed and the row is flagged — because a tool that quietly adjusted a number to reconcile its own arithmetic would be destroying the evidence you needed.

Where the stub does not print both sides of a relationship, no check runs and the screen says so — reported as a check that could not run, never as a pass. That distinction is the difference between a trust signal and a decoration.

Values are editable before export, so correcting a misread figure is a change on screen rather than another upload.

Keep the stub itself as the reference while you review. The extracted table is a convenience built from the document; where the two disagree, the document is right and the table needs fixing.

Exports are CSV and XLSX. XLSX is usually the better choice here — a pay stub has several groups of figures rather than one flat table, and a spreadsheet keeps that structure readable in a way a CSV opened in the wrong tool does not.

Accented characters, currency symbols and locale-specific formatting are preserved through extraction and into the exported file — a name with a tilde in it survives the round trip into Excel.

The language of the stub is detected and recorded with the document, and a Spanish-language stub is read with the same field names as an English one. What has not been done is a regression test on a real Spanish pay stub: the one stub tested to the project's standard is an English payroll-provider sample, so this page claims character preservation and nothing more for Spanish-language stubs. Payroll formats are also national: a stub follows the conventions of the country and the provider that produced it, and StackExtract does not claim to handle every country-specific format.