BankStatementScan
English

Blank, zero or missing bank amount: do not treat them as the same

Distinguish unused debit/credit fields from explicit zeros and failed extraction before calculating totals or importing a bank CSV.

A blank amount can mean an unused debit column, an unreadable cell or a missing extraction. Zero means a known numeric value. Keep these states distinct until the source confirms which applies; filling every blank with zero can conceal missing transactions.

Classify the cell before cleaning the spreadsheet

An empty-looking cell is a visual observation, not a complete data definition. Use this review matrix on the original statement and retain the classification in your working file.

Source situationReviewed statusAmount used in a complete totalNext action
Debit 12.00, credit visibly unusedKnown debit; unused opposite side−12.00Preserve the blank credit in the source fields
Explicitly printed 0.00Confirmed zero0.00Keep evidence of the printed value
Debit blurred or cut offUnresolved amountUnknownReview a better source; do not impute zero
Both debit and credit empty on a description linePossible continuationNot yet a transaction amountEstablish which transaction owns the line
Raw value exists but conversion returns an errorParsing failureUnknown until resolvedCheck separators, sign and data type

The table is a proposed review method, illustrated with invented values. A missing amount is different from an unused side: for the first row the transaction amount is known, even though one of its source cells is empty. Keep those two levels separate when counting incomplete transactions.

Practical method

  1. Compare the blank cell with the PDF. Record whether it is visibly empty, explicitly zero or unreadable.

  2. Add a review-status column before calculations. Use zero in calculations only for a confirmed unused side of a debit/credit pair.

  3. Keep unresolved rows out of an approved export, with their source references, rather than silently converting errors into zero.

Fictional example

Fictional row A has debit 12.00 and a visibly empty credit field: a calculation may treat that unused credit as zero. Row B has a blurred debit and no credit; its amount is unknown. Turning B into 0.00 hides the problem even though both rows initially look partly blank.

Keep the raw cell and the decision in separate fields

For each amount, retain the source text, page/row reference, interpretation and derived numeric value. Use interpretations such as known amount, confirmed unused side, printed zero, and unresolved reading. The raw credit cell of A stays empty; only the calculation uses zero for that confirmed unused side. The blurred debit of B stays unknown. An explicit zero remains a reviewed value rather than being grouped with B.

Add a fictional row C whose amount is explicitly printed as 0.00. The three signed amounts are therefore −12.00, unknown and 0.00. The known subtotal is −12.00, with two resolved amounts out of three and one unresolved amount. It is not the complete movement total. If B is later confirmed as a debit of 5.00, the complete total becomes −17.00. Label the earlier result “known subtotal, one amount unresolved”, not “total −12.00”.

A numeric result does not clear the missing-value check

Calculate the known subtotal and check value types separately; neither replaces a review of missing amounts. Neither establishes source completeness. Review the unresolved count beside the sum. If an exchange format cannot carry that status, accompany an explicitly partial file with an exception list, or wait for resolution before releasing a complete export. Preserve the excluded source rows so the recipient can distinguish “not supplied” from “zero”.

Keep null, empty text and numeric zero distinct

A CSV field can contain no characters, a spreadsheet formula can display nothing, and a query can store null. The recipient may interpret these differently. Decide the business meaning from the source first, then map that meaning to the destination’s allowed representation. A text label such as “unresolved” belongs in a status field, not in a numeric amount column expected by an importer.

A subtotal over known amounts must remain explicitly partial when any candidate amount is unresolved. For the invented set {−12, null, 0}, the known sum is −12. Do not present it without its companion counts: three candidate transactions, two known amounts, one unresolved. An entirely unknown set is different again: there is no known subtotal to report as zero. A successful type conversion or a nonempty total cell does not decide completeness.

Choose between a complete delivery and a disclosed partial file

Before export, count confirmed transactions, confirmed zero amounts, unresolved transaction amounts and excluded continuation or control rows. The counts describe different categories; “ten blanks” alone does not tell the recipient whether ten payments are missing. Give each unresolved transaction a source locator and a reason so it can be corrected without searching the whole PDF again.

If the receiving import requires a number on every row, pause the complete import until unresolved amounts are clarified. When a partial delivery is useful and accepted by the recipient, label it as partial, preserve the excluded rows separately and state the omitted count. For example, the three-row fictional case may deliver two reviewed rows and an exception list with row B; it must not claim to deliver all three payments. Recheck the generated CSV in plain text and in the receiving preview: a status column lost during export can turn an explicit uncertainty into an apparently normal blank.

Checks and limits

Count unresolved amounts separately from numeric zeros. Check whether an empty-looking cell contains a formula returning an empty string. A type check distinguishes kinds of stored values, but source review determines their meaning. Approve the export only when the treatment of each missing amount is explicit.

Keep the original file unchanged and record any unresolved item before using the table.

Distinguish an unused debit or credit field from a missing reading. Debit and credit columns to one signed amount: a bank CSV method · Bank statement columns shift at a page break: check the boundary · Check a bank CSV before opening it in Excel.

BankStatementScan is in preparation. The site offers an access request and a fictional example; it does not currently convert your bank files. See the planned service.

Sources consulted on 16 October 2026

Leave your work email to register your interest. The conversion product is still in preparation.

Explore the example
BankStatementScan

Request access to BankStatementScan.

Leave your work email to register your interest. The conversion product is still in preparation.

Submitting sends your email and visit/context information to BankStatementLab infrastructure for BankStatementScan. No account, payment or automatic email is created. Privacy.