MoneyWorks: inspect statement defaults before loading bank history

This guide follows the current public MoneyWorks manual’s Cash Transactions chapter, using its Importing Bank Statements route. The page does not identify your installed build. If your product has different controls, establish the matching version guidance before proceeding; this is a preparation checklist, not a tested import.

The desktop apps export date, description, and amount as CSV. Open CSV in Excel to save an XLSX workbook. Statement support varies: verify the result against your own PDF.

Distinguish the route and its settings

The manual uses Command → Load Bank Statement to open Statement Coding. Before selecting or accepting a file, record the existing settings:

Control	Documented role	Preflight question
Bank	Target MoneyWorks bank account	Is it the account identified by this source?
Source	Statement-file interpreter	Is this native QIF/OFX-family data or the Generic CSV route?
Default Income A/c / Default Expense A/c	Fallback codes for items not allocated by rules	Are the remembered codes appropriate for this job?
Exclude items before / And after	Dates outside the interval are omitted	Would the settings discard required historical rows?
Auto-Reconcile	Can omit recognised existing items and mark records reconciled	Has that effect been deliberately reviewed?

These fields serve different purposes. Changing Source cannot repair a wrong Bank selection. A plausible default expense code cannot establish the correct treatment of every withdrawal.

Check file route and coverage together

The manual describes native bank formats including QIF and OFX-family files, a Generic CSV source, and a separate Import Transactions alternative for text data. Do not treat those as an identical CSV wizard across all MoneyWorks products. Regional bank feeds mentioned for Australia and New Zealand are a separate service, not a global capability implied by this article.

Identify the MoneyWorks product and the source’s single bank account. Preserve the original bank file.
Inspect the existing Statement Coding configuration without loading or accepting new data for this review.
Compare the source’s first and last relevant dates with both cutoff controls. The manual says the “before” default relates to the prior import’s last transaction; inspect the actual value, not an assumed month boundary.
Record remembered fallback income/expense accounts and any rules relevant to the proposed data. Keep unknown coding unresolved rather than relying on last time’s defaults.

Auto-Reconcile has an accounting consequence

According to the manual, Auto-Reconcile compares against existing transactions, marks recognised duplicates for omission and marks new transactions reconciled; it also describes marking existing recognised transactions reconciled. It is not merely a date filter or a guarantee that a full bank statement comparison has been performed.

Keep an inventory of existing records and expected source items before choosing that option. A recognised match is still subject to your account and evidence checks. This guide has not executed the option or verified a particular organisation’s matching behaviour.

Synthetic preflight that should stop before import

The source identifies account A for September. Statement Coding still selects Bank B, carries a September 15 “before” filter, remembered codes PriorIncome and PriorExpense, and Auto-Reconcile is selected.

The mismatch in Bank is enough to stop the current decision. Even after the account is resolved, September 1–14 might be excluded by the existing filter, and the coding and reconciliation effects still require review. Do not correct one field and call the entire configuration safe.

Deliver source identity, target identity, cutoffs, fallback codes and the unresolved effects as a checklist. The resulting evidence supports an authorised next step; it does not claim successful import, duplicate prevention or automatic accounting accuracy.

Test the date decision independently of the application

For a bookkeeper preparing a historical import, the source interval is the dates present in the original file; the cutoff interval is the range Statement Coding is configured to keep. They need not match. A wrong target Bank stops the decision before either interval is relied on.

The fictional date worksheet isolates the manual’s “before” and “after” wording. With a September 15–30 inclusive interval, an executed Python comparison gives:

Fictional record	Date	Documentary interval model
M1	September 14, 2026	Outside, before lower boundary
M2	September 15, 2026	Inside, at lower boundary
M3	September 30, 2026	Inside, at upper boundary
M4	October 1, 2026	Outside, after upper boundary

Two rows are inside and two outside this model. The CSV is a teaching worksheet, not a MoneyWorks import file; Python did not execute MoneyWorks or test its parser. In your preflight, resolve the wrong Bank first, then record the actual cutoff values and any required rows they would omit. Even if dates agree, remembered coding defaults and Auto-Reconcile remain separate decisions. Do not describe a corrected date range as a successful or reconciled import.

Synthetic review case. The values are teaching data, not a vendor export or an import file.

For a bank source available only as PDF, download LocalExtract. It processes one PDF locally into date,description,amount CSV; review and adapt those rows for the actual destination.

Documentation for the added task checked October 16, 2026.