Your cash flow looks amazing after you pull a bank statement into Excel… a little too amazing. If negatives turned into positives, you didn’t mess up the math. The sign just got lost on the way in.

Happens all the time with PDFs and some CSVs. Accounting parentheses, trailing minus signs (123.45-), weird Unicode minus characters, non‑breaking spaces, DR/CR labels, even regional formats (1.234,56 vs 1,234.56) can trip Excel and wipe the minus. Annoying, but fixable.

Below, I’ll show what causes it, how to spot the exact issue fast, and several easy fixes—Find/Replace, formulas, Text to Columns, or a repeatable Power Query setup with the right locale. We’ll also check balances so you know your numbers add up. And if you just want it to work every time, I’ll show you a simple way to convert statements with BankXLSX so the signs survive the trip.

Executive summary and the quick fix

If Excel shows bank statement negatives as positives after PDF import, you’re fighting how text is parsed. Banks show “negative” in a bunch of ways: (1,234.56), 1,234.56-, DR/CR, or red text. When that hits Excel, the sign can be dropped or turned into a character Excel doesn’t treat as a minus.

Quick ways to fix it now:

• Normalize characters: swap Unicode minus (CHAR(8722)) and en dash (CHAR(8211)) for a regular “-”, and remove non‑breaking spaces (CHAR(160)).
• Turn accounting parentheses into real negatives: replace “(” with “-”, delete “)”, then convert to numbers.
• If the minus is trailing, move it to the front with a formula, then use VALUE or Text to Columns so Excel treats it as numeric.

Example: =VALUE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(A2,CHAR(8722),"-"),CHAR(8211),"-"),CHAR(160)," ")) usually fixes text numbers after cleanup. For parentheses: =-VALUE(SUBSTITUTE(MID(A2,2,LEN(A2)-2),",","")).

Last step—always: check that opening balance + SUM(transactions) = closing balance. If it doesn’t tie, a sign is still off somewhere.

Rather skip the manual stuff? BankXLSX preserves minus signs when converting PDF bank statements to Excel. It reads parentheses, trailing minus, DR/CR, and regional formats correctly, so you can move on with your month-end.

Why negatives flip to positives during conversion (root causes)

Excel expects a leading “-”. Many statements don’t use one. That’s where things go sideways:

• Negative numbers in parentheses not recognized in Excel. (1,234.56) looks right to humans, but Excel reads that as text unless you convert it.
• Trailing minus signs (1,234.56-). Copy/paste or PDF extraction turns that into a harmless character at the end of a string.
• Unicode minus vs hyphen issue in Excel (CHAR 8722). PDFs, OCR, or exports love fancy minus characters. Excel doesn’t.
• Non-breaking spaces near currency symbols. CHAR(160) blocks number conversion and can separate the sign from the digits.
• Locale mismatches. Import an EU-style 1.234,56 with US settings and you’ll get nonsense or text—sign info gets lost in the chaos.
• DR/CR without a minus. If that column gets dropped or ignored, everything looks positive.
• Cleanup mistakes. Remove parentheses but forget to add a minus? Boom—positives everywhere.

One more weird one: multi-line PDF extraction. The minus or closing parenthesis falls onto the next line, so the parser reads a positive number in one row and an orphaned sign on the next. Easy way to flip amounts without noticing.

Rapid diagnosis: determine exactly where the sign is lost

Don’t guess—check the pattern. A few quick tests will tell you what broke:

• Number or text? In a helper column, try =ISNUMBER(A2). FALSE means Excel hasn’t parsed it yet.
• Peek at the edges. =RIGHT(A2,1) catches a trailing minus. =LEFT(A2,1) and =RIGHT(A2,1) spot parentheses.
• Hunt sneaky characters. =UNICODE(MID(A2,pos,1)) reveals if you’re dealing with a Unicode minus vs hyphen issue in Excel (CHAR 8722).
• Kill NBSPs. If =LEN(A2) > LEN(SUBSTITUTE(A2," ","")) but it still won’t convert, remove CHAR(160), the non‑breaking space blocking number conversion Excel.
• Locale check. Do your decimal and thousands separators match your Excel region? If not, fix the import.
• Coercion test. After cleanup, try =VALUE(cleaned) or multiply by 1. If it turns into a positive, your sign logic still needs work.

Have a running balance column in the PDF? Great. Calculate daily deltas and compare to your signed transaction column. If they don’t match, you’ve found the rows with flipped signs—no need to hunt line by line.

Fixes directly in Excel (no import redo needed)

You can repair most files without starting over. Try these:

• Parentheses to negatives: Select the Amounts, hit Ctrl+H, replace “(” with “-”, then replace “)” with nothing. Remove thousand separators and use Text to Columns to make them numbers.
• Trailing minus fix: =IF(RIGHT(A2,1)="-",-VALUE(SUBSTITUTE(LEFT(A2,LEN(A2)-1),",","")),VALUE(SUBSTITUTE(A2,",",""))) handles 123.45- cleanly. It’s a common “fix trailing minus sign amounts in Excel (e.g., 123.45-)” approach.
• Normalize odd characters: =SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(A2,CHAR(8722),"-"),CHAR(8211),"-"),CHAR(160)," ") swaps look‑alike dashes and clears NBSP.
• Text to Columns to convert text numbers in Excel: Data > Text to Columns > Finish often nudges cleaned values into real numbers.
• Value vs look: If it’s red or bracketed but SUM ignores it, that’s just formatting. Convert first; pretty it up later.

Handy move: create one “cleanup” named formula that normalizes characters. Then build sign rules on top of that. Keeps you from accidentally negating twice when steps pile up across sheets.

Power Query: a repeatable, locale-aware cleanup pipeline

If you do this every month, Power Query saves time and reduces fixes to a refresh:

• Get Data from PDF/CSV/Table.
• Replace values: turn Unicode minus and en dash into “-”; swap NBSP for a normal space. Many “Power Query convert parentheses to negative numbers” guides start here.
• Handle sign rules: replace “(” with “-”, delete “)”. For trailing minus, use if Text.End([Amount],1) = "-" then -1 else 1 logic to apply the sign.
• Map DR/CR: if there’s a Type column, do if [Type]="DR" then -Number.From([Amount]) else Number.From([Amount]).
• Set types with locale: Change Type > Using Locale so 1.234,56 and 1,234.56 parse correctly—prevents locale mismatch decimal comma CSV import in Excel.
• Remove clutter: currency symbols, footnote markers, long dashes that actually mean zero.
• Validate inside the query: calculate totals and the balance tie-out. If it doesn’t reconcile, stop the load so you can fix it before anyone posts numbers.

For tricky PDFs, group by page or section first. That keeps shifting columns on later pages from scrambling earlier rows—and helps preserve signs when layouts get weird.

Importing with the right locale and settings

Pulling in a CSV? Set it up right and you dodge most sign problems:

• Data > From Text/CSV. Choose File Origin and Delimiter. Click Transform Data and set Column Type Using Locale to match the statement (e.g., German (Germany) for 1.234,56).
• For bank statement CSV import settings for correct signs, set “Decimal number” with the right locale before loading. That stops 1.234,56 from becoming 123456 or plain text.
• If amounts use parentheses or a trailing minus, don’t hope the wizard guesses the sign—add a quick replace or conditional step in Power Query.
• Try not to copy/paste from PDFs. That’s how Unicode minus and NBSP slip in. If PDF is your only source, convert to CSV or use a statement-aware converter.

Bonus tip: save a per‑bank import preset in Power Query with locale and column mapping baked in. When the bank tweaks the layout, your sign and locale rules still hold. Future you will be grateful.

Quality control: prove your signs are correct

Before pushing data into your GL or dashboards, verify it:

• Reconcile opening and closing balances after conversion: Opening + SUM(Signed Transactions) = Closing. Add a “Difference” cell. It should say zero.
• Match totals: rebuild “Total Debits” and “Total Credits” and compare to the statement. If debits are tiny, you likely lost parentheses or a minus along the way.
• Sanity check: filter by category (fees, interest, refunds). You know which ones should mostly be negative or positive.
• Spot check a handful of lines against the PDF/portal.
• Look for oddballs: -0.00, very large amounts, rows with currency codes or symbols.

One more solid check: compute a running balance from your converted data and line it up with the statement’s running balance (if they provide it). The first mismatch usually points straight to the row with the wrong sign.

Edge cases you’re likely to encounter

Some patterns pop up over and over, especially in PDFs:

• Red text/brackets lost as negatives during PDF to CSV conversion. Color doesn’t survive extraction, so add the sign yourself.
• Dashes as zero: a long “—” in Amount often means 0. Replace with 0 before you convert.
• Amounts with currency codes/symbols: “USD -1,234.56” or “1.234,56 EUR.” Strip codes/symbols first, then parse with the right locale.
• Multi-line descriptions: sometimes the sign and digits land on different lines. Combine by date/ID first, then set the sign.
• Mixed locales in one statement: parse by currency with a conditional locale step in Power Query.
• Double signs: after making “(123)” into “-123”, don’t also multiply by -1 somewhere else.

Watch for “invisible” minus too. Some PDFs draw a vector minus that never lands in the text layer. If your totals don’t reconcile, check likely withdrawal rows and validate against the running balance to confirm the intended sign.

Prevent the problem next time: process and templates

Turn this from a rescue mission into a routine:

• Document each bank’s style: parentheses or trailing minus? DR/CR? Decimal and thousand separators?
• Build a reusable template: a Power Query setup that normalizes Unicode minus, removes NBSP, converts parentheses, maps DR/CR, and sets types by locale. Next month: Refresh.
• Keep a tiny validation block: opening + transactions = closing. If it breaks, don’t proceed.
• Archive the original PDF/CSV with the converted file. Future audits—and future you—will thank you.
• Train the team: a one‑pager with screenshots for Text to Columns and Change Type Using Locale goes a long way.

If you manage multiple entities or banks, store rules in a simple “bank profile” table (locale, sign style, currency). Let your query read those and apply them. It helps you preserve minus signs converting PDF bank statements to Excel, even when layouts drift a bit.

Fast, reliable conversion with BankXLSX

If you don’t want to babysit imports, BankXLSX is an automated bank statement to Excel tool that preserves negative signs. It’s built for real bank layouts, not just pretty PDFs:

• Sign intelligence: converts parentheses to negatives, fixes trailing minus, and maps DR/CR to the correct sign.
• Character hygiene: normalizes Unicode minus and dashes, removes NBSP, and drops footnotes without touching amounts.
• Locale-aware parsing: handles 1.234,56 and 1,234.56 side by side without guesswork.
• Robust extraction: multi-page PDFs, shifting columns, multi-line descriptions—no problem.
• Clean outputs: typed amounts in XLS/XLSX or CSV, plus an audit trail so you can see what changed.

Finance teams like the control: save per‑bank profiles, require reconciliations, and stop files that don’t tie. Fewer re-uploads to your ERP, fewer late-night cleanup sessions, and evidence ready when someone asks “how did you get this number?”

Implementation checklist (Before, During, After)

Before

• Identify sign conventions (parentheses, trailing minus, DR/CR), locale, and currency. Note if running balances exist for validation.
• Pick your workflow: Excel-only, Power Query, or BankXLSX.

During

• Normalize characters: replace Unicode minus, en/em dashes, and remove NBSP.
• Apply sign logic once: convert parentheses, move trailing minus, map DR and CR to negative values in Excel where needed.
• Set data types with the right locale; remove currency symbols and thousand separators.
• Coerce to numbers using VALUE/Text to Columns; confirm with ISNUMBER.

After

• Reconcile opening + SUM(transactions) = closing.
• Match debits/credits to the statement totals; scan for weird cases like -0.00.
• Spot check 10–20 lines against the PDF or banking site.
• Save/refresh your template or profile; archive the source files.

Tip: add a tiny “conversion metadata” sheet—date, file name, locale, and a short log of replacements. It shows your work without slowing you down.

FAQs and troubleshooting

• Why do numbers show positive even though the PDF used parentheses? Parentheses are visual formatting, not a true minus. Replace “(” with “-”, remove “)”, then convert.
• How do I fix trailing minus signs? Move “-” to the front with a formula or a Power Query conditional, then convert the text to a number.
• What’s the difference between hyphen and Unicode minus? Unicode minus (CHAR 8722) looks the same, but Excel often treats it as text. Replace it with a standard hyphen.
• Excel shows the right color or brackets but formulas act wrong—why? You’re looking at formatted text. Convert the value to numeric first.
• How do I handle DR/CR? Build a signed Amount: DR becomes negative, CR becomes positive.
• My EU-format numbers (1.234,56) import incorrectly—what settings should I use? Import via From Text/CSV and set Column Type Using Locale to match the statement.
• How do I avoid double-negatives? Don’t add a leading “-” and also multiply by -1 later. Keep sign logic in one step.
• Does this work for both PDF and CSV? Yes. CSV with the right locale is easier. PDFs benefit from a statement-aware converter or a solid Power Query flow.

Quick takeaways

• Why it happens: sign cues vanish during PDF/CSV import—parentheses, trailing minus (123.45-), Unicode minus/en dash, non‑breaking spaces, DR/CR, or locale mismatches—so negatives show up as positives or plain text.
• Diagnose fast: check ISNUMBER/ISTEXT, look at the first/last character for parentheses or trailing minus, normalize characters (CHAR 8722, 8211, 160), verify separators, and compare running balance deltas.
• Fix in Excel: convert parentheses with Find/Replace, move a trailing minus with a formula, normalize characters, then coerce with VALUE or Text to Columns; or use Power Query with “Change Type Using Locale” and DR/CR mapping. Avoid double‑negatives.
• Prevent and validate: import with the right locale, use bank CSVs when possible, and always reconcile (opening + SUM = closing). Want a reliable, fast path? Use BankXLSX to export clean XLS/XLSX or CSV.

Conclusion

Negatives turning positive after converting a bank statement PDF to Excel usually comes down to lost sign cues—parentheses, trailing minus, Unicode minus, non‑breaking spaces, DR/CR, or locale issues. Spot the pattern, fix it with a quick Find/Replace, a couple formulas, Text to Columns, or a Power Query step, then reconcile opening + transactions = closing.

If you want fewer headaches, try BankXLSX. It understands financial formats, preserves signs, handles locales, and gives you clean XLS/XLSX or CSV you can trust. Upload a sample and see it in minutes. Start a free trial or request a demo.