TL;DR.<\/strong> A bank statement export (CSV, OFX, QFX) has 30+ fields in 4 tiers: 4 core transaction fields (date, description, amount, balance), 8 transaction metadata fields (type, code, check number, reference, etc.), 12+ account metadata fields (account number, routing, branch, statement date, etc.), and 6 summary fields (opening\/closing balance, total deposits, total withdrawals, fees, interest). The 4 core fields appear in every export; the 25+ others vary by bank and export format. The data types: dates as ISO or US format, amounts as decimal with sign convention, codes as alphanumeric.<\/p>\n<\/blockquote>\n\n The fields on a bank statement are the individual data points that the bank provides about the account and the activity. The fields are organized in a hierarchy: the most important fields (the core transaction fields) appear on every statement; the supporting fields (the transaction metadata) appear on most; the background fields (the account metadata) appear once per statement; the summary fields (the totals) appear at the end.<\/p>\n\n\n What most guides miss about this workflow is that the quality depends on the mechanism, not on the tool. Two tools that look different on the surface often run the same 4-step process underneath: read, find, parse, verify. The difference is in how well each step handles edge cases (merged cells, missing balances, non-standard date formats, scanned vs digital input). Choosing between tools based on UI alone misses the actual quality lever.<\/p>\n\n\n The field hierarchy is the same across all US bank statements, but the specific field names, formats, and order vary by bank. A user who switches banks has to learn the new bank’s field conventions. A user who writes software to parse bank statements has to handle the variation.<\/p>\n\n The information on a bank statement (covered in the what information is on a bank statement<\/a> article) is the conceptual content: the account number, the transactions, the balances. The fields are the specific data points that carry the information.<\/p>\n\n For example, the opening balance is information. The field that carries it is called “Opening Balance” in some banks, “Beginning Balance” in others, “Prior Balance” in others. The information is the same; the field name and format vary.<\/p>\n\n The 4 fields that appear for every transaction on every bank statement.<\/p>\n\n The date the transaction posted to the account. The format varies: “MM\/DD\/YYYY” (US), “YYYY-MM-DD” (ISO), “DD\/MM\/YYYY” (European), or spelled-out (“January 15, 2025”).<\/p>\n\n The data type is date. The value is the calendar date, not the time. The time of day is not included in the bank statement (only the calendar date).<\/p>\n\n For some transactions (checks, ACH), the date the user initiated the transaction may differ from the posting date by 1-3 days. Some banks show both dates; some show only the posting date.<\/p>\n\n The merchant name, payee, or transaction memo. The format varies widely: “STARBUCKS #1234 SEATTLE WA”, “ACH CREDIT FROM ACME CORP”, “CHECK #1001”, “WIRE TRANSFER OUT”.<\/p>\n\n The data type is text (string). The length varies: 20-100 characters typically. The bank may truncate long names.<\/p>\n\n For a bank statement converter<\/a>, the description is the most important field for matching transactions to the user’s records (invoices, bills, receipts).<\/p>\n\n The dollar amount of the transaction. The sign convention varies: most banks use positive for deposit and negative for withdrawal, but some use the opposite, and some use a separate debit\/credit column.<\/p>\n\n The data type is decimal. The precision is typically 2 decimal places. The currency is typically US dollars, but multi-currency accounts may have a different currency.<\/p>\n\n For a converter, the sign convention is the most common source of error. The converter has to know which convention the bank uses and normalize to a single convention for the output.<\/p>\n\n The running account balance after the transaction. Optional in some bank statements, mandatory in others.<\/p>\n\n The data type is decimal. The precision is typically 2 decimal places. The value is the closing balance from the prior transaction plus the amount of the current transaction.<\/p>\n\n For a converter, the balance is the verification field. The sum of the transaction amounts should equal the difference between the closing balance and the opening balance. If it does not, the converter flags the statement for manual review.<\/p>\n From Bank Statement to QuickBooks-Ready File<\/p>\r\n That manual cleanup you just read about? This tool skips it. Turn your PDF into QBO for QuickBooks without storing your data anywhere.<\/p>\r\n Start Converting<\/a>\r\n<\/div><\/div><\/div> The 8 fields that appear for most transactions but vary by bank.<\/p>\n\n A label that identifies the type of transaction: “Deposit,” “Withdrawal,” “Check,” “ACH Debit,” “ACH Credit,” “Wire Out,” “Wire In,” “ATM,” “Fee,” “Interest,” etc.<\/p>\n\n The data type is text. The values are bank-specific.<\/p>\n\n A short alphanumeric code that identifies the transaction: “ACH,” “WIR,” “CHK,” “ATM,” “DBC” (debit card), etc.<\/p>\n\n The data type is text. The codes are typically 2-5 characters.<\/p>\n\n For check transactions, the check number from the check itself.<\/p>\n\n The data type is integer. The value is the check number, typically 4-6 digits.<\/p>\n\n A unique identifier for the transaction, used for tracking and dispute. The format varies: “TXN123456789,” “REF000123,” “20250115-001,” etc.<\/p>\n\n The data type is text. The value is bank-specific.<\/p>\n\n The date the bank processed the transaction. May differ from the transaction date (the date the user initiated the transaction) by 1-3 days for checks and ACH.<\/p>\n\n The data type is date. The format is the same as the transaction date format.<\/p>\n\n The date used for interest calculation. May differ from the posting date by a few days.<\/p>\n\n The data type is date. The format is the same.<\/p>\n\n A unique identifier for the merchant, often the same as the MCC (Merchant Category Code). Used for reconciliation and rewards programs.<\/p>\n\n The data type is integer. The value is typically 4 digits.<\/p>\n\n For multi-currency accounts, the currency of the original transaction (before conversion to the account currency). For US bank accounts, this is usually the same as the account currency.<\/p>\n\n The data type is text (ISO 4217 code: “USD,” “EUR,” “GBP,” etc.).<\/p>\n\n The 12+ fields that appear once per statement, in the header or footer.<\/p>\n\n The unique account identifier. The format varies: 4-17 digits typically. Often partially masked for security (“*<\/em>*1234″).<\/p>\n\n The data type is text. The value is the account number.<\/p>\n\n The bank’s 9-digit routing number (ABA number). Used for ACH and wire transfers.<\/p>\n\n The data type is integer. The value is 9 digits.<\/p>\n\n The type of account: “Checking,” “Savings,” “Money Market,” “CD,” “IRA,” etc.<\/p>\n\n The data type is text. The values are bank-specific.<\/p>\n\n Identifies the specific branch that holds the account. Optional.<\/p>\n\n The data type is text. The value is bank-specific.<\/p>\n\n The date the statement was generated. May differ from the statement period end date by a few days.<\/p>\n\n The data type is date. The format is the same as the transaction date.<\/p>\n\n The cycle number (e.g., “Cycle 1” of the month, or the sequential number of the statement). Used for tracking statements.<\/p>\n\n The data type is integer. The value is the cycle number.<\/p>\n\n The bank’s internal identifier for the customer. Different from the account number.<\/p>\n\n The data type is text. The value is bank-specific.<\/p>\n\n The legal name of the account holder.<\/p>\n\n The data type is text. The value is the customer’s name.<\/p>\n\n The address on file for the account holder. May be omitted for privacy.<\/p>\n\n The data type is text. The value is the address.<\/p>\n\n The name and address of the bank. Standard on every statement.<\/p>\n\n The data type is text. The value is the bank’s information.<\/p>\n\n The phone number for customer service. Required by Regulation E.<\/p>\n\n The data type is text. The value is the phone number.<\/p>\n\n The standard insurance notice. Required by federal regulation.<\/p>\n\n The data type is text. The value is the standard notice.<\/p>\n\n The 6 fields that appear at the end of the statement, summarizing the period.<\/p>\n\n The account balance at the start of the statement period. Equals the prior statement’s closing balance.<\/p>\n\n The data type is decimal. The value is the prior closing balance.<\/p>\n\n The account balance at the end of the statement period. The most important number on the statement.<\/p>\n\n The data type is decimal. The value is the current balance.<\/p>\n\n The sum of all deposits in the period.<\/p>\n\n The data type is decimal. The value is the sum of positive transactions.<\/p>\n\n The sum of all withdrawals in the period.<\/p>\n\n The data type is decimal. The value is the sum of negative transactions (in absolute value).<\/p>\n\n The sum of all fees in the period (overdraft, monthly maintenance, ATM, etc.).<\/p>\n\n The data type is decimal. The value is the sum of fee transactions.<\/p>\n\n The interest earned (or charged) in the period.<\/p>\n\n The data type is decimal. The value is the interest amount.<\/p>\n\n\n A common failure mode bookkeepers report is treating this as a single operation rather than a chain of dependent steps. The temptation is to find a tool that ‘just works’ and stop investigating the mechanism. The result is a wrong-fix cycle: the tool gives partial output, the bookkeeper spends 30+ minutes troubleshooting, the fix is for the wrong step, and the same error recurs on the next statement. The fix: identify which step failed and apply the right intervention to that step.<\/p>\n\n\n The 4 core fields appear in every export, but the field names and formats vary by bank.<\/p>\n\nWhat “Bank Statement Fields” Means<\/h2>\n\n
The 4-Tier Field Hierarchy<\/h3>\n\n
\n
The Difference Between “Fields” and “Information”<\/h3>\n\n
The 4 Core Transaction Fields<\/h2>\n\n
1. Date<\/h3>\n\n
2. Description<\/h3>\n\n
3. Amount<\/h3>\n\n
4. Balance<\/h3>\n\n
![\"Bank](\"https:\/\/easystatementsheet.com\/blog\/wp-content\/uploads\/what-information-is-on-a-bank-statement.jpg\" "\\"\\"")
![\"Bank](\"https:\/\/easystatementsheet.com\/blog\/wp-content\/uploads\/bank-statement-anatomy.jpg\" "\\"\\"")
The 8 Transaction Metadata Fields<\/h2>\n\n
1. Transaction Type<\/h3>\n\n
2. Transaction Code<\/h3>\n\n
3. Check Number<\/h3>\n\n
4. Reference Number<\/h3>\n\n
5. Posting Date<\/h3>\n\n
6. Value Date<\/h3>\n\n
7. Merchant ID<\/h3>\n\n
8. Original Currency<\/h3>\n\n
The 12+ Account Metadata Fields<\/h2>\n\n
1. Account Number<\/h3>\n\n
2. Routing Number<\/h3>\n\n
3. Account Type<\/h3>\n\n
4. Branch Code<\/h3>\n\n
5. Statement Date<\/h3>\n\n
6. Statement Cycle<\/h3>\n\n
7. Customer ID<\/h3>\n\n
8. Account Holder Name<\/h3>\n\n
9. Account Holder Address<\/h3>\n\n
10. Bank Name and Address<\/h3>\n\n
11. Customer Service Phone<\/h3>\n\n
12. FDIC\/NCUA Notice<\/h3>\n\n
The 6 Summary Fields<\/h2>\n\n
1. Opening Balance<\/h3>\n\n
2. Closing Balance<\/h3>\n\n
3. Total Deposits<\/h3>\n\n
4. Total Withdrawals<\/h3>\n\n
5. Total Fees<\/h3>\n\n
6. Total Interest<\/h3>\n\n
How the Fields Vary by Bank<\/h2>\n\n
Field Name Variations<\/h3>\n\n