Home › Blog › Excel, CSV & Google Sheets › Signed Amounts vs Debit and Credit Columns
Understand the two amount conventions in statement files, which importers expect each one, and how to convert between them without flipping signs.
By StatementVerified Editorial · November 2, 2026 · 7 min read · Filed under Excel, CSV & Google Sheets
Every statement file presents amounts in one of two ways. Either there is a single amount column where money in and money out are distinguished by sign, or there are two columns, one for debits and one for credits, where each row uses only one of them. Both conventions are legitimate, both are common, and mixing them up is the single most reliable way to import a month of transactions exactly backwards. Deposits become payments, payments become deposits, and the account appears to have done the opposite of everything it did.
The confusion is compounded because the words debit and credit mean one thing on a bank statement and nearly the opposite in everyday ledger language. This guide untangles the terminology, shows how to tell which convention a file uses, explains which importers prefer which form, and gives a careful method for converting between the two without flipping a single sign.
In a signed-amount file, one column carries every transaction. Money leaving the account is negative and money arriving is positive, in the usual export convention, though a minority of banks reverse this and must be identified by testing a known transaction. In a two-column file, each transaction sits in either the debit column or the credit column and the other cell is blank or zero. On a bank statement for a deposit account, credits are money in, because the bank owes you more, and debits are money out. That is the bank view of the account, and statement converters preserve it.
The trap is that in your own books, the same deposit that the bank calls a credit increases your cash asset, which bookkeepers record as a debit to cash. New bookkeepers regularly try to fix a file that was never broken, swapping columns to match ledger language and reversing the import. The rule is simple: inside a statement file, think like the bank. Credit means in, debit means out. Translation into ledger language is the accounting software job at import, not something to pre-correct in the data.
Do not guess from the column headings alone, because headings vary and some converters label a signed column with a neutral word. Test the file against known facts. Find a transaction you can identify with certainty, a payroll deposit, a rent payment, a card purchase, and check how the file represents it. Then add the columns. In a two-column file, total credits minus total debits should equal the movement between the opening and closing balances. In a signed file, the plain sum of the amount column should equal that same movement. Whichever arithmetic ties to the statement is the convention the file is actually using, regardless of what you expected.
Watch for hybrid files, the genuinely dangerous case. Some conversions produce a signed amount column and also populate debit and credit columns from different parts of the statement, or switch style at a page break. A hybrid imports unpredictably because the importer will follow whichever mapping you give it across rows that do not share a logic. If testing reveals a hybrid, rebuild the file into one pure convention during cleaning rather than trying to map your way around it.
Import tools differ. Some bank-feed importers are built around a single signed amount and will reject or mishandle a two-column file unless their mapping screen offers separate money-in and money-out assignments. Others, particularly desktop import formats and accountant-oriented tools, are designed for split columns and treat a signed file awkwardly, sometimes importing every negative value as the opposite type. There is no universal winner; there is only the match between your file and the specific importer in front of you, which is why the mapping step asks what it asks.
Decide the target form per destination and record it on the saved mapping profile for that bank and account. A bookkeeper serving several clients may legitimately keep the same bank in signed form for one client file and split form for another, because the destination differs. What you must never do is change the form casually month to month for the same destination. Consistency lets you compare files, reuse checks, and notice immediately when a bank changes its export and the convention silently changes with it.
To turn two columns into one signed column, the formula in words is: for each row, take the credit amount if present as a positive value, otherwise take the debit amount and make it negative, and put the result in the single amount column. To go the other way, test the sign of the signed amount: positive values go into the credit column, negative values go into the debit column as positive numbers, because split columns conventionally hold unsigned amounts. Work on a copy, add the new columns beside the old ones, and compare row by row for a sample before deleting anything.
Verification after conversion is arithmetic, not eyeballing. The sum of the new signed column must equal total credits minus total debits from the original. In the split direction, the new column totals must reproduce the positive and negative sums of the original signed column. Then run the balance test for the whole period against the statement. Only when both checks pass do you remove the original columns and save the converted file as the import version, keeping the pre-conversion file in the folder as evidence of what changed.
A whole-file sign reversal is mercifully obvious once you look: the register movement is the negative of the statement movement, and known deposits show as payments. If the batch can be removed, remove it, fix the file, and re-import cleanly. Hand-editing hundreds of reversed records invites partial fixes, and a partially reversed file is worse than a fully reversed one because no single test describes it anymore. If removal is impossible in your system, reverse the import with an equal and opposite approach your software supports, under advice, rather than improvising line by line.
Partial sign errors, a handful of rows flipped during cleaning or conversion, are found by the running balance walk and by reconciliation differences that equal exactly twice a transaction amount. That doubling is the fingerprint of a sign error: the books differ from the bank by the amount counted once in each direction. When a reconciliation difference is an even, familiar number, divide it by two and search for a transaction of that size before hunting anywhere else. You will save yourself hours over a career with that one habit.
Money in. Statement files use the bank view of the account: a credit increases what the bank owes you, so deposits are credits and payments are debits. Do not swap the columns to match ledger terminology; the importer handles that translation.
Build a signed column on a copy of the file: credits become positive values and debits become negative values. Verify that the sum of the new column equals total credits minus total debits, and that the period still ties to the opening and closing balances before importing.
Check whether the difference is exactly twice the amount of a real transaction. A sign flip counts the amount once in the wrong direction, so the gap doubles it. Search for a transaction of half the difference and inspect which side of the account it landed on.
Excel, CSV & Google Sheets · November 3, 2026
Excel workbooks and plain CSV each win in different bookkeeping jobs. Learn the formatting risks of workbook round-trips and when to use each.
Excel, CSV & Google Sheets · November 5, 2026
Ambiguous date orders in statement files put transactions in the wrong month. Use one clear format per file and check the rows most at risk.
Excel, CSV & Google Sheets · November 4, 2026
Remove header blocks, page-title rows, subtotals, blank rows, and stray characters from a converted bank CSV so it imports cleanly the first time.
Convert a statement now and watch the reconciliation check verify it against the statement itself.
Your first conversion is free — no card, no sign-up — and every result is reconciled against the statement itself before you download it.