BankStatementScan
English

Minus signs and parentheses in bank amounts: normalize without reversal

Review Unicode minus signs, trailing signs and parentheses before converting bank amounts to numbers, with a controlled example.

Decide what a negative amount means in the source before normalizing its spelling. The glyph −, a trailing minus and parentheses may require different import handling. They are not permission to make every debit negative twice.

Identify the source sign convention first

  1. List the exact amount patterns present in the PDF or raw export. Separate a signed-amount column from positive debit/credit columns.

  2. Create one explicit rule per confirmed pattern in a working column. Apply it only to amounts, not references or descriptions, and retain the original spelling.

  3. Parse the normalized result as a number. Flag unmatched patterns and compare the direction with the source column or transaction label.

Fictional example

For a fictional source that explicitly uses all three forms for outflows, −25.40, 25.40- and (25.40) each become −25.40. A fourth value 25.40 in a positive debit column needs the separate debit/credit mapping, not a guessed parentheses rule. Never turn −25.40 into +25.40 by applying a second sign inversion.

Recognize one complete pattern at a time

Separate recognition, sign assignment and numeric conversion. For this fictional signed column, accept a plain number, one leading minus, one trailing minus or one complete pair of parentheses. Remove the recognized wrapper, parse the magnitude using the confirmed decimal convention, then apply the recorded sign once. Do not also run the positive debit-column rule on that result.

Reject (−25.40), 25.40-- or a missing closing parenthesis for review instead of guessing how two markers interact. A reference containing a hyphen is outside the rule. Replace only the complete, confirmed amount pattern; keep the original text for comparison.

Verify both direction and repeatability

Use two additional fictional rows: an outflow (25.40) and an inflow 40.00. Expected signed values are −25.40 and +40.00, net +14.60. A lost negative would produce +65.40, a 50.80 difference. Separate outflow and inflow totals explain that difference; a count of converted cells alone would not.

Run the working rule a second time on its own output as a check: −25.40 must stay −25.40. If it changes, the process applies a direction rule more than once. Keep amounts that are already valid numbers separate from text requiring normalization, and compare the saved output with a known payment and receipt before import. An unfamiliar pattern remains an exception even if a plausible total can be produced.

Separate a recognized spelling from a confirmed direction

Create three working fields beside the untouched source: recognized pattern, signed result and exception reason. Set the decimal and thousands conventions before parsing. In this fictional EUR export, commas mark decimals and periods group thousands; that convention belongs to this example, not to every English-language bank file.

Fictional sourceConfirmed contextProposed outcome
−25,40Signed column; Unicode minus denotes outflowNumeric −25.40
1.234,50-Signed column; trailing minus denotes outflowNumeric −1234.50
(25,40)Document explicitly defines negative parenthesesNumeric −25.40
25,40Positive debit column−25.40 after the separate debit mapping
(−25,40) or blankConflicting markers or missing amountUnresolved; no numeric value invented

First recognize the entire raw amount, then remove only its confirmed sign wrapper and documented grouping characters. Convert the remaining magnitude with this file’s decimal convention and apply direction once. An ASCII hyphen - and Unicode minus − are different characters; recognizing one does not prove the other was handled. A dash in a description or reference remains outside this amount rule.

Treat blank, unrecognized and zero as different outcomes. A visibly documented 0,00 can become numeric zero. An empty field, lone dash or unreadable digit remains unresolved until its meaning is confirmed. Keep exception rows in the table so they are visible; do not let a sum silently omit them and then mark the whole batch complete.

For a second fictional check, combine 1.234,50- with an inflow of 2.000,00: expected net is +765.50 EUR. Losing the negative gives +3234.50, a difference of 2469.00, twice the debit magnitude. Check both directional totals and the exception count. If the parsed sign conflicts with a source debit/credit label, stop that row and inspect the bank’s convention rather than choosing whichever sign balances the statement.

Checks and limits

Count positive and negative results before and after transformation. Review a payment, receipt and reversal. A text-replacement function can perform a chosen substitution, but cannot infer the bank’s sign convention. If parentheses denote an annotation rather than a negative number, keep that row unresolved until the source clarifies it.

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

Interpret signs after confirming the amount and removing documented thousands separators. Debit and credit columns to one signed amount: a bank CSV method · Bank amounts stored as text: find invisible thousands spaces · Check a bank statement balance without hiding extraction errors.

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.