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.

On this page8sections
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
-
List the exact amount patterns present in the PDF or raw export. Separate a signed-amount column from positive debit/credit columns.
-
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.
-
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 source | Confirmed context | Proposed outcome |
|---|---|---|
−25,40 | Signed column; Unicode minus denotes outflow | Numeric −25.40 |
1.234,50- | Signed column; trailing minus denotes outflow | Numeric −1234.50 |
(25,40) | Document explicitly defines negative parentheses | Numeric −25.40 |
25,40 | Positive debit column | −25.40 after the separate debit mapping |
(−25,40) or blank | Conflicting markers or missing amount | Unresolved; 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.
Related checks
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.