Amount Sign QA: Catch Parentheses, DR/CR, and Negative Mismatch Before Import

A sign-mapping QA workflow that catches parenthetical negatives, DR/CR confusion, and amount sign drift before export.

May 4, 20265 min read

Amount Sign QA: Catch Parentheses, DR/CR, and Negative Mismatch Before Import

Amount signs are where exports lie with a straight face.

A value like 45.99 can be a debit or a credit depending on the statement format. Parentheses can mean negative. DR/CR columns can flip the sign. A minus sign can disappear in OCR. And because the number still parses, the bug survives long enough to hit reconciliation.

Amount Sign QA is the gate that prevents that. It checks that the sign you export matches the statement’s actual sign convention, then verifies the same sign survives CSV, XLSX, and JSON.

If you’ve ever seen totals drift by a penny or a whole row because sign logic was inconsistent, this is the fix.

Why sign bugs are so dangerous

Sign mistakes are bad because they look like valid numbers.

-45.99 is valid.
45.99 is valid.
(45.99) is valid text.
DR 45.99 is valid business notation.

The parser doesn’t crash. The export looks tidy. The ledger is wrong.

That’s why amount sign QA has to be explicit, not inferred from “it seems fine.”

What the sign gate must prove

Your pipeline should prove all of this:

The statement convention is known

parentheses as negative
DR/CR or debit/credit labeling
explicit minus signs

The parsed sign matches the cue

a debit is negative when it should be
a credit is positive when it should be

The sign is stable across exports

CSV, XLSX, and JSON all preserve the same signed value

Boundary rows are handled correctly

fees, reversals, and refunds often use different sign rules than purchases

Sign convention patterns to watch

Pattern 1: parentheses

(45.99) usually means a negative amount.

But don’t assume every bank uses the same convention. Some use parentheses only in summaries, not transaction rows.

Pattern 2: DR/CR columns

A separate column may indicate whether a row is a debit or credit.

In that case, the numeric amount alone is incomplete. The sign comes from the indicator column.

Pattern 3: explicit minus signs

The minus sign is easiest to read and easiest to lose in OCR.

A missing minus sign can turn a withdrawal into income.

Pattern 4: mixed conventions in one statement

Some statements use one sign convention for card payments and another for transfers or fees.

That’s where “global sign rules” fail.

The QA workflow

Use this sequence.

Step 1: classify the statement’s sign rule

Look at the header and a few sample rows.

Step 2: derive sign from the statement cue

Never just trust the raw number.

Step 3: compare sign to surrounding balance behavior

If the statement has running balances, the sign should move the balance the right direction.

Step 4: run export parity

CSV/XLSX/JSON should agree on the final signed value.

Step 5: quarantine ambiguous rows

If a row has unclear sign evidence, do not guess.

Common failure modes

Failure 1: minus sign disappears in OCR

The row still looks valid, but the transaction reverses direction.

Failure 2: DR/CR mapped backwards

A debit gets treated as a credit because the parser inverted the indicator column.

Failure 3: parentheses treated as formatting, not meaning

The parser strips the parentheses and loses the negative semantics.

Failure 4: refunds and fees share the same label but not the same sign rule

A fee may be negative while a refund is positive, or vice versa.

A practical sign rule table

Cue	Normalized sign	Risk if wrong
`(45.99)`	negative	withdrawal becomes credit
`DR 45.99`	negative (if DR means debit)	debit/credit inversion
`CR 45.99`	positive (if CR means credit)	incoming payment becomes expense
`-45.99`	negative	OCR-minus loss
plain `45.99` with indicator column	depends on indicator	sign ambiguity

Do not let one format invent a different meaning than the others.

Worked example: one missing minus sign breaks the month

The failure

The statement includes:

04/30 Refund 120.00
04/30 Fee 12.00
05/01 Subscription 45.00

OCR drops a minus sign on the fee row.

Now the export treats the fee as income.

What QA catches

sign cue does not match row meaning
running balance moves the wrong direction
export parity may still pass if every format preserves the same wrong sign

Repair

map the fee row according to statement cue, not raw text alone
re-run sign validation against balance movement
re-export

Worked example 2: DR/CR inversion

The statement has a separate indicator column:

DR 25.00 means money out
CR 25.00 means money in

If the parser swaps them:

purchases become credits
deposits become debits

What QA catches

the balance changes in the wrong direction
samples near the top of the statement show reversed movement

Repair

fix the indicator mapping table
add a unit test for DR/CR behavior
re-run export parity and balance QA

How this connects to other gates

Sign QA interacts with:

running balance sequence QA, because sign errors break the balance step
export parity QA, because different formats may round or render signs differently
dedupe QA, because sign is part of the transaction fingerprint

FAQ

1) Can I just normalize every amount to negative?

No. That destroys the meaning of credits and debits.

2) What if the bank mixes conventions?

Then the statement is layout-specific and the sign rules need to be layout-specific too.

3) Is sign QA still needed if the totals tie out?

Yes. Totals can tie out while the row-level sign logic is wrong in a way that breaks categorization and matching.

4) Should sign QA happen before dedupe?

Yes. Dedupe fingerprints need the correct sign.

5) What’s the fastest practical gate?

Compare sign cues against running-balance movement on a sample set from the top, middle, and bottom of the statement.

Bottom line

Amount Sign QA keeps numeric values from meaning the wrong thing.

If signs are stable and consistent, reconciliation stops being a guessing game.

FAQ