(1,234.56) is not being read as a negative number

Amounts wrapped in parentheses either fail to import or come through as positive numbers. A column that should net out to a small figure is roughly twice what it should be.

Why this happens

• Parentheses are the accounting convention for a negative, inherited from ledgers, where a minus sign was easy to miss and easy to lose to a bad photocopy. Every general ledger and most finance exports still write them this way.
• To anything reading the file as data, though, “(1,234.56)” is a string starting with an open bracket, which is not a number. So it either fails, or falls back to being read as text, or has its brackets stripped by a helpful cleanup step that leaves the value positive.
• The positive case is the expensive one. A refund, a credit note, or a reversal that lands as a positive does not merely disappear from the total; it moves it in the wrong direction by twice its own value, and the resulting figure is plausible enough to survive a review.

What to do right now

• Total the column and compare it against a figure you already trust before using any of it. This error is invisible per row and obvious in aggregate.
• Look specifically at rows that should be credits: refunds, returns, reversals, adjustments. If those are positive, the whole column needs redoing rather than patching.
• Ask for the export with a minus sign rather than brackets if the source system offers the option. It is usually a display setting on the report, and it costs the sender nothing.

Stopping it on the next file

A number field reads a parenthesised value as negative, so (1,234.56) arrives as -1234.56 and a credit subtracts. That is applied along with the rest of the coercion in one pass, which means a cell can carry a currency symbol, a thousands separator, and brackets at once and still resolve to the right signed number rather than to text.

The invoice line items template is a sheet with those rules already set, if you want to see the shape of one before building your own.