Separate a statement export from a decision: an offchain review packet

A reimbursement discussion becomes difficult to review when a transaction table silently turns into a claim about what the community approved. A bank statement records movements in an account. An invoice describes a purchase. A decision record explains authorization. Those documents can support one another, but none should be substituted for the others. This note proposes a small, practical packet for checking ordinary offchain expenses without confusing extraction, reconciliation, and approval.

Disclosure: I am sharing this resource in connection with Bank Statement Converter. This is a document handling example, not a funding request, governance proposal, investment recommendation, or claim of affiliation with Karura or SubSquare. The examples below are fictional. They do not describe a real treasury, member, bank account, or transaction, and the approach does not require connecting a wallet or taking any onchain action.

Begin with a question the evidence can answer

Start by writing the limited question at the top of the packet. For example: do the three submitted expense receipts correspond to the three payments selected from this statement period? That question is narrower than asking whether the payments were appropriate, whether a project succeeded, or whether the account holder complied with every applicable rule. Keeping the question narrow helps reviewers identify what they can actually confirm and where a separate decision is still necessary.

Agree on the period and the account scope before extracting anything. A screenshot of a single payment may omit the booking date, currency, or nearby reversal. Conversely, a complete personal statement may reveal much more than a reimbursement reviewer needs. The account holder should prepare an appropriately limited working copy through an authorized process. Do not place original financial documents, account identifiers, or personal addresses in a public discussion just to demonstrate a workflow.

Preserve the difference between source and working table

Keep an original source reference in the private working packet, subject to the relevant retention rules. Record a neutral document identifier, statement period, and page number for each selected row. A reviewer should be able to return from a row in the working table to the relevant source without guessing which export file was used. A filename such as March expenses is not enough when several versions exist and dates have been interpreted differently.

Treat the exported spreadsheet as a working representation rather than the source of authority. Extraction can put visible information into useful columns, but it does not determine ownership, authorization, purpose, or completeness. In particular, a description containing a supplier name does not prove that the payment covers the invoice attached to the packet. The link between those two records needs its own explanation, and uncertain matches should remain visibly uncertain.

Use a tiny fictional fixture before a real packet

A useful practice fixture contains six deliberately different rows. Include one outgoing supplier payment, one incoming refund, one internal transfer, one fee, one duplicate looking amount on a different date, and one description that wraps onto another line. Write down the expected interpretation in ordinary language before importing anything. The goal is not to imitate a bank document convincingly; it is to make the review questions explicit with harmless synthetic data.

Give the fixture two dates where practical: the transaction date and the booking date. Include a currency column even when every row uses the same currency. Keep an original amount representation alongside a normalized amount used for calculations. These choices expose assumptions early. If a spreadsheet changes a date on opening, removes leading zeroes from a reference, or interprets a separator incorrectly, the small fixture makes the change easier to identify.

Extract first, then check the columns

Bank Statement Converter is a browser based tool for turning PDF or image bank statements into Excel, CSV, or JSON. It supports individual and batch processing, with individual files, ZIP downloads, or merged exports. Its paid subscriptions and page credits should be checked against the current pricing before use. The product is one possible extraction step, not an approval system, accounting judgment, or promise that every document will produce an error free table.

The product reference is https://bank-statement-converter.online/. Use only documents you are authorized to process and review the applicable terms and data handling requirements before uploading sensitive material. No confidentiality, accuracy, or bank integration guarantee is implied here. A community can apply the same checks to a table obtained through another normal extraction method, including a bank supplied export. The important part is the evidence boundary, not which tool produced the first draft.

After extraction, inspect the column headings and several representative rows before merging files or calculating totals. Check whether debits and credits appear as separate columns, signed values, or positive numbers with a direction label. Verify a wrapped description against the source. Make sure page headings, opening balances, and footer text have not been treated as transactions. A clean looking table is not a substitute for these basic checks.

Reconcile a defined subset, not an unexplained grand total

Build a review sheet that separates the original row identifier, source location, normalized amount, proposed receipt match, and reviewer note. Use explicit states such as matched, unmatched, ambiguous, or excluded with reason. Do not replace these states with a single green checkmark whose meaning is unclear. Another reviewer should understand whether the mark refers to extraction accuracy, a receipt match, or approval, because those are different conclusions supported by different evidence.

For the fictional supplier payment, compare amount, currency, date context, and payment reference with the receipt packet. For the refund, retain a separate row and explain which earlier expense it may reverse. Do not silently subtract the refund from another row and discard its source location. An internal transfer should not become a supplier expense simply because money left one account. A fee may require its own category rather than being folded into an unrelated invoice.

When two payments have the same amount, resist matching the first plausible receipt automatically. Mark both candidates and explain what additional evidence would distinguish them. A corrected invoice reference, a booking date, or an account holder explanation may resolve the question. If it does not, leave the ambiguity visible. The packet is more useful when it honestly identifies an unresolved match than when it produces an attractive total through undocumented assumptions.

Keep approval separate from arithmetic

Once the selected rows have been checked, compute a subtotal for that explicitly defined subset. Record the currency and any exclusions next to the subtotal. If the packet contains multiple currencies, avoid presenting one combined number without an explained conversion basis. A reviewer should be able to reproduce the arithmetic from the listed rows. Reproducing a number, however, still does not establish that every included expense was authorized or that an activity achieved its intended outcome.

Link the packet to the appropriate authorization record through a neutral reference, not by rewriting a payment description to sound approved. Where no authorization has been provided, state that the document check is incomplete for that purpose. Keep discussion about approval, accounting treatment, and document extraction in separate fields or sections. This makes it possible to correct a spreadsheet import without accidentally changing the apparent decision history.

Handoff with a short limitations note

A useful handoff explains the source period, extraction method, selected subset, checks performed, unresolved questions, and reviewer date. It should also say what was not checked. For example, confirming that a payment row matches a receipt does not establish tax treatment, legal compliance, beneficial ownership, or project delivery. Those questions may need qualified review or different evidence. Clear limitations protect readers from relying on the packet for a purpose it was never designed to serve.

Before sharing anything publicly, create a separate summary that excludes account numbers, private references, and original documents. Explain the method with the fictional fixture rather than publishing real statement rows. Keep access to the underlying packet limited to the appropriate people. The practical outcome is a traceable review process: a reader can distinguish what the source shows, what the extraction produced, what was matched, and what remains a separate human decision.