Catch Up the Books Without Retyping Months of Statements

Catch-up work falls back to PDFs because the live connection is not a historical record. A feed established today does not retroactively produce last year, an account that has been closed cannot be connected at all, and a client whose records are a folder of downloads has exactly what they have.

How far back a connection reaches varies by institution and by the connection itself, so this is not a universal limitation with a single number attached to it. What is consistent is the shape of the problem: the months you most need are the months least likely to be available anywhere except a PDF.

That makes the statement the authoritative record for the period, which is a useful thing rather than a consolation. It is the document the bank issued, and it carries its own totals to check the transactions against.

Each statement is one job. You upload it, the transactions are extracted, and the result is shown for review before anything is exported — so a month is converted and checked, then the next one.

A statement that covers several accounts needs more attention in review than a single-account one. The rows are kept separated by account where the document distinguishes them, and checking that separation is right before export is the step worth not skipping: rows that are individually correct but attributed to the wrong account are the hardest kind of error to find later. Several statement periods merged into one PDF are a different thing: StackExtract reads one statement per upload, and flags a file that appears to hold more than one, so split those before uploading.

Several statements can be uploaded at once, and each becomes its own job with its own status rather than one combined batch. A month that fails to extract does not hold up the others, and a month that needs twenty minutes of review does not block a month that needs none.

Where the statement prints opening and closing balances, the arithmetic is checked: the extracted transactions should move the opening figure to the closing one. A statement that does not reconcile is flagged rather than exported quietly, because on catch-up work a missing transaction discovered months later is expensive.

A statement that does reconcile tells you something specific and limited — that no amount is missing, duplicated or misread, because any of those would change the total. It does not tell you a description is right or that two transactions are in the correct order. The final review is yours, and the flags exist to tell you where to spend it.

Where a statement prints no balances, the check is reported as one that could not run rather than as a pass, and nothing is quietly adjusted to make the arithmetic work. A figure that disagrees is shown as printed and the row is flagged — on catch-up work, a number silently corrected is a discrepancy you will meet again later without knowing where it came from.

Reviewed rows export to XLSX or CSV, and for bank statements to a QuickBooks-ready CSV shaped for that import workflow.

From there the work is yours. StackExtract does not categorise transactions, does not assign accounts, and does not complete reconciliations inside your accounting software — the import and everything after it happens in your environment, with your decisions.

Each PDF counts as one document regardless of length, and a document that fails to extract is not charged for. On catch-up work — where the statements are long and their quality is unknown until you try them — both of those change what it is reasonable to attempt.