Bank CSV Field Mapping: Dates, Debit, Credit, and Narration

A bank CSV mapping is a contract between a source export and the schema used by reconciliation or accounting. The safest mapping begins with fields that actually exist in the source and keeps ambiguous concepts explicit.

Source-backed mapping example

A real bank-statement CSV example uses TRAN_DATE, CHQNO, PARTICULARS, DR, CR, BAL, and SOL. Its canonical mappings include:

• TRAN_DATE → transaction_date
• DR → debit_amount
• CR → credit_amount
• PARTICULARS → narration
• CHQNO → cheque_no

BAL and SOL are not automatically renamed because the correct destination meaning depends on the workflow. Keeping them unchanged is safer than inventing a universal accounting meaning.

N26 and Revolut-style entity fields

A separate multi-bank normalization workflow shows a transaction entity with bookingDate, valueDate, partnerName, partnerIban, type, paymentReference, accountName, amount, originalAmount, originalCurrency, exchangeRate, and category. These are useful examples of the concepts a multi-bank model may carry, but they should not be treated as guaranteed headers in every N26 or Revolut export.

Decide mappings by meaning

Dates need a documented choice: booking date and value date are not always interchangeable. References and narration may both be text but serve different reconciliation purposes. A single signed amount is not equivalent to having separate debit and credit columns unless you explicitly transform it.

The normalizer changes column names and order while preserving values. After mapping, validate the destination's date, decimal, currency, and required-field rules separately.

Map bank CSV fields

See the transformation

Awkward source headers become import-ready columns.

Rename the columns you need while keeping every value under the correct header.

cust_idcustomer_id

given_namefirst_name

mailemail

✓ Values stay with the right column