Bank statement workflow for bookkeepers: from intake to handoff

For each client statement, preserve the original and identify the exact reviewed revision that reached the accounting system. PDF conversion is one preparation step; it does not establish target-software readiness or completed reconciliation.

Open one identifiable processing job

Prefer a suitable bank-native export. When a client provides only PDF, LocalExtract can extract a CSV locally, which you then check against the source before preparing a target-specific import copy.

Record an internal client alias, account alias, currency, statement coverage and destination organisation before opening a file. Verify those details against the engagement’s records and the document; filenames alone are not evidence of ownership. Use aliases in filenames rather than embedding complete account numbers.

Keep an intake register with the source filename, received date, document period, version and missing pages or statements. A renamed copy of an already received statement is not a new period. If a PDF combines accounts or currencies, stop and establish the boundaries before preparing any upload. The three-field output does not carry a verified client or account identity for you.

Separate source documents, extracted outputs, reviewed copies and import receipts in each job. Keep originals unchanged and limit access to the staff who need them. Local conversion avoids the PDF upload for extraction, but a shared folder, backup or later accounting upload can transmit copies. Choose and document those destinations under your own access and retention arrangements; converter choice alone does not establish compliance.

Track revisions instead of overwriting approval

This is a manual handoff process. Its register and review controls are not built-in LocalExtract features.

1. Register the client, account, currency, period and destination organisation against the retained source. Record received version, missing pages and unresolved ownership or scope questions.
2. If extraction is needed, process the selected PDF and compare every source movement. Keep uncertain dates, signs and unreadable descriptions on hold instead of treating a matching net total as approval.
3. Save an explicitly reviewed file revision with the reviewer and evidence notes. Keep original bank narrative, application-added categories and target mappings identifiable; a later edit needs a new revision and affected checks.
4. Prepare a separate target copy for the actual product, organisation and account. Retain its mapping and exact submitted revision, import reference/result and failed subset; submission does not prove full acceptance.
5. Hand off the identified source, reviewed output, target copy and unresolved exceptions together. Record reconciliation review as a separate result from import completion.

A file hash can help identify the exact bytes reviewed; it does not prove correct extraction, ownership or authorization. When you change a description, sign or mapping, create a new revision and repeat the affected checks. Do not silently replace a previously approved file and keep its old approval label.

Check a synthetic handoff before any upload

This invented register contains two clients and three distinct jobs. The identifiers are teaching aliases, not real account details. Each file’s content and destination are independently specified by the scenario.

Both clients can have an original named October.pdf in separate folders. The name does not authorize merging their outputs. Even the first row passes only the stated handoff controls; it is not a certified accounting import or permission to upload client data.

Download the synthetic handoff cases for the job definitions, byte-identification examples and rejected cross-client, currency and revision controls. Python checks the defined scope/revision decisions. No customer data or accounting application is used, and those checks do not grant access or approval in a real engagement.

Review one statement before moving to the next

For each selected PDF, compare the extracted dates, complete descriptions, directions and amounts with the source. Account for every source movement in the chosen scope; checking only first/last rows or a net sum can miss offsetting errors. Record unreadable text and unknown date/sign conventions as exceptions rather than deleting awkward-looking rows.

Use the CSV reading guide and date/decimal guide for those specific preparation problems. Once existing exports need assembly, the file-combination guide covers that separate task. It does not create a LocalExtract multi-PDF queue or authorize combining different clients or accounts.

LocalExtract selects and processes one PDF at a time, performs parsing/OCR on the device and exports date,description,amount CSV. It has no desktop batch queue or automatic accounting synchronization. Open CSV in Excel to save an XLSX workbook if needed; the desktop app does not export XLSX directly. Account access and periodic Pro verification require a network. Download LocalExtract for a PDF source.

Keep finance-application categories separate from source bank evidence

When a finance application produces an annotated export, keep the bank-issued source, application-produced file and reviewed working copy as separate revisions. A user category is useful context, but is not automatically a bank-authenticated classification or the destination’s final accounting code.

For a concrete documented example, MoneyMoney’s export interface exposes purpose, category and comment separately; its AppleScript interface can also restrict an export by account, dates or category. The official Hibiscus CSV template likewise keeps category and note separate from other transaction fields. These examples establish a provenance question, not identical menus or layouts across finance applications.

In a synthetic case, the user labels a −35 USD payment in the finance application “Travel” and exports only that category. Preserve the source narrative and the user-entered label in separate columns. The file may help review travel items, but it cannot establish complete account coverage or the final tax treatment. Missing non-Travel rows are outside that filter, not proof they never occurred.

If the original narrative is unavailable, mark it missing rather than reconstructing it from a category. Request an appropriately scoped source through the agreed channel. No MoneyMoney or Hibiscus application export was executed for this example.

Extend the handoff register to the source object and cutoff

Some missing facts concern the kind of evidence, not another CSV correction. Add source type, population/filter, cutoff, currency, evidence owner and unresolved question to the existing job record. Keep a single observed bank movement distinct from any proposed component allocation.

For UK VAT, HMRC’s disbursement guidance requires all of its conditions, including agency, customer responsibility/permission and separately passed-through exact costs. Merely listing a cost separately is insufficient. Retain the underlying facts for the responsible reviewer; leave classification unconfirmed when they are missing. This register is not a VAT decision tree for other jurisdictions.

For Shopify Payments, the activity-report documentation describes period/currency balance activity, a three-day data delay and a custom range beginning January 1, 2025. Preserve the actual selected coverage and report-generation context. A period report cannot prove that a particular payout has reached the bank. Use the specific payout guide for that evidence chain rather than reproducing its export instructions in the handoff record. Do not treat a staff permission or ownership transfer as proof of the engagement’s actual access.

For an authorised Wise sender, the confirmation guide describes a completed transfer’s PDF: on the web, Home transaction list → the transfer’s three dots → Get transfer confirmation; in the app, the transfer → Details → Get PDF receipt on iOS or Download transfer receipt on Android. Only the sender can download it; in-progress transfers have no such option and cancelled transfers use a statement instead. Where a recipient bank needs to trace a transfer, the PDF’s banking-partner reference is the relevant documented reference. Establish the recipient’s requirement first and send only appropriately scoped evidence through the approved channel; do not attach a whole month’s unrelated statement merely because it is available. If the economic purpose or supplier support remains unknown, use the missing-payment-evidence guide.

Keep a three-layer cutoff record rather than a single “shop balance”: the bank account’s issued coverage/balance, the platform’s currency-specific balance/source time, and the provider’s identified unsettled events. Do not add those amounts together; the populations can overlap. Add a subsequent-settlement index that links each open event at the handoff to later provider and bank evidence only when its identity is supported.

In this manual structure, an event shown as unsettled at T is not also a bank receipt at T. A later equal bank amount does not establish the relationship. Carry the open event forward, preserve the original cutoff view and identify who owns follow-up. Shopify’s stated data delay makes report generation time and cutoff coverage particularly important; mark unavailable cutoff evidence unknown rather than recreating a balance from today’s display.

A provider-generated Wise confirmation and an independently prepared working summary are different evidence objects. Preserve an unchanged provider original with its identity. If the recipient specifically requires a bank-issued confirmation, do not label a Wise provider PDF or your own worksheet as that bank document; clarify the actual requirement. A minimal working summary should be visibly labelled “working summary—not an official bank/provider receipt”, with relevant transfer/date/currency/amount/reference, source revision and any redaction limits. Choose an appropriately scoped copy through the approved process, preserve the original under control and check the exact final attachment. Use the PDF redaction guide for that different operation; a visual rectangle alone is insufficient.

For closed Australian products, link the actual ING or NAB guide instead of assuming one archive period applies to every closed deposit or card account. Record what the owner actually obtained and which later refund/fee periods remain unanswered. Record the actual confirmation revision, recipient response and remaining closed-period gaps separately; completing the register does not close those questions. Sources for these additions checked October 17, 2026.

Prepare the copy for the actual target

Record the accounting product, edition/region, destination organisation and bank account. Follow its current field and date/sign requirements. The QuickBooks guide is scoped to QuickBooks Online US; the Sage guide is scoped to Sage Accounting UK. Their instructions do not establish other editions’ compatibility. The Xero guide covers Xero’s own mapping and review.

Other target-specific routes are the GnuCash account and matcher guide, Lexware Office in German and Pennylane in French. The last two links intentionally open their available languages. Lexware’s official CSV instructions require payer/recipient information and perform no CSV duplicate check; do not invent that extra field from a description. This is one concrete reason that a three-field extraction is not universally import-ready.

Record partial results and close the right task

Check existing feed/manual-import coverage before sending a selected period. Source-file deduplication and checking what is already in the destination are separate tasks. Keep the submitted revision and an import result record; if only some rows fail, identify which succeeded before retrying. Lexware’s official procedure, for example, provides a failed-row download rather than a reason to resubmit the entire successful set.

After import, follow the separate statement-reconciliation workflow. Xero’s reconciliation instructions distinguish imported statement lines from the transactions they need to match or create. Retain the reconciliation outcome and outstanding items separately from an “uploaded” status.

Measure actual intake, conversion, correction, import and review effort if evaluating a workflow. Record document conditions and unsuccessful attempts too. This guide makes no verified speed, annual-hours, revenue or payback claim.

Updated October 15, 2026: removed unsupported efficiency and compatibility claims, batch language and generic software steps; added client/account/revision handoff controls. Official sources checked on that date.

Updated October 17, 2026: added the distinction between bank-source fields, finance-application categories and destination mappings, with an explanatory provenance diagram. The linked official export documentation was rechecked.