When finance teams process hundreds of payments each month across different bank branches, manual tracking becomes a liability. Errors in account numbers, missing routing codes, or incorrect payment formats lead to failed transactions and delayed vendor payments.<\/p>\n
Bank account setup in ERP systems<\/a> eliminates these risks by centralizing all bank-related information in one place. Each account includes validated routing numbers, IFSC codes, and SWIFT codes for international transfers. When payment batches run, the system pulls accurate bank details automatically, reducing manual data entry and the errors that come with it.<\/p>\n The configuration also enables automated check sequencing. Instead of tracking checkbook numbers in spreadsheets, the system manages multiple checkbooks per account, assigns priority levels, and selects the correct sequence when generating checks. This prevents duplicate check numbers and maintains proper audit trails.<\/p>\n Linking payment classes and statement classes to specific accounts streamlines batch payment processing. Once configured, the system generates payment files in the exact format your bank requires, without manual file creation. Statement loading becomes equally automated, matching incoming transactions to existing records and flagging unreconciled items immediately.<\/p>\n Clear organizational structure matters when operating multiple entities. Defining which bank accounts belong to which organization prevents transaction posting errors and keeps financial records clean across subsidiaries or business units.<\/p>\n Bank headers store branch-specific information that makes each account unique. When a company maintains accounts at multiple branches of the same bank, each branch gets its own header record. This separation matters because routing numbers, IFSC codes, and branch addresses differ even within the same banking institution.<\/p>\n The header captures essential identifiers: routing numbers for domestic transfers, IFSC codes for transactions within certain countries, and SWIFT codes for international payments. These codes ensure payments route correctly through banking networks without manual intervention.<\/p>\n Address details include the physical branch location. This information appears on checks and wire transfer documentation, helping recipients and intermediary banks verify transaction authenticity.<\/p>\n Bank verification classes apply validation rules during transactions. If you define a verification class at the tenant level, it applies to all banks unless overridden at the individual bank level. This centralized control prevents invalid account configurations from causing payment failures.<\/p>\n Marking a bank as owned activates it for transactions. Until you enable this setting, the bank and its accounts remain invisible in transaction screens. This control lets you configure everything before making the account available to users processing payments.<\/p>\n Each bank account record includes operational details that govern how payments flow through the system. The account number links directly to your actual bank account. Account type selection determines available transaction types: checking accounts support standard payments, credit card accounts handle corporate card reconciliation, savings accounts manage reserve funds, and letter of credit accounts facilitate trade finance.<\/p>\n Currency assignment matters for multinational operations. Defining the account currency ensures exchange rate calculations apply correctly when processing payments in different denominations. Credit limits set boundaries on how much can be spent or transferred from each account, preventing overdrafts.<\/p>\n Opening balances bring historical data into the system. When migrating from another platform or going live mid-period, entering the current balance ensures reconciliation accuracy from day one. IBAN numbers support multi-country operations, especially when dealing with European banking systems that require this standardized account identifier.<\/p>\n Check number control manages checkbook sequences automatically. When you receive a new checkbook from your bank, you enter the starting and ending check numbers into the system. If you have multiple checkbooks for the same account, priority settings determine which one the system uses first. This prevents gaps in check sequences and maintains proper numerical order.<\/p>\n Bank account documents track each checkbook separately. You can see which checkbook is currently active, how many checks remain, and when you need to order a new one. Payment method linkage determines which processes apply when generating payments from this account, connecting operational settings to actual payment execution.<\/p>\n Payment classes define the structure of files sent to your bank for batch processing. Each bank requires payment files in specific formats with particular column arrangements and data validations. Payment class configuration<\/a> matches these requirements exactly, ensuring files the system generates meet bank specifications without manual reformatting.<\/p>\n The class itself is written in code and linked to specific payment methods and bank accounts. When you process a payment batch and mark it complete, the system uses the linked payment class to generate a CSV file containing all payment details. The file includes only the columns your bank expects, in the order they require, with data formatted according to their rules.<\/p>\n This automation eliminates manual file creation. Without it, someone would need to export payment data, rearrange columns, reformat dates and amounts, and manually construct the file each time. With payment class configuration<\/a> in place, the system handles this automatically after each batch closes.<\/p>\n Multiple payment methods can share the same payment class if file formats are consistent. For example, if your bank uses the same file structure for ACH payments and wire transfers, you can link both payment methods to one class. If formats differ, you create separate classes for each method.<\/p>\n Statement classes work in reverse compared to payment classes. Instead of generating files to send to the bank, they define how to import files received from the bank. Each bank provides statement data in different CSV formats with varying column structures, date formats, and transaction descriptions.<\/p>\nSetting Up Bank Headers and Branch-Level Details<\/h2>\n
Configuring Bank Accounts with Payment Controls<\/h2>\n
Linking Payment Classes for Automated File Generation<\/h2>\n
Statement Classes and Reconciliation Workflow<\/h2>\n